“Is our data safe?” is the first question in almost every AI project, and often the one answered least precisely. The honest answer depends on where data actually flows, and an AI system has more stops along the way than most people expect.
The six places your data can end up
Take a typical knowledge assistant that answers employee questions from internal documents. Data passes through:
- The source systems: SharePoint, the DMS, the ERP. These already have owners and access rules.
- The ingestion pipeline, which extracts and splits documents into passages.
- The embedding model, which turns each passage into a vector for search. If this is a cloud API, every document passes through it.
- The vector database, which stores those passages and vectors, often as a copy of sensitive content.
- The language model, which receives the question plus the retrieved passages for every single request.
- Logs and traces, which record prompts and answers for debugging and quality control, and are the place where sensitive data most often piles up unnoticed.
Each of these is a processing location in the sense of the Swiss Data Protection Act (nDSG) and the GDPR. Each needs an answer to three questions: where is it, who operates it, and how long is data kept?
Contracts first
As soon as an external provider processes personal data on your behalf, you need a data processing agreement under Art. 9 nDSG and Art. 28 GDPR. In practice that means:
- A DPA with your implementation partner, covering what they may see and do during the project.
- A list of subprocessors: the cloud provider, the model provider, the monitoring tool. You should approve this list, and changes to it.
- For any provider outside Switzerland and the EU, a check of the legal basis for the transfer, such as an adequacy decision or standard contractual clauses.
An NDA protects business secrets; it does not replace a DPA for personal data. You usually need both.
Design choices that keep data under control
Contracts set the rules; architecture decides how much is at stake. The choices that matter most:
Choose the region deliberately. Major cloud providers operate data centres in Switzerland, and several offer language models in Swiss or EU regions. Where a capable model is not available in the region you need, open-weight models can run on your own infrastructure or in a Swiss cloud.
Switch off what you do not need. Many model APIs offer options for zero data retention and exclude business customers’ data from training by default. Confirm both in writing and configure them explicitly, rather than relying on defaults that can change.
Minimise before you send. Not every field needs to reach the model. Names, account numbers and addresses can often be replaced with placeholders before the request and restored afterwards. The model still does its job; the provider never sees the identifiers.
Respect existing permissions. A knowledge assistant must not become a way around access rules. Each answer should be built only from documents the asking user is allowed to see, enforced at retrieval time, not by asking the model to be discreet.
Treat logs as sensitive data. Mask personal data in traces, set a retention period, and restrict who can read them. Debug logs kept forever are a common finding in audits.
Plan the exit. At project end, data is returned or deleted, including copies in vector databases, backups and test environments, and the deletion is confirmed in writing.
A one-page data map
Before any real data flows, we produce a one-page map of the system: every component, its location, its operator, what data it sees and how long it keeps it. It is the document your data protection officer will ask for, it makes the records of processing activities straightforward, and it turns “is our data safe?” into a question with a concrete, checkable answer.