For two years, enterprise AI compliance planning ran on a simple calendar: prohibitions in February 2025, general-purpose model rules in August 2025, high-risk obligations in August 2026 and August 2027. That calendar has moved. The high-risk dates are now December 2027 and August 2028, the core obligations did not go away, and the enforcement machinery switched on in August 2026. A plan built on the old dates is not early. It is pointed at the wrong quarter.
This is not a legal brief. It is the operating view a US technical leader needs: what the EU regime now requires and when, how the provider and deployer roles divide the work, what conformity assessment actually involves, what is happening in the US, and which contract clauses decide who pays when a regulator disagrees.
The 2027 deadline moved, and that is the planning lesson
The EU AI Act entered into force on 1 August 2024. It did not apply in full on day one; it applies in stages, and the staging has been amended. The European Commission states that high-risk rules for sensitive use cases listed in Annex III have been extended to 2 December 2027, and high-risk rules for AI embedded in regulated products under Annex I to 2 August 2028. The change came through the simplification package known as the AI Omnibus, proposed on 19 November 2025, agreed politically on 7 May 2026, and in force on 27 July 2026.
Two conclusions follow. First, the delay is about readiness tools, not about relaxing the standard: the Commission ties the timing to the availability of standards and guidance that help companies comply. The obligations themselves, from risk management to technical documentation to human oversight, are still in the regulation. Second, dates in this regime can move again. Any plan that treats a published date as permanent will be re-planned at least once, so build the plan around capabilities and evidence rather than around a single deadline.
The compliance calendar, as it stands
The table shows each date as it now stands, with the original statutory date noted wherever the calendar changed. That is also why you should verify against the Commission's own page before you put a date in a plan.
| Date | What applies | Note |
|---|---|---|
| 1 August 2024 | Regulation enters into force | No substantive obligations yet |
| 2 February 2025 | Prohibited practices and AI literacy duties | Still in force |
| 2 August 2025 | General-purpose AI model obligations, governance, penalty provisions | Codes of practice published in 2025 |
| 2 August 2026 | Remainder of the regulation applies, including transparency rules; AI Office and national authorities enforce | Enforcement is now live |
| 2 December 2026 | Prohibition on systems generating non-consensual intimate imagery or child sexual abuse material; legacy generative systems must meet transparency duties | Added by the AI Omnibus |
| 2 August 2027 | General-purpose models placed on the market before August 2025 must be compliant; national regulatory sandboxes operational | Applies to older model versions |
| 2 December 2027 | High-risk obligations for Annex III use cases | Extended from 2 August 2026 |
| 2 August 2028 | High-risk obligations for Annex I products | Extended from 2 August 2027 |
Read the enterprise implications by row. If you deploy a general-purpose model through an API, your obligations as a deployer are already live. If you build a high-risk system for hiring, credit, education, or essential services, you have until December 2027 to produce evidence, which sounds generous until you count the work: a risk management file, data governance records, technical documentation, logging, human oversight design, accuracy and cybersecurity testing, and a quality management system behind it.
Provider or deployer: the role question decides the workload
The regulation splits duties between the provider, who develops a system or places it on the market under its own name, and the deployer, who uses it professionally. Most enterprises assume they are deployers. That assumption fails more often than teams expect. Under Article 25, a deployer becomes a provider if it puts its name or trademark on a high-risk system, substantially modifies it, or changes its intended purpose. Fine-tuning a vendor model for a new use case, or wrapping it in your own product brand, can move you across the line.
Deployer duties are lighter but not trivial. You must use the system according to the instructions, assign human oversight to people with the competence and authority to intervene, ensure input data is relevant, monitor operation, keep the logs the system generates, and inform affected workers and individuals in the cases the regulation specifies. Certain deployers, including public bodies and some private providers of essential services, must also complete a fundamental rights impact assessment before first use.
Map every AI system to a role before you map it to a deadline. The deliverable is a register with four columns: system, role, risk class, and the evidence you would show an authority. Systems used only for narrow internal tasks usually fall outside high-risk classification, and the register is how you demonstrate that rather than assert it.
Conformity assessment: self-assessment is the default route
For most Annex III high-risk systems, the conformity route is internal control, a documented self-assessment against Annex VI rather than a notified body audit. Systems that are safety components under Annex I product law go through the Annex VII route with a notified body. Either way, the evidence is similar, and it is buildable now: a risk management system that runs through the lifecycle, data governance records covering provenance and bias testing, technical documentation per Annex IV, automatic logging, instructions for use, human oversight measures, and accuracy, robustness, and cybersecurity testing.
After assessment comes the administrative layer: an EU declaration of conformity, CE marking, and registration in the EU database for Annex III systems. Then post-market monitoring and serious incident reporting, with deadlines measured in days rather than months. Penalties are steep: up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher, for the prohibited practices, and lower but still material ceilings for other breaches.
None of this requires a large team if you start with the documentation you already produce for security reviews and model risk management. The gap is usually traceability, not content: prove that the risk file you wrote in March matches the model you shipped in September, and that the test results belong to the version in production.
The US picture: no federal statute, many state edges
The United States still has no comprehensive federal AI statute. Federal activity has leaned toward adoption and export rather than a new compliance regime, which is why state law and contract terms carry most of the practical weight. The state pattern clusters into four buckets: employment and decision tools, where bias audits and candidate notices are common; consumer disclosure and content provenance rules for generated media; restrictions and reporting duties for government use and procurement; and a smaller set of frontier-model reporting laws.
Two examples show the range. New York City's automated employment decision tool law has required bias audits and notices since 2023, and it applies to tools used for hiring and promotion in the city. Texas enacted HB 149 in 2025, creating a state framework with prohibited uses and disclosure duties. Colorado passed a comprehensive high-risk law whose compliance date has already moved once, which is the same lesson as the EU calendar: track effective dates, do not assume them. The practical exposure for a US enterprise is a patchwork where one state's disclosure duty is another state's prohibited practice, and your vendor contract is the only document that allocates the cost of getting it wrong.
Procurement clauses that decide who carries the risk
Regulatory risk moves through contracts. Whether you buy or sell AI, these terms deserve a line-by-line review. First, a representations clause stating which party is provider and which is deployer for each system, with the intended purpose written down. Second, documentation cooperation: the provider supplies technical documentation and instructions for use sufficient for your conformity work, and updates them when the model changes. Third, change notice: advance warning before a model, prompt, or hosting change that could alter risk class or behavior, with a retest window. Fourth, incident notification with a defined clock, because your reporting deadline is measured in days. Fifth, audit and evidence rights, including the right to see test results rather than a summary. Sixth, regulatory-change termination, so a shift in classification does not trap you in a multi-year deal.
For sellers, the same list is a sales asset. A vendor that can hand over an Annex IV-shaped documentation pack, a change-notice commitment, and an incident clock closes enterprise deals faster than one that answers questions with a trust page. For buyers, insist that AI terms sit in the master agreement rather than an attached addendum that nobody reviews at renewal.
What to do next
- Build the AI system register this month: system, provider or deployer role, risk class, evidence owner, and next review date.
- For any Annex III candidate, assign one owner to the conformity file and map each required document to an existing artifact or a gap.
- Audit contracts for role, change notice, incident notification, documentation cooperation, and regulatory-change termination before your next renewal.
- Track the Commission's AI Act page quarterly and log every date you rely on, with the source and the date you checked it.
- Decide now who signs off on a high-risk classification, and write the criteria down so the decision is repeatable.
The useful posture for 2027 is not waiting for certainty. It is building the register, the evidence trail, and the contract language while the calendar is still being adjusted.
