inxo.ioPreview
Start free

Data Processing Addendum

Effective 2026-09-10

inxo — Data Processing Addendum

Version 2026-09-10. Several provisions are marked [counsel] where the choice is a legal determination rather than a description of how the system behaves.

This Data Processing Addendum (“DPA”) forms part of the Terms of Service between No Compromise AI, LLC (“Processor”, “we”) and the customer organization (“Controller”, “you”). Where this DPA and the Terms conflict on the processing of personal data, this DPA governs.

1. Roles

You are the controller of the personal data contained in the mail we process for you. We are the processor, acting only on your documented instructions.

Where you are yourself acting as a processor for your own client — an agency or managed-service arrangement — you are that client’s processor and we are their sub-processor. In that case you warrant that you hold your client’s authority to give us the instructions in this DPA on their behalf.

One account may span more than one controller. A connection whose Microsoft tenant is not your own organization’s tenant is treated as a different controller, and your account-level acceptance does not authorize it. Such a connection cannot begin processing until instruction evidence exists for that controller specifically. This is enforced by the system, not by policy: activation is refused without it.

2. Your instructions

Your acceptance of this DPA is your documented instruction to process personal data as described here, and it is recorded as such — the acceptance record and the processing instruction it creates are written together, so the authority we rely on is an actual record rather than an inference.

We process personal data only:

  • to provide the Service as described in the Terms and the documentation;
  • on your further documented instructions, including through your configuration of the Service; and
  • where required by law, in which case we will tell you first unless the law forbids it.

We will tell you if we consider an instruction to infringe data protection law.

3. Subject matter and details of processing

  • Subject matter: provision of the inxo email-response service.
  • Duration: for the term of the Terms, plus the retention periods in §7.
  • Nature and purpose: receiving, threading, classifying and storing email; generating draft replies using a language model; storing the knowledge-base entries you author, converting them into search vectors, and searching them when a reply is drafted so the passages found are given to the model alongside the conversation; sending messages you approve or that your configured automation sends; and maintaining audit records of those acts.
  • Categories of data subject: your personnel who use the Service; the people who send mail to the mailboxes you connect; and third parties named within the content of that mail.
  • Types of personal data: email content, email addresses and display names, thread and delivery metadata, end-user identifiers, and any personal data your correspondents choose to include in what they write.
  • Special categories: not required by the Service and not requested. Because we process inbound mail as it arrives, we cannot prevent a correspondent from including such data in a message. It is subject to the same measures as all other content. [counsel: whether an explicit exclusion or an acknowledgement of incidental receipt is the right treatment.]

4. Confidentiality

Personnel authorized to process personal data are bound by confidentiality obligations and are granted access only as their role requires.

5. Security (Art. 32)

We implement the technical and organisational measures described in Annex II. In summary: encryption in transit and at rest; secrets held in a managed key vault and never in our database or configuration; database-level tenant isolation such that a query which omits its tenant scope returns nothing; append-only audit records the application cannot modify or delete; and least-privilege access to production.

6. Sub-processors (Art. 28(2), 28(4))

You give general authorization for the sub-processors listed in Annex III and published in our sub-processor register.

Before a new sub-processor begins processing, we notify account administrators in advance, by email and in the Console, and you may object within the stated window. If you object, you may pause the affected processing or terminate the affected service without penalty.

A change to the register does not require you to re-accept this DPA and does not interrupt your service pending a click. Each sub-processor is bound by data protection obligations no less protective than these, and where a sub-processor fails to fulfil its data protection obligations we remain fully liable to you for its performance of them.

