AI Act compliance is widely seen as a legal matter. Every new regulatory deadline spawns its own ecosystem of experts, and the AI Act is no exception.

Yet the real question goes well beyond the legal framework. It's operational, and it's uncomfortable: do you know exactly which AI systems are running in your information system today? On what data, with what level of decision-making autonomy, under whose responsibility?

For many CIOs, the honest answer is "no." And that's precisely where the real issue for your organization begins.

In a nutshell

The AI Act came into force in August 2024 and is rolling out in successive waves through 2027. For CIOs, this isn't just about building an action plan to meet regulatory obligations: the regulation assumes a level of control over the AI ecosystem that most organizations don't yet have.

Here, you'll understand what the AI Act really requires, and why only an approach that goes beyond legal compliance can build something that holds up over time. To go further and get a complete action plan (risk levels, timeline, detailed steps, and an operational checklist), check out Smoteo's practical guide.

How does the AI Act apply to your organization?

As the world's first regulatory framework on artificial intelligence, the AI Act doesn't only target software vendors or major tech platforms. It applies to any organization that develops, deploys, or uses AI systems that produce effects on people located in the European Union, regardless of where that organization is based.

In other words: if your activity affects users established in the EU, you're concerned, no matter where your company is headquartered.

In practice, the regulation distinguishes three regulatory roles, which IT departments frequently combine:

• The provider, who develops or places an AI system on the market. Your IT department is a provider when it builds its own tools in-house.

• The deployer, who uses an AI system in a professional context, including via a third-party SaaS tool. Your IT department is a deployer when it integrates a third-party tool - a Microsoft Copilot, an HR scoring SaaS tool, or a generative AI API connected to a business application, for example.

• The importer or distributor, who markets solutions originating outside the EU. Your IT department holds this role if it redistributes internally solutions developed outside the EU - which is the case for nearly all major language models.

This overlap has a direct consequence: IT cannot delegate compliance to its vendors. Even when it purchases a third-party solution, it remains responsible for how it uses that solution - from risk classification to human oversight to documentation. The provider is responsible for their system. The deployer is responsible for their deployment and the conditions under which they use it in their own context.

What changes compared to GDPR

The instinct is understandable: many organizations have approached the AI Act as a natural extension of GDPR. The reality is more nuanced.

GDPR applies to the company as an entity. The AI Act, on the other hand, applies system by system. The same organization can therefore have very different obligations depending on the tools it deploys - even within a single department. In practical terms, this means having compliant data governance isn't enough: you need to be able to classify each system individually, justify that classification, and keep it up to date.

Organizations already GDPR-compliant have a useful foundation: a processing register, impact assessments, data governance. But that's not enough. The AI Act covers the system, where GDPR covers the data. One aims to protect people in their interactions with AI systems; the other protects their personal data.

But the two frameworks overlap as soon as an AI system processes personal data.

How to Ensure Compliance with the AI Act

Download the guide

What are the penalties for AI Act non-compliance?

Penalties are often the first thing that comes to mind when discussing AI Act compliance. The topic deserves to be addressed clearly - but also put into perspective.

The regulation provides for three tiers of administrative fines, proportional to the level of risk involved and the size of the organization:

• Prohibited uses (unacceptable risk) carry fines of up to €35M or 7% of global annual turnover

• Breaches of obligations applicable to high-risk systems: up to €15M or 3% of global turnover

• Breaches of transparency obligations: up to €7.5M or 1% of global turnover

For SMEs, fines are capped at whichever is lower between the flat threshold and the percentage of turnover - an important distinction for mid-sized organizations.

But fines aren't the real risk. The real risk, for an IT department, is being unable to respond to an audit for lack of documentation, and having to scramble to reconstruct under pressure what should have been built in advance. If regulators identify a high-risk system deployed without prior classification, without a usage register, without formalized human oversight, good faith won't make up for the absence of a real process.

Delays aren't a signal to wait

You may have noticed that in 2026, the EU pushed back certain high-risk deadlines. This isn't a political retreat, it's a technical consequence. The European standardization bodies CEN and CENELEC weren't able to produce the harmonized standards within the originally planned timeframe. Without these standards, companies don't know exactly what to do, or how to demonstrate compliance to regulators.

In November 2025, the European Commission therefore proposed (via the Digital Omnibus) tying the application date of high-risk rules to the actual availability of these support tools. A political agreement was reached on May 7, 2026. The deadline for standalone high-risk systems is now set at December 2, 2027.

"The AI Act compliance timeline is significant. But the steps of mapping, classification, technical documentation, and setting up human oversight take time: four to six months on average for the first four steps, in a well-structured organization. Starting now means giving yourself the means to move forward without being caught off guard."

- Fouzia Mahieddine, co-founder at Smoteo

Why compliance is, above all, a governance problem

There's one question the AI Act forces you to answer: do you know exactly what's running in your information system? Not what should be running. What's actually running, today, on what data, under whose responsibility.

This is exactly where AI Act compliance stops being a legal matter and becomes a governance matter.

Shadow AI: what you can't see, you can't govern

Shadow AI refers to all the AI use cases deployed within a company without validation or tracking by IT — accumulating through decentralized decisions. It might be a SaaS tool adopted directly by marketing, a copilot activated by a developer on their own machine, a machine learning model embedded in a customer service tool, or a generative AI API integrated into a business application by an external vendor, without ever going through an architecture review.

And this isn't an isolated scenario. According to a 2026 Flexera study, 70% of IT leaders believe business teams are purchasing more cloud and SaaS applications than IT is aware of.

"From a regulatory standpoint, every untracked tool represents an unassessed, undocumented, unmanaged exposure. What you can't see, you can't govern. And what you don't govern, you can't defend."

- Fouzia Mahieddine, co-founder at Smoteo

