How to govern AI use in your company: a framework for European organizations

why bans do not work

The instinct when AI tools first surface as a governance concern is often to restrict them. Block the domains. Add a line to the policy that prohibits unauthorized AI use. Wait for the risk to recede.

The problem is that AI tools have become embedded in how people work. Microsoft research finds that 1 in 2 people using AI at work do so without their employer's knowledge. A blanket ban does not stop this. It pushes it underground. Employees continue using the tools. They stop mentioning it to IT. The data still flows. The organization has less visibility than before, not more.

The second problem is the productivity cost. AI tools are genuinely useful. Restricting them without a framework that identifies which tools are acceptable creates friction that your teams will route around. Governance that works starts from a different premise: AI adoption is a given. The goal is to make it visible, classifiable, and controlled, so that the tools people use are tools you have assessed, and the data that moves is data you have said can move.

the governance framework

step 1: visibility first

You cannot govern what you cannot see. This is the precondition for every other step. Visibility means knowing, at any point, which AI tools are in use, by whom, through what channels, and with what access to company data. That includes tools IT deployed, tools teams adopted independently, personal AI accounts used for work, AI browser extensions installed on managed devices, and connector apps that received OAuth grants to access company email or documents.

The practical starting point is your identity provider. Pull the full list of OAuth grants and filter for AI-related apps. This alone surfaces a significant portion of active AI tool use, including tools that never went through IT. Then check DNS logs for known AI domains, which catches browser-based tools with no OAuth footprint. Then review the browser extension inventory if you manage endpoints. What you are building is an inventory: a list of what is actually running, with the access each tool holds. A policy written without it will contain gaps the writer did not know existed.

step 2: data classification

Once you know what tools are in use, the next question is what data can and cannot move into them. A data classification for AI use does not need to be elaborate. It needs to be specific enough that an employee reading it can answer the question: is this thing I am about to paste into the tool covered? Start with these categories:

• Personal data. Customer names, contact records, employee data, anything covered by GDPR. No consumer-tier AI tool without a DPA.
• NDA-covered material. Anything from a client engagement or vendor relationship with confidentiality terms.
• Source code. This is the category that most commonly reaches external models without governance (the Samsung incident in 2023 involved source code and internal data pasted into ChatGPT over roughly three weeks before detection).
• Financial data not yet public. Projections, M&A information, unreleased results.
• Internal strategy documents. Roadmaps, org plans, competitive intelligence.

The classification does not prevent all risk. It gives employees a reference point, creates the basis for a policy employees can follow, and creates an audit trail that can be referenced if a question arises later.

step 3: approved-tool list and vetting process

An approved-tool list tells employees which AI tools they can use. A vetting process tells them what happens when they want to use something that is not on the list. Both are needed. A list without a vetting process becomes stale. A vetting process without a list gives employees no guidance for day-to-day decisions.

What goes on the approved list: tools that have been reviewed for the questions below, with any conditions noted, for example "ChatGPT Teams (enterprise mode required, no personal data)." The five vetting questions to answer for every tool before approving it:

1. Does the vendor offer a Data Processing Agreement (DPA)? If you are using the tool with personal data, you need one. A consumer-tier tool almost never provides this.
2. Are inputs used to train the model? Free and consumer tiers commonly retain this right. Enterprise plans with training disabled are the standard for work use.
3. What is the data residency? Where is the data stored and processed? For EU personal data, this has direct GDPR implications.
4. Does an enterprise or business plan exist that disables training? If yes, that plan is what gets on the approved list, not the free tier.
5. What security certifications does the vendor hold? ISO 27001 and SOC 2 Type II are the baseline.

Define who receives vetting requests and what the expected turnaround is. Requests that disappear into a queue drive informal adoption. A target response time, even a preliminary "this is being reviewed," keeps the process usable.

step 4: technical controls

Policy tells people what to do. Technical controls make the policy enforceable and provide a safety net for the cases where it is not followed. Three categories are relevant. DNS monitoring: if you run DNS filtering, configure alerts or blocks for known AI domains not on your approved list, which catches browser-based tools that leave no OAuth footprint. DLP on sensitive data categories: data loss prevention policies configured on the categories in your classification can flag or block uploads of covered material to external AI endpoints, and browser-based DLP catches the most common pattern of a user copy-pasting from an internal document into a browser tab. MDM-managed browser extensions: AI browser extensions can read open tabs, intercept typed text, and in some configurations access authentication tokens, so manage extensions through your MDM policy, block unapproved ones, review the access scopes of approved ones, and document what each is permitted to access. These controls do not replace policy. They address the gap between what a policy says and what happens on a given Tuesday when someone finds a useful tool.

step 5: employee education on the mechanism

The last step is telling people why the rules exist, not just what they are. A rule that says "do not enter personal data into AI tools" is less effective than an explanation: "Consumer AI tools commonly use your inputs to improve their models. Personal data entered without a DPA in place creates a GDPR exposure for the company and potentially for the customer whose data was shared. That is why the rule exists." People follow guidance they understand. This does not require a long training session. A short document, communicated at onboarding and re-referenced when the policy updates, is enough. The point is that employees know there is a policy, know where to find it, and understand enough about the reason to make the right call when they face an edge case.

the main risks, briefly

The framework above addresses the most common path by which AI governance breaks down. The risks that sit underneath it are worth naming.

Data leakage into external models. Employees paste proprietary content into public AI tools: contracts, customer data, financial figures, source code. The data leaves before any policy defines the boundary. This is a visibility and policy problem, not a discipline problem.

Unvetted tools in the stack. Tools adopted without checking DPA status, training-on-data terms, EU data residency, or whether an enterprise tier exists. The exposure is proportional to the data the tool touches.

