AI Regulations in 2026: What Product Teams Must Build

In May 2026 the EU agreed to delay the AI Act's high-risk obligations, and a lot of product teams heard exactly one thing: we have more time. The standalone high-risk deadline under Annex III moved to 2 December 2027. Product-embedded high-risk systems under Annex I moved to 2 August 2028. Sixteen months and twelve months of relief respectively, on the toughest and most expensive parts of the regime — risk management systems, data governance, technical documentation, conformity assessment, post-market monitoring.

That is a real reprieve and it was granted for a sensible reason: the standards, notified bodies, and supporting infrastructure were not going to exist in time. But reading it as a general pause is a mistake that will cost some teams a scramble, because the obligations that did not move are precisely the ones that land in the codebase rather than in a compliance binder.

The rest of the Act became applicable on 2 August 2026 — a fortnight ago as this is published. Prohibited practices have been in force since February 2025. General-purpose AI model obligations since August 2025, along with the penalty provisions. And the transparency requirements around AI-generated content, including machine-readable marking, land on 2 December 2026 — roughly fifteen weeks out.

So the accurate summary of AI regulations in 2026 is not "delayed". It is: the paperwork-heavy tier slipped, the engineering-heavy tier did not. This article is about the second kind — what actually has to exist in your product, in what order to build it, and what it costs if you leave it until the audit.

One necessary caveat before any of it. We build software, not legal advice. The Digital Omnibus package that carried these changes was still moving through formal adoption steps as of mid-2026, and details shift. Everything here should be checked against the final published text with counsel who knows your sector. What we can tell you with confidence is what the engineering work looks like, because that part does not change much regardless of which way the marginal legal question resolves.

What Actually Changed, and What Didn't

The clearest way to hold this is by separating the obligations by where the work lands.

Delayed to 2 December 2027 — Annex III standalone high-risk systems: biometrics, critical infrastructure, education, employment and worker management, credit and insurance assessment, essential public services, law enforcement, migration, justice
Delayed to 2 August 2028 — Annex I high-risk systems embedded in products already covered by EU product safety legislation
In force since 2 February 2025 — prohibited practices, and the AI literacy duty on providers and deployers
In force since 2 August 2025 — general-purpose AI model obligations, governance structures, and the penalty regime
Applicable from 2 August 2026 — the remainder of the Act outside the specifically deferred high-risk provisions
Landing 2 December 2026 — transparency and marking obligations for AI-generated and AI-manipulated content, with a short additional window for models placed on the market before August 2026

The pattern is worth pausing on. What got deferred was the tier requiring external infrastructure to exist — harmonised standards, notified bodies, conformity assessment capacity. What did not get deferred is everything a company can do on its own: telling people they are interacting with AI, marking synthetic content, not doing the prohibited things, and keeping records. Regulators deferred what they could not support, not what they considered optional.

The Deadline Most Teams Misread

We have now had several versions of the same conversation with engineering leaders, and it goes like this. The legal team circulated a note saying high-risk obligations are delayed to December 2027. The roadmap item got moved to next year. Nobody asked whether the product was high-risk in the first place — and in most of these cases it was not.

That matters, because if your system is not high-risk, none of the delay applies to you. Your obligations were the transparency ones all along, and those are live now. A customer service assistant, a document summariser, a coding tool, a marketing content generator, a recommendation engine — the overwhelming majority of AI features being shipped in commercial software are not Annex III systems. They are limited-risk systems whose obligations are disclosure and content marking, both of which are already or imminently in force.

The teams with genuine breathing room are the ones building CV screening, credit scoring, biometric identification, or safety components in regulated products — and they are also the teams for whom the deferred obligations are a twelve-to-eighteen-month programme, not a sprint. If that is you, the extension is welcome and you should still be starting now, because conformity assessment against standards that do not exist yet is not something to begin in the final quarter.

Disclosure Is an Engineering Requirement, Not a Legal One

The transparency obligations sound trivial until you try to implement them properly across a real product surface. People must be told when they are interacting with an AI system unless it is obvious. Emotion recognition and biometric categorisation require notification of the people subjected to them. Synthetic audio, image, video, and text content must be marked as artificially generated in a machine-readable way, and deep fakes must be disclosed.