7. Deletion and return (Art. 28(3)(g))

  • On disconnection of a mailbox, we delete the content we hold for that connection.
  • On termination, at your election we either delete the personal data we hold for you or, on your written request made before the end of the term, make it available for export in a structured, commonly used format and delete our copies afterwards — save where law requires retention. We offer the choice because Article 28(3)(g) is a choice; in practice most of the content already lives in your own mailbox, but drafts, classifications and the approval record exist only here.
  • Retention while in service, which differs by kind:
    • Message and thread content is retained for the life of the mailbox connection. There is no time-based expiry on it; it is deleted on disconnection, on termination, or on a valid erasure request.
    • Drafts are pruned 30 days after the conversation closes, adjustable per workspace within a 30-to-90-day range — 30 is a floor, not a default that can be lowered.
    • Knowledge-base entries you add have no time-based expiry at all — unlike drafts, they persist while the entry exists, because they are content you authored rather than a by-product of a conversation. They are deleted when you delete them, when the workspace closes, or when the last mailbox connection for that data controller is disconnected — the last, not the first, so removing one mailbox never destroys knowledge the others still rely on.
    • Audit and compliance records are retained for a minimum of one year, as evidence of what was approved and sent, and are not in the erasure set.
    • Backups are point-in-time and roll off on a bounded cycle (currently seven days), which is the documented outer limit on how quickly a deletion becomes irreversible everywhere.
  • What a drafted reply may draw on from your knowledge base, and the limits on it. From this version, drafting searches your knowledge base and passes matching passages to the model with the conversation. Three limits apply and each is enforced in the service rather than intended. The search is scoped to your workspace and the specific data controller whose mailbox the message arrived on — so where you hold mailboxes for several client organizations, one client’s entries are never read while replying on another’s mail, and where the controller cannot be determined nothing is retrieved. The number of passages and their total size are capped, so what a draft discloses to the model does not grow with your knowledge base. And a draft that could not search — no entries, budget spent, endpoint unavailable — falls back to the conversation alone and records that it did, rather than silently producing a less-grounded reply. Because a knowledge base is shared across every conversation in a workspace, a passage written while handling one data subject may be matched while replying to another. So every reply written using the knowledge base is put to a person for review — automatic sending is withheld for all of them, rather than only for those a check flags, because a check over the wording is the part an attacker able to place text in a knowledge base would be influencing. Where a reply does repeat personal data traceable to a passage, the reviewer is shown its source.
  • A limitation on erasure inside the knowledge base, stated rather than discovered. We find a data subject in mail by an index over the structured, address-bearing fields — sender, recipient, and so on. A knowledge-base entry is free text you wrote, and we do not index it that way, so we cannot yet prove we have found every mention of a person inside it. We will not paper over that with a best-effort search: while a workspace holds any knowledge-base content — or a live reply draft that was written from it — an erasure request for that controller is held rather than reported complete, and you can act on it immediately by deleting the entries concerned — a per-entry delete is available on the API today. The draft half matters because deleting an entry does not delete a reply already written from it: that reply’s text is free text too, and holding only on the entry would let us certify a completion over a copy we had not looked at. An UNSENT draft clears itself when its content is swept under the retention window in §7; a reply that was sent keeps a copy in the conversation, so its hold clears when that conversation’s content is deleted — on disconnect, at workspace closure, or when you delete the thread. We would rather hold an open request than hand you a completion certificate we cannot stand behind. This limitation lifts when deterministic knowledge-base discovery ships.
  • Erasure by us reaches our copy. Your Microsoft 365 mailbox is yours and is your system of record; Microsoft is your processor for it, not our sub-processor, and any erasure obligation you owe a data subject in respect of that mailbox remains yours to discharge. Stated precisely, because the difference matters: the administrative permission you grant at connect time does include the ability to move a message to your Deleted Items — it is requested so that offboarding can remove what the Service put there — but no part of the Service exercises it today, and we will tell you before that changes.

8. Data subject rights (Art. 28(3)(e))

We assist you, by appropriate technical and organisational measures and insofar as possible, in responding to data subject requests. Where a data subject approaches us directly about data we process for you, we refer them to you and do not act without your instruction.

Erasure and access requests are scoped to the directing controller. In a managed-service arrangement, a request from one of your clients reaches that client’s data and no other client’s.

9. Assistance (Art. 28(3)(f))

We assist you with data protection impact assessments, prior consultation, and security incident notification, taking into account the nature of processing and the information available to us. We notify you without undue delay after becoming aware of a personal data breach affecting your data, with the information available at the time — describing the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. [counsel: whether to commit to a fixed outer bound in hours, which must not be shorter than the incident-response runbook can actually meet.]

10. Audit (Art. 28(3)(h))