The consequence: mapping isn't enough

Inventorying AI systems is necessary, but it's not sufficient.

What the AI Act actually requires goes well beyond an inventory.

You need to:

• Connect each system to its architectural context, the data flows it relies on, and the business processes it touches.

• Assign a named owner to each system.

• Document data quality.

• Formalize human oversight mechanisms.

And of course, keep all of this continuously up to date (not produce an annual snapshot that's already outdated by the next deployment), to ensure no system is left without an owner or current documentation.

This is exactly where static approaches show their limits. A spreadsheet, a one-off AI audit, or a frozen register can't hold up over time in an IT environment that's constantly evolving. AI features get silently switched on inside existing solutions, and vendors embed AI components into deliverables without notice. In this context, every new SaaS deployment is a potential unclassified exposure.

In short: AI Act compliance isn't a state you reach - it's a capability you maintain.

At any given time, you need to be able to answer:

• Which AI agents are operating in my IT environment?

• On what data?

• With what level of decision-making autonomy?

• Who is responsible for them?

• Is their documentation up to date?

• Are they subject to human oversight, and how?

These are the questions regulators will ask - and that your executive committee will, sooner or later, ask too. And if the answer to any of these is "I don't know," you have an AI governance problem, not just a compliance problem.

How to Ensure Compliance with the AI Act

Download the guide

The structural link between IT governance and AI compliance

AI Act compliance isn't a side project running parallel to existing IT governance. It builds on it… or it exposes its gaps.

If your organization has already structured its application portfolio, its capability mapping, and its IT risk management, you're starting six to twelve months ahead. If you haven't yet built that foundation, you'll need to build both at once — which is doable, but demanding.

In this sense, the AI Act acts as a magnifying glass. It exposes governance gaps that existed before it, and that should have been fixed regardless. Investing in an IT and AI governance framework is a strategic asset that pays off well beyond the AI Act: strategic alignment, portfolio management, relationship with the executive committee, control over operational risk, and more.

How do you build AI Act compliance that lasts?

AI Act compliance should be treated as a capability to build, with a named sponsor, a dedicated team, defined milestones, and an allocated budget. The December 2, 2027 deadline allows time - provided you don't let it slip away.

Start with governance, not mapping

Mapping without governance produces a register with no owner; and a register with no owner is maintained by no one.

Before mapping anything, the top priority is appointing an AI compliance lead with a clear mandate, access to senior leadership, and cross-functional credibility. This role can sit with the DPO, the CISO, a specialized legal counsel, or a dedicated team.

Around that person, a cross-functional steering committee needs to be formed: IT, DPO, Legal, Security, business units. AI compliance is inherently cross-functional by nature, so trying to drive it from a single department is an organizational dead end.

This is also the moment to launch an AI Act training program for teams: the Article 4 obligation on AI literacy has applied since February 2025, and identifying who needs to upskill should be a priority from day one.

Map without blind spots, then classify use case by use case

Once governance is in place, mapping can begin. Its scope needs to leave no blind spots: in-house systems, SaaS solutions, tools embedded within third-party applications, systems under development, planned projects.

Classification then happens use case by use case, not software by software. Each category of system needs to be assessed against the Annex III criteria. Ambiguous cases should be escalated to the steering committee, and if needed, to regulators or specialized legal counsel. Tracking the entire process is itself a compliance requirement. Registering high-risk systems in the EU database is also something to plan for from this stage onward.

Document, oversee, manage continuously

For every system classified as high-risk, Annex IV-compliant technical documentation is an inevitable cornerstone. It needs to cover the system's entire lifecycle: from design through production deployment, including validation work, residual risk assessment, and potentially affected fundamental rights.

Human oversight needs to be designed in from the start - not bolted on after the fact. And AI compliance needs to be built into the validation process for every new IT project: that's what makes it possible to move forward without accumulating regulatory debt.

What this process actually requires, step by step, with the pitfalls to avoid and a full checklist, is laid out in our practical guide: download it here to make sure you don't miss anything in your AI Act compliance journey.

What does that look like with Smoteo?

Meeting AI Act requirements means deploying a solid governance infrastructure.

That's exactly what Smoteo enables, through:

• A usage register that structures the ongoing inventory of all active AI tools and initiatives by department.

• An AI Value Stream Map, to visually map AI agents across the business and IT ecosystem.

• Epic Cards that directly form the documentation base required under Annex IV - built progressively as scoping happens, with no re-entry or last-minute reconstruction under pressure.

• An AI Agent Governance module, which structures exactly what the AI Act assumes: every agent positioned in its real context, with its associated data flows and constraints.

All of it connected through a meta-model that links strategy, architecture, portfolio, and delivery into a single unified view.

Compliance is the starting point, not the destination

What the regulation brings to light aren't legal gaps: they're governance gaps that existed long before it, ones many organizations should have fixed regardless. The organizations that come out of this regulatory period stronger will be the ones that understood that managing a portfolio of AI agents in a coherent, traceable, strategically-aligned way is a lasting competitive advantage - far beyond compliance.

That's also the paradox of what the AI Act makes possible: turning a regulatory constraint into an opportunity to structure what should have been structured all along.

Being AI Act compliant isn't just about meeting a regulatory requirement: it's about building an organization that's trustworthy in its relationship with artificial intelligence. One capable of managing, evaluating, and evolving its digital ecosystem with clarity, ethics, and confidence. An organization where innovation and governance don't conflict, but reinforce each other.

Timeline of deadlines, detailed risk levels, a 7-step action plan, and an operational checklist: everything you need to structure your AI Act compliance is in Smoteo's practical guide: download it for free.

Practical Guide

How to Ensure Compliance with the AI Act

Deadline schedule, risk levels, and a comprehensive checklist to keep your project on track

Download the guide

Download the guide