How to Govern AI Use in Your Company: A Framework for EU 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 in your organization, 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. This inventory is the input for every step that follows. 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.

Who owns the process. 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 of controls are relevant here.

DNS monitoring. If you run DNS filtering, configure alerts or blocks for known AI domains that are not on your approved list. This catches browser-based tools that leave no OAuth footprint. It is not a complete picture, but it creates visibility where none existed.

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. Browser-based DLP, available through some endpoint management platforms, catches the most common pattern: a user copy-pasting from an internal document into a browser tab.

MDM-managed browser extensions. AI browser extensions can read the content of open tabs, intercept typed text, and in some configurations access authentication tokens. The risk profile is significant and they are rarely inventoried. Manage extensions through your MDM policy: block unapproved extensions, review the access scopes of approved ones, and document what each approved extension 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 and starts using it.

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 that says: "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. The mechanism, the explanation of what happens when someone pastes something into a free-tier tool and why that creates a problem, is what converts a policy document into a behavior change.

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. Each links to a deeper resource.

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 installed in browsers 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. Models produce errors regardless, so 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, writing assistants, summarization tools, and similar software, 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 (candidate screening, performance evaluation), financial decisions (credit risk, fraud detection), or any of the specific high-risk categories named in the Act, 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 apply from August 2026.

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. Example: enterprise plan required, no personal data, internal use only. 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. List approved extensions or define the approval channel.

6. Output verification. Any AI-generated content used in external documents (client proposals, contracts, public communications) 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 landscape requires it.

The template version of this outline, with example language and a data classification section you can adapt to your environment, is available to download below.

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. Approving a tool without specifying the plan tier leaves the data exposure open.

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 landscape 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. They are often installed in seconds, with broad browser permissions, by employees who did not think of it as an IT decision. 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, particularly for the data classification rules, makes compliance a choice rather than a compliance 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. A data classification that includes personal data as a protected category closes the most common AI-related GDPR gap.

ISO 27001. 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 to AI governance: specifically, controls over third-party data processors and over data shared with external systems.

NIS-2 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. As described above, the deployer obligations in the Act 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.

‍