Machine-readable is the phrase that turns this into an engineering project. A line of grey text under a chat window satisfies nobody's reading of that requirement. It means provenance metadata that travels with the artefact — which for images and video increasingly means C2PA content credentials, and for text means a defensible approach to marking and attribution that survives being copied out of your interface.

Every generated artefact needs a durable record of what produced it, when, with which model version, and on whose instruction
Disclosure has to be present at the point of interaction, not buried in terms of service
Any surface where AI output is mixed with human-authored content needs to distinguish them, which is a data model question, not a UI question
Metadata must survive your own pipeline — resizing, re-encoding, and CDN transforms routinely strip exactly the fields you are relying on
Third-party model output arriving through your product carries the same obligations, so your vendor contracts and ingestion path need to preserve provenance

That last point catches people. If you pipe a partner's generated content through your platform and strip its credentials on the way, you have created a compliance problem that did not exist upstream. We have found this in production more than once, and it is almost always an unintentional side effect of an image-processing step nobody thought of as compliance-relevant.

Provider or Deployer? This Determines Everything

Before scoping any of this, establish which role you occupy, because the obligations differ substantially and most teams assume the lighter one.

A provider develops an AI system or has one developed and places it on the market under its own name or trademark. A deployer uses an AI system under its own authority in a professional capacity. If you build a product on top of a foundation model and sell it, you are a provider of that system even though you did not train the model. That surprises people who reason that the model vendor holds the risk.

Worse, the roles can shift. Substantially modifying a system, or putting your own name on someone else's, can move a deployer into provider obligations. Fine-tuning a model and shipping it as a feature is the common path by which a company that considered itself a customer of AI becomes a provider of it. Get this classified early, in writing, with counsel, because every other decision in the compliance programme depends on it.

The United States: Sectoral, Fragmented, and Faster Than the EU in Places

There is no federal AI statute of the EU's scope, and the practical picture for US-facing products is a patchwork that in some respects binds sooner than the AI Act does.

Colorado's AI Act, addressing algorithmic discrimination in consequential decisions, has been the most closely watched state regime and has itself been subject to timing changes — check the current effective date rather than trusting a note from last year. California has layered obligations around automated decision-making, training-data transparency, and disclosure. Illinois, Texas, Utah, and New York City have their own instruments, with New York City's bias-audit requirement for automated employment decision tools being the most operationally demanding for anyone in hiring.

Sectoral regulators are the sharper edge. The FTC has been explicit and active on deceptive AI claims — overstating what a model does is straightforward false advertising, and enforcement has not waited for new legislation. Financial regulators apply existing model risk management expectations to AI. Healthcare has FDA pathways for software as a medical device that predate all of this.

For most US-facing products the honest priority order is: do not lie about what the AI does, do not let it produce discriminatory outcomes in consequential decisions, and keep evidence that you checked both. That covers the enforcement risk that actually materialises.

UK, UAE, Canada, and the Divergence Problem

The UK has stayed with a principles-based approach delegated to existing sector regulators rather than a single statute, which is lighter to comply with and harder to plan against because your obligations depend on which regulator has jurisdiction over your use case.

The UAE has been notably strategy-led rather than restriction-led, with a national AI programme and sector guidance rather than a broad prohibitory regime — a meaningful commercial consideration for teams choosing where to launch AI-heavy products first, alongside the usual data residency questions.

Canada's federal AI legislation stalled with the prior parliamentary session, leaving existing privacy law and sectoral guidance carrying the load, with the direction of travel still broadly toward an EU-influenced model.

The practical consequence of this divergence is that per-jurisdiction compliance branches in your product are a trap. Build to the strictest regime you plausibly serve — currently the EU on transparency and provenance — and treat the others as subsets. Maintaining three behavioural variants of the same feature is more expensive than the strictest single implementation and considerably more likely to be wrong somewhere.

The Compliance Architecture: What Belongs in the Product

Here is the part we actually get paid for. Regulatory readiness that lives in documents rots immediately. Readiness that lives in the system stays true because the system enforces it. The components below are what we build into AI products regardless of the customer's risk tier, because the marginal cost during initial build is small and the retrofit cost is not.

