Your German office is bound by German criminal law. Your AI supply route has to answer for it.

§ 203 StGB binds everyone admitted to practise in Germany, whatever the firm's letterhead says. What decides admissibility is not which model you use - it is who you obtain it through, and what that chain has signed.

Book a conversation The eight-link chain

Why an international firm ends up in German criminal law

Most AI governance material written for law firms is about confidentiality as a professional duty. In Germany it is also a criminal offence. § 203 of the German Criminal Code makes the unauthorised disclosure of a client secret punishable, and the duty attaches to the individual admitted to practise - the partner in your Munich or Frankfurt office - not to the firm that employs them.

That produces a procurement problem specific to multi-jurisdiction firms. A tool selected centrally, contracted centrally and rolled out network-wide can be perfectly sound in every other office and inadmissible for the German one. And because the obligation runs down the chain, infrastructure operated elsewhere in your own group - a shared service centre, a nearshore development team, a group data platform - becomes part of what § 203 asks about the moment German matter data reaches it.

This track sets out what the German practice has to be able to show: the eight links between a matter and a model, the eight questions to put to any provider, and the sample instruments that carry them.

An intent-only offence, two professional-body positions, no case law

The precision first, because the German market is full of overstatement in both directions. § 203 StGB is an intent-only offence, and under § 205 StGB it is prosecuted only on complaint. Careless use of an AI tool is not automatically a crime, and the widespread framing of "AI chat with client data equals criminal offence" shortens the legal position. It stays serious nonetheless: what is at stake is the client secret, the professional rules, and the question of to whom the firm can evidence its diligence.

Who decides whether a cloud AI service is admissible? No court has ruled on it. Two professional-body positions sit side by side, and a serious provider names both.

Position Core statement Consequence for the firm
DAV, opinion SN 32/2025 Service providers may be engaged without client consent in so far as necessary (§ 43e Abs. 1 BRAO, § 203 Abs. 3 S. 2 StGB); reasonable and appropriate safeguards limit knowledge to what is necessary. There is no duty to exclude access technically. Cloud AI is workable where necessity is reasoned, the chain is obligated and knowledge is technically limited.
BRAK, AI guidance 12/2024 More conservative: the mere possibility of the provider taking cognisance is already problematic. The contractual line - the Abs. 4 obligation, closed systems - carries more weight; technical arguments alone do not satisfy the chamber's reading.

For tax advisers there is a further chamber layer: the Federal Chamber of Tax Advisers has set out its requirements for outsourcing and consent in its AI FAQ (as at 01/2026), and § 62a StBerG requires the client's express consent for matter-related outsourcing. Anyone selling you an AI service without distinguishing these positions is selling you an unexamined risk.

This is also why our answer does not rest on one reading of the law. The interpretation has not been conclusively settled by the courts, so the offer rests on a contract and technology chain built to hold up under the stricter reading as well - not on the more favourable opinion being right.

Sources: DAV opinion SN 32/2025 (anwaltverein.de), BRAK guidance on AI use, as at 12/2024 (brak.de), BStBK FAQ on AI use (bstbk.de); each retrieved 22 July 2026.

Eight links, none of them optional

A provider claim of "§ 203-ready" is not something you can verify by trusting it. You need a grid. The chain is that grid: eight links of contract and configuration that together carry the supply route. Each is verifiable on its own - as a document, as a configuration record, or as a named responsibility. If one is missing, the whole claim hangs in the air.

  1. The data processing agreement under Art. 28 GDPR
  2. The secrecy obligation under § 203 Abs. 4 Satz 2 Nr. 1 StGB
  3. The sub-processor chain, obligated at every stop
  4. The provider itself as an obligated link
  5. EU region and data zones - the deployment type, not the continent
  6. Third-country transfer and the professional-law foreign-service bar, assessed separately
  7. Training exclusion and a retention matrix per data type
  8. Client consent and transparency under Art. 13/14 GDPR

Each link in full, with its test question and the form of proof - and, as a working document for provider conversations, the same eight as a checklist.

Four audited supply routes

Admissibility is never a property of the model. It is a property of the combination of model and supply route. The same model can be sound over one route and uncovered over another. Four routes have been examined contractually and technically:

Route 1 - Microsoft Azure: the contractual line

Microsoft operates a standardised secrecy addendum for professionals bound by secrecy, concluded between customer and Microsoft. It is signed firm by firm - each connection is its own contractual matter with its own term. The publicly documented scope is Microsoft 365; for the Azure models Microsoft refers to case-by-case clarification. For our contractual line that clarification has been carried through to signature and covers the Azure models, so the firm does not negotiate the scope itself. An EU-only deployment is mandatory. CLOUD Act exposure remains on this route, which is why the transfer impact assessment is a mandatory part of the chain rather than an optional extra.

Source: Microsoft Learn documentation (secrecy addendum for professionals bound by secrecy, abuse-monitoring eligibility, deployment types); retrieved 22 July 2026.

Route 2 - Google Vertex: contractual and technical line

For the Google route our contract chain is signed - a firm does not need to run its own contractual matter with Google. Instrument and scope are disclosed on request. Separate from that is the technical line: that no prompts are stored for our own Google Cloud project rests on a separately approved exception which sits externally with Google and is bound to the project. The reference configuration is deliberately set to maximum non-persistence: EU endpoint, no caching, no abuse monitoring. Deployments in a customer tenant need their own exception per project; we accompany that application as part of the service.

