EU AI Act: What your company actually needs to do

The EU AI Act is not as scary as the consultants selling compliance want you to think. It’s also not as trivial as the vendors selling AI platforms want you to think. Somewhere between those two extremes is what your company actually has to do — and for most enterprises, that “actually” is a shorter list than the panic suggests.

Let’s cut through it.

The structure in one paragraph

The AI Act classifies AI systems into four risk categories: unacceptable (banned outright — social scoring, real-time biometric identification in most public contexts, a handful of others), high-risk (heavily regulated — CV screening, credit scoring, critical infrastructure, medical devices, and similar), limited-risk (transparency obligations only — chatbots must disclose they’re bots, generated content must be labeled), and minimal-risk (no specific obligations, which is the vast majority of business AI). Separately, general-purpose AI models — the foundation models — have their own regime targeting the providers, not the users.

That’s the whole taxonomy. Most enterprise AI systems sit in the limited or minimal categories.

Timelines: what’s already live, what’s coming

The Act entered into force in August 2024, and the obligations have been phasing in since. The prohibitions on unacceptable-risk systems took effect in February 2025. The general-purpose AI obligations on providers took effect in August 2025. The bulk of the high-risk system obligations landed in August 2026 for AI systems that are components of products covered by existing EU product safety legislation, with the remaining high-risk obligations reaching full applicability in 2027.

What that means practically: if you have a high-risk system in production or in your near-term roadmap, the compliance clock is already running. If you don’t, you have time to build the foundation properly rather than sprint against a fire drill.

What most enterprises actually need to do (the 80/20)

For a company that uses AI to run its business rather than to build AI products for others, the compliance work breaks into four concrete deliverables.

1. An AI system inventory. A single list of every AI system your company uses, whether built internally, embedded in a SaaS product, or delivered by a consultancy. This sounds trivial and is usually the hardest step, because shadow AI is everywhere. Marketing has generative tools nobody documented. Finance has a forecasting model in a spreadsheet. HR has a screening tool a vendor added last quarter. You can’t classify what you can’t see, and you can’t govern what you haven’t inventoried.

2. Risk classification for each item on the inventory. Which category does each system fall into? For most enterprises, 80% will be minimal-risk (recommendation engines that aren’t decisioning credit or employment, internal productivity tools, forecasting for operations), 15% will be limited-risk (customer-facing chatbots, generative content), and a handful will be high-risk. The high-risk items are the ones that determine your compliance burden. Get this classification right — and documented — because it’s the foundation for everything else.

3. Documentation for the high-risk systems. For each high-risk system: purpose, data used to train it, performance characteristics, known limitations, monitoring approach, human oversight mechanisms, and how bias and errors are detected. This is the substantive obligation. It’s not a form to fill in; it’s a living document that reflects how the system actually behaves. If a regulator or auditor asks how your credit scoring model was validated, you should be able to hand them a document that answers the question in under an hour of reading.

4. Human oversight for high-risk decisions. Whatever the AI system does, a human has to be positioned to catch, override, or investigate its outputs. That means workflow design, not just a policy document. If your AI screens CVs, who reviews the rejections? If it flags fraud, who decides to freeze the account? The oversight has to be real and traceable.

That’s the core of it. Four items. None of them require a specialized compliance platform. All of them require someone inside the company who owns the outcome.

What you probably don’t need to worry about yet

A lot of enterprise anxiety is misdirected at obligations that don’t apply.

Foundation model provider obligations. If you’re using OpenAI, Anthropic, Mistral, or Google’s models via API, you’re a downstream deployer, not a provider. The heavy documentation obligations on general-purpose models fall on the companies training them, not on you. Your obligations are around how you deploy and monitor the systems you build on top.

Conformity assessments for internal tools. The heaviest procedural obligations — third-party conformity assessments, CE marking equivalents — apply to specific categories of high-risk systems, mostly those that are components of regulated products. An internal productivity tool that helps your sales team draft emails is not in scope, no matter how much a vendor tries to convince you it is.

“AI Act certification.” There is no general certification. Some vendors are marketing what they call “AI Act compliant” products or services. Compliance is a property of how you use a system in your specific context, not an intrinsic property of the technology. Treat these labels with the skepticism they deserve.

The governance gap

The Act’s substantive obligations aren’t onerous for most companies. What is onerous is that they require a level of internal coordination that most enterprises don’t have.

Who owns the AI inventory? The CTO doesn’t want it because most of the systems weren’t built by engineering. The CISO doesn’t want it because it’s not a security artifact. Legal doesn’t want it because they aren’t close enough to the systems to classify risk. Procurement doesn’t want it because they only see the vendors, not the shadow builds.

This is the governance gap. Compliance obligations don’t create themselves an owner. Without someone whose job is to close the loop across engineering, legal, procurement, and business units, the inventory doesn’t get built, the classifications don’t get made, and the documentation stays theoretical until the regulator arrives.

This is why the AI Act is, in practice, an argument for AI leadership. Not because the regulation is punitive — the penalties are real but the compliance work itself is manageable. But because the regulation surfaces a coordination problem that was already there, waiting for a reason to become urgent.

Practical first steps

Start with the inventory. Not with a framework, not with a policy document, not with a vendor evaluation. Get one person to spend two weeks talking to every function in the company and cataloging what AI is actually in use. You will find things nobody knew about. That list is the foundation for every other decision.

Then classify. Most items will drop into minimal-risk and require no further action. A short list will require attention. Focus your compliance investment there.

Then decide who owns it going forward. That is the question the AI Act is really asking your company to answer. Not “are you compliant” but “who is accountable.” Once you have the person, the compliance work becomes a project. Without them, it becomes a permanent state of low-grade anxiety.

The good news: this is a solvable problem. Companies that treat it as a governance exercise rather than a legal panic tend to arrive at a compliance posture that’s stronger, cheaper, and more useful than what the consultants would have sold them. And the internal capability they build in the process pays dividends far beyond the regulatory obligation itself.