We make available the information necessary to demonstrate compliance with this DPA and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate. [counsel: frequency, notice, confidentiality and cost allocation.]

11. International transfers

All personal data STORED under this DPA is stored in a single United States region — we operate one deployment, we do not offer Controller a choice of region, and every shard, replica and backup stays in that region (Annex III). This is a statement about storage and not about every processing operation: the model calls described in Annex III run against separately pinned targets which may sit elsewhere, and on one provider path may be outside Microsoft’s infrastructure altogether. For personal data whose processing under this DPA originates in the EEA, the UK or Switzerland, our storage of it is itself an international transfer, before any question of where a model call separately runs — stated because we cannot offer a customer an EU or UK deployment, and we would rather say so here than let the separate model-call carve-out read as though storage were the safe part.

Where processing involves a transfer of personal data out of the EEA, the UK or Switzerland, the transfer is governed by the European Commission’s 2021 Standard Contractual Clauses, incorporated by reference, together with the UK International Data Transfer Addendum where the UK GDPR applies. Each transfer is supported by a transfer impact assessment for that specific flow, with the applicable supplementary measures.

A transfer impact assessment is maintained per pinned target — per {provider, model, region} combination — and re-assessed before a new combination is enabled, rather than written once for all present and future targets. Posture varies by target, so one assessment cannot cover them all.

We do not rely on the EU-US Data Privacy Framework as a transfer mechanism. [counsel: if No Compromise AI, LLC self-certifies, restate this as supplementary; as drafted it must not imply an option that does not exist.]

[counsel: module selection. Module Two where you act as controller and we as processor; Module Three where you are a processor for your own client, and for our onward transfers to sub-processors. Both arise in the product’s tenancy model.]

Model inference is the transfer that matters most, and on every path it is not yet permitted. Which agreement is required depends on which model the workspace is pinned to. Where the model is one Microsoft itself sells and hosts (our Foundry-OpenAI path), Microsoft is the processor and the required agreement is the one described in Annex III. Where the model is a Claude model (our Foundry-Claude path), Anthropic, PBC is an independent processor, not a Microsoft-internal boundary, and requires its own agreement — carrying no-training and a separately verified retention commitment where available — distinct from whatever covers the Microsoft-hosted path. Neither agreement has been executed, and until each is, together with its own transfer impact assessment, your mail is not sent to that path’s model at all: the workspace receives and threads mail and does nothing else with a model. Neither drafting nor classification runs, because both are model calls. This is enforced by a fail-closed readiness check keyed to the specific provider, model and region — separately, for each of the two paths.

12. California (CCPA/CPRA service-provider rider)

For personal information subject to the CCPA as amended:

  • We act as a service provider. We do not sell or share personal information as those terms are defined, and we will not.
  • We process personal information only for the business purpose of providing the Service under our written contract with you, and not for any commercial purpose of our own, nor for cross-context behavioural advertising.
  • We will not retain, use or disclose personal information outside the direct business relationship, and will not combine it with personal information from another source except as permitted.
  • We will comply with applicable obligations and provide the same level of protection.
  • You may take reasonable and appropriate steps to stop and remediate unauthorized use.
  • We certify that we understand the restrictions in Cal. Civ. Code §1798.140(ag) and will comply with them.
  • We do not use sensitive personal information for any purpose beyond the business purposes permitted by Cal. Civ. Code §1798.121. We do not request it; inbound mail may contain it.
  • Your right to take reasonable and appropriate steps to stop and remediate unauthorized use includes the audit rights in §10.
  • We notify you if we determine we can no longer meet these obligations.

Other US state privacy laws. The obligations in this DPA are intended to satisfy, and should be read to satisfy, the analogous processor obligations under other applicable US state consumer privacy laws, including the Virginia CDPA, Colorado CPA, Connecticut CTDPA and Utah UCPA.

13. Order of precedence

In the event of conflict, in this order: the Standard Contractual Clauses where they apply, then this DPA, then the Terms — as to the processing of personal data.

Annex I — Parties and description of processing

Data exporter: the customer organization accepting this DPA, acting as controller (or as processor for its own client). Data importer: No Compromise AI, LLC, acting as processor (or sub-processor). Contact details, and any Article 27 representative, to be completed.

The categories of data subject, types of personal data, nature, purpose, duration and frequency of processing are as set out in §3. Processing is continuous for the term.

Annex II — Technical and organisational measures

  • Encryption in transit and at rest.
  • Secret management: credentials and signing material held as references into a managed key vault, resolved by workload identity; never stored as database columns or configuration values.
  • Tenant isolation: every record carries its account; a query that omits the tenant predicate returns no rows rather than another tenant’s rows. Enforced at the data layer with a test that must pass on every change.
  • Access control: least-privilege, permission-scoped credentials; separate credential classes for people and for automated agents, with the higher-risk operations available to neither by default.
  • Audit: records of configuration changes, approvals and sends are append-only, and the database enforces it: the application’s role is denied UPDATE and DELETE on those tables, so an application-level compromise cannot rewrite the record of what it did. Deployment caveat, stated rather than assumed: this separation is applied by a privileged database step, and the external tamper-evidence anchor is a separate control. Until both are deployed in a given environment, the guarantee is the code’s rather than the database’s. We will not represent the stronger form as being in force before it is.
  • Content containment: inbound mail is treated as untrusted data throughout — hidden HTML stripped before model input, and rendered to reviewers in a sandboxed frame.
  • Egress control: outbound requests are validated on every attempt and every redirect hop against internal and metadata address ranges.
  • Fail-closed preconditions: a missing safety precondition disables the capability rather than degrading it — including the model-provider readiness check that blocks drafting entirely until the provider terms are in force.
  • Data minimisation to the model: attachments are never sent; hidden content is stripped; context is bounded; and the model’s output is confined to a message body, with recipient, subject, sending address, language and AI marking applied by the system.
  • Tested, not merely implemented: these measures are regularly tested, assessed and evaluated for effectiveness — each one above is held by an automated gate that fails the build, rather than by a periodic self-assessment.

Annex III — Sub-processors

As published in the sub-processor register, which is versioned and carries advance change notification. At this version:

Sub-processor Purpose Location
Microsoft Corporation — Azure Hosting and managed data services A single United States region — currently Microsoft’s Central US region. One deployment; no region election is offered. Every shard, replica and backup stays in that region — no cross-region replica. For a Controller established in the EEA, the UK or Switzerland, this storage is itself an international transfer (§11).
Microsoft Corporation — Azure AI Foundry Model inference for drafting and classification, when the workspace is pinned to a model Microsoft itself sells and hosts (our Foundry-OpenAI path — Microsoft is the sole processor on that path); text embedding for the knowledge base, both when you save an entry and when an incoming message is used as a search query while drafting (embedding always runs through this entry, on every path) The region pinned on the workspace’s provider-readiness record — separately pinned for embedding; not necessarily the region above
Anthropic, PBC Model inference for drafting and classification, only when the workspace is pinned to a Claude model on Azure AI Foundry (our Foundry-Claude path). Claude on Foundry is a Marketplace offering Anthropic — not Microsoft — sells and operates; Anthropic is an independent processor for the prompts and completions sent to it, and Azure OpenAI’s zero-data-retention commitments do not extend to it. Microsoft separately shares Controller’s contact information, transaction details and usage volume with Anthropic to operate the offering. Automatic safeguards may flag content for human review by Anthropic’s Trust and Safety team, on an exceptions-only basis Depends on the hosting option recorded on the workspace’s provider-readiness record: on Azure infrastructure, in the region above for that call; or on Anthropic’s own infrastructure, which Microsoft states may be outside Azure and outside that region entirely

This determination has now been made (previously recorded here as open). On our Foundry-OpenAI path, Microsoft is the sole processor and no further vendor receives your data. On our Foundry-Claude path, Anthropic, PBC is a further, independent sub-processor, recorded above with its own entry. The determination did not require execution of the model-provider terms — it turns on how Microsoft’s two model-sale shapes work, which Microsoft documents regardless of our own contract status. What is still required, on both paths, is execution of that path’s own agreement and transfer impact assessment before any customer mail reaches it — see §11 and the fail-closed readiness check. Nothing above authorizes sending mail to either model today.