Common AI Data Protection Mistakes That Prove Costly
Why AI data protection mistakes are getting expensive right now
An AI assistant is activated in minutes, a chatbot goes live within days, a copilot is rolled out with a licence click. The temptation is strong to move fast first and deal with data protection later. That order is exactly what gets expensive. Not because AI is subject to special rules, but because existing law applies in full: the Federal Data Protection and Information Commissioner (FDPIC) has made clear that the Swiss Federal Act on Data Protection (FADP) is worded in a technology-neutral way and is therefore directly applicable to AI-supported data processing. Where there is an EU nexus, the GDPR and the EU AI Act come on top.
The costs rarely arise where companies expect them. The fine is only one part. In practice, what weighs more heavily is the halted project that has to be rebuilt after the fact, the enterprise customer who walks away during the vendor review and the incident in which confidential data ends up in someone else's model. The same six mistakes keep recurring. None of them is exotic, all of them are avoidable. This article shows what many companies are getting wrong right now, what it costs and how to do better.
Mistake 1: Tolerating shadow AI on private accounts
The most common mistake starts without a project and without a decision. Employees paste customer correspondence, application documents or draft contracts into free AI accounts because it speeds up their work and nobody has set any other rule. For the company, this is a disclosure of personal data to a third party: without a contract, without a check of the recipient country and often with the possibility that the inputs are used to train the model. For law firms, medical practices, banks or fiduciaries, professional secrecy is at stake as well.
This gets expensive twice over. A prompt that has left the company cannot be recalled, and a blanket ban merely shifts usage to private devices. The better route is a short, readable AI policy with three elements. First, a list of approved tools with business accounts. Second, a simple data classification that defines what never belongs in a prompt. Third, training that illustrates both with concrete examples. Our articles on ChatGPT at work and the AI policy template for SMEs show what such a framework looks like.
Mistake 2: Using AI providers without a contract or transfer check
Anyone who has personal data processed by an AI tool is, as a rule, engaging a processor. Under Art. 9 FADP and Art. 28 GDPR this requires a data processing agreement (DPA), and it must be in place before the first data flows. In practice it is often missing, because the tool was bought with a credit card or because nobody checked whether the chosen plan includes a DPA at all. Just as often it remains unclear whether the provider may use inputs to improve its models, which sub-processors it engages and how long prompts and outputs are retained.
Then there is the cross-border disclosure. Many AI providers process data in the United States or access it from there. That is only permitted on a basis under Art. 16 and 17 FADP, for example the provider's certification under the Swiss-U.S. Data Privacy Framework or standard contractual clauses with a documented risk assessment. Anyone who wilfully skips this step risks a personal fine under Art. 61 FADP and, in the vendor review, the awkward question of the basis on which customer data sits with the model provider. The better route: choose a business or enterprise plan with a DPA, contractually exclude training use, and document data location and sub-processors. Our article on the Swiss data processing agreement explains the minimum content.
Mistake 3: Starting without an inventory or a DPIA
Many companies cannot say which AI applications they are running, which data flows into them and who is responsible. Without that overview, the foundation for everything else is missing. The record of processing activities under Art. 12 FADP remains incomplete, the privacy notice is no longer accurate, and nobody notices when a pilot quietly becomes a production system.
The missing data protection impact assessment (DPIA) has particularly serious consequences. Art. 22 FADP requires one where processing may entail a high risk to the personality or fundamental rights of the data subjects. The Act expressly mentions the use of new technologies and the large-scale processing of sensitive personal data. Art. 35 GDPR follows the same logic. AI applications involving health data, applicant data, profiling or scoring regularly fall within scope. Anyone who carries out the DPIA only after go-live identifies the risks once the architecture, provider and contracts are already fixed. Every correction then costs many times more. The better route: an AI inventory as the first deliverable, a short threshold check per application and the DPIA before the decision on provider and architecture.
Mistake 4: Giving the AI assistant overly broad access
AI assistants that access internal file shares, emails and chats do not invent new permissions. They use the existing ones, and more thoroughly than any human would. What used to sit in a forgotten folder with overly broad sharing is now delivered by the assistant in response to a simple question: payroll lists, personnel files, sick notes, board minutes. The problem is not the AI, it is the permission sprawl that has grown over the years and that the AI makes visible.
Legally, this is a matter of data security under Art. 8 FADP. The Data Protection Ordinance requires access control that limits authorised persons to the personal data they need for their tasks. If internal access to HR data turns into an incident, the consequences are an investigation, a possible notification to the FDPIC under Art. 24 FADP and a loss of trust among staff. On top of that come new attack paths such as prompt injection, where manipulated content induces the assistant to hand over data. The better route: clean up permissions before the rollout, activate sensitivity labels for sensitive data, start with a pilot group and switch on logging. Our article on Microsoft Copilot and data protection describes the concrete steps for Microsoft 365. For technical testing of AI applications, there is AI Security.
Mistake 5: Staying opaque and letting the AI decide
Data subjects must know that their data is being processed and for what purpose. The duty to inform under Art. 19 FADP applies to AI as well. Anyone who introduces a chatbot in customer service, AI-supported pre-selection in recruiting or automated analysis of customer calls must update the privacy notice. The FDPIC expects the purpose, functioning and data sources of AI-supported processing to be made transparent. Where there is an EU nexus, Art. 50 of the EU AI Act has additionally required since 2 August 2026 that people can recognise when they are interacting with an AI system.
It becomes delicate when the AI does not just assist but decides. If a decision with legal effects or a significant adverse effect is based exclusively on automated processing, for example a loan refusal, a rejection in a recruitment process or the termination of a contract, Art. 21 FADP and Art. 22 GDPR apply. The data subject must be informed, may state their point of view and may request a review by a human. In its SCHUFA judgment of December 2023 (C-634/21), the Court of Justice of the European Union held that even an automatically calculated score can be such a decision if it is decisive for the outcome. A human who merely rubber-stamps the AI's result does not change that. The better route: record for each application whether the AI prepares or decides, provide for a genuine human review with real discretion, and build the information into the privacy notice and the process.
Mistake 6: Repurposing customer data for training and testing
Data collected to perform a contract is not automatically training material. The principle of purpose limitation under Art. 6 para. 3 FADP and Art. 5 GDPR requires that personal data is only processed in a way that was recognisable at the time of collection or is compatible with it. Anyone who uses support tickets, call recordings or customer documents to train their own model, to fine-tune a third-party model or to fill an assistant's knowledge base needs a sound justification and must inform the data subjects. In B2B business, the DPA with the customer regularly rules out such use in addition.
The second part of the mistake shows up later. If a person requests access or erasure, the company must know where their data sits: in prompts, logs, vector databases and training data sets. Individual records can hardly be removed from a trained model in a targeted way. In the worst case, the only option is retraining without the data concerned. The better route: check and document purpose compatibility before any secondary use, work with anonymised or synthetic data wherever possible, define retention periods for prompts and logs, and extend the access and erasure processes to the AI systems.
What the mistakes cost and how to do better
The direct sanctions are well known but often misjudged. The FADP provides for fines of up to CHF 250,000, and not against the company but against the responsible individual. What is punishable is the wilful breach of, for example, the duties to inform, the rules on processors, on cross-border disclosure or the minimum requirements for data security. Our article on FADP fines and personal liability explains the details. The GDPR threatens fines of up to EUR 20 million or 4 percent of worldwide annual turnover, the EU AI Act, depending on the infringement, up to EUR 35 million or 7 percent. In addition, the FDPIC can order that processing be adjusted, suspended or discontinued and that personal data be deleted. In practice, the indirect costs usually weigh more heavily: rebuilding a system that has already been introduced, delays in sales because the customer's security questionnaire cannot be answered cleanly, and the effort of handling an incident.
All six mistakes can be avoided with manageable effort if the order is right: inventory before rollout, contract before data flow, DPIA before the architecture decision, permissions before the assistant, information before go-live, purpose check before training. SIDD supports you with the AI Governance Check, which delivers a documented AI inventory, an initial classification and a prioritised action list. The AI Officer keeps your AI governance current on an ongoing basis. Our data protection advisory covers the data protection side, from DPA to DPIA. To discuss a first assessment of your AI applications, reach us via the contact form; for implementation, request a proposal via our quote form.
