The EU AI act is already here. Are you ready?

An article by Juan Abal and Daniel Cato

Think your AI provider owns the risk? It’s not that simple. Much of the conversation around the EU AI Act has focused on the deadlines that have moved, but it’s what hasn’t changed that organisations need to be thinking about now.

Over the past year, a familiar pattern has emerged, organisations know the EU AI Act exists. They know something significant was due in 2026. And they have heard, correctly, that the most demanding requirements have been pushed back. 

The conclusion many have drawn from that is understandable, but it is the wrong one. 

The Digital Omnibus deferred the rules for high-risk AI, including the conformity assessments, the technical documentation, and the registration obligations. Those requirements now apply from December 2027 for standalone systems, and from August 2028 where AI sits inside products already covered by EU product legislation. 

What was not deferred are the transparency obligations. Those took effect on 2 August 2026, and unlike the rules for high-risk AI, they apply to every AI system regardless of how it is classified.

“The deadline that moved is not the deadline that matters to most organisations. The one that mattered, has already passed.”

Why this reaches UK organisations:

The Act applies where an AI system is placed on the EU market, and where the output of that system is used within the EU. A UK organisation with European customers, a European subsidiary, AI-enabled products or services delivered into Europe, or supply chain involvement in AI systems used in Europe may well be in scope regardless of where it is headquartered or where its systems are hosted. 

Scope depends on the specifics, and it needs assessing rather than assuming. The relevant question is not where an organisation is based, but what role it plays in relation to an AI system and whether that activity creates a connection to the EU market.  But “we are UK-based” is not an answer by itself and it could be an inaccurate one. 

What is in force:

AI literacy obligations are already in force. Providers and deployers must take proportionate measures to support the AI literacy of staff and others operating or using AI systems on their behalf, taking account of their knowledge, experience and the context in which the systems are used. This does not necessarily mean providing the same training to everyone, but organisations should be able to demonstrate how they are equipping people to use AI appropriately.

The transparency requirements are narrower than the high-risk rules but can apply regardless of risk classification. The specific duty depends on whether an organisation provides or deploys the system: 

• Organisations deploying AI systems that interact directly with individuals must ensure people are informed that they are interacting with AI, unless this is already obvious from the context. 
  
• Deployers of emotion recognition or biometric categorisation systems must inform affected individuals of their use, subject to limited exceptions. 
  
• Providers of AI systems that generate synthetic audio, image, video or text content must ensure outputs are appropriately marked or disclosed as AI-generated in accordance with the Act’s transparency requirements. 
  
• Deployers using deepfakes or publishing AI-generated content on matters of public interest may also have additional disclosure obligations. 

There is one date still ahead. Systems that were already generating content before August 2026 have until 2 December 2026 to meet the content marking requirement. For organisations running generative tooling that predates this summer, that is a live deadline rather than a distant one. 

The assumption worth challenging:

Many organisations are not building AI models, but buying them, embedded in a productivity suite, a service desk platform, a recruitment tool, a customer chat function. 

That leads to a reasonable but perhaps mistaken assumption: that the obligation sits with whoever built the technology. 

It doesn’t. The Act distinguishes between the organisation that develops, places, distributes or otherwise makes an AI system on the market and the organisation that deploys and uses it. Each role carries its own duties. An organisation using an AI system cannot assume compliance has been outsourced to the vendor. The organisation using the system is responsible for how it is deployed, how people affected by it are informed, whether staff use it appropriately and whether meaningful human oversight and governance is in place for the risks the system creates. 

In practice, organisations often occupy multiple roles at once. A business may procure a third-party AI model, integrate it into its own services and then deploy it internally, bringing different obligations under the Act depending on the activity being performed.

Procurement transfers the technology. It does not transfer the accountability. 

There is a further point that catches organisations out. Role classification is not fixed. Applying your own branding to a third-party system, modifying it substantially, or putting it to a materially different purpose can shift your status from user to provider – and with it, the full weight of the obligations.  

This is where compliance can move beyond procurement and vendor due diligence. Decisions made during integration, customisation and deployment can alter the organisation’s responsibilities, even where the underlying technology was purchased from someone else. 

“Classification follows the use case, not the technology.”

A second misconception is worth addressing directly, because it is leading organisations in both directions at once. 

High risk is not a property of the technology and it is not a property of the delivery model either. A platform is not high risk because it is sophisticated, or because it is delivered as a service, or because it uses a large language model. 

Whether a system is high risk depends principally on its intended purpose and the context in which it is used. The same technology can produce very different regulatory outcomes depending on the function it performs. Uses such as assessing someone’s creditworthiness, screening job applicants or determining access to certain essential services may fall within the Act’s high-risk categories. By contrast, systems used only for routine expense administration, drafting marketing copy or summarising meetings would not ordinarily fall within those categories, although classification must always be based on the system’s actual intended purpose and operating context. 

The practical consequence is that two organisations using the same underlying technology may reach different classification outcomes because they are using it for different purposes. Classification cannot be inferred from the product category, procurement route, delivery model or sophistication of the technology alone. Nor should an organisation rely solely on a supplier questionnaire or description of the product: it must understand how the system is being used within its own operating environment.

This is not a point-in-time exercise. 

There is a strong instinct, particularly in organisations with mature compliance functions, to treat this as an assessment: run it, document it, file it, revisit at renewal. 

The Act is not built that way. It treats risk management as a continuous process across the lifecycle of a system, supported by ongoing monitoring, review, and where necessary, corrective action once that system is in use. Models evolve. Systems are retained. New features are introduced. A tool procured for one function quietly becomes the mechanism for another. 

An assessment completed in March describes an estate that no longer exists by September. 

This will be familiar to anyone who has watched shadow IT evolve into shadow AI. Capability is arriving through features switched on inside platforms organisations already own, and through updates delivered by suppliers and through agents configured by teams who would not describe themselves as deploying an AI system at all.  

The challenge is not simply identifying AI at a point in time. It is maintaining visibility as systems, use cases and responsibilities change. Governance that depends on a once-off assessment or on people remembering to raise a request before introducing new capability, is unlikely to keep pace with the rate AI is being adopted across the organisation…

Looking ahead starts with three practical priorities: 

1. Establish visibility
   Identify the AI systems and capabilities already in use across the organisation. This should include standalone products; AI functionality embedded in existing platforms and agents or workflows configured by individual teams. 
   
   
2. Determine the organisation’s role
   Establish, system by system basis, whether the organisation is acting as a provider, deployer, importer or distributor. Purchasing the underlying technology does not, by itself, determine the organisation’s regulatory role or remove its responsibilities. 
   
   
3. Classify by intended purpose
   Assess how each system is actually being used, who may be affected and what decisions or outputs it supports. Classification should be based on purpose and context, rather than product name, delivery model or technical sophistication.
   

The regulatory requirements may continue to evolve. Organisations that understand their AI estate will be better placed to respond to future changes, their regulatory roles and purpose for which AI is being used.   For them, future requirements are more likely to be absorbed as an evolution of existing governance. Those that do not may find that every new deadline begins with the same question: what AI are we actually using?  

This article reflects the position as of September 2026. The AI Act timeline has been amended once already and may be amended again. It is general information rather than legal advice; scope and obligations depend on individual circumstances.