Regulation · Europe · Decision brief
AI Act enforcement becomes an operating-model test
The decisive question is no longer whether an organisation has an AI policy. It is whether it can prove, system by system and claim by claim, who controlled the model, the data, the change, the human decision and the evidence.
Executive judgement
The EU AI Act is moving from legislative interpretation into operational enforcement. That transition changes the economic problem. During the policy phase, a company could treat AI governance as a legal workstream: map the regulation, classify a few use cases and publish principles. Enforcement tests something harder. It tests whether legal duties have been translated into repeatable controls across procurement, product development, deployment, monitoring, incident response and supplier management.
The strategic implication is asymmetric. Organisations with a reliable inventory, role classification and evidence chain can absorb regulatory change as a controlled update. Organisations that cannot identify which model version made which consequential output face a reconstruction exercise every time a regulator, customer or auditor asks a question. That reconstruction is slow, expensive and unreliable. Compliance therefore becomes part of the technical operating model, not a document stored beside it.
Evidence
The binding baseline is Regulation (EU) 2024/1689. It establishes a risk-based system, distinguishes prohibited practices, high-risk systems, transparency obligations and rules for general-purpose AI, and allocates duties according to the actor’s role. Those roles matter. A provider placing a system on the market does not have the same obligations as a deployer using it, an importer, distributor or product manufacturer. A company may also change role when it substantially modifies a system or markets it under its own name.
The European Commission’s implementation material shows that the Act is phased rather than activated by one universal date. Prohibitions and AI-literacy provisions began applying in February 2025. Governance rules and obligations for general-purpose AI models applied from August 2025. The Commission’s enforcement powers for those GPAI obligations follow from August 2026, while providers of models placed on the market before 2 August 2025 have a later compliance date. Other obligations follow the timetable in the Act and subsequent implementation measures. Any control register that reduces this to “the AI Act starts in 2026” is therefore too crude for operational use.
The Commission’s GPAI guidelines clarify how it interprets model scope, provider status and compliance duties. The General-Purpose AI Code of Practice offers a voluntary route for demonstrating compliance in areas such as transparency, copyright and systemic risk. Voluntary does not mean irrelevant: a provider may choose another method, but it still needs evidence that the statutory result is achieved. The Code is best understood as one available compliance architecture, not a substitute for the law.
Technical governance sources reinforce the same direction. The NIST AI Risk Management Framework organises work into Govern, Map, Measure and Manage. It is not EU law, but it provides a useful control vocabulary: establish accountability, understand context, measure material risks and manage them over the lifecycle. The value of using such a framework is interoperability. Legal requirements can be mapped to operational controls without pretending that a voluntary technical framework itself proves legal compliance.
Mechanism
Enforcement pressure travels through five mechanisms. First, regulators can request documentation and evidence. Second, enterprise customers move obligations into procurement questionnaires and contracts. Third, incident reporting and post-market monitoring expose systems whose real behaviour diverges from their approved design. Fourth, employees and affected people can surface uses that were absent from the central inventory. Fifth, model and product changes can silently invalidate an earlier assessment.
A defensible operating model therefore needs a live system-of-record. Each AI use case should have a stable identifier, business purpose, owner, legal entities, affected groups, geographic scope and lifecycle state. It should record the organisation’s role, the risk classification and the reasoning behind both. It should link to the exact model and version, data categories, evaluation results, human-oversight design, security controls, supplier evidence, user information, incidents, changes and approvals. The links matter more than the existence of isolated files.
Procurement is a critical control point. A buyer should not accept the generic statement that a supplier is “AI Act compliant.” It needs model-specific answers: which entity is the provider; whether the model is GPAI; when it entered the EU market; what documentation and downstream information are available; how copyright policy is implemented; how systemic-risk duties are handled where applicable; how changes are notified; and what audit, termination and evidence-retention rights survive a dispute. Contract language must follow the actual allocation of roles, not the supplier’s marketing category.
Change management is equally important. A new model version, fine-tuning method, data source, user population or decision authority can alter risk and legal treatment. The release process should trigger reassessment when a defined materiality threshold is crossed. The prior evidence package must remain immutable and retrievable; otherwise the organisation can only show today’s configuration, not the configuration that produced the historical decision under examination.
Human oversight must be designed as a control, not described as a slogan. The evidence should show what the human can see, when intervention is possible, what competence is required, whether automation bias was tested and how overrides are recorded. A nominal approval button after an opaque recommendation does not demonstrate effective oversight. Likewise, AI literacy should be role-based: a procurement lead, model engineer, frontline operator and board member require different competence and evidence.
Counterarguments
One counterargument is that implementation details remain fluid, so investment should wait. The uncertainty is real: standards, guidance, national enforcement practice and political changes can alter the route to compliance. But waiting does not remove the need for an inventory, provenance, monitoring or accountability. These are reversible, framework-neutral capabilities. They reduce the cost of adapting when a rule changes. What should be delayed is irreversible tooling built around one speculative interpretation, not the evidence foundation.
A second counterargument is that responsibility sits with the model vendor. That is only sometimes true and never complete. The deployer controls context, user population, integration, human authority and often the consequential decision. It must understand its own duties and may become a provider after substantial modification or rebranding. Supplier evidence is an input to governance; it cannot replace governance.
A third argument says that low-risk uses need no governance. Proportionate controls are appropriate, but zero visibility is not. Without an inventory the organisation cannot know which uses are low risk, detect scope drift or demonstrate that it made a reasonable classification. A lightweight record and change trigger are cheaper than rediscovery after an incident.
Scenarios
Managed transition. The organisation has a complete use-case registry, assigns roles consistently and closes the highest-risk evidence gaps before enforcement. Supplier contracts provide usable documentation, release gates detect material changes and monitoring produces board-level exceptions. Compliance costs remain material but predictable; governance also improves product reliability and enterprise sales.
Paper compliance. Policies and risk assessments exist, but identifiers, versions and controls are disconnected. Teams can answer routine questionnaires, yet cannot reconstruct an output or prove which safeguards operated. The first serious customer challenge or regulatory request causes manual evidence collection, inconsistent answers and delayed releases.
Hidden-role shock. A business unit fine-tunes, rebrands or materially modifies a third-party system and assumes the vendor remains solely responsible. A complaint or incident reveals that the company has provider-like obligations without provider-grade documentation. Remediation becomes urgent and commercially disruptive.
Uncertainties
Exact obligations depend on facts that a general article cannot determine: the system’s intended purpose, actor role, market date, deployment geography, affected sector, whether a model has systemic risk and whether sector-specific law also applies. Implementation timelines and guidance may continue to change. This analysis is therefore a strategic operating assessment, not legal advice for a specific system.
The evidence is strongest on the regulation’s structure and published Commission implementation position. It is weaker on how uniformly national authorities will enforce borderline cases and how courts will interpret contested terms. Organisations should preserve that uncertainty in the control record instead of converting it into a false binary of compliant or non-compliant.
Decision framework
- Establish scope: enumerate AI systems, shadow uses and embedded supplier features; give every use a stable identity.
- Assign roles: record provider, deployer, importer, distributor and product-manufacturer implications with dated reasoning.
- Prioritise exposure: combine legal category with consequence, scale, vulnerability, reversibility and evidence weakness.
- Build the evidence chain: connect requirements to controls, controls to tests, tests to immutable results and results to accountable owners.
- Control suppliers: require model-specific documentation, change notice, incident cooperation, auditability and exit rights.
- Gate material change: reassess classification and safeguards before changed systems reach production.
- Witness independently: verify consequential controls through an assurance function that is not the sole system operator.
- Report exceptions: give the board unresolved high-impact gaps, overdue remediation and evidence freshness—not a decorative compliance percentage.
Sources
- Regulation (EU) 2024/1689 — Artificial Intelligence Act, official legal text.
- European Commission — AI Act regulatory framework, implementation overview and timeline.
- European Commission — Guidelines for general-purpose AI model providers.
- European Commission — General-Purpose AI Code of Practice.
- NIST — Artificial Intelligence Risk Management Framework 1.0.
- NIST AI RMF Core — Govern, Map, Measure and Manage.