GDPR-compliant AI agents.

Where your data actually goes

The default is an EU-resident inference endpoint (Azure Sweden Central) with zero retention, contractually excluded from training. Nothing is kept, and nothing you send improves somebody else’s model.

That is the default, not the ceiling. The same agent runs unchanged in your own cloud tenant, in a network-isolated private endpoint, or entirely on your own hardware — and you can move between those later without a rebuild. Four tiers, described in full on where it runs.

Bound by professional secrecy? § 203 StGB doesn’t bend for AI

For lawyers, tax advisors and doctors this is not a policy preference, it is criminal law. Run privileged client data through a consumer chatbot and you can breach § 203 StGB — and the fact that the tool was convenient is not a defence.

The engineering answer is narrow and it works: keep that data on an EU-resident, zero-retention endpoint under a proper processing arrangement, or never let it leave your own hardware at all. The duty of confidentiality stays intact. That is the line between an AI you are not allowed to use and one you are — and it is a deployment decision, not a prompt.

This is also why the on-premise tier exists rather than being a talking point. For some practices it is the only tier that qualifies.

The four articles we engineer

• Art. 25

  Privacy by design

  Data minimisation, access control, and technical and organisational measures built into the agent — not a policy written after the fact.

• Art. 17

  Deletion, engineered

  The right to erasure works because it is built: retention windows and archive-then-purge, the same data lifecycle that runs our own products.

• Art. 28 · 35

  The paperwork, as a by-product

  A ready data-processing agreement, and the technical input your DPIA and your data-protection officer ask for — produced by the build, alongside the AI-Act evidence.

• EU-resident

  Your data stays in the EU

  EU-hosted, EU-resident inference, zero retention, never used for training. On request, in your own cloud or fully on-premise.

Engineering, not legal advice

Your data-protection officer or lawyer takes the legal position. What we produce are the artifacts that position has to stand on: the processing arrangement, the technical measures, the deletion lifecycle, and the DPIA input. Those are engineering deliverables, and getting them wrong is an engineering failure — which is the part we own.

Questions

Is our data used to train the model?

No. The default endpoint is zero-retention and excluded from training. On the on-premise tier the question does not arise, because nothing leaves the building.

Can we keep everything inside our own infrastructure?

Yes — open-weight models on your own hardware, with no external call made at all. See the four deployment tiers.

Do you provide a DPA?

Yes, a ready Art. 28 data-processing agreement plus the technical input for your Art. 35 DPIA, produced by the build.

What about the AI Act — is that separate?

Related, and best done in one pass. The Act governs the system, the GDPR governs the data, and almost every agent triggers both. Doing them separately means doing the same analysis twice — see EU AI Act compliance.

We are a Kanzlei / tax practice. Where do we start?

With the deployment tier, before the use case. Establish which tier your confidentiality duty permits, and the rest of the design follows from it. Write to me and say what data is involved.