The EU AI Act in Practice
.png)
For most of the past two years, European boardrooms treated the EU AI Act as a date on a calendar.
That framing no longer works. The regulation is already partly in force, its timeline has just been
rewritten, and many of its most important provisions still depend on standards and guidance that
are not finished. For organisations trying to scale AI, the real question is no longer when the Act
applies, but how to build AI adoption so that compliance becomes a by-product of good practice
rather than a separate project.
Where things stand now
The first amendment to the Act has already landed. The Digital Omnibus on AI, Regulation (EU)
2026/1744, was approved by the European Parliament on 16 June and the Council on 29 June,
published in the Official Journal on 24 July, and entered into force on 27 July 2026. The practical
calendar now looks like this:
The headline “the deadline moved” is misleading. Since 2 August 2026, deployers must disclose
when people are interacting with an AI system and when content is artificially generated or
manipulated, and providers of generative systems must mark outputs in a machine-readable way.
Neither the chatbot disclosure requirement nor the deepfake labelling requirement received any
grace period. Any company running a customer-facing assistant or producing synthetic marketing
content is already in scope today.
Brake or enabler for AI adoption?
The Act is frequently portrayed as a brake on innovation. In practice, its effect on adoption depends
on how an organisation responds. Companies that treat it as a legal checklist tend to freeze: pilots
stall while legal teams debate classification, and business units quietly adopt ungoverned tools
instead. Companies that treat it as a design specification tend to move faster, because the Act
essentially codifies what mature AI programmes do anyway: know what systems you run,
understand their risk, document decisions, keep humans meaningfully in control, and monitor
performance after deployment.
The 16-month reprieve on high-risk obligations creates a strategic choice. It can be used as breathing
room to build governance properly, or it can be spent waiting. The second option is risky: the
underlying obligations have not been softened, only deferred, and organisations that postpone will
face the same workload in 2027 with less time and more AI already embedded in their processes.
How companies should prepare
Preparation does not need a complex framework. It comes down to five moves.
Build an AI inventory. You cannot classify what you cannot see. This includes internally built models,
AI features inside SaaS products (HR platforms, CRM, ERP), and employee use of generative tools.
For most mid-market organisations, the inventory reveals far more AI than leadership expected, and
most of it arrived through procurement rather than development.
Classify by risk and by role. For each system, determine the risk tier (prohibited, high-risk,
transparency-only, minimal) and your role (provider, deployer, importer, distributor). Role matters
as much as risk. A company that significantly modifies a vendor’s system, or puts its own brand on it,
can become a provider and inherit the full provider obligations.
Fix what is live now. Transparency obligations apply today. Chatbot disclosures, labelling of AI-
generated content, and prohibited-practice screening (for example, emotion recognition in the
workplace) should be closed first.
Embed governance into existing processes. Rather than creating a parallel “AI compliance” function,
integrate AI checkpoints into procurement, vendor due diligence, product development, data
protection impact assessments, and internal audit. Vendor contracts in particular need updating:
deployers depend on providers for documentation, instructions for use, and logging capabilities they
cannot produce themselves.
Invest in literacy as capability, not a tick-box. Article 4 was rewritten from a duty to ensure a
sufficient level of AI literacy into a duty to take measures to support its development — an
obligation of effort rather than result. Legally, the bar is lower. Operationally, it is not: untrained
staff remain the most common source of AI misuse, data leakage, and poor decisions based on
unverified output.
The gaps that still need to be addressed
Several structural gaps make compliance harder than the text suggests.
Standards are behind the timeline. The Act relies on harmonised technical standards to translate
legal requirements into testable criteria, and these are still incomplete. The delay was driven partly
by a persisting shortage of notified bodies and a standards gap. Crucially, the standards-linked
conditional mechanism originally proposed by the Commission was dropped in favour of fixed dates.
This gives businesses certainty, but deadlines now apply regardless of whether harmonised
standards are ready. Organisations may have to demonstrate conformity against requirements
whose technical interpretation is still being written.
Agentic AI is largely unaddressed. The Act was drafted around discrete AI systems with a defined
intended purpose. Autonomous agents that chain tools, call other models, act across systems, and
adapt their behaviour at runtime fit awkwardly into that model. Who is the provider of a multi-agent
workflow assembled from a GPAI model, a third-party orchestration layer, and internal tools? How is
“intended purpose” defined for a general agent? How does human oversight work when an agent
executes dozens of actions per minute? The Act offers no specific answers, yet this is exactly where
enterprise adoption is heading.
The GPAI value chain is thin in the middle. Obligations for foundation model providers and for
deployers are relatively clear. The downstream integrators who fine-tune or wrap those models into
business applications sit in a grey zone, dependent on upstream documentation they cannot verify.
Liability remains a separate question. The Act governs market placement and use, not who pays
when AI causes harm. The proposed AI Liability Directive was withdrawn, leaving liability to the
revised Product Liability Directive and national tort law. Compliance with the Act does not equal
protection from claims.
Regulatory overlap is unresolved. AI obligations interact with GDPR, DORA, NIS2, the Medical
Devices Regulation, and sector rules, each with its own authority and reporting logic. A bank’s credit-
scoring model or a hospital’s diagnostic support tool may face three or four overlapping regimes
with no single point of coordination. National enforcement structures are also being built at
different speeds, which creates the risk of divergent interpretation across member states.
Where the Act creates ambiguity
Beyond the gaps, the text contains interpretive grey areas that organisations must resolve
themselves, often without guidance.
The definition of an “AI system” is broad and functionally based, which leaves many advanced rule-
based and statistical tools in a grey area. High-risk classification includes an exemption for systems
that perform only narrow procedural or preparatory tasks, but the boundary between “preparatory”
and “materially influencing a decision” is a judgement call. The Omnibus provided some relief,
clarifying that AI systems that only assist users or optimise performance will not automatically face
high-risk obligations if their failure or malfunction does not create health or safety risks. The line
between deployer and provider, triggered by “substantial modification”, remains undefined in
practical terms, as does what counts as effective human oversight.
The consequence of ambiguity is not just legal risk; it is decision paralysis. When classification is
uncertain, organisations tend either to over-classify (slowing adoption and inflating costs) or to
under-classify (accumulating hidden exposure). The pragmatic response is to document the
reasoning behind each classification decision. A defensible, recorded rationale is far stronger in front
of a regulator than a correct answer reached by accident.
The impact on daily operations
The long-term impact of the Act is operational, not legal. Staying compliant means AI governance
must work at the pace of AI adoption: new tools are procured monthly, models are updated
continuously, and employees experiment daily. An annual compliance review cannot keep up.
Organisations that succeed will treat the AI Act the way mature companies treat GDPR or
information security: as a standing operating capability with clear ownership, a living inventory,
lightweight intake and review for new use cases, vendor requirements built into procurement, and
post-deployment monitoring. The stakes justify the investment. Violations of prohibited practices
can lead to fines of up to €35 million or 7% of total worldwide annual turnover, whichever is higher.
But the stronger argument is commercial: customers, auditors, and business partners increasingly
ask for evidence of responsible AI, and the Act gives that evidence a common language.
Conclusion
The EU AI Act is neither the innovation killer its critics claim nor the finished rulebook its supporters
hoped for. It is an evolving framework with firm principles, shifting timelines, and meaningful gaps,
particularly around standards, agentic AI, and liability. The organisations that will benefit most are
those that stop waiting for full clarity and start building the governance muscle now: inventory,
classify, fix what is live, embed controls into existing processes, and invest in people. Done well,
compliance and adoption stop being competing priorities and become the same programme.
Meet us