AI browser extensions with broad access. Extensions can read open tab content, intercept typed text, and in some configurations access session tokens. Most are not inventoried. Few have any audit trail.

Prompt injection. Malicious instructions embedded in content that an AI model processes. A document fed to an AI assistant contains hidden text that changes what the model does. The attack is invisible in the input and difficult to predict in its output. Relevant to any deployment where AI reads external or user-supplied content.

Agentic AI with over-access. AI agents that act with a user's credentials can send emails, create documents, and take actions in connected apps. The actions an over-permissioned agent can take are bounded only by the credentials it holds. Define the scope of access before deployment, not after something goes wrong.

Hallucinations in external-facing output. AI models produce confident, well-formatted, incorrect output. When that output is used in contracts, client proposals, financial reports, or external communications without a verification step, the error leaves the organization. The governance question is whether a human review step sits between AI output and external use.

what the EU AI Act means for a deployer

The EU AI Act is typically framed as a regulation for AI developers. That framing misses a significant part of the regulation's scope. The Act creates obligations for deployers, meaning organizations that use AI systems in a professional context. If your organization uses AI tools at work, the EU AI Act applies to you in some form. The question is which obligations apply and at what level.

Risk classification. The Act assigns AI systems to four categories: unacceptable risk (prohibited), high risk (significant requirements), limited risk (transparency obligations), and minimal risk (no mandatory requirements). Most general-purpose AI productivity tools fall into the limited or minimal risk categories. High-risk classifications apply to specific use cases: AI used in employment decisions, credit scoring, critical infrastructure management, and biometric identification among others.

What this means in practice for most deployers. If your AI tools are general-purpose productivity software, your primary obligation is to have an inventory of what you use, to apply transparency labeling where required (for example, disclosing that customer-facing chatbot responses are AI-generated), and to stay aware of the phased implementation timeline.

Where it becomes more demanding. If you use AI in HR processes, financial decisions, or any of the specific high-risk categories, you have deployer obligations that include a fundamental rights impact assessment, documented human oversight procedures, log retention, and informing affected individuals where required.

GDPR interaction. The EU AI Act does not replace GDPR. For AI systems that process personal data, both apply. A DPIA already required under GDPR may now need to be accompanied by an AI-specific impact assessment.

The implementation timeline. Prohibition on unacceptable-risk systems applied from February 2025. Obligations for general-purpose AI models and providers apply from August 2025. Obligations for high-risk systems in certain contexts were originally set for August 2026; the Digital Omnibus, adopted in June 2026 and pending Official Journal publication, defers standalone Annex III high-risk obligations to 2 December 2027. The practical first step is the same as for the governance framework: build an inventory of AI systems in use, then classify them.

a starter policy outline

An AI Acceptable Use Policy does not need to be long. It needs to be specific enough to follow. This outline covers the essential components.

1. Scope. Who the policy applies to. All employees, contractors, and other users accessing company systems.
2. Approved-tool list. A named list of AI tools approved for work use, with any conditions noted. The list is a living document, reviewed quarterly.
3. Data classification. The categories of data that cannot be entered into any external AI tool, with plain-language examples. At minimum: personal data covered by GDPR, NDA-covered material, source code, unreleased financial data, internal strategy documents.
4. Vetting process. What to do when you want to use a tool not on the approved list. Name the requester, the owner, and the target response time.
5. Browser extensions. Only AI browser extensions approved through MDM policy are permitted on managed devices.
6. Output verification. Any AI-generated content used in external documents requires a human review step before use.
7. Reporting. If you observe or suspect that company data has been shared with an unapproved AI tool, report it to IT. No penalty for good-faith reporting.
8. Review cadence. The policy is reviewed and updated on a defined schedule, or when a significant change in the AI tool market requires it.

common mistakes

Writing the policy before building the inventory. A policy that does not account for tools already in use will require exceptions before it is even published. Build the inventory first.

A classification that is too vague. "Do not share confidential information" does not tell an employee whether a client name in a summary falls under the rule. Specific categories with examples are what produce behavior change.

Approving the free tier of a tool. The free tier of almost any AI tool uses inputs for training and does not provide a DPA. The enterprise or business plan is what belongs on the approved list.

No vetting process for new tools. Without a defined process, employees who want to use an unapproved tool either wait indefinitely or use it informally. Both outcomes are worse than a lightweight process with a defined owner and turnaround time.

Treating this as a one-time project. The AI tool market changes fast. A policy and approved list that are not reviewed at least annually will diverge from reality. Build in a review cadence.

Ignoring browser extensions. Extensions are the most invisible category of AI tool, often installed in seconds with broad browser permissions. Include extensions in your MDM policy.

Not explaining the why. Policies without a rationale are followed less consistently than policies with one. A short explanation of why each rule exists makes compliance a choice rather than a burden.

how this maps to standards

AI governance work does not sit in isolation. It connects directly to several frameworks you may already be working against.

GDPR. Any AI tool that processes personal data requires a DPA. The approved-tool list with verified DPA status is your primary evidence of compliance on this point.

ISO 27001. Annex A includes controls for supplier relationships, information classification, and access control that AI governance work directly satisfies. An AI tool vetting process with documented records provides the supplier assessment evidence these controls require.

SOC 2. The availability and confidentiality trust service criteria both have direct relevance: controls over third-party data processors and over data shared with external systems.

NIS2 and DORA. Both require documented risk management across the technology supply chain. An AI tool with broad OAuth access to company systems is part of that supply chain. Vetting records and an approved-tool list are evidence for this requirement.

EU AI Act. The deployer obligations require an inventory of AI systems in use, classification against risk categories, and documentation of oversight for high-risk deployments. The governance framework above builds the inventory and classification as its first steps.