ChatGPT at work: risks, rules and secure alternatives
ChatGPT is used daily in many companies across the DACH region – often without IT knowing, and through private accounts. The productivity upside is real, and so are the risks: confidential data in external systems, no central control, no traceability.
The question is therefore rarely whether AI arrives in a company, but by which route. A ban moves usage to private devices and removes only the visibility, not the risk.
This article sets out what actually happens to inputs, compares the available tiers and describes the requirements an enterprise solution has to meet.
What happens to inputs in ChatGPT
In consumer versions of AI chatbots, inputs may be used to improve the models. Whether that happens depends on a setting each person configures for their own account. For a company that is not a defensible basis: a setting individuals can change is not a technical or organisational measure.
Processing also typically happens on servers outside the EU and Switzerland. That pushes the question of disclosure abroad to the front – under Art. 16 FADP and Chapter V of the GDPR.
Business and enterprise versions improve the position considerably: they exclude training on inputs contractually and provide a data processing agreement. Two points remain open that no price tier resolves: the tie to a single model provider, and the question of which law governs the company operating the infrastructure.
The three tiers compared
Several tiers sit between a private account and a central platform. The comparison looks at categories, not individual products – the detail differs by provider and contract.
| Private account | Business tier of one provider | Central AI platform | |
|---|---|---|---|
| Processing location | Set by the provider, usually outside the EU | Set by the provider, regions partly selectable | Selectable, for example EU or Switzerland |
| Training on inputs | Depends on a setting configured by the individual | Contractually excluded | Contractually excluded |
| Data processing agreement | No | Yes | Yes |
| Roles, permissions, SSO | No | Yes | Yes |
| Traceability through audit logs | No | Depends on provider and tier | Yes |
| Choice of model | One provider | One provider | Several providers through one access point |
The typical risks in day-to-day work
Four risk areas recur in practice. Usually only the first one gets discussed at all.
- Data leakage: client and business data ends up in external systems by copy-and-paste – depending on the case a breach of the GDPR, the revFADP, confidentiality agreements or professional secrecy.
- Hallucinations: language models write convincingly but not always correctly. Taking figures, deadlines or legal bases at face value is the most common substantive error.
- Missing governance: without central administration there are no roles, no audit logs and no overview of who does what with which data. When someone leaves, the private account and its history stay behind.
- Dependence on one provider: building processes on a single model means carrying that provider's pricing, availability and product decisions with no fallback.
Why a ban does not work
Blocking AI tools across the board moves usage to private devices and accounts. Shadow AI grows, control falls, the productivity gains are lost – and the risk stays, only now without visibility.
There is also a practical problem: a ban is barely enforceable technically. Access through a private phone is outside corporate IT's control, and that is exactly where usage migrates.
What works better is an official offering that is at least as good as the private alternative in daily work. Only then does the rule stand a chance of being followed – and only then does the documentation arise that data protection and supervisors expect.
What the legal framework requires
The legal framework is not an obstacle to AI, but it sets conditions. Four points concern practically every company in the DACH region.
- Data protection: every input containing personal data is a processing operation – with record, information and due diligence duties under the revFADP and the GDPR.
- Processing on behalf: using an AI provider requires a contract under Art. 28 GDPR or Art. 9 FADP.
- Disclosure abroad: the processing location must be known and permissible; third countries require a safeguard.
- AI literacy: since 2 February 2025, Art. 4 of the EU AI Act requires staff to have sufficient AI literacy – regardless of the risk class of the application.
Requirements for a secure alternative
An enterprise solution should meet these criteria. They follow directly from the risks and the legal framework.
- Access to every leading model instead of dependence on a single provider.
- Hosting and data storage in the EU or Switzerland, with a clear answer on the processing location.
- Contractually assured: no training on company data, not even in aggregated form.
- Central administration with roles, permissions and single sign-on, so access reliably ends when someone leaves.
- Audit logs that evidence who accessed what and when.
- A data processing agreement for the GDPR and the revFADP, with a confidentiality undertaking available for holders of professional secrets.
From shadow AI to governed use
The order determines the outcome. Starting with the rule instead of the offering loses the people you need.
- Take stock without the threat of sanctions: which tools are actually used, for which tasks? Threaten consequences and you will not get honest answers.
- Provide an official offering that covers the most frequent tasks from that inventory.
- Write an AI policy that points to the offering instead of only prohibiting – with clear data classes.
- Roll out access centrally, assign roles, connect single sign-on.
- Train people on what the system can do, where its limits are and how output is checked. That also addresses Art. 4 of the AI Act.
- Document: add the processing to the record, update the privacy policy, file the contract.
- Follow up: watch usage, collect unmet needs, review the policy annually.
Questions to ask the provider
These questions separate defensible offerings from marketing claims. They should be answered in writing.
- In which country are inputs processed, and which law governs the company operating the infrastructure?
- Is training on our data contractually excluded – including for sub-processors?
- Which sub-processors are used, and how will we be informed about changes?
- Which individuals at the provider can access content, in which cases, and is that logged?
- How long are inputs and conversation histories retained, and how are they deleted?
- Is there a data processing agreement, and can a confidentiality undertaking be added?
Frequently asked questions
May employees use ChatGPT for work?
That is the company's decision, not the law's. Use is permissible where no personal data or confidential information flows into a system that is not secured for it. Without an internal rule employees have no basis for that distinction – which is why the AI policy is the first step.
Is a business or enterprise tier not secure enough?
It resolves two important points: training on inputs is contractually excluded and a data processing agreement is in place. What remains open is the tie to a single model provider and the question of which law governs the operator of the infrastructure. Whether that suffices depends on the sector and the type of data.
What does a secure AI platform cost?
Pricing is usually calculated per person per month and depends on functionality and user numbers. The more meaningful comparison is not the list price but the sum of individual licences, unused accounts and the effort that missing governance causes when something goes wrong.
What about data already sitting in private accounts?
It cannot be retrieved retrospectively. What helps is documenting the situation, assessing the categories of data affected and checking whether a notification duty under Art. 24 FADP or Art. 33 GDPR applies. After that, the priority is stopping the inflow rather than cleaning up backwards.
Do we need works council approval?
In Germany the works council must be involved under Section 87 (1) no. 6 BetrVG where a system is capable of monitoring behaviour or performance – which audit logs regularly are. In Austria, Sections 96 and 96a ArbVG apply. Switzerland has no comparable co-determination, but Art. 26 ArGV 3 prohibits monitoring systems aimed at controlling behaviour.
How do we handle hallucinations?
They cannot be excluded technically, but they can be contained organisationally: output counts as a draft, not as advice. For figures, deadlines and legal bases, verification at the source is mandatory. Applications that draw on your own stored documents lower the risk considerably because they return citable passages.
Sources
- Regulation (EU) 2016/679 (GDPR) · EUR-Lex
- Swiss Federal Act on Data Protection (FADP, SR 235.1) · Fedlex – Swiss Federal Chancellery
- European Data Protection Board · EDPB
Related reading
Bring AI into your company securely.
Try Custodos with your team – and see how quickly secure AI becomes productive.
- Try it with the whole team
- Set up in minutes
- Productive from day one