Whether an AI tool is permissible in your company is rarely decided by the technology. Most of the time it is decided by a document hardly anyone reads: the data processing agreement. The discussion still tends to run through other questions. Is the vendor reputable? Are the servers in Europe? Does the model train on our data? All legitimate points. Legally, though, the answer hangs on something less spectacular: As soon as an AI tool processes personal data on your behalf, the vendor is your data processor. And for that, the Swiss data protection act (nDSG) has clear rules that are considerably older than the current AI wave.
What Art. 9 nDSG requires, in three sentences
The law is pleasantly short on this point. Art. 9 nDSG allows you to delegate the processing of personal data to a processor, provided the processor only handles the data the way you would be allowed to yourself. You must satisfy yourself that the processor can guarantee data security. And the processor may only pass the processing on to a third party with your prior approval.
Translated: You remain responsible. The vendor works on your behalf, under your rules, and the data processing agreement records what the vendor may and may not do with the data of your customers and employees.
That AI changes none of this has been made clear by the Swiss Federal Data Protection Commissioner: the data protection act is worded technology-neutrally and applies directly to AI-supported data processing. There is no AI transition period and no grey zone in which you could wait for a Swiss AI law. The rules apply from the moment the tool is in use.
One more term that causes confusion: in Germany, the same document is called an Auftragsverarbeitungsvertrag, or AVV. The Swiss law speaks of the Auftragsbearbeiter, the data processor. International vendors call it a Data Processing Agreement or Data Processing Addendum, DPA for short. All three mean the same principle. If you find a DPA on a vendor's website, you are looking at the right document.
Why this still goes wrong with AI tools
Processing on behalf of a controller is not a new discipline. For payroll, hosting and the CRM, many companies set up the contracts properly at some point. With AI tools, the routine breaks down, for three reasons.
First, AI tools rarely enter the company through procurement. They arrive through employees who want to solve a problem, and they show up in no contract folder. We described this in our post on shadow AI in companies: what nobody procured, nobody put under contract either.
Second, with AI services the account tier determines the contractual situation. The same software exists as a private free account and as a company account, and only one of the two stands in a contractual relationship with your company. A private free account cannot have a data processing agreement with your company, because your company is not a party to that account at all. Which data may go into ChatGPT therefore depends less on the tool than on the account it runs through.
Third, the data flow does not feel like data processing. A meeting transcript, a summarized email thread, an uploaded customer list for analysis: it feels like everyday work, not like transferring personal data to a third party. But that is exactly what it is, the moment the data arrives at the vendor.
Where the contract lives: with the account tier, not the product
With reputable vendors you do not have to negotiate the contract. It already exists; you only have to find it and check whether it applies to your account tier.
Microsoft is the clearest example, because M365 is already in use in many SMEs. The Data Protection Addendum is part of the product terms for the online services. If you use Microsoft 365 on a company subscription, the data processing for these services is covered by it. No separate paper, no signing round. This also explains, in passing, why the company edition of an AI assistant stands differently under data protection law than the private account from the same manufacturer: the difference lies in the contractual setup around it, the software is the same.
With other vendors, the same look is worth taking: search the website for "Data Processing Addendum" or "DPA" and check two things. Which account tier does the document apply to, and does it cover the way you use the tool? A DPA that only applies to enterprise contracts, while your team works with individual accounts, protects exactly nobody.
Two limits belong to an honest picture. The data processing agreement does not answer the question of disclosure abroad; that runs through a separate chapter of the nDSG and is its own checkpoint with US vendors. And it changes nothing about what you feed into the tool. A clean contract covering the processing of customer data does not turn bad data practice into good practice.
Your vendor's vendor
One point from Art. 9 deserves particular attention with AI tools: the processor may only pass the processing on to third parties with your prior approval. With AI services, this passing on is the normal case. The transcription tool sends the audio track to a speech-to-text service, the assistant in the CRM calls another manufacturer's language model, and the whole thing is hosted with a third cloud provider. Your contractual partner is one company; the data chain is longer.
In practice, DPAs solve this with a subprocessor list: the vendor lists which third parties it uses, and you approve this list along with the contract. Part of that is a mechanism for how the vendor announces changes and how you can object. That is where the look is worth it. If you find no such list in the DPA, or you find one that is missing the language model the vendor visibly uses, then you do not know where your customers' data actually ends up. That is no reason for alarm, but it is a reason to query the vendor before personal data flows.
The chain has a second consequence: it also turns around. If you are yourself a data processor for your customers, say as a fiduciary, agency or IT service provider, then the AI tool you use is a subprocessor of your customers. Your own contracts may then require you to disclose this use or have it approved. In that case, the questionnaire that uncovers it comes not from the regulator but from the customer.
The check that takes an hour
Three steps are enough to start, with no project and no external auditor.
Step 1: List the AI tools that see personal data. Not all AI tools, only those with personal data involved: names, email addresses, customer files, job applications, transcripts with identifiable people. If you cannot produce this list off the top of your head, that is your real finding. Then the AI inventory is missing, and the contract is step two.
Step 2: For each tool, check the account tier and the contract. Company account with a valid DPA for your type of use: fine. Private or free account with personal data running through it: gap. Company account, but the DPA only applies to a higher contract tier: also a gap, just better disguised.
Here is what that looks like in practice, using a meeting transcription tool as the example. Who opened the account, the company or an individual? Which tier is it on, free, pro or business? Is there a DPA, and does it apply to this tier? Does it state which subprocessors see the audio track? Four questions, one tool, a few minutes. The answers fit into one line of your list, and after ten tools you have a picture that, in our experience, very few companies have of their AI use.
Step 3: Close the gaps and record the decision. Three routes are open: raise the account to the company tier, restrict the use to data without personal references, or stop the tool for this purpose. Which route it is, is a business decision. That it was taken and recorded is the point at which chance turns into governance.
For most AI applications in everyday SME life, this fulfils the obligation. It only goes one level further when the processing itself carries a high risk for the people affected: then the law additionally requires a data protection impact assessment, and the Commissioner names high-risk AI applications as a case for it. When your SME needs such an impact assessment is something we have described separately; you do not need one for the translation tool on a company account, but you certainly do for AI-supported applicant screening.
In Art. 61, the nDSG provides for fines of up to CHF 250,000 for wilfully disregarding the requirements of Art. 9, directed at the responsible individual. Wilfulness is required, and in everyday life that is rarely the moment the gap surfaces. A different one is more realistic: the security questionnaire from your biggest customer asks for the list of your data processors, and the AI tools are not on it.
The contract is the start, not the goal
A data processing agreement does not make an AI tool secure. It makes the responsibilities clear, and that is the first step towards everything else: data classification, usage rules, an inventory that stays current. This inventory and contract work is the core of AI governance as we set it up with SMEs: unspectacular, in weeks rather than months, and with the effect that the question "May we use this tool?" has a documented answer instead of a gut feeling.
If you are not sure where your AI tools stand contractually, an initial conversation is the shortest route to an honest assessment.
And until then, the question that deserves an hour of your time: which of your AI tools sees personal data today without a contract behind it?