A model registry — every model and version in production, its provider, purpose, the systems calling it, and who owns it. Most organisations genuinely cannot produce this list on request, which makes every other obligation unanswerable
Structured inference logging — inputs, outputs, model version, retrieved context, and the decision path, retained under a defensible policy and searchable by case
Provenance and content credentials attached at generation time and preserved through every downstream transform
An evaluation harness run on every model or prompt change, with results stored as evidence rather than discarded after review
Human oversight hooks — real intervention points with the authority and the information to override, not a rubber-stamp queue
Data lineage covering what trained or fine-tuned each model, what was in the retrieval corpus, and under what rights it was obtained
Incident detection and reporting paths, including a defined threshold for what constitutes a reportable malfunction

None of that is exotic. It is roughly what a mature engineering organisation would want anyway for debuggability and cost control, which is the argument to use internally when compliance is a hard sell. The registry and the logging in particular pay for themselves in incident response long before a regulator asks. Teams building this into enterprise AI systems from the start consistently report it as the cheapest insurance in the stack.

Why Retrofitting Costs Three to Five Times More

The number in that heading is from our own project history rather than a study, so treat it as a practitioner's estimate. But the mechanism behind it is not mysterious.

Building logging in at the start means one decision about a shared interface every model call passes through. Retrofitting it means finding every call site across services written by people who have left, adding instrumentation without changing behaviour, backfilling nothing because the historical data is gone, and re-testing everything. Provenance is worse: adding it later means the artefacts already in circulation have no credentials, and there is no way to establish after the fact what generated them.

The most expensive version we have seen was a company that could not establish which model version had produced a set of customer-facing outputs from eight months earlier, because model references were interpolated from an environment variable that had been updated in place. The remediation cost more than the original feature. Nothing about that failure was legally exotic — it was ordinary poor engineering hygiene that became a compliance problem because someone eventually asked.

Data Governance and Training-Data Transparency

Training-data transparency obligations, particularly for general-purpose models, are the direction of travel everywhere even where they are not yet binding. For most teams building on top of foundation models rather than training them, the exposure is narrower than feared but not zero.

What you are responsible for is what you added: fine-tuning datasets, retrieval corpora, and any customer data flowing into either. The questions that need answerable responses are whether you had rights to use each source, whether personal data entered training or retrieval and on what lawful basis, whether a deletion request can actually be honoured in a fine-tuned model or vector index, and whether customer data from one tenant can surface for another.

That last one is a security bug with a compliance consequence rather than a compliance issue with a security consequence, and it is the one we find most often in custom software development audits — usually as a missing tenant filter on a vector query. It is also the one most likely to end a customer relationship, entirely independently of any regulator.

Human Oversight That Isn't Theatre

Meaningful human oversight is a requirement in several regimes and a genuine engineering design problem in all of them. The failure mode is universal and well documented in aviation and medicine long before AI: give a human an approval button on a system that is right 97% of the time, and within weeks they approve everything. The oversight is nominal, the accountability has been transferred to a person who cannot realistically exercise it, and the audit trail says a human reviewed it.

Oversight that actually functions needs the reviewer to see the basis for the recommendation and not just its conclusion, needs a workload that permits genuine review, needs override to be as easy as approval, and needs override rates to be monitored — because a reviewer approving 100% is evidence the control is not working, not evidence the model is excellent.

This is worth designing deliberately, particularly in agentic workflows where the system takes actions rather than making recommendations. The oversight question changes shape entirely when the model can act: the meaningful control is not reviewing each step but bounding what the agent is permitted to do at all, and logging what it did.

What This Costs and How to Phase It

Rough figures from work we have delivered, for a company shipping AI features in a commercial product and not operating a high-risk system.

Classification and gap assessment — which regimes apply, provider or deployer, risk tier per feature: 2–3 weeks, and it reliably changes the plan
Disclosure and content marking, including provenance through the asset pipeline: 4–8 weeks depending on how many surfaces generate content
Model registry and structured inference logging: 4–6 weeks if retrofitted onto a reasonably consolidated architecture, considerably more if model calls are scattered
Evaluation harness with retained evidence: 3–6 weeks, and it improves shipping velocity independently of compliance
Full high-risk conformity programme: 9–18 months, a different category of undertaking entirely, and not something to start late

For a team shipping ordinary AI features the total is roughly a quarter of engineering effort spread across a year, most of which is work with independent operational value. That is a very different conversation from the one people expect when compliance is raised, and it is worth framing it that way when asking for the budget.

A Readiness Checklist You Can Run This Month

List every AI feature in production and every model behind it, including the ones a team added without telling anyone
Classify each as provider or deployer, and by risk tier, with counsel sign-off recorded
Audit every surface where users interact with AI output and confirm disclosure is present and unambiguous
Trace one generated asset end to end and check whether its provenance metadata survives to the customer
Try to answer "which model version produced this output on this date" for a real case from six months ago
Check whether any consequential decision — hiring, credit, access, pricing to individuals — is model-influenced, because that changes your tier
Verify tenant isolation on every retrieval index carrying customer data
Confirm someone owns AI compliance by name, with time allocated, not as an addendum to a security role

Most teams fail the fifth item, and it is the cheapest one to fix going forward and the most expensive to fix backwards.

The Strategic Read

The delay to 2027 and 2028 was not a signal that AI regulations are softening. It was an admission that the supporting infrastructure was not ready, paired with a deliberate decision to keep the transparency obligations moving on schedule. Regulators kept the parts that protect people from being deceived and dropped the parts that would have required certification bodies that do not exist yet.

For product teams the sensible response is to stop treating this as a compliance project with a deadline and start treating it as a set of engineering properties your AI systems should have anyway. Know what models you run. Log what they do. Mark what they generate. Be able to explain a decision. Keep evidence you evaluated it. Every one of those is defensible on operational grounds alone, and every one is what a regulator, an enterprise procurement questionnaire, or an incident review will ask for.

The companies that will find 2027 painful are not the ones that started late. They are the ones that spent the extension writing policy documents instead of instrumenting systems. If you want a view on where your architecture stands against this, get in touch — or read more about how we build AI development services with governance in from the first sprint.

Frequently Asked Questions

Have EU AI regulations been delayed to 2027?

Partly. The high-risk obligations were deferred — to 2 December 2027 for Annex III standalone systems and 2 August 2028 for Annex I product-embedded systems. Prohibitions, general-purpose AI model obligations, penalties, and the transparency requirements were not deferred. If your product is not high-risk, the delay does not change your position at all, and your obligations are already live.

Do AI regulations apply to my company if we are not in the EU?

The AI Act applies extraterritorially where an AI system is placed on the EU market or its output is used in the EU, so a US or Indian company serving EU customers is in scope. This mirrors how GDPR reached non-EU companies. The practical trigger is whether EU users can access the product or its outputs reach the EU, not where the company is incorporated.

What is the difference between an AI provider and a deployer?

A provider develops an AI system or has it developed and places it on the market under its own name. A deployer uses one under its own authority in a professional context. Building a product on a third-party foundation model and selling it makes you a provider of that system. Substantially modifying a system or applying your own branding to it can move you from deployer to provider, which carries materially heavier obligations.

When do AI content marking and watermarking rules take effect?

Transparency and machine-readable marking obligations for AI-generated and AI-manipulated content are due on 2 December 2026 under the amended timeline, with a short additional window for models already on the market before August 2026. In practice this means provenance metadata attached at generation and preserved through your delivery pipeline, not just a visible label in the interface.

Is a disclaimer saying 'AI-generated' enough to comply?

For user-facing disclosure it is a necessary part, but the marking obligation is explicitly machine-readable, which a rendered text label is not. You need metadata that travels with the artefact — content credentials for images and video, and a defensible marking approach for other media — and it must survive resizing, re-encoding, and CDN transformation, which is where most implementations quietly fail.

What are the penalties for non-compliance with the EU AI Act?

The Act sets tiered administrative fines, with the highest band for prohibited practices reaching up to €35 million or 7% of worldwide annual turnover, whichever is higher, and lower bands for other breaches and for supplying incorrect information. The penalty provisions have applied since August 2025. Member States set and enforce the specifics, so exposure depends on where you operate.

How do we know if our AI system is high-risk?

High-risk covers systems listed in Annex III — biometrics, critical infrastructure, education, employment and worker management, access to essential services including credit and insurance, law enforcement, migration, and justice — plus safety components in products already regulated under EU product safety law. Most commercial AI features are not high-risk. Making a consequential decision about an individual is the strongest signal that you might be, and it warrants a formal classification with counsel.

What should we build first if we have limited engineering time?

A model registry and structured inference logging. They are prerequisites for answering almost every question any regime asks, they cost a few weeks, and they pay for themselves in incident response and cost control regardless of regulation. Disclosure and content marking come next if you generate customer-facing content, because that deadline is the nearest one.