Which AI Act dates moved, and which did not?
The high-risk dates moved. The other 2026 dates stayed where they were. Regulation (EU) 2026/1744, the Digital Omnibus on AI, is dated 8 July 2026. It was published in the Official Journal on 24 July and took effect on 27 July, six days before the old 2 August 2026 deadline. High-risk obligations for Annex III use cases such as hiring and credit scoring now apply from 2 December 2027. AI built into regulated products under Annex I follows on 2 August 2028. Article 50 transparency, the part that covers chatbots, agents and content generators, has applied since 2 August 2026. Generative systems placed on the market before that date have until 2 December 2026 to add machine-readable marking, and two new prohibitions start on the same day.
None of the high-risk requirements got easier to meet. They got a fixed later date, which replaced the conditional trigger the Commission first proposed (Gibson Dunn, 27 May 2026). SMEs and a new "small mid-cap" category (under 750 employees) may file the technical documentation on a simplified form (Orrick).
Plenty of guides written in 2025 and early 2026 still put every obligation on 2 August 2026, which for high-risk systems is now simply wrong.
What follows is an engineering reading of the text. It is not legal advice.
Six dates, one table
Every date we track, with the build work it triggers. The two 2026 rows are code that ships this year. The 2027 and 2028 rows are architecture decisions: retrofitting logging and human oversight into a live system costs more than designing them in.
AI Act dates after the Omnibus
| Obligation | Applies from | What changed | Engineering consequence |
|---|---|---|---|
| Article 50: tell people they deal with AI; deployer labelling of deepfakes and public-interest text | 2 Aug 2026 | Nothing, still on the original date | Disclosure at first interaction in the chat UI and in agent messages |
| Article 50(2) marking for generative systems on the market before 2 Aug 2026 | 2 Dec 2026 | New transitional period (new systems are covered from 2 Aug 2026) | Signed metadata and watermark on generated media; a detection route |
| New Article 5 bans: non-consensual intimate imagery, CSAM | 2 Dec 2026 | Added by the Omnibus | Output safeguards in any image or video generator |
| National AI regulatory sandboxes | 2 Aug 2027 | Postponed | A supervised testing option before the high-risk date |
| High-risk, Annex III (stand-alone) | 2 Dec 2027 | Postponed from 2 Aug 2026 | Classification gate now; logging and human oversight designed in |
| High-risk, Annex I (product-embedded) | 2 Aug 2028 | Postponed | Plan with the product's sectoral conformity route |
Outside the EU still counts
If the output is used in the EU, the Act applies. Article 2(1)(a) covers providers that place AI systems on the EU market "irrespective of whether those providers are established or located within the Union or in a third country". Article 2(1)(c) reaches third-country providers and deployers "where the output produced by the AI system is used in the Union". A US SaaS company with EU customers is in scope for Article 50 from its first EU conversation, and so is a Swiss insurer whose chatbot answers German users.
Free or paid makes no difference, say the Commission's Article 50 guidelines. Unforeseeable downstream use alone should not pull in a third-country provider that never placed the system on the EU market. That carve-out is narrow; if you sell to EU buyers, you are in.
How do we classify an AI feature before we build it?
When we scope an AI feature, classification happens in discovery, before anyone writes an estimate. The answer decides what goes into the backlog, from a single disclosure component up to a full conformity file. Five questions, always in this order, answers written into the feature's register entry.
- Provider or deployer? Whoever puts the system out under their own name is the provider, including a company running an in-house chatbot for its own use. When we build for a client, the client is usually the provider.
- Prohibited? Check Article 5. From 2 December 2026 that list also includes systems that generate intimate imagery of an identifiable person without consent, or CSAM. Image and video features get this check every time.
- Annex III? Look at the intended purpose against the eight areas. The ones that come up most in our discovery calls: filtering job applications and evaluating candidates (point 4(a)), creditworthiness and credit scores (point 5(b), fraud detection excepted), admission and grading in education (point 3).
- Does an Article 6(3) exception hold? The candidates are a narrow procedural task, improving a completed human activity, detecting deviations from past decisions, or a preparatory task. Profiling of natural persons is always high-risk. If the provider relies on an exception, it documents the assessment before launch (Article 6(4)). The registration duty for these self-assessed systems survived the Omnibus "with a lighter administrative footprint" (Freshfields).
- Does it talk to people or generate content? Then Article 50 applies. If all five come back negative, the feature is minimal-risk and adds no AI Act build items.
Drift is the case we watch hardest. An HR platform's chatbot answers candidates' questions about open roles: Article 50, one disclosure line. Later a product owner asks for a "rank these CVs against the job description" button. That button sits squarely in Annex III point 4(a), which names systems used "to analyse and filter job applications, and to evaluate candidates". Ranking people by their CVs is profiling, so no 6(3) exception rescues it. Article 25(1)(c) then makes whoever changed the intended purpose the provider of a high-risk system. When a ticket like that shows up we stop and reclassify it as a separate system with its own register entry and its own logging plan. A deployer of that system will have to keep its logs for at least six months (Article 26(6)).
Article 50 in a chatbot or agent: where it lands in code
Four places: the first screen of a conversation, every message an agent sends to a person, generated files, and the text output pipeline. The Commission guidelines of 20 July 2026 require disclosure "at the latest at the time of the first interaction or exposure", in a clear and distinguishable manner. A line in the terms of service does not count, and the "obvious from context" exception is to be read restrictively (Commission Q&A).
Agents get the most specific text. Paragraph 31 of the guidelines says agents must disclose "both their artificial nature and the person on whose behalf they are acting". If the provider cannot know whether the agent will meet a human, it should disclose itself wherever that is reasonably likely, and also to the person who instructed it at key steps such as authorisation. For an agent that sends email or books appointments, that means a label in every outbound message plus a principal field in the agent's config (the architecture side is in how AI agents work). Backend machine-to-machine calls are out of scope. So are web requests, browser actions and chain-of-thought (paragraph 63).
We put the same facts in the API response, so every client renders them the same way and the logs can prove what the user saw:
{
"reply": "Your refund for order 48213 was approved.",
"ai": {
"generated": true,
"acting_for": "Example Retail GmbH",
"disclosure_rendered_at": "2026-10-16T09:12:04Z",
"model": "vendor-model@2026-09-snapshot",
"prompt_version": "support-v14",
"marking": ["signed-metadata"]
}
}
For generated media the reference is the Code of Practice on AI-generated content, finalised on 10 June 2026. About 190 organisations had signed it by the end of July, and the Commission and the AI Board confirmed it as adequate. It asks for at least two machine-readable layers, signed and timestamped metadata plus an imperceptible watermark. Plain text, which cannot carry metadata, needs one layer (DLA Piper, 16 Jul 2026). Watermarking is not required for text under 200 tokens, and watermark-detection interoperability is due by 2 February 2027 (Paul, Weiss, 4 Aug 2026).
What text counts? The guidelines treat AI translations as standard editing, so no marking. Summaries and rewrites that change meaning do need it. Source code and short strings are excluded. Content generated before 2 August 2026 needs no retroactive labelling.
Two things are still open. The 20 July document, C(2026) 5054, is a Commission decision approving the content of a draft Communication, and guidelines bind nobody; only the Court of Justice interprets the Act. And the Omnibus removed the Commission's power to impose common marking rules through an implementing act (recital 41), so for now the voluntary code is the only EU-wide reference.
What we log even when nothing is high-risk
Article 12 automatic logging is a high-risk duty and starts with the Annex III date. We log on every AI feature anyway, because when someone asks about Article 50 or a 6(3) assessment they want the same evidence: which model version ran, and who changed the classification on which date.
- Classification record. The written assessment, versioned in the repository, with the date and who signed it off.
- Model and prompt pinning. Model ID with its snapshot, and the prompt version. A silent vendor upgrade changes behaviour, and you cannot reproduce an incident without these.
- Disclosure events, one timestamp per session.
- Data lineage for anything that feeds evals or fine-tuning.
- Evals rerun on every model or prompt change, with results stored.
The cost is storage and personal data. Conversation logs are personal data, so we hash user identifiers and keep raw text only as long as the retention policy says. For agents we want the log to be tamper-evident. We use SealedRun, an independent open-source recorder, so that a log entry cannot be edited without that edit showing up. The wider control set is in securing AI agents in production; the attack side is in our OWASP Top 10 for LLM applications notes.
Your model vendor does not carry your duties
A hosted model leaves your Article 50 obligations where they were. Paragraph 27 of the Commission guidelines says Article 50 "does not explicitly apply to GPAI models". The duties sit with the provider of the system built on top; model providers are only "encouraged" to add model-level marking that helps downstream. General-purpose model providers carry their own obligations, which have applied since 2 August 2025, technical documentation and a copyright policy among them. None of that covers your chatbot's disclosure.
Supervision splits too: the AI Office takes systems built on a provider's own GPAI model (Orrick), while your product on someone else's API stays with national authorities.
We keep a vendor register per project and re-check it when a model is deprecated or a contract changes:
- feature: support-assistant
role: provider # client ships it under its own brand
risk_class: art50-only # 6(3) not needed, no Annex III purpose
model: vendor-model@2026-09-snapshot
region: eu-west
data_terms: no-training, 30-day retention (contract clause 7.2)
vendor_marking: none for text; signed metadata on images
owner: product lead
recheck: 2026-12-02
The vendor_marking line is the one people skip. If nobody marks text, write that down with what you do instead.
The first sprint
Inventory every AI feature, including the ones a vendor switched on for you. Classify each with the five questions above. Add the disclosure component and the response metadata. Turn on version pinning and disclosure logging. Name one owner per feature. Put 2 December 2026 on the register as the first re-check date. If a feature lands in Annex III, open a separate track for it now. December 2027 is close for a system that needs human oversight designed in.
We do this as part of secure development and compliance work, or as the first step of an AI build. Send us the feature list and we will tell you which rows matter.