EU AI Act Deadlines Moved. Here Is What Applies To Your SaaS Product Now

A board member forwards an article about the EU AI Act and asks for the company's position by Friday. The product has one AI feature, a support assistant, and nobody is sure whether that makes the company a provider, a deployer, or neither.

The answer is a set of dates, and the dates have already changed once. The obligations were rescheduled by the Digital Omnibus amendments, and a large share of the guidance still online carries the original timetable. So the first useful thing to know about the EU AI Act deadlines is that anything you read without a revision date on it is probably wrong.

The dates that actually apply, and the ones that moved

Here is the current position, with what changed.

Obligation	Applies from	Status
Prohibited practices and AI literacy	2 February 2025	In force, unchanged
General purpose AI model obligations	2 August 2025	In force, unchanged
Article 50 transparency duties	2 August 2026	In force now
Machine readable marking of synthetic content	2 December 2026	Moved later
Annex III high risk, use based	2 December 2027	Moved from 2 August 2026, about 16 months
Annex I high risk, product regulated	2 August 2028	Moved from 2 August 2027, about 12 months

Two things follow from that table and they point in opposite directions.

The high risk obligations, the expensive ones, are further away than most 2025 planning assumed. If you built a roadmap against 2 August 2026 for Annex III, you have roughly 15 more months than you thought.

But Article 50 is live now, and it is the one almost nobody scoped, because transparency sounds administrative next to risk management and conformity assessment. It is not administrative. It reaches every product with a chatbot in it.

A word of caution worth saying plainly: this timetable has been amended once already, and further adjustment is possible. Build against the dates, but design so that a date moving does not invalidate the work. Everything in the sections below has value independent of the regulation, which is the safest way to spend money on a moving target.

That is not a reason to wait, and the reason is commercial rather than legal. Enterprise procurement moved ahead of the regulator. Security questionnaires have carried AI questions since well before the first deadline, and a buyer who asks how you classify your product does not care that the obligation starts in 2027. The answer is either ready or the deal slows down, which is the same dynamic that made SOC 2 unavoidable long before anyone was legally required to hold one.

Are you a provider, a deployer, or both

The Act assigns duties by role, and most SaaS companies occupy two roles at once without noticing.

A provider develops an AI system and places it on the market under its own name. If your product ships an AI feature to customers, that is you, even where the model underneath belongs to somebody else.

A deployer uses an AI system under its own authority. If you also run an AI tool internally, for CV screening or support triage, that is you as well, in a different capacity and with different duties.

The trap is the assumption that using a third party model makes you neither. Building a support assistant on somebody else's model and selling it inside your product makes you a provider of that assistant. The model provider has its own obligations, and those do not transfer.

This matters commercially as well as legally, because your customers are deployers of your product and they have their own duties. A deployer of a high risk system has to keep logs, assign human oversight and monitor operation, and none of that is possible unless the product gives them the surfaces to do it. A product that cannot support its customers' obligations becomes hard to buy, regardless of where your own duties land. That is the argument for building the oversight and logging surfaces even when your classification says you do not have to.

There is also a route into provider status by accident. Substantially modifying a high risk system, or putting your own name on one, can move the duties onto you. In practice this catches companies that fine tune a model heavily and rebrand the result.

The transparency obligations are the ones live today

Article 50 is short, unglamorous, and already applies. Four requirements matter for a normal SaaS product.

Tell people they are talking to a machine. Any system interacting with a person has to make that clear, unless it is obvious from the context. In practice this is a label on the assistant, present before the first exchange rather than in a footer.

Mark synthetic content. Content generated or manipulated by AI has to be marked in a machine readable way so it can be detected as artificial. This is the requirement that moved to 2 December 2026, which gives most teams a real but not generous window.

Disclose emotion recognition and biometric categorisation to the people subjected to it. Rare in B2B SaaS, and absolute where it applies, including sentiment features in support tooling that are marketed as reading how a customer feels.

Label deep fakes and AI generated text published to inform the public. Narrower than it sounds, and worth checking if your product publishes generated copy on a customer's behalf.

The engineering here is smaller than the high risk work and it is not zero. Machine readable marking means provenance metadata attached at generation time and surviving export, which touches your storage and your file handling rather than your UI.

The export path is where this gets missed. Marking survives inside your own system easily enough, and the moment a customer downloads a generated document as a PDF, copies text into an email or pushes it through your API into their CRM, the metadata has to travel with it or the requirement is unmet in exactly the places a regulator would look. Decide early which export formats you support properly and which you do not, because retrofitting provenance into a file pipeline after launch means reprocessing everything already generated.

The disclosure requirement has a quieter design consequence too. Making it clear that a person is talking to a machine is trivial in a chat window with a header. It is considerably less obvious in an email your product sends on a customer's behalf, in a voice channel, or in a widget embedded on a third party site where your branding is absent. Each of those surfaces needs its own answer, and they are easy to forget because the feature team only ever tests the chat window.

A short test for high risk

Most SaaS products are not high risk. Working that out quickly is worth more than reading the whole Act, because the two answers lead to completely different budgets.

Annex III lists the use based categories. Adapted to the products we usually see, ask whether your AI feature does any of the following:

• Decides or materially influences who gets hired, promoted or dismissed, including CV filtering and task allocation
• Decides or materially influences access to education, including admissions and scoring
• Determines eligibility for essential services, including credit scoring and insurance pricing for life and health
• Is used in law enforcement, migration, border control or justice
• Is a safety component of critical infrastructure
• Performs biometric identification or categorisation

If none of those describe your feature, you are almost certainly outside the high risk regime, and your obligations are the transparency ones above plus whatever your customers demand contractually. Write that conclusion down with the date and the reasoning, because you will be asked to defend it in a security review.

Two edges are worth checking rather than assuming. Materially influences is doing a lot of work in that list. A tool that ranks candidates for a recruiter to review is still influencing a hiring decision, and calling the human the decision maker does not by itself take you out of scope if the human is approving a ranked list at volume. Second, a general purpose feature can be caught by how a customer uses it: a summarisation tool sold generally is one thing, and the same tool sold specifically for screening applications is another. Where your marketing describes a use case on the list, expect to be read against that use case.

If one of them does describe your feature, the work is substantial and the date is 2 December 2027 for Annex III. That is not far away for a programme of this size.

What high risk actually asks you to build

This is the section that separates a compliance document from an engineering plan. High risk obligations are mostly systems work, not paperwork.

1. A risk management system that runs across the lifecycle rather than as a one off assessment. In practice, a register with owners, review dates and evidence of mitigation.

2. Data governance. Training, validation and testing data has to be relevant, representative and examined for bias. This means knowing your data lineage, which most teams do not, and being able to show it.

3. Technical documentation sufficient for an authority to assess conformity. Substantial, and considerably easier to produce as you build than to reconstruct afterwards.

4. Automatic logging of events across the system's lifetime, with enough retention to support traceability. If this sounds like the audit logging a SOC 2 report also wants, that is because it is largely the same system.

5. Human oversight designed in, not asserted. A person has to be able to understand the output, override it, and stop the system. This has real product design consequences and is frequently where the roadmap changes. Understand is the demanding word: a confidence score with no explanation of what drove the output does not let a reviewer exercise judgement, it only lets them approve faster.

6. Accuracy and cybersecurity at a level appropriate to the purpose, declared and tested, including performing predictably on inputs the system was not designed around.

Anyone selling you a subscription as the answer to that list has misread it. A governance platform helps you track and evidence the work. It does not build the logging, the lineage or the oversight surface.

What you have already built that counts

The good news, and it is genuine. If you have done security compliance already, a meaningful share of this is done.

Already have	Covers part of
SOC 2 audit logging	Automatic logging and traceability
ISO/IEC 27001 risk register and controls	Risk management structure and cybersecurity
ISO/IEC 42001 AI management system	Governance, and it maps closest of all
GDPR Article 30 records and data mapping	Data governance and lineage
Access reviews and role granularity	Human oversight controls

ISO/IEC 42001 is the one worth knowing about, because it is an AI management system standard designed to sit alongside 27001 and it maps onto a large part of the governance expectations. It is not a substitute for conformity and it is a considerable head start, and it is certifiable now rather than in 2027.

The overlap is worth quantifying before you budget. On the products we have looked at, roughly half the evidence a high risk assessment wants already exists in some form once SOC 2 and ISO 27001 are in place: the logging, the access controls, the risk register structure and the incident process. What is genuinely new is the AI specific half, meaning data lineage, model documentation, evaluation results and the oversight surface. Budgeting the whole thing as new work overstates it by a wide margin, and budgeting it as free because you hold a certificate understates it by the same margin.

Sequencing point: if you are going to do 42001 anyway for enterprise buyers, doing it before the high risk deadline turns two projects into one and a half.

What this costs, with the hours shown

Published rates, published hours, arithmetic you can argue with. We hold no certifications ourselves. We build the controls and the evidence that let you hold them.

Component	Hours	Note
Classification and written position	30 to 60	Do this first, it may end the project
Article 50 transparency surface	60 to 130	Disclosure, labelling, the UI states
Provenance and machine readable marking	90 to 180	Metadata that survives export
Model and data lineage tracking	140 to 300	The line most teams underestimate
Automatic logging and retention	120 to 240	Shares heavily with SOC 2 work
Human oversight surface	100 to 220	Override, escalate, stop
Technical documentation pipeline	80 to 170	Generated as you build, not reconstructed

At $40 to $100 per hour by seniority, blending to $60 to $70 for a mixed squad, a transparency only scope lands near 150 to 310 hours, so roughly $10,000 to $20,000 at a $65 blend. A full high risk readiness programme runs 620 to 1,300 hours, so roughly $40,000 to $85,000, and that assumes the product does not need a design change to accommodate human oversight. When it does, that change is usually the largest single line and it is not on this table because it is specific to your product.

A sequence that does not waste work on a moving target

First, classify and write it down. A page naming your role, your Annex III answer and the reasoning, dated and signed by somebody. For most products this ends the project, and the page is what you send to procurement.

Second, close Article 50. It is in force now, it is the cheapest line on the table, and it is the one an enterprise customer can check in your product in thirty seconds.

Third, build the machine readable marking ahead of 2 December 2026 if you generate content.

Fourth, and only for a high risk product, start the lineage and logging work. These have the longest lead time, they are the least reversible, and they are worth having regardless of what the regulation does next.

Fifth, treat 42001 as the vehicle rather than doing governance twice.

One thing not to do: appoint an AI governance committee before anyone has written the classification page. Committees generate meetings, and the classification is 30 to 60 hours of work that frequently ends the conversation entirely.

Two dates in the plan: 2 December 2026 for synthetic content marking, and 2 December 2027 for Annex III. Anything else you read with an earlier date on it was probably written before the timetable changed.