Data Sovereignty
How OGuardAI strengthens a section 203 StGB, CLOUD Act, and Schrems II posture by keeping raw identifiers inside a runtime you control. Background, not legal advice.
Audience: Legal Counsel, Data Protection Officers, Compliance Teams, regulated buyers in the DACH region
Regulated teams in the DACH region face a specific version of the AI adoption problem. The strongest models are operated by US providers, professional-secrecy and transfer law constrain what may leave your control, and hosting a US provider's model in an EU data center does not settle the question. This page covers the three rules that come up most often, section 203 StGB, the US CLOUD Act, and Schrems II, and where OGuardAI fits.
The thesis is narrow and honest: own the runtime, not the model. Keep the raw identifiers inside infrastructure you control and let the model work on tokens. That narrows what you disclose and reduces your dependence on any single legal mechanism. It does not make you compliant on its own.
This page is background and a description of a technical control, not legal advice and not a certification. Whether a given deployment satisfies section 203 StGB, the GDPR, or a transfer assessment is a legal question for qualified counsel. OGuardAI is one control you operate inside that assessment.
Section 203 StGB: why an AVV is not enough
Section 203 StGB (Verletzung von Privatgeheimnissen) is German criminal law. It protects secrets entrusted to Berufsgeheimnisträger: doctors, lawyers, tax advisers, and similar professions. It sits next to the GDPR, not inside it. A data processing agreement (Auftragsverarbeitungsvertrag, GDPR Article 28) governs the data-protection relationship; by itself it does not resolve the criminal-law question.
The 2017 reform (in force since 9 November 2017) made outsourcing workable. Section 203 (3) lets a secrecy holder involve external service providers as "sonstige mitwirkende Personen", which can include cloud and AI providers. The permission is conditional. The involvement must be actually necessary for proper professional practice, the provider must be contractually bound to confidentiality and informed of the criminal consequences of a breach, and the secrecy holder must select and monitor the provider with care. The provider itself joins the circle of persons who can be criminally liable.
So an AVV alone is not the point. The reform layers a specific confidentiality obligation, a criminal-consequence notice, a necessity test, and a selection-and-monitoring duty on top of it.
Where OGuardAI helps: when identifiers are detected and tokenized before the request leaves your runtime, the model provider receives tokens and safe metadata rather than the underlying secret. That narrows what is disclosed, which speaks to the necessity test, and it lowers the secret's exposure at the point where section 203 applies.
What stays yours: the necessity assessment, the contractual confidentiality and notice, the careful selection and monitoring, and the handling of anything a policy whitelist deliberately passes through. Only detected entities are tokenized, and person, company, and location detection requires the NER sidecar. OGuardAI reduces the disclosed secret; it does not remove your section 203 duties.
The US CLOUD Act: why EU hosting is not a defence
The US CLOUD Act lets US authorities compel US-headquartered providers to produce data they control, regardless of where that data is stored, including in an EU data center. This sits in tension with GDPR Article 48, under which EU data may not be handed to a non-EU authority solely on the basis of a foreign order.
Choosing an EU region does not settle this. The reach follows provider control, not data-center geography. In June 2025, Microsoft's French subsidiary stated under oath before the French Senate that it could not guarantee data would be shielded from US authorities, even under a France-marketed sovereign offering. The EDPB reaches the same place from the other side: its Recommendations 01/2020 name encryption with keys held outside the provider's control as the primary adequate technical measure. The EU Data Act (Regulation (EU) 2023/2854), applying from September 2025, adds an obligation on providers to take measures against unlawful non-EU government access to data held in the EU.
Where OGuardAI helps: the defence that holds up is technical, not geographic. When the raw identifiers stay inside your self-hosted runtime and the session travels as a sealed, client-held blob encrypted with a key you control, a US-reachable provider holds only tokenized text and a session envelope it cannot open. There is less readable secret for any order to reach.
What stays yours: OGuardAI does not answer a legal order for you, and it does not cover data you send to a provider outside the tokenized path. Provider credential headers pass through unscanned by design. The transfer assessment and the choice of provider remain your decisions.
Schrems II and the Data Privacy Framework
Schrems II (2020) invalidated Privacy Shield and held that Standard Contractual Clauses support a US transfer only where the data is genuinely protected from US government access. That requires a transfer impact assessment that honestly weighs CLOUD Act and FISA 702 exposure, and technical supplementary measures where a real risk is found.
The EU-US Data Privacy Framework, adopted in July 2023, is the current successor. As of mid-2026 it remains valid but is under active challenge. The EU General Court dismissed the Latombe challenge on 3 September 2025; an appeal to the Court of Justice is pending, and a separate NOYB challenge continues to question the durability of the underlying US executive order and the independence of its redress mechanism. Commentators expect a view from the Court of Justice in late 2026 or 2027, with a genuine possibility that adequacy is set aside a third time.
Where OGuardAI helps: technical data minimization reduces how much you depend on the transfer mechanism staying valid. If the content you send to a US model is tokenized, you are transferring tokens and safe metadata rather than directly identifiable data, which is a supplementary measure in the spirit of the EDPB recommendations.
What stays yours: the transfer impact assessment, the legal basis for any transfer, and the judgment about residual risk. A future ruling could move the ground under any US transfer, which is the point: leaning on technical minimization is more durable than leaning on a single adequacy decision.
The EU AI Act (high-risk date deferred to 2 December 2027, pending publication)
The EU AI Act regulates AI systems by risk. On the original timeline, most obligations for high-risk systems, including the Article 10 data-governance requirements, applied from 2 August 2026. The Digital Omnibus (political agreement 7 May 2026, Parliament endorsement 16 June 2026, Council green light 29 June 2026) defers the stand-alone Annex III high-risk obligations to 2 December 2027, and embedded Annex I product AI to 2 August 2028. That deferral binds only once published in the EU Official Journal; verify the current status, because until publication the original 2 August 2026 date remains the formal law. The Article 5 prohibited-practice and Article 4 AI-literacy duties already applied from 2 February 2025 and are not deferred; the Article 50 transparency rules were not among the deferred high-risk items. This is a different axis from the rules above: it governs how an AI system is built and operated, not how data crosses a border.
OGuardAI is not an AI Act conformity route, and it does not address dataset quality, bias examination, risk management, or CE conformity. Its relevance is narrow and honest. If you deploy a high-risk system on a third-party model, tokenizing personal data at the input boundary supports data minimization and data protection by design, and the per-operation audit trail supports the record-keeping expectation. Article 10 (5) permits processing special categories of data for bias monitoring only under safeguards such as pseudonymization and access control, which tokenization is well suited to support.
What stays yours: the risk classification, the conformity assessment, the dataset governance for any model you train, and the overall obligations for the system you place on the market or put into service.
Per-vertical scope notes
The wedge lands differently per profession. In each case OGuardAI narrows what the model sees; the professional duties stay with you.
| Vertical | Typical sensitive identifiers | Secrecy regime | What OGuardAI narrows | What stays yours |
|---|---|---|---|---|
| Tax advisers (Steuerkanzlei) | client names, Steuernummer or IdNr, account numbers, DATEV client references | § 203 (1) Nr. 3 StGB, § 102 AO | tokenizes the identifiers before the prompt leaves the runtime | necessity, the confidentiality obligation on any provider, the AVV, DATEV data terms |
| Legal (Kanzlei) | client and counterparty names, case and file numbers, addresses | § 203 (1) Nr. 3 StGB, § 43a BRAO | tokenizes the parties while keeping case structure in safe metadata | the mandate-secrecy duty, conflict checks, and the privilege assessment |
| Healthcare (Praxis, Klinik) | patient names, medical record numbers, insurance IDs, dates of birth | § 203 (1) Nr. 1 StGB, GDPR Article 9 | tokenizes the detected PHI identifiers and restores per output channel | treatment-context necessity, the AVV or BAA, and clinical review of restored output |
The honest posture
- OGuardAI is a control you operate, not a model, a contract, or a certification.
- It strengthens a section 203, CLOUD Act, and Schrems II posture by narrowing what leaves your runtime.
- It does not make you compliant, replace an AVV or a transfer assessment, answer a legal order, or constitute legal advice.
- Only detected entities are protected, NER requires the sidecar, and a policy whitelist can deliberately pass a value through.
For the binding technical detail, see Security Guarantees and the Trust page. For the control-by-control regulatory mapping, see Compliance Controls.
References
- Gesetz zur Neuregelung des Schutzes von Geheimnissen bei der Mitwirkung Dritter an der Berufsausübung schweigepflichtiger Personen (2017), amending section 203 StGB.
- EDPB and EDPS joint response on the impact of the US CLOUD Act on the EU (2019).
- EDPB Recommendations 01/2020 on measures that supplement transfer tools.
- Regulation (EU) 2023/2854 (Data Act), Chapter VII.
- EU-US Data Privacy Framework adequacy decision (2023) and subsequent litigation (Latombe, General Court, 3 September 2025).