Building AI services for professionals bound by confidentiality obligations: a guide with Privatemode AI

Anyone building AI services for professionals bound by confidentiality obligations, whether as a legal AI startup, a law firm building in-house, or for tax advisory, auditing, or insolvency administration, runs into the same architecture question. How can an LLM be used productively without the infrastructure or model provider itself being able to access the data? This isn't a German-specific issue. The same requirement comes up in every jurisdiction with client confidentiality, professional secrecy, or contractual confidentiality obligations.

Standard LLMs are unsuitable under § 203 StGB

Encryption in transit and at rest is standard today, but it doesn't solve the problem. During processing, data sits in plaintext on typical cloud infrastructure, visible to the infrastructure and model operators and, in doubt, to state access claims against the provider, regardless of where in the EU the data is stored. This isn't a theoretical risk: in June 2025, a Microsoft representative had to admit under oath before the French Senate that he could not guarantee that French citizens' data would not be handed over to US authorities without the French government's consent, a direct consequence of the US CLOUD Act. A standard data processing agreement doesn't change that, it governs data protection accountability, not technical access.

Privatemode AI for verifiable confidentiality when using LLMs

Privatemode processes requests inside confidential computing environments, so data stays encrypted throughout transmission, storage, and inference. A small software component runs on your own side, handles the encryption, and automatically checks before every request that the other side is actually running the expected, unmodified software, not something else. The full code of the security-relevant components is public on GitHub, and the builds are reproducible. That can be verified independently, instead of just promised contractually.

In practice, that means no reliance on a promise, but a technically enforced, externally verifiable protection that holds even if the provider itself were compromised or compelled to hand over data.

Integrating secure LLMs into AI services for professionals bound by confidentiality obligations

Privatemode's API is OpenAI/Anthropic-compatible and can therefore be integrated directly into existing codebases. The proxy runs as a Docker container or native binary, locally at the developer's site or within your own infrastructure, and handles encryption and attestation automatically in the background, without the application having to implement any cryptography itself. Chat completions, embeddings, tool calling, and speech-to-text are available, among others. We also offer a growing selection of models (such as Kimi K2.6, GLM 5.2 in preview, or embedding models from Qwen), so more complex products can be built on top of it, not just a simple chat.

Confidentiality agreement under § 203 StGB: what technology doesn't replace

Even with this architecture, a contractual layer remains necessary. In Germany, for example, the professional codes for lawyers, tax advisors, auditors, and insolvency administrators (§ 43e BRAO, § 62a StBerG, § 50a WPO) require a separate confidentiality agreement in text, including the criminal-law notice under § 203 StGB, whenever a service provider is engaged. A standard data processing agreement isn't sufficient for this, according to the professional chambers. We've entered into such a supplementary agreement with a legal-tech customer: it recognizes our position as an independently liable "participating party," fixes confidential computing as an agreed technical measure, and additionally governs the right to refuse testimony and protection against seizure. As a participating party, unauthorized disclosure carries a prison sentence of up to one year or a fine. Acting for payment or for personal gain raises that to up to two years (§ 203 (4) and (6) StGB). Anyone who additionally exploits the data, for example to train a model, also becomes liable under § 204 StGB, again with up to two years' imprisonment or a fine. This cuts both ways, a provider who can show that its own subcontractors, such as Privatemode, have no technical access to the plaintext data has an easier time meeting its own due diligence obligations when selecting them, and correspondingly bears less risk of being held responsible for an unauthorized disclosure by its own supply chain. This pattern carries over to other industries with comparable confidentiality obligations. The principle stays the same: technology and contract complement each other, neither replaces the other.

The last question concerns the provider's own jurisdiction. If it is subject to a foreign disclosure obligation such as the US CLOUD Act, a contractual assurance can be overridden by a valid official order, unless the architecture makes that moot because there's nothing usable to hand over. Our subcontractors are accordingly based within the EU and are ISO 27001-certified.

Checklist before go-live

1. Architecture: Does it technically rule out access by the provider and infrastructure, and can that be independently verified cryptographically rather than just promised?
2. Contract: Is there a separate confidentiality agreement in text form covering the obligations relevant to the specific profession, or only a standard data processing agreement?
3. Jurisdiction: Where are the provider and its subcontractors based, and what foreign disclosure obligations might they be subject to?
4. Integration: Can the existing codebase be adapted with reasonable effort, or does the solution force a complete rebuild?

Anyone who resolves these four points before getting started can build an AI service for professionals bound by confidentiality obligations that won't need retrofitting later, when the first major customer asks about the architecture.