Data Protection With AI: Why Checklist Compliance Is Not Security
Short answer: what AI can and cannot do for data protection
Short answer: AI tools produce a privacy notice, a record of processing activities or a list of technical and organisational measures in minutes. That saves time and is often usable as a draft. But it only answers the question of whether a document exists. The Swiss Federal Act on Data Protection (FADP) asks a different question: whether personal data is actually protected in a way that is appropriate to the risk.
This is exactly the difference between checklist compliance and real security. A checklist ticks off what is there. Security shows in whether measures work in day-to-day operations and are reviewed regularly. An AI tool knows neither your systems nor your permissions nor your suppliers. It can describe what a secure company looks like. Whether yours is one, it cannot know.
This article is for executives and those responsible for data protection in Swiss SMEs who use AI for their data protection work or plan to. It shows what AI is suited for, five typical pitfalls, what the law means by data security, and how to use AI so that the result is more than paper.
What AI is good for in data protection work
In data protection work, AI is not a problem but a useful tool, provided the task fits. It is well suited to work where a human can check the result with reasonable effort:
- structuring first drafts of policies, instructions and training material,
- summarising long contracts and data processing agreements and checking them for missing clauses,
- putting texts into plain language or translating them,
- checking existing documents for contradictions, for example between the privacy notice and the record of processing activities,
- preparing question lists for interviews with the business units.
What all these tasks have in common is that the AI works with material you supply, and that someone with expertise reads the result critically. It becomes difficult when the AI is expected to contribute facts about your company or about the legal situation that nobody verifies. That is where the pitfalls begin.
Pitfall 1: The AI does not know your company
Anyone who asks an AI to create a record of processing activities for a fiduciary firm with twelve employees receives a plausible record for an average fiduciary firm. Whether your company has outsourced payroll, which CRM is in use, where job applications end up and which service provider has remote access to the server is not in the model. The AI fills the gaps with assumptions, and in the finished document those assumptions look like facts.
For the privacy notice this has legal consequences. Art. 19 FADP requires that data subjects are appropriately informed about the collection of their data, including the purpose of processing and the recipients. A notice that names tools you do not use and omits the ones you do use does not meet that duty. It is worse than a template that is visibly unfinished, because it creates the impression that the work is done.
The better route: the facts come from your company, not from the model. First establish which systems, data categories, recipients and cross-border links really exist, and only then let the AI do the wording.
Pitfall 2: Plausibly worded, legally off the mark
Language models generate text that sounds convincing. They do not check whether a statement is true. In data protection this shows up particularly often as a mix-up: there is far more text about the EU GDPR than about the Swiss FADP. The result is documents for Swiss companies that in reality reproduce EU law.
| Typical statement in the AI draft | What applies under Swiss law |
|---|---|
| "Data breaches must be reported within 72 hours." | Art. 24 FADP requires notification to the FDPIC "as quickly as possible", and only where a high risk to the data subjects is likely. The 72 hours come from Art. 33 GDPR. |
| "Every processing operation needs a legal basis, for example consent." | Private controllers need a justification only where the processing violates personality rights (Art. 30 and 31 FADP). The system of legal bases comes from Art. 6 GDPR. |
| "The company must designate a data protection officer." | Under Art. 10 FADP, private controllers may appoint a data protection officer. A duty to designate one exists in certain cases under Art. 37 GDPR. |
| "The company faces fines of up to 4 percent of turnover." | Art. 60 et seq. FADP provide for fines of up to CHF 250,000 against the individual who acted, and only in the case of wilful conduct. Turnover-based fines against companies are governed by Art. 83 GDPR. |
| "A record of processing activities is always mandatory." | Companies with fewer than 250 employees are exempt, unless they process sensitive personal data on a large scale or carry out high-risk profiling (Art. 12 para. 5 FADP, Art. 24 of the Data Protection Ordinance). |
Where a company additionally falls under the GDPR, both sets of rules apply side by side. That is precisely when it must be clear which statement comes from which law. On top of that come invented or outdated article numbers, which in running text are hard to tell from real ones.
The better route: ask for the source of every legal statement and look it up in the official text. A statement without a verifiable source does not belong in a document you sign.
Pitfall 3: Checklist compliance instead of real security
The pitfall with the most serious consequences concerns data security. On request, an AI delivers a tidy list of technical and organisational measures: access concept, encryption, backup, multi-factor authentication, training. Every line can be ticked off. That is exactly what makes the list deceptive, because it describes a target state. Whether that state has been reached is not in it.
The law does not ask for a catalogue but for a result. Under Art. 8 FADP, controllers and processors must guarantee "a level of data security appropriate to the risk". The Data Protection Ordinance spells this out: the need for protection must be determined, the measures must be geared to the risk, and both must be "reviewed throughout the period of processing" (Art. 1 of the Ordinance). Art. 3 of the Ordinance describes objectives, not documents. Authorised persons should only have access to the data they need for their tasks. After an incident, data should be rapidly restorable. Known critical vulnerabilities should be resolved, and breaches of data security should be recognised rapidly.
| What the checklist ticks off | What real security asks |
|---|---|
| "Backup concept in place" | When was a restore last tested, how long did it take, and is the backup protected against a ransomware attack? |
| "Access granted on a need-to-know basis" | Who can actually access the HR drive today, and when were the permissions last reviewed? |
| "Multi-factor authentication introduced" | Does it apply to all accounts, including administrators, service accounts and remote access by suppliers? |
| "Systems are kept up to date" | How long does a critical vulnerability stay open, and what does the latest vulnerability scan show? |
| "Data processing agreements concluded" | Have you satisfied yourself that the service provider is able to guarantee data security, as Art. 9 para. 2 FADP requires? |
| "Data breach process documented" | Has it been rehearsed, and who decides on a Saturday evening whether to notify? |
| "Staff trained" | Do employees recognise and report a phishing message when one really arrives? |
| "Deletion concept drawn up" | Is data actually deleted once the retention period has expired, including in archives and cloud services? |
An AI can fill in the left-hand column in seconds. The right-hand column can only be answered inside the company: by looking into the systems, by running a test, by producing evidence. An attacker does not read your policies. They try out whether the account without a second factor, the forgotten share or the unpatched server exists.
Pitfalls 4 and 5: outdated documents and false certainty
Documents age, companies change
An AI-generated document is a snapshot. A new tool, a new service provider, a new site: every change makes the record, the privacy notice and the list of measures a little less accurate. That is why the Ordinance requires ongoing review and, where necessary, adjustment of the measures. Data protection is an ongoing operation, not a project that ends when a folder is handed over.
The better route: one responsible person, a fixed review cycle and a trigger whenever a new system or service provider is introduced.
The document as false proof
Documents that look good lower attention. Management, the board and customers read "Encryption: implemented" and assume it is true. If it is not, the document itself becomes the problem: when things go wrong, it shows that the requirement was known and not implemented. Anyone who assures customers in a security questionnaire of measures that do not exist creates a contractual risk on top.
Responsibility cannot be handed over to a tool. The company remains responsible, and the criminal provisions of the FADP are directed at the individuals who act. Under Art. 61 let. c FADP, anyone who wilfully fails to comply with the minimum requirements for data security is liable on complaint to a fine of up to CHF 250,000.
One last point is easily overlooked: anyone who, for the sake of data protection work, copies internal documents, staff lists or contract details into an AI tool without a business contract commits a data protection mistake in the process. Our article on common AI data protection mistakes shows which ones.
Using AI properly: let it draft, verify yourself
The sensible route is not to do without AI but to divide the work clearly. The AI drafts and structures. Facts, legal assessment and the testing of effectiveness stay with people.
- Take stock before anything is written. Systems, data categories, recipients, cross-border links and permissions come from interviews and from the systems, not from assumptions.
- Determine the risk. Which data would be most critical if lost, disclosed or unavailable? The measures are geared to that (Art. 1 of the Data Protection Ordinance).
- Let the AI draft. With your material, and in a tool covered by a business contract.
- Check every legal statement against the primary source. The Act and the Ordinance are publicly available.
- Test effectiveness instead of asserting it. Restore test, permission review, vulnerability scan or penetration test. Record the results.
- Define responsibility and rhythm. Who checks what and how often, and what triggers an extraordinary review?
Three questions for every AI-generated data protection document
- Does it match our company, line by line?
- Is it legally correct, and where does it say so?
- Who checks whether it is lived in practice, and with what?
As a starting point, a checklist is perfectly useful, because it shows which topics exist. That is what our Swiss data protection checklist is for. It does not replace the second step: looking for the evidence behind every line. For the technical side, the FDPIC guide to technical and organisational data protection measures is a good foundation.
Conclusion, support and sources
AI makes data protection work faster, but not correct by itself. Documents are the beginning. Protection only arises once measures are implemented, tested and kept up to date. Those who know the difference use AI to their advantage. Those who overlook it have a complete folder and an untested risk.
SIDD works with AI itself. LexCommand, our in-house, citation-backed legal AI, traces every legal statement back to a retrievable primary source. Assessment and responsibility stay with our consultants. In our data protection advisory we establish the actual state of your data processing. With a penetration test we check whether the technical measures deliver what the documentation promises. To discuss a first assessment, reach us via the contact form.
Sources
All sources accessed on 30 September 2026.
- Federal Act on Data Protection (FADP, SR 235.1), Fedlex, status as of 7 July 2025 (English translation, not legally binding)
- Ordinance on Data Protection (SR 235.11), Fedlex, status as of 1 December 2025 (English translation, not legally binding)
- Regulation (EU) 2016/679 (GDPR), EUR-Lex
- FDPIC: Guide to Technical and Organisational Data Protection Measures (TOM), notice of 23 January 2024
This article is general information and not legal advice.
