In nearly every company we talk to, the first artificial-intelligence system in production was not built by engineering. It was a browser tab. A support agent pasted a complaint into ChatGPT to draft a polite reply. A recruiter asked Copilot to rank fifty CVs. A finance analyst uploaded a spreadsheet of customer payments "to find the pattern". None of this went through legal, and all of it has legal consequences. This note explains what switches on the moment your people use generative tools with company or customer data, and what you can put in place in a few weeks.
1. The GDPR switches on immediately
A prompt that contains a name, an email address, an order number or a description of a person is a processing of personal data. You are the controller. The tool vendor is, depending on the plan, your processor or an independent controller that may use the content to train its models. That raises four questions you must be able to answer: what is the lawful basis, is there a processor agreement (Article 28) with the vendor, where does the data go (many consumer plans route through the US without a transfer mechanism), and did you tell the people concerned in your privacy notice. If staff use personal accounts, you have none of these in place, and a complaint or an audit will show it.
2. The AI Act adds literacy duties and, sometimes, a role
Since 2 February 2025, Article 4 of the AI Act requires every company that uses AI systems to ensure a sufficient level of AI literacy among the staff who operate them. That applies to a recruiter using a chatbot as much as to a data scientist. If the tool is used to screen candidates, assess creditworthiness or make decisions about access to services, you may also be a deployer of a high-risk system, with duties on human oversight, monitoring and information to affected people. Even where the use case is harmless, you need to know which systems are in use, which is why an AI inventory is the first deliverable in nearly every engagement.
3. Your contracts probably already prohibit it
Look at the confidentiality clause in your customer agreements and your NDAs. Most say that confidential information may not be disclosed to third parties and may only be processed on systems under your control. Uploading a customer's document to a public model is, on a plain reading, a breach of that clause, regardless of what the vendor does with it. The same applies to your employees' obligations under their employment contracts and to your own obligations as a processor under Article 28 (no sub-processors without authorisation).
4. For regulated companies it can be a reportable incident
If you are a financial entity under DORA, a provider under NIS2 or hold a licence from DNB or the AFM, an uncontrolled flow of client data to an external system may count as an ICT or security incident that triggers internal escalation and, above a threshold, reporting to the regulator. Health data, children's data and special categories lower that threshold further.
Six things that close the gap
An AI use policy of two pages: which tools are approved, which data classes may go in, what must never (special-category data, source code, customer documents), and who approves new tools. Approved business accounts with a processor agreement, no training on your content, EU data residency where offered and single sign-on, so you can see usage. An inventory of AI systems with owner, purpose and a first risk classification. AI literacy training of one hour, recorded, covering what the tools do, hallucinations, confidentiality and the policy. Updated clauses in employment terms, NDAs and customer agreements that say what is permitted. An intake step for new use cases, so the next tool goes through a thirty-minute review instead of a crisis.
None of this slows your teams down. It gives them a safe lane and the company a defensible record. If you would like the policy template and the training outline, email us.