The EU AI Act compliance clock has started

On 2 August 2026, the EU AI Act moved into its main enforcement phase. That does not mean every requirement applies to every AI system today. It means organisations can no longer treat the Act as a distant policy story. The practical task is to identify their AI estate, understand the role they occupy, and separate obligations that already apply from high-risk rules that have been delayed.

The wrong first question

Imagine a mid-sized professional-services firm. Staff use a general-purpose AI assistant to prepare proposals and translate material. Recruitment uses a ranking tool. The website has a conversational assistant. Marketing generates images, while a client team is considering an AI-supported decision workflow.

A director asks: "Does the EU AI Act apply to us?"

The honest answer is not a simple yes or no. The organisation may be a deployer for one system, a provider for another, and merely a customer of a general-purpose model provider elsewhere. One use may require basic literacy and internal guidance. Another may trigger a transparency duty. A recruitment use may become a high-risk classification question. A self-branded product feature may shift the organisation further up the regulatory value chain.

That is the first managerial lesson of the Act: compliance does not attach to the word AI in the abstract. It attaches to roles, systems, purposes, people, outputs and markets.

2 August 2026 matters - but it is not the finish line

The AI Act entered into force in August 2024, but its requirements were deliberately phased. Prohibited practices and AI literacy began to apply in February 2025. Obligations for providers of general-purpose AI models followed in August 2025. From 2 August 2026, the AI Office and Member State authorities have enforcement powers over the provisions that are already applicable, while Article 50 transparency requirements enter the live compliance picture.[1, 3]

The timetable was then changed only days before this milestone. Regulation (EU) 2026/1744 - the Digital Omnibus on AI - entered into force on 27 July 2026. It extended the principal Chapter III requirements for Annex III high-risk use cases to 2 December 2027 and for high-risk AI embedded in regulated products under Annex I to 2 August 2028.[1, 2]

This creates a dangerous temptation to use the later dates as permission to do nothing. They are not. The delay applies to particular high-risk requirements, not to the Act as a whole, and not to every other legal or commercial responsibility surrounding AI.

1. 2 February 2025: Prohibited practices and AI literacy applied.
2. 2 August 2025: General-purpose AI model-provider obligations applied.
3. 2 August 2026: Enforcement powers and Article 50 transparency obligations applied.
4. 2 December 2026: Two new prohibitions and the legacy-generator marking transition apply.
5. 2 December 2027: Main Annex III high-risk requirements apply.
6. 2 August 2028: Main Annex I product-embedded high-risk requirements apply.

Official enforcement framework.

The first question is your role, not your software

The Act uses several role definitions, and the same organisation may occupy more than one of them. A company that buys a third-party AI service is commonly a deployer. A company that develops a system - or has one developed - and places it on the market or puts it into service under its own name may be a provider. Importers and distributors have separate positions in the supply chain.[4]

This is not a technical distinction. It determines who must design, document, disclose, monitor, cooperate and, in some cases, appoint an authorised representative. It also means that white-labelling, substantial modification, fine-tuning or embedding AI into a product can change the answer. The contract label chosen by the parties does not necessarily decide the statutory role.

For most organisations, the immediate work is therefore a role map. For each AI use, record who supplies the model, who supplies the application, whose name appears on the service, who controls the use, who receives the output, and whether the organisation has modified or integrated the system. When those facts are unclear, the legal classification will be unclear too.

What already demands attention

1. Prohibited practices

Certain uses have been prohibited since February 2025. The list includes manipulative or deceptive practices that cause or are reasonably likely to cause significant harm; exploitation of vulnerabilities linked to age, disability or social or economic situation; certain forms of social scoring; untargeted scraping of facial images to build recognition databases; and emotion inference in workplaces and education, subject to a medical or safety exception. Two additional prohibitions introduced by the 2026 Omnibus take effect in December 2026.[5, 2]

Most organisations will not be operating obvious prohibited systems. The risk lies in assuming that a tool sold as engagement analytics, wellbeing intelligence, behavioural insight or fraud prediction cannot cross a line because its commercial label sounds ordinary. Human resources, education, biometrics, behavioural targeting and public-facing services deserve an explicit screen rather than a casual assurance from the supplier.

2. AI literacy

Providers and deployers must take measures to support the AI literacy of people operating and using systems on their behalf. The appropriate response depends on the system, the users, their knowledge, the purpose and the risk. The Commission explicitly says that employees using a general-purpose assistant for advertising copy or translation should understand risks such as hallucination.[6]

Article 4 does not demand a universal certificate or a particular governance structure. The Commission says organisations can retain internal records of training or other guidance, and that no specific AI officer or governance board is mandated for Article 4 compliance. That is permission to be proportionate, not permission to be vague.[6]

A useful literacy programme is therefore role-based. A casual user needs practical guidance on verification, confidentiality, copyright and acceptable use. A manager approving an AI-supported recommendation needs to understand human oversight and escalation. A developer or procurement lead needs deeper knowledge of documentation, testing, change control and supplier evidence.

3. Transparency for people and AI-generated content

Article 50 now creates live transparency duties for particular systems and content. Providers of AI systems designed for direct interaction with people must ensure that individuals are informed they are interacting with AI unless this is obvious. Providers of generative systems must support machine-readable marking and detection of synthetic content. Deployers have disclosure duties for deepfakes and for people exposed to emotion-recognition or biometric-categorisation systems.[7]

Deployers must also label AI-generated or manipulated text published to inform the public on matters of public interest, unless it has undergone substantive human review or editorial control and a person or entity holds editorial responsibility. The Commission is clear that spell-checking or grammatical correction alone is not substantive review.[7]

This does not mean that every AI-assisted email, report or marketing sentence needs a warning label. It does mean that organisations should distinguish private working material, customer interaction, synthetic media, deepfakes and public-interest publishing - and should be able to explain the human editorial process where they rely on the review exception.

4. General-purpose model-provider duties

The general-purpose AI obligations that began in August 2025 mainly concern organisations that provide such models, rather than ordinary users of third-party assistants. Providers must maintain technical documentation, make information available to downstream system providers, operate a copyright-compliance policy and publish a summary of training content. Providers of models with systemic risk have additional evaluation, incident-reporting, risk-mitigation and cybersecurity duties.[8]

The important point for an ordinary buyer is not to imitate the model provider's compliance programme. It is to ask what documentation and support will travel down the chain. A system provider cannot responsibly classify, integrate or monitor an application if the model layer is a black box and the contractual route provides no useful evidence.

What can legitimately wait - and what should not

The principal high-risk requirements do not all apply today. Following the Digital Omnibus, Chapter III requirements for systems classified under Annex III apply from 2 December 2027. These can include, subject to the Act's definitions and exclusions, uses in biometrics, critical infrastructure, education, employment, essential services, migration, law enforcement and justice. High-risk AI that forms a safety component of regulated products under Annex I follows on 2 August 2028.[1, 2]

A business does not need to manufacture a complete 2028 compliance file for every low-stakes AI assistant in 2026. It can legitimately wait for some final standards, guidance, conformity routes and product-specific obligations to mature. What it cannot sensibly postpone is finding the systems, identifying plausible high-risk candidates, preserving supplier evidence, assigning owners and deciding what would trigger escalation.

The distinction matters commercially. An organisation that waits intelligently avoids premature bureaucracy. An organisation that waits blindly accumulates unknown use, weak contracts and undocumented decisions. The first is sequencing. The second is governance debt.

Outside the EU? Do not assume you are outside the Act

There are different practical starting points for organisations inside and outside the Union, but the Act is deliberately extraterritorial in important respects.

• An EU-established organisation that uses an AI system under its authority is a deployer within the Act's territorial scope.
• A non-EU provider can be in scope when it places an AI system or general-purpose model on the Union market or puts a system into service there, regardless of where the provider is established.
• A non-EU provider or deployer can also be in scope where the output produced by the AI system is used in the Union.
• Importers, distributors, product manufacturers and authorised representatives can have their own obligations in the value chain.[9]

That makes the UK, United States or another third country different from a purely domestic EU deployment, but not automatically exempt. A UK software company selling an AI recruitment product to EU employers should expect the Act to matter. A US service business using AI to generate decisions, recommendations or public-facing output used in the EU should examine the output-use trigger. A company using AI only for a wholly non-EU internal process may be further from the core scope, although contracts, group structures and other EU laws may still create obligations.

Third-country providers of high-risk AI systems must appoint an authorised representative in the EU before making those systems available on the Union market. Providers of general-purpose AI models established outside the Union have a parallel representative regime, subject to the Act's specific conditions and exceptions.[10, 11]

The commercial spillover is likely to be wider than the strict legal boundary. EU customers, distributors and product partners will ask non-EU suppliers for classification, documentation, transparency support, incident cooperation and contractual assurances because their own ability to comply depends on the supply chain. In practice, an organisation can feel the Act through procurement before it hears from a regulator.

The sensible first response is an AI estate, not compliance theatre

The Act rewards something many organisations do not yet have: a reliable view of the AI systems operating across the business. That does not require an enterprise compliance platform on day one. It requires a structured register that can be defended and updated.

For each system or material use, record at least:

• the model, application or service and the supplying entity;
• the business purpose, users and people affected;
• whether the output informs, recommends or makes a consequential decision;
• the data involved, including personal, confidential or regulated information;
• the countries in which the system, users, customers and outputs are located;
• the organisation's likely role: provider, deployer, importer, distributor or product manufacturer;
• current transparency, human-review, logging, security and incident controls;
• vendor evidence, contractual support and known limitations;
• the accountable owner, review date and escalation route.

This register should connect to existing privacy, cybersecurity, procurement, product, employment and risk-management processes. Article 4 does not require a new AI officer or governance board, and many organisations will be better served by clear accountability inside existing functions than by creating another committee with no operational visibility.[6]

Meeting-ready artefact: the AI Act first-response map

Use the following questions in an initial management, procurement or governance discussion. The purpose is not to reach a final legal conclusion in one meeting. It is to expose the evidence gaps that prevent a defensible conclusion.

Use: first-pass governance discussion. It is a diagnostic, not a substitute for system-specific legal classification.

What to ask vendors, developers and consultants

Strong answers should contain documents, boundaries, named responsibilities and change-control commitments. Weak answers rely on phrases such as "compliant by design" or "the customer remains responsible" without explaining what the supplier has actually done and what evidence the customer will receive.

1. Which AI Act role do you believe you occupy, which role do you believe we occupy, and which facts support that allocation?
2. Which obligations apply to this system now, which are expected later, and which do you say do not apply?
3. What is your written classification rationale, including any conclusion that the system is not high-risk?
4. What transparency, synthetic-content marking or user-notification features are built into the service, and what remains for us to implement?
5. What information, logs, instructions and change notices will you provide so that we can monitor use and demonstrate our own controls?
6. What are the known failure modes, prohibited or unsupported uses, human-review requirements and escalation conditions?
7. Could our configuration, fine-tuning, integration, white-labelling or use of your system change our role or the system's classification?
8. How will you support incident handling, regulatory enquiries, model or product changes, and transition to the 2027 or 2028 requirements?
9. For a non-EU supplier, who is the EU importer, distributor or authorised representative where one is required?

What businesses should not do

• Do not treat the Act as one date. The law is already live in some areas and delayed in others.
• Do not classify every use as high-risk. Over-classification creates cost and obscures the genuinely sensitive systems.
• Do not wait until 2027 to build the inventory. A later compliance date does not make an unknown system easier to govern.
• Do not assume buying transfers responsibility. Provider and deployer duties sit at different points in the value chain.
• Do not create a grand governance structure before assigning operational owners. A committee cannot govern systems it cannot see.
• Do not forget the rest of the law. Data protection, employment, equality, consumer, intellectual-property, cybersecurity and product rules continue to apply.
• Do not let the maximum fine become the whole business case. The near-term costs of weak AI governance are more likely to appear as procurement delay, failed assurance, poor decisions, reputational damage and rework.

The compliance milestone is really a management milestone

The most useful response to 2 August 2026 is neither alarm nor postponement. It is a change in posture. AI use should move from scattered adoption and vendor assurance to a visible estate with owners, role definitions, evidence, proportional literacy, transparency checks and escalation paths.

The organisations best prepared for the later high-risk rules will not necessarily be those that spend the most on compliance in 2026. They will be those that can answer basic questions quickly: what the system is, why it is used, who is affected, what role the organisation occupies, what the supplier has proved, what remains uncertain and who can stop or change the deployment.

The Act's timetable is phased. Your knowledge of your AI estate should not be.