EU AI Act Compliance

The EU AI Act attaches obligations by role and by risk classification, and most of the obligations on a high-risk system are evidentiary: they ask what the system did, not what your policy says it should do. This page sets out the current timeline, which obligations are evidence obligations, and what has to be in the call path to produce that evidence.

The timeline moved, and most published guidance has not caught up

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and amended the application dates in Article 113 of the AI Act. If you are working from a compliance calendar built before that date, two of the dates on it are wrong.

• 2 February 2025 — in force. The Article 5 prohibited practices. AI literacy duties, recast by the 2026 amendment as obligations to support staff skills development.
• 2 August 2025 — in force. General-purpose AI model obligations, the governance and notified body provisions, and the penalty regime.
• 2 August 2026 — in force. The general application date, including the Article 50 transparency obligations.
• 2 December 2026 — upcoming. Two prohibitions added by the 2026 amendment, and the transitional compliance date for Article 50(2) marking of synthetic content.
• 2 December 2027 — upcoming. High-risk obligations for Annex III systems. Moved from 2 August 2026.
• 2 August 2028 — upcoming. High-risk obligations for Annex I systems. Moved from 2 August 2027.

The delay is not a reprieve in the way it is usually read. The obligations that moved are the ones that require evidence produced by a running system, and that evidence cannot be generated retroactively. An organization that treats December 2027 as the date to start is an organization that will be asked, in December 2027, for records from systems that were not instrumented to produce them.

Whether it reaches you

Scope is not limited to organizations established in the Union. It extends to providers placing AI systems on the EU market wherever they are established, and to providers and deployers outside the Union where the output produced by the system is used in the Union.

Role matters as much as geography. Buying a system does not reliably make you a deployer: substantially modifying a high-risk system, or placing one on the market under your own name or trademark, makes you a provider, with a materially heavier obligation set. Classification is per system and per intended purpose, so the same model can land differently in two of your own use cases.

Our EU AI Act readiness self-assessment walks the eight questions in the order the Regulation works through them and returns the obligations that attach. It runs in your browser and stores nothing.

The obligations that are really evidence obligations

Read the provider and deployer duties together and a pattern appears. Several of them cannot be discharged by a document, because they are claims about what happened at the moment a system acted.

• Article 12 — record-keeping. Automatic logging of events over the system's lifetime.
• Article 13 — transparency to deployers. Instructions sufficient for the deployer to interpret the output and operate the system properly.
• Article 14 — human oversight. Designed so oversight is effective rather than nominal. A reviewer approving three hundred items an hour is not exercising oversight, and the record has to be good enough to tell the difference.
• Article 15 — accuracy, robustness and cybersecurity. Including resilience to adversarial manipulation.
• Article 26 — deployer duties. Use per the instructions, assign competent human oversight, monitor operation, inform affected people, and retain the automatically generated logs for at least six months where they are under your control.
• Article 27 — fundamental rights impact assessment. Required of public bodies, private entities providing public services, and any deployer of credit scoring or life and health insurance pricing systems. An existing data protection impact assessment can be relied on in part.
• Article 72 — post-market monitoring. A documented plan, proportionate to the risk.
• Article 73 — serious incident reporting. On defined timelines, starting when you become aware.

Article 12, Article 26(6), Article 14 and Article 73 have a shared property. Each is a claim about a specific moment, and a claim of that kind can only be produced by something that was present at that moment. A quarterly attestation cycle and a spreadsheet inventory produce claims about what the organization intended. This is the distinction between runtime governance and governance by documentation.

Penalties: read the tiers rather than the headline

The figure usually quoted is the top tier only. Article 99 sets three: up to EUR 35 million or 7% of total worldwide annual turnover for breaches of the Article 5 prohibitions; up to EUR 15 million or 3% for most other operator obligations; and up to EUR 7.5 million or 1% for supplying incorrect or misleading information to authorities. In each case the higher of the two applies — except for SMEs and small mid-caps, where the cap is the lower of the fixed sum and the percentage.

What Smartflow contributes

Smartflow is an on-premises control plane in the call path between an agent and the model it uses. Every prompt, response and tool call passes through it, and policy is enforced inline before anything leaves the enterprise perimeter. The consequence for this Regulation is narrow and specific: the evidence is a byproduct of enforcement rather than a separate reporting exercise.

• Against Article 12 and Article 26(6). The prompt, the caller identity, the policy version and the decision are recorded at the moment of the call. Retention is set by the customer. Defaults are 30 days for request logs and 365 days for the audit trim, and there is no product maximum — trimmed logs are archived offline by default, to a destination the customer sets. Where an immutable archive is required, it is a connector the customer enables and pipes records to.
• Against Article 14. A high-severity action can be held pending human approval: the call waits, a person approves or denies, and the ticket redeems once. Agent credentials are issued with scopes, spend caps and expiry, and the audit record names the person who authorized the agent. Enforcement of agent identity is a setting rather than a default, so it is a control you turn on deliberately — see agent authority scope.
• Against Article 15. Policy and content controls evaluate inline, before a call executes, including for indirect prompt injection arriving inside content an agent was asked to read.
• Against Articles 72 and 73. Post-market monitoring and incident reporting draw on the same runtime record rather than a parallel process, which is what makes the reporting clock survivable.

What this does not do is make an organization compliant. Classification, the fundamental rights impact assessment, conformity assessment and the technical documentation are organizational work, and no control plane performs them for you. What a control plane can do is make the evidentiary obligations satisfiable, and remove the argument about whether a policy was actually applied.

Related reading

EU AI Act readiness self-assessment · AI supervision evidence checklist · ISO/IEC 42001 · Human-in-the-loop · AI bill of materials · AI incident response · Board reporting

Verified against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 and European Commission sources in September 2026. This page is not legal advice.