Claude Opus, Claude Sonnet and Claude Haiku are obtainable over the same platform - with no storage, EU endpoints and no content access by Google or Anthropic. That is more remarkable than it sounds: these are the current frontier models, not a stripped-down public-sector variant. The honesty runs the other way too: Claude Fable and Claude Mythos cannot, as things stand, be obtained over any of the audited routes in a form suitable for work under § 203 - we state that rather than pass over it. Model classes whose terms provide for multi-week prompt retention and mandatory data sharing with the model provider are blocked for secrecy-bound workloads here.

Sources: Google Cloud documentation (data governance, abuse monitoring, Cloud Data Processing Addendum), Anthropic documentation (Claude on Vertex AI); documentation retrieved 22 July 2026.

Route 3 - open models at an EU operator with no US parent

EU inference of open models at a European operator with no US parent company. The CLOUD Act question falls away structurally and the professional-law foreign-service bar is not engaged. Eight models are on offer: Llama, Mistral, Qwen, Apertus, Gemma, GPT-OSS, DeepSeek and Kimi. The § 203 addendum with the operator is signed, as is the reseller agreement: secrecy obligation in text form with notice of criminal liability, and onward obligation of that operator's sub-contractors.

Route 4 - the same chain, with the machine in Germany

A standardised § 203 secrecy agreement has existed since 2021 for a provider operating from German data centres. We have signed it, including its application to the AI Foundation Services, where DeepSeek R1, Llama and Mistral Small run managed behind an OpenAI-compatible API.

Source: our operator in German data centres / T-Cloud public documentation (AI Foundation Services); retrieved 22 July 2026.

Redaction and pseudonymisation sit in front of all four routes as data minimisation and a second line of defence. They are not a condition of compliance under § 203 - the legal line is carried by the obligation and the contract chain.

The documents, before the conversation

Anyone assessing an AI supply route under German professional secrecy runs into a procurement problem: the documents that decide the question usually arrive only once you are already inside a sales process. Here it is mostly the other way round. Five of the seven sample instruments are open on the web, with no form and no email address, so that the assessment can happen before the conversation - and so that it can be run against other providers too.

What each of the seven documents does, and why the operative text is in German while this commentary is in English.

Questions we get from international firms

Does § 203 StGB apply to our London or New York office?

Not directly - but it applies in full to anyone admitted to practise in Germany, and that is the person sitting in your German office. § 203 StGB attaches to the individual professional, not to the firm. Two consequences follow for a multi-jurisdiction firm. First, a group-wide AI rollout that is fine for the rest of the network can be inadmissible for the German practice, and the decision is not the German partner's alone once the tooling is procured centrally. Second, if matter data from the German office is processed on infrastructure procured elsewhere in the group, that infrastructure becomes part of the chain § 203 asks about.

Are our people outside Germany exposed?

They can be. Since the 2017 reform, § 203 Abs. 4 Satz 1 StGB makes the assisting person - the external IT provider, the shared service centre, the group's own infrastructure team - criminally liable in their own right for unauthorised disclosure. The German professional must obligate them under § 203 Abs. 4 Satz 2 Nr. 1 StGB; the professional rules require text form and an express notice of criminal liability (§ 43e BRAO, § 62a StBerG, § 50a WPO). A confidentiality clause in an employment contract or a standard DPA is not that instrument.

Is a DPA under Art. 28 GDPR enough?

On the prevailing view, no. The DPA satisfies Art. 28 GDPR. It does not replace the obligation under § 203 Abs. 4 Satz 2 Nr. 1 StGB, which binds the assisting person to secrecy and is backed by that person's own criminal liability under § 203 Abs. 4 Satz 1 StGB. There is a counter-view - since § 203 requires no form beyond text form and every DPA carries a confidentiality clause, the DPA might already satisfy the criminal-law requirement (Keiper, tax & bytes / NWB, 22 July 2026, retrieved 26 July 2026). The author labels it a teleological reading without supporting commentary or case law. We sign the separate instrument anyway: an unresolved question of interpretation is not a sound basis for a firm's decision, and an express notice of criminal liability is provable in a dispute where a general confidentiality clause is not.

Does the AI use have to be necessary in the first place?

Yes, and this is a separate hurdle that sits before the whole contract chain. § 43e Abs. 1 BRAO permits access to protected facts only in so far as it is necessary for obtaining the service; § 62a StBerG and § 50a WPO are built in parallel. In practice that means two things. The question is not whether AI is useful in general, but whether this particular step requires protected facts to be disclosed at all - a draft with no matter reference, research on a point of law, or a text redacted beforehand does not reach the threshold. And necessity is a question of volume: only the data the step needs may flow, not the whole file because it happens to be there. Necessity is assessed before the chain and is not replaced by it: it decides which data flows at all, the chain decides under what obligations it flows.

What about US providers?

Two separate assessments. First the GDPR layer: third-country transfer under Art. 44 et seq. GDPR, CLOUD Act exposure, and the provider's DPF status. Second the professional-law foreign-service bar: § 43e Abs. 4 BRAO, § 62a StBerG and § 50a WPO permit service providers abroad only where secrecy protection is comparable - which can make US sub-processing inadmissible regardless of the contract stack. Firms that want to avoid both questions structurally choose the routes with no US parent in the chain.

Are the sample documents available in English?

The commentary is; the instruments are not, and deliberately so. Each document is an instrument of German law, drafted to be signed under German law and read by a German court or chamber if it is ever tested. Translating the operative text would create a second version whose wording has never been reviewed. What this track does instead is explain in English what each document does, what it is for and where it sits in the chain, so that your general counsel or procurement can assess the set before your German colleagues sign it.

Hold the chain against your own setup

We walk the eight links against your planned or running deployment - supply route, contracts, deployment type. As a technical and organisational assessment, not as legal advice.

Book a conversation