A chain, not a certificate
Eight links of contract and configuration carry a supply route under German professional secrecy. Each one is verifiable on its own - as a document, a configuration record or a named responsibility. If one is missing, the whole claim hangs in the air.
Why a chain - and not a certificate
Anyone wanting to test a provider claim such as "§ 203-compliant" needs a grid, not trust. This is that grid: eight links of contract and technology that together carry the supply route. Each is verifiable on its own. If one is missing, the whole statement hangs in the air. The overview page AI under German professional secrecy introduces the chain; this page takes it link by link, with the test question and the form of proof for each.
The doctrinal frame behind it, named openly: § 203 Abs. 3 Satz 2 StGB permits the involvement of assisting persons - which on the prevailing reading includes IT and AI service providers. § 203 Abs. 4 Satz 2 Nr. 1 StGB requires that those persons be obligated to secrecy. And the technical line of "no human plaintext access" addresses the element of "disclosure" in subsection 1: on the DAV reading (SN 32/2025), purely automated processing without a human taking cognisance does not amount to disclosure at all. That interpretation has not been conclusively settled by the courts. The BRAK is more conservative: on its AI guidance (as at 12/2024), the mere possibility of taking cognisance may suffice. The chain therefore runs both lines in parallel - contract and technology as a belt-and-braces risk argument, not as cumulative legal conditions.
Part of the criminal-law precision: § 203 StGB is an intent-only offence and, under § 205 StGB, prosecuted only on complaint. This chain is not about a threat scenario. It is about provability - to whom can a firm evidence that its supply route holds?
Sources: DAV opinion SN 32/2025 (anwaltverein.de), BRAK guidance on AI use, as at 12/2024 (brak.de); each retrieved 22 July 2026.
Link 1: The data processing agreement (Art. 28 GDPR)
The basis of any processing on instructions: purposes, data categories, technical and organisational measures, instruction rights, deletion duties. For AI infrastructure the DPA has to govern more than a standard SaaS contract does - prompt content as its own data category, logging policy, environment separation.
Decisive for the chain: the DPA on its own is not the § 203 safeguard. It is link 1 of 8 - the data protection foundation on which the criminal-law obligation in link 2 is built.
Link 2: The secrecy obligation (§ 203 Abs. 4 Satz 2 Nr. 1 StGB)
The link most provider assurances cannot evidence: an obligation to secrecy, backed by criminal liability, of the persons assisting at the service provider (§ 203 Abs. 4 Satz 2 Nr. 1 StGB) - backed by criminal liability because those persons are themselves liable under § 203 Abs. 4 Satz 1 StGB if they disclose without authority. Text form and an express notice of criminal liability are required not by § 203 StGB itself but by the professional rules (§ 43e BRAO, § 62a StBerG, § 50a WPO; for notaries § 26a BNotO). The confidentiality clauses customary under the GDPR - "our staff are bound to confidentiality" - do not perform this function: they are employment-law undertakings, not criminal-law ones. Selection and supervision remain with the professional: § 43e Abs. 2 BRAO requires careful selection of the service provider, and ongoing supervision - up to terminating the relationship on breach - stays their responsibility.
The test question for any provider: is the obligation documented and inspectable before the contract is concluded? Established practice for that - a matter of provability, not a requirement of § 203 itself - is a separate instrument rather than a clause inside the main contract. In our own market screening of 22 July 2026, around 8 of some 25 providers examined in the German-speaking market had a substantive contract document at all; the combination of a freely inspectable document before any registration, a separate Abs. 4 instrument as evidence, and legal review was unoccupied at that date.
Link 3: The sub-processor chain
The obligation does not stop at your contracting party. Who actually processes? The SaaS provider? Its cloud provider? The model operator behind that? Every stop in the chain must either be obligated itself under subsection 4 or demonstrably have no plaintext access - it is the same Abs. 4 obligation passed along the chain, not three different norms. A named, current sub-processor list with a change-notification duty is therefore a mandatory document, not a nice-to-have.
Concretely: for a firm chat on an Azure basis, the Microsoft contract line and the deployment type belong in the assessment. For Google-based setups the question is no longer whether a § 203 secrecy agreement exists - Google offers one - but whether the provider has actually signed it and what its scope is. Two points decide it. Does it cover all the models in use, or only some? And does it capture the firm's matter data - or only the provider's own confidential information? The Cloud Data Processing Addendum alone answers neither.
Source: Google Cloud documentation (Cloud Data Processing Addendum); retrieved 22 July 2026.
Link 4: The provider itself as an obligated link
A supply-route provider who defines itself out of the chain has not understood it. Gosign stands in the chain as a processor: its own staff and its sub-processors obligated to secrecy - under § 203 Abs. 4 Satz 2 Nr. 2 StGB, the provision for an assisting person who engages a further one, where Nr. 1 addresses the firm obligating us - and instructed on criminal liability in line with the client's professional rules. It is the same Abs. 4 obligation the firm passes to Gosign and Gosign passes on to staff and sub-processors. Gosign is a named assisting person in the DPA; mapping-key handling and retention are governed contractually.
The architecture is designed for no human access in normal operation - pseudonymisation before the model call, re-insertion afterwards, a plaintext-free audit trail, and logged break-glass exceptions under four-eyes control. Important in the assessment: this redaction layer is data minimisation and defence in depth. It is not the condition for satisfying § 203; it lowers the residual risk under both of the readings set out above.
Link 5: EU region and data zones
"Runs in the EU" is a deployment property, not a marketing sentence - and how concrete it is differs per supply route. Ask for the specific deployment type with EU-only processing; a standard deployment in an "EU region" is not enough, because processing can still route globally. EU endpoint, disabled caching and a documented non-persistence configuration belong in the same assessment.
The test question: does the provider name the specific deployment type - or only the continent?
Sources: Microsoft Learn / Azure documentation (deployment types and data residency), Google Cloud documentation (data governance); each retrieved 22 July 2026.
Link 6: Third-country transfer - Art. 44 et seq. GDPR, CLOUD Act, DPF status, and the foreign-service bar
Two separate assessments, routinely stirred into one sentence.
Under data protection law (Art. 44 et seq. GDPR): with US providers, CLOUD Act exposure persists even with an EU deployment - the US parent can be compelled to produce. A transfer impact assessment with the DPF status of each provider in the chain and supplementary measures is therefore a mandatory building block, not a formality. Only a chain with no US corporation in it structurally may claim to be free of CLOUD Act exposure - which applies to EU inference of open models and to German data-centre providers with a § 203 secrecy agreement, not to the Azure or Google routes.
Under professional law (the foreign-service bar): § 43e Abs. 4 BRAO, § 62a StBerG and § 50a WPO permit engaging service providers abroad only where secrecy protection is comparable. US sub-processing can therefore be inadmissible under professional law regardless of standard contractual clauses and a completed transfer assessment - a link that pure GDPR checklists systematically miss.
Link 7: Training exclusion and retention - the retention matrix
Two questions per model route: are your inputs used for training? And how long do prompts or responses sit anywhere? The answers differ per supply route and per model class, which is why every chain needs a contractual training exclusion and a retention matrix per data type governing at least these four:
| Data type | Requirement | Why |
|---|---|---|
| Plaintext inputs (prompts, documents) | Transient - no persistence beyond the processing itself | The core of the non-persistence argument under both legal readings |
| Pseudonym mappings | TTL-bound with a defined deletion period | Re-insertion needs the key only for a limited time |
| Audit log (plaintext-free) | Retention aligned to German bookkeeping principles | Provability without the content of the secret |
| Contract and billing data | Statutory periods (HGB / AO) | Commercial and tax retention duties |
That retention decides suitability is not theoretical. Certain premium model classes are available over cloud platforms only with 30-day prompt retention and mandatory data sharing with the model provider - excluded for secrecy-bound workloads regardless of how good the model is. The specific periods per combination belong in the provider's model catalogue, not in a footnote.
Source: Google Cloud documentation (abuse monitoring, model classes with retention duties); retrieved 22 July 2026.
Link 8: Client consent and transparency (Art. 13/14 GDPR)
The last link closes the chain towards the client. First, the transparency duties under Art. 13/14 GDPR: the firm's privacy notice has to reflect the AI processing and the service provider chain. Second - depending on the professional rules - the consent of the client, or of the parties in the case of notaries. § 62a Abs. 5 StBerG and § 50a Abs. 5 WPO regularly require it expressly for matter-related outsourcing; for lawyers, § 43e Abs. 5 BRAO requires the client's consent where the engagement of the service provider relates to an individual matter; for notaries, § 26a Abs. 4 BNotO requires the parties' consent where the service directly serves an individual official act. A provider silent on the consent question leaves its customers to solve the hardest link alone.
Sample consents (client and parties variants) and a sample transparency notice are part of the Gosign contract kit and freely inspectable (v0.11), as samples for case-by-case adaptation by a lawyer, without warranty.
You know the links - now what?
The eight links are also available as a working document for provider conversations: eight questions, each with the form of proof and the usual trap. The instruments that carry them are set out in the contract kit.
Questions about the chain
Why eight links and not a certification?
What if a provider cannot evidence one of the links?
Is the redaction layer what makes the setup compliant?
Hold the eight links against your own setup
We walk them against your planned or running deployment - supply route, contracts, deployment type. As a technical and organisational assessment, not as legal advice.
Book a conversation