Approaches
The four common ways teams protect data when adopting AI, their real tradeoffs, and where OGuardAI fits. OGuardAI is not the right choice for every case.
Audience: architects, security and compliance leads, and engineering leaders choosing how to adopt AI on sensitive data
There are four common ways to reconcile "use the strongest AI" with "keep the data protected". Each has a real place. This page compares them honestly and says where OGuardAI fits and where it does not. For the regulatory substance behind the exposure rows, see Data Sovereignty. For a tool-level comparison against Presidio, AWS Comprehend, and Azure AI Language, see Why OGuardAI.
The four approaches
1. Cloud model plus a data processing agreement
Send data to a hosted commercial model and rely on a data processing agreement (Auftragsverarbeitungsvertrag), the provider's security posture, and a transfer mechanism (SCCs or the Data Privacy Framework).
This is the fastest path and gives you the best model quality with no extra engineering. The tradeoff is that raw data leaves your control, so your section 203, CLOUD Act, and transfer exposure is the highest of the four, and a contract does not by itself remove the criminal-law or transfer risk. It fits low-sensitivity data, or cases where the agreement and the provider's assurances genuinely satisfy your risk assessment.
2. One-way redaction
Detect sensitive values and remove or mask them before the request leaves, with no restoration. The model works on placeholders and the output stays generic.
It is simple, keeps raw values from leaving, and needs no session state. The cost is quality: stripping identifiers destroys the context the model needs, so a multi-party thread or a personalized reply becomes hard or impossible, and there is no way to put the real values back. It fits analytical or aggregate work where you never need the original values in the output.
3. Self-hosted (sovereign) model
Run an open-weight model on infrastructure you control, so no data crosses to a third party at all.
This gives the strongest data sovereignty of the four and the lowest third-party exposure, because nothing leaves your boundary. The cost is that open models still trail the best commercial models on many tasks, and you carry the full operational burden: GPUs, model updates, and MLOps. It fits the highest-sensitivity workloads where no external model is acceptable and you can fund the infrastructure.
4. Tokenize and restore (OGuardAI)
Detect sensitive values, replace them with semantic tokens that carry safe metadata, send the tokenized text to any model, and restore the real values deterministically in the output, governed by policy.
This keeps commercial-model quality because the model still runs on fluent text with enough context to be useful, it is reversible so the output can be personalized per channel, and it narrows your section 203, CLOUD Act, and transfer exposure because the raw identifiers stay inside a runtime you control. The tradeoffs: only detected entities are protected (person, company, and location need the NER sidecar), you operate an extra runtime component, and a policy whitelist can deliberately pass a value through. It is a control, not a compliance guarantee.
Side by side
| Dimension | Cloud + DPA | One-way redaction | Self-hosted model | OGuardAI |
|---|---|---|---|---|
| Model quality | Best | Best, minus stripped context | Trails commercial models | Best |
| Raw identifiers leave your control | Yes | No | No | No, for detected non-whitelisted values |
| Restores real values in output | Yes, they were never masked | No | Yes, they never left | Yes, per policy and channel |
| Preserves context for the model | Yes | No, context is stripped | Yes | Yes, via safe metadata |
| Section 203 / CLOUD Act / transfer exposure | Highest | Low | Lowest | Reduced |
| Engineering and operating effort | Lowest | Low | Highest | Moderate |
| Works with any provider | Yes | Yes | Not applicable, it is your model | Yes |
How to choose
- Choose cloud plus a DPA when the data is low sensitivity, or the agreement and provider assurances meet your risk assessment.
- Choose one-way redaction when you need only analytical or aggregate output and never need the original values back.
- Choose a self-hosted model when the workload is too sensitive for any third-party model and you can fund the infrastructure.
- Choose OGuardAI when you want commercial-model quality and reversible output while keeping raw identifiers inside your runtime, which is the common case in regulated and DACH contexts.
These are not mutually exclusive. A team can run a self-hosted model for its most sensitive workflow and use OGuardAI in front of a commercial model for the rest, or apply one-way redaction to values it never needs to restore while tokenizing the ones it does.
Honest limits
OGuardAI is a runtime control, not a model, a contract, or a certification. Only detected entities are protected, NER for person, company, and location requires the sidecar, and a policy whitelist can deliberately pass a value through. It reduces exposure and preserves quality; it does not make a deployment compliant on its own. See Trust for the honest posture and Security Guarantees for the binding technical contract.
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.
Regulatory Timeline
A dated view of the EU and DACH data-protection and AI developments that make protecting data in AI systems a present concern, and what they mean in practice. Background, not legal advice.