Eight questions. Ask for a document, not a sentence.
The market for AI offerings claiming to meet German professional secrecy requirements is growing faster than its evidence. The answer to that is not suspicion - it is a method.
How to use this list
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. Ask each of the eight questions - and have the answer shown to you as a document or a configuration record, not as a sentence. Each point names the form of proof and the trap that usually hides there.
The yardstick behind it, named openly: a supply route compliant with the professional rules and with § 203 on the DAV reading (SN 32/2025), which has not been conclusively settled by the courts. We name the more conservative BRAK position alongside it - the mere possibility of taking cognisance may suffice - and for tax advice, audit and the notarial profession the relevant norms and chamber positions are their own (§ 62a StBerG, § 50a WPO, § 18 BNotO). The doctrinal derivation of each point is set out in the eight links between a matter and a model; this page is its tool form.
The eight-point checklist
☐ 1. Is there an AI-specific DPA under Art. 28 GDPR?
What to look for: the DPA is inspectable before the contract is concluded and treats prompt content as its own data category, governs the logging policy and environment separation - not just the standard SaaS clauses.
The trap: a generic SaaS DPA with no AI reference - or the claim that the DPA is already the § 203 safeguard. It is point 1 of 8, not the answer to everything.
☐ 2. Is there a separate secrecy obligation under § 203 Abs. 4 StGB?
What to look for: a separate instrument obligating the service provider's assisting persons to secrecy and instructing them on criminal liability under § 203 StGB - as a document, inspectable BEFORE the contract is concluded and before any registration.
The trap: the confidentiality clauses customary under the GDPR ("our staff are bound to confidentiality") offered as a substitute - they are employment-law undertakings, not criminal-law ones. Second trap: the instrument exists "after signature".
☐ 3. Is the sub-processor chain named in full - and each stop obligated or demonstrably without plaintext access?
What to look for: a named, current sub-processor list with a change-notification duty that also identifies the cloud provider and the model operator behind your provider.
The trap: the chain stops at your contracting party. Worth particular attention with Google-based setups: a § 203 secrecy agreement is available there, so do not ask whether one exists - ask whether the provider has signed it and what its scope is. Does it cover all the models in use? And does it capture your matter data, or only the provider's own confidential information? The Cloud Data Processing Addendum alone does neither.
☐ 4. Does the provider stand in the chain as an obligated link itself?
What to look for: evidence that its own staff are obligated and instructed under § 203 Abs. 4 StGB, plus a described no-human-access architecture (pseudonymisation, plaintext-free audit trail, logged exceptions).
The trap: the provider defines itself out of the chain ("we never see the data") - or sells the redaction layer as the condition for compliance. Pseudonymisation is data minimisation and a second line of defence; the legal line is carried by the obligation and the contract chain.
☐ 5. Does the provider name the specific EU deployment type - or only the continent?
What to look for: a configuration record with the specific deployment type and EU-only processing, plus an EU endpoint, disabled caching and a documented non-persistence configuration - named and evidenced, not offered as a marketing region.
The trap: "runs in the EU" as a marketing sentence. A standard global deployment in an EU region can route processing globally - the region is not the deployment type.
☐ 6. Are third-country transfer AND the professional-law foreign-service bar answered as separate assessments?
What to look for: a transfer impact assessment with the DPF status of each provider in the chain - and, in addition, an answer on the foreign-service bar (§ 43e Abs. 4 BRAO, § 62a StBerG, § 50a WPO): service providers abroad only where secrecy protection is comparable.
The trap: both assessments stirred into one sentence - or the foreign-service bar missing entirely because only a GDPR checklist was worked through. US sub-processing can be inadmissible under professional law despite standard contractual clauses. And only a chain with no US corporation in it structurally may claim to be free of CLOUD Act exposure.
☐ 7. Is there a contractual training exclusion and a retention matrix per data type?
What to look for: contract plus configuration record: no training on your inputs, and a defined period for each data type. The specific periods per model route belong in the provider's model catalogue, not in a footnote.
The trap: verbal assurances instead of contract text - and undisclosed exceptions. Certain premium model classes are available over cloud platforms only with 30-day prompt retention and mandatory data sharing with the model provider, and are therefore excluded for secrecy-bound workloads regardless of model quality.
☐ 8. Does the provider supply samples for client consent and the transparency notice?
What to look for: sample documents for express consent (§ 62a StBerG, § 50a WPO; for lawyers § 43e Abs. 5 BRAO where the engagement relates to an individual matter) and for the transparency information under Art. 13/14 GDPR - plus input components for your data protection impact assessment under Art. 28 Abs. 3 lit. f GDPR.
The trap: the provider stays silent on consent and leaves its customers to solve the hardest link alone. A sample client consent and transparency notice is part of the Gosign contract kit and freely inspectable (v0.11) - as a sample for case-by-case adaptation by a lawyer, without warranty.
Extract: the retention matrix for point 7
Four data types, four requirements - have the provider show you where each one sits in the contract or in the configuration:
| 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 |
Questions about the checklist
Is a DPA under Art. 28 GDPR enough as evidence for § 203?
What does it mean if a provider cannot evidence a point?
May we print this and use it in the firm?
Is this legal advice?
Hold the checklist against a concrete offer
We walk the eight points against your planned or running setup - supply route, contracts, deployment type. As a technical and organisational assessment, not as legal advice.
Book a conversation