The EU AI Act: five questions, not a list of articles

In August 2026 a great many organisations read the news about the EU AI Act and heard a single word: delay. The high-risk deadline moved. The obligation did not disappear, and some of what arrives next is closer than the headlines suggested.

Management then asks a reasonable question — what applies to us now? The wrong answer is a list of articles. The useful answer starts with what the organisation actually does with AI, because a purchased AI feature can still create your obligation. Buying the technology does not outsource accountability for the way it is deployed, changed, or used.

Our brilliant intern has entered a regulated workplace. It now needs more than capability. It needs a defined job, boundaries, supervision, and evidence the organisation can defend.

A later deadline is preparation time. It is not permission to postpone discovery, ownership, controls, or evidence.

What actually moved — and what did not

The Act became generally applicable on 2 August 2026, but its duties arrive in stages, and the Digital Omnibus amended only part of that schedule. The distinction matters, because some controls are already enforceable while others have later application dates.

• Already in force. Prohibited practices and the AI literacy duty have applied since 2 February 2025. Obligations for providers of general-purpose AI models followed in August 2025, with the Commission’s enforcement powers beginning a year later.
• Also live. Transparency obligations were not deferred. Depending on the system and the use, people may need to be told that they are interacting with AI, or that content has been artificially generated or manipulated.
• Deferred. Annex III high-risk requirements moved to 2 December 2027, and high-risk systems embedded in regulated products to 2 August 2028.
• Added, not removed. The same amendment that deferred the high-risk timetable expanded the list of prohibited practices, with the new prohibitions taking effect in December 2026 — sooner than the deadline everyone is talking about.

That last point is the whole story in miniature. The package that granted the extension also brought an obligation forward. Reading it as a delay is a misreading.

One · Where is AI actually used?

Inventory the decision and the business process, not merely the model or the product name. One general-purpose model can support recruitment, fraud detection, customer service, and marketing. The technology is the same. The legal and business context is not.

At minimum, record the purpose, the people affected, the data used, the output produced, the action enabled, and the accountable owner. Shadow AI is now a compliance blind spot rather than a security one: an unrecorded use cannot be classified, controlled, or evidenced.

Two · Which role do we perform?

The common first mistake is starting with the familiar risk pyramid. Before classifying the system, determine the organisation’s role in the AI value chain — and decide it per use case, not per vendor. The same organisation can be a provider in one use case, a deployer in another, an importer in a third, and a product manufacturer elsewhere.

“We bought it” usually means the organisation is a deployer. It does not mean exempt. Use under organisational authority still carries duties: instructions, competent human oversight, monitoring, and records become operating controls rather than legal abstractions.

Role can also change after deployment. Rebranding a system, substantially modifying it, or changing its intended purpose can move an organisation into provider responsibilities. That should trigger reassessment, not merely a technical change ticket.

Three · What risk class applies?

The answer may be prohibited, high-risk, subject to transparency duties, subject to model duties, limited-duty, or outside scope altogether. Prohibited means do not deploy: no control library converts a prohibited practice into an acceptable deployment.

High-risk classification depends heavily on intended purpose and context, so the business use can matter more than the underlying algorithm. And transparency is not a footer exercise — the disclosure has to reach the affected person, in the relevant interaction, clearly and in time to matter.

One layering trap is worth naming. General-purpose model obligations and AI-system obligations operate at different levels. A compliant underlying model does not automatically make the downstream system compliant.

Four · What applies now, and what comes next?

Build a dated obligation map for each use case rather than relying on one enterprise-wide deadline. Prohibited-practice controls and AI literacy are already applicable. Transparency duties and model obligations are active. The enforcement environment is operational.

High-risk controls need design lead time in any case. Risk management, data governance, logging, human oversight, technical documentation, and post-market monitoring do not appear overnight. And the vendor’s roadmap is a dependency, not your evidence — you still need your own record of use, role, configuration, oversight, monitoring, and decision rights.

Five · Can we prove control?

Compliance becomes real only when evidence has an owner, a location, a review cycle, and a decision it supports. A policy expresses intent; evidence shows that the operating control exists, is used, and can be challenged.

I would build one chain and test it: obligation, risk, control, evidence, accountable owner. If any link is missing, that is an assurance gap, whatever the policy says.

• Literacy has to be relevant. Proportionate to people’s technical knowledge, experience, context, and the systems they operate. Generic annual awareness will not carry every role.
• Oversight needs authority. A reviewer requires competence, context, time, and the ability to refuse or suspend the system. Without the last one, it is not oversight.
• Logs need a reader. Retention without monitoring is storage, not assurance.

One use case, worked through

Consider an AI recruitment assistant that screens applications and recommends candidates. Its use affects access to employment, so the consequence is not merely a generated answer — it may influence an opportunity for a real person.

The employer is at least the deployer. Material modification, a changed purpose, or placing the system under its own name may alter that position. Employment-related use may fall within Annex III depending on the specific intended purpose and any applicable exclusions, and that classification deserves legal validation rather than a confident guess.

Some duties apply now; the amended high-risk requirements come later. The evidence should show instructions, human oversight, monitoring, incidents, changes, and decisions — and it should survive staff, vendor, and model changes.

What I would do in ninety days

Build the minimum defensible AI operating system, in three passes.

• Days 1–30 — discover and classify. Use-case inventory, role map, provisional classification, and an escalation path for uncertainty.
• Days 31–60 — assign controls and evidence. Name owners, close the immediate transparency, prohibition, and literacy gaps, and define where evidence lives.
• Days 61–90 — test the operating model. Follow one high-impact use case from procurement through deployment, monitoring, change, incident response, and retirement.

I would not wait for perfect regulatory certainty. I would build traceable decisions, proportionate controls, and evidence that can adapt as guidance and standards evolve.

A delayed deadline can still become an early advantage. Organisations that understand their AI estate adopt faster, because they can tell acceptable uncertainty from unmanaged exposure. The test changes the management conversation from are we compliant to which decision can we defend, with what evidence, and under whose authority.

Choose one AI use case this week. Record its use, your role, its risk class, the applicable timetable, and the evidence owner — before approving the next change.

← All field notes