AI Governance & Compliance
A practical framework for mid-size and enterprise companies to govern AI adoption under the EU AI Act without slowing the business down.
A practical framework for mid-size and enterprise companies to govern AI adoption under the EU AI Act without slowing the business down.
Two years ago, AI governance was a topic for legal counsel and a handful of forward-looking compliance officers. Today it sits on board agendas alongside cybersecurity and financial controls, and for good reason. AI adoption inside mid-size and enterprise organizations rarely follows a single, sanctioned rollout plan. It arrives through dozens of parallel channels at once: a marketing team subscribing to a generative writing tool, a sales team piloting an AI note-taker, an engineering group experimenting with a coding assistant, a vendor quietly embedding a machine-learning feature into a platform you already pay for. Each of these decisions feels small in isolation. Collectively, they create an AI footprint that no single person in the organization can fully describe — let alone defend in front of a regulator, an auditor, or a works council.
This is the core problem AI governance exists to solve. It is not about slowing down experimentation or building a compliance department around every prompt. It is about giving the organization visibility into what AI systems are in use, what data they touch, who is accountable for them, and how decisions get made when something goes wrong. Done well, governance is closer to an operating system for AI adoption than a control function bolted onto it. Done poorly — or not at all — it becomes something the organization discovers it needs only after an incident: a customer complaint about an automated decision, a data protection authority inquiry, a journalist asking why a chatbot said something it shouldn't have, or a works council objecting after the fact to a monitoring tool nobody consulted them on.
The regulatory backdrop matters, but it is not the only reason to act. Even in jurisdictions with lighter AI-specific regulation, the underlying risks — data leakage through consumer AI tools, biased or unexplainable automated decisions, reputational exposure from AI-generated content — are the same. What the EU AI Act does is give these risks a structure and a timeline, which makes it a useful forcing function for building governance that would be good practice regardless.
The AI Act organizes AI systems into four risk tiers, and understanding which tier your use cases fall into is the single most clarifying exercise a governance program can run.
Unacceptable risk covers a short list of prohibited practices: social scoring by public authorities, certain forms of biometric categorization that infer sensitive attributes, and emotion-recognition systems used in workplaces or schools (with narrow safety-related exceptions). These prohibitions have been enforceable since February 2025. Very few mid-size or enterprise companies operate anywhere near this category, but it is worth confirming explicitly rather than assuming.
High-risk systems are those listed in Annex III — think AI used in recruiting and HR decisions, creditworthiness assessment, access to essential services, and critical infrastructure management. These carry the heaviest obligations: conformity assessments, technical documentation, human oversight design, and post-market monitoring. Annex I covers a second high-risk category: AI embedded in regulated products such as medical devices, machinery, or lifts, governed largely through existing product-safety frameworks.
Limited-risk systems trigger transparency duties rather than conformity assessments: chatbots must disclose that users are interacting with AI, and synthetic or manipulated content (including deepfakes) must be labeled as such.
Minimal-risk is everything else — and this is where the large majority of AI use inside a typical mid-size company actually sits. Drafting assistants, internal search tools, code completion, meeting summarizers, and most productivity-oriented AI features fall here, with no specific AI Act obligations attached beyond general good practice.
The practical takeaway for most readers of this page: your organization's AI footprint is very likely concentrated in the minimal- and limited-risk tiers, not the high-risk tier that dominates AI Act commentary. That is genuinely reassuring, and it is worth saying plainly rather than letting anxiety about "the AI Act" drive disproportionate caution across the board. The discipline is in knowing this with confidence rather than assuming it.
One further complication worth naming honestly: the regulatory timeline itself has been moving. As of mid-2026, a provisional agreement reached in May 2026 under the so-called Digital Omnibus process has pushed back several key dates — Annex III high-risk obligations from August 2026 to December 2027, and Annex I product-embedded obligations from August 2027 to August 2028, as currently scheduled. Obligations on providers of general-purpose AI models have largely stayed on their original August 2027 track. Formal adoption and publication of these changes were still pending at the time of writing. The lesson here is not to memorize specific dates — they may shift again — but to build a governance program that tracks the regulatory calendar as a living input rather than treating any single date as fixed. A program built around "what applies today and what to watch for" ages much better than one built around a static compliance checklist.
One of the most valuable reframes a governance engagement can offer a client is clarifying which role the organization actually occupies under the AI Act, because the obligations attached to each role are dramatically different.
A provider is an organization that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name. Providers of high-risk systems face the full weight of the regulation: conformity assessments, detailed technical documentation, risk management systems, and registration obligations.
A deployer is an organization that uses an AI system under its own authority — typically a vendor's product — without having built it. Deployer obligations are real but considerably lighter: maintaining human oversight, monitoring the system for signs of malfunction or unexpected behavior, informing and consulting works councils where employee-facing systems are involved, and in some circumstances informing individuals that an AI system is being used in a decision that affects them.
Here is the point that matters most in practice: the overwhelming majority of mid-size and enterprise organizations, including most DACH-region companies engaging AI vendors for HR software, customer service tools, or analytics platforms, are deployers, not providers. They are not building foundation models or placing high-risk AI systems on the market — they are procuring and configuring tools built by others. Recognizing this distinction early in a governance engagement often does more to right-size the compliance effort than any other single step, because it shifts the conversation from "how do we build a conformity assessment program" to "how do we exercise good oversight over the tools we buy." Those are very different projects, and confusing them is one of the most common ways organizations either over-invest in compliance theater or under-invest in the oversight they actually owe.
The most common governance failure mode is not a mishandled high-risk system — it is shadow AI: employees and teams adopting consumer-grade AI tools with company data, entirely outside any central visibility, because no faster sanctioned path existed. The fix is not a ban. Bans against convenient tools reliably fail; they just push the behavior further out of sight. The fix is a lightweight intake process that is faster to use than going around it.
At minimum, every new AI tool or model — whether a SaaS subscription, a browser extension, a custom-built model, or an AI feature embedded inside a vendor platform you already use — should be logged in a central AI use-case register before rollout. The register needs only a handful of fields to be useful: the tool's purpose, the categories of data it will touch, the vendor or model provider behind it, and a named business owner accountable for it. This single artifact is often the most valuable deliverable of an entire governance engagement, because it is the first time the organization can actually see its own AI footprint in one place.
The approval process itself should be tiered, mirroring the AI Act's own risk logic rather than inventing a new framework from scratch:
The point of tiering is speed: most requests should clear the first gate in days, not weeks, freeing the full review process for the smaller number of cases that genuinely warrant it.
AI governance does not exist in a vacuum from GDPR — in practice, most of the sharpest questions a governance program has to answer sit exactly at the intersection of the two frameworks.
Data minimization and purpose limitation apply to anything fed into a prompt, a fine-tuning dataset, or a retrieval-augmented generation pipeline just as they apply to any other processing activity. Teams building internal AI tools need the same discipline about what data goes in that they would apply to a traditional database: only what is necessary, for a defined purpose, retained no longer than needed.
Data Protection Impact Assessments become mandatory, not optional, wherever an AI system performs profiling or drives automated decisions that affect individuals — think candidate screening, credit assessment, or performance evaluation. A governance program should have a clear trigger rule for when a DPIA is required, rather than leaving it to case-by-case judgment each time.
Vendor due diligence deserves particular attention and is frequently under-scoped. Before adopting any AI vendor, the organization should understand its sub-processor chain, where data is hosted and processed (EU residency matters for many clients), and — critically — whether prompts and outputs are used by the vendor to train its own models. This last point is easy to miss in a standard procurement checklist and has real consequences: data submitted to a tool that trains on customer inputs can end up influencing outputs served to other customers.
Finally, retention and deletion policies for chat and prompt logs are one of the most overlooked liabilities in this space. Organizations that would never let a customer database run without a retention policy routinely let AI chat logs accumulate indefinitely, unreviewed, containing exactly the kind of personal or confidential data those retention policies exist to protect. This is a low-effort, high-value fix: define retention periods for AI interaction logs and enforce them the same way you would for any other system of record.
An audit trail is only useful if it is concrete enough to actually reconstruct a decision months later, and this is where many governance efforts stay too abstract to be useful in practice. A workable audit trail records, at minimum:
That incident log deserves special emphasis. It is, in practice, the artifact regulators, auditors, and internal risk committees actually ask to see. An organization that can produce a clear, honest record of what went wrong, when it was caught, and what changed afterward is in a fundamentally stronger position than one that has no record at all — even if the underlying incident count is identical. Audit trails are not primarily about proving nothing ever goes wrong; they are about proving the organization notices when it does and responds.
The single most important framing in this entire discussion is that governance should scale with an organization's AI maturity, not arrive as a reaction to an incident. A simple three-stage model makes this concrete.
Stage 1 — experimentation and pilots. A handful of teams are trying AI tools, use is exploratory, and the business impact of any single tool is limited. At this stage, an acceptable-use policy and a basic tool register are genuinely sufficient. Anything heavier is disproportionate and will be seen internally as bureaucratic overreach, which undermines buy-in for later stages.
Stage 2 — scaling across departments. AI use has spread beyond early adopters into multiple business units, and the aggregate footprint is now large enough that ad hoc oversight breaks down. This is the point at which a formal cross-functional governance body, standardized intake and risk-tiering (as described above), and DPIA templates become necessary rather than optional.
Stage 3 — AI embedded in core or customer-facing processes. AI is no longer a productivity add-on; it materially shapes how the company serves customers, makes decisions, or operates critical processes. This stage calls for a full compliance program: conformity-assessment-style documentation for relevant systems, continuous monitoring, and regular reporting to the board.
The common failure pattern is skipping straight from Stage 1 informality to a reactive Stage 3 scramble, usually triggered by a data leak, a shadow-AI discovery, or a regulatory inquiry. Governance debt compounds in much the same way technical debt does: the longer an organization defers building the register, the intake process, and the audit trail, the more expensive and disruptive it becomes to retrofit them across a much larger and more entangled AI footprint. The organizations that manage this well treat governance as infrastructure to build incrementally alongside adoption, not as a project to launch once, under pressure, after something has already gone wrong.
A low-cost, high-visibility first step exists at every maturity stage, and it is worth calling out on its own: Article 4 of the AI Act requires organizations to ensure that staff and anyone operating AI systems on their behalf have adequate AI literacy. This obligation has been in force since February 2025, applies regardless of which risk tier your use cases fall into, and can typically be satisfied through a short training program paired with an acceptable-use policy. It is one of the few AI Act obligations that a mid-size company can point to as already complete, well ahead of the higher-risk conformity obligations still years out on the calendar.
For organizations operating in Germany, there is a compliance dimension that runs entirely independent of AI Act risk classification and is easy to underestimate: the co-determination rights of the Betriebsrat under Section 87 of the Works Constitution Act (BetrVG). These rights cover the introduction of technical systems capable of monitoring employee behavior or performance, and a striking number of everyday AI tools trigger them — productivity trackers, AI-assisted performance review tools, and call-center copilots among the most common examples.
Crucially, this trigger has nothing to do with whether the AI Act classifies the tool as high-risk. A tool the AI Act treats as minimal-risk can still require works council consultation under German labor law if it has monitoring capability. This means the internal approval workflow needs a dedicated works-council trigger, checked separately from — and in addition to — AI Act risk classification. Building this as a distinct checkpoint in the intake process, rather than assuming AI Act compliance covers labor-law obligations, avoids one of the more painful and avoidable governance gaps for organizations with a German workforce.
It is worth closing on a reframe that executive audiences often find more persuasive than a purely compliance-driven pitch: well-designed governance is an enabler of speed, not primarily a brake on it. An approved-tool catalog and a fast, well-understood intake path let business units adopt new AI tools with far less legal back-and-forth per request than they would face without one. The alternative — ad hoc, ungoverned adoption across the organization — tends to work fine for a while and then forces an abrupt, company-wide freeze-and-review process the moment something goes wrong, which is far slower and more disruptive for everyone than the lightweight process it replaced.
The business case for investing proactively is also worth stating plainly, once, without overstating it: penalties for prohibited AI practices under the AI Act can reach up to EUR 35 million or 7% of global annual turnover, and other violations up to EUR 15 million or 3%. These figures justify building governance capability; they are not a reason to operate from fear, and a well-run program should not be sold on fear either.
For organizations operating globally, it is also worth noting that AI Act obligations are not confined to EU-headquartered companies. They can apply extraterritorially wherever an AI system's outputs are used in the EU market, regardless of where the system was developed or deployed from. Global enterprises frequently need to reconcile EU AI Act governance with other frameworks operating in parallel — the NIST AI Risk Management Framework in the United States being the most common reference point — and a well-designed governance program should be built to map cleanly onto both rather than treating EU compliance as a separate, bolted-on track for European operations alone.
Whatever your organization's current maturity stage, the practical starting point is almost always the same: build the AI use-case register, put a lightweight tiered intake process behind it, and pair it with a short AI-literacy program for staff. This is achievable in weeks, not quarters, and it gives the organization the visibility it needs to make every subsequent governance decision — including when and how to scale toward the fuller program that later stages require.