Why architecture beats policy for sensitive data and AI

Ask most vendors how they keep sensitive data safe around a third-party model, and the answer is procedural. There is a data processing agreement, a policy on what staff should not paste into a chat window, and a training session most people no longer remember.

All of it depends on someone under deadline pressure remembering a rule written when the pressure was lower. A policy can be forgotten. An architectural constraint cannot.

The pattern: anonymize before inference

Before any content reaches a model, whether a document, a transcript or a structured record, every real identity in it is replaced with a stable alias.¹ That covers names, addresses and identifiers. Stable means the same real value maps to the same alias throughout a run. The model can still tell that one person appears three times in a document without ever seeing who that person is. The model works only on aliased content. At the very end, locally, on infrastructure that never sent anything to the model, the aliases are reversed to real values.

The trust comes from a second, independent check. It inspects everything about to cross the boundary toward the model. If it finds a real value that should have been aliased, it fails the entire run instead of logging a warning and continuing. A check built on the same logic as the substitution shares its blind spots. A separate check catches the bugs the first pass cannot see, which turns “we anonymize the data” into something you can verify.

Why this is a compliance strategy

Switzerland’s revised Federal Act on Data Protection has been in force since September 2023. On 8 May 2025 the Federal Data Protection and Information Commissioner confirmed that it applies to AI systems processing personal data.² An AI system that touches the personal data of people in Switzerland is already inside an enforced framework, whether or not anyone called it an AI project.

Two obligations in that framework show the difference architecture makes. A data protection impact assessment is required where processing, including AI-driven processing, carries a higher risk to individuals. It has to be scoped while the system is being designed, not written afterwards to describe what exists. A system built around anonymize-before-inference has a smaller DPIA to write than one that sends raw personal data to a third-party model and relies on a contract, because the risk being assessed is smaller. Breach notification applies on the same timelines and thresholds as any other breach under the act. A breach of an aliased dataset that never held real identifying values is a different event from a breach of one that did.²

Architecture does not make the compliance conversation unnecessary or the obligations disappear. It narrows the question your DPIA has to answer.

What still applies

You still need a DPIA, a breach response plan and an assessment of what counts as personal data in your use case. This article is not legal advice about your obligations. The architecture changes the question those obligations ask. “Can we trust everyone downstream to handle raw personal data correctly, forever?” becomes “Did the independent verification gate ever let a real value through?” A system can be built to answer the second question.

For how this fits with hosting choice and DPIA practice, see how we handle your data. For the wider regulatory landscape, see AI regulation in Switzerland.

Footnotes

1. See anonymize before inference for the full internal build this article draws on. ↩

2. FDPIC, “Update - Current data protection legislation is directly applicable to AI,” 8 May 2025. Swiss-specific. https://www.edoeb.admin.ch/en/update-current-legislation-directly-applicable-ai. FADP in force since 1 September 2023; Art. 22 (DPIA duty) and Art. 24 (breach notification). Official text: https://www.fedlex.admin.ch/eli/cc/2022/491/en ↩ ↩²