Back to Insights
5 min read • Data residency

Where the data lives when an AI layer answers your customers

Every conversation about an AI layer in a clinic, a law practice or a rental agency reaches the same question within ten minutes, and it is never about the model. It is: where does our data go?

The honest answer is longer than the question, so most vendors avoid it. This memo gives the answer the way we give it on a scoping call, because an owner who understands it signs faster and sleeps better than one who was told "it's secure".

The four places data can be

When an inbound message, a call recording or a booking request passes through an AI layer, it can sit in four places. Only one of them is usually discussed.

  1. Your own systems. The mailbox, the calendar, the phone system, the CRM. The data is already there and stays there. The AI layer reads from these and writes back into them. Nothing new is created outside your walls.
  2. The processor's region. The servers that run the drafting and classification. For an EU client this is an EU region; for a South African client it is a region we name in writing, with the POPIA position stated. The processor is named in the proposal, not described as "the cloud".
  3. The model provider. The frontier model that handles the judgment steps. This is the place everyone worries about, and the one with the clearest contractual answer: the business tier of every provider we use carries a no-training clause. Your data is processed to produce an answer and is not used to improve the model.
  4. Nowhere. A growing share of the work does not need a frontier model at all.

That fourth place is the one worth understanding.

Two kinds of work, two kinds of model

An AI layer that triages a support inbox or classifies incoming calls does two different jobs. The first is high-volume and shallow: is this a booking, a cancellation, a complaint, a supplier invoice? Which language? Is the sender already a customer? This is classification, and it happens hundreds of times a day.

The second is low-volume and deep: draft the reply to the family asking about a care plan; summarise the twenty-minute call into the four fields the coordinator fills in; decide whether this message needs a human before anything else happens. This is judgment, and it happens a few dozen times a day.

The two jobs do not need the same model. Classification runs well on open-weight models, and open-weight models can run inside your own infrastructure or inside the processor's EU region with no call to a third party at all. Judgment steps go to a frontier model, under the no-training terms above, and only the content needed for that step is sent.

We call this hybrid routing. In practice it means that for most clients the majority of messages never leave the region, and the minority that do are the ones where a human will read the output anyway.

What a human still does

Every reply the layer drafts is sent by a named person. That line is not a safety disclaimer; it is the design. The audit trail shows who approved what, and that trail is what compliance officers and insurers ask to see. A model that "resolves end-to-end" has no such trail, which is why we do not build that way.

It also means data access is bounded by people, not by the system. The coordinator who could already read the patient register is the one who sees the summary. Nobody new gets access because an AI layer exists.

The agreement that makes it real

Three documents turn the paragraphs above into something you can hold us to.

The data processing agreement names the processor, the region, the categories of data, the retention period and the sub-processors. For EU clients it follows Article 28 of the GDPR; for South African clients it states the POPIA position. We provide the draft; your counsel reviews it. We do not give legal advice and we say so.

The access checklist lists every system the layer will read from and write to, and the permission level for each. Nothing is connected without a line on that list being approved.

The proposal states where the data lives, in the same words as the DPA, on the page before the price. If a proposal you receive from anyone puts the price before the data paragraph, ask why.

The questions to ask any vendor

If you are evaluating an AI layer from us or from anyone else, these five questions separate a real answer from a reassuring one.

  1. Where exactly is the processing region, and can you name the provider?
  2. Which steps go to a frontier model, and under which terms?
  3. Which steps could run inside our own infrastructure if we asked?
  4. Who signs the DPA on your side, and when, relative to the start date?
  5. Who sends the reply to our customer: the system, or a person we employ?

A vendor who answers all five in writing before the kickoff is one you can work with. A vendor who answers "it's all encrypted" has answered a different question.

Where this lands in practice

A Proof Sprint takes about two weeks and starts with the access checklist and the DPA, not with the model. By the end of it you have a working layer on one channel, a written record of where every byte went, and a person on your team who has approved every draft for two weeks and can tell you what the layer gets wrong. The guarantee is the same for every client: Measurable ROI in 90 days — or 50% of your project fee back.

If you run a clinic, a practice or an agency and want the four-places answer for your own stack, the free 15-minute audit is the place to start. Bring the name of the one inbox or phone line that costs you the most time; we will tell you where its data would live, and what it would take to make that true in writing.

Want the four-places answer for your own stack?