The date has arrived. Someone posts a link to the EU AI Act in the project channel and asks whether the workflow is “compliant now”. The question sounds sensible. It is also too large to answer in a chat reply.
From 2 August 2026, much of the AI Act became applicable and enforcement responsibilities moved into a more active phase. Some provisions arrived earlier; some high-risk rules have later transition points; amendments have also been moving through the EU process. The calendar matters. It still cannot tell you what the system does, which role your organisation occupies, or whether the evidence behind this particular use is good enough.
That is the operating gap. A regulatory date is being asked to make a deployment decision.
Start with the workflow people actually use
“We use AI in recruitment” is not a workable description. Neither is “the model only makes recommendations”. Before reaching for a category, write down the journey as it exists on an ordinary Tuesday.
A manager uploads applications. A service extracts information, ranks candidates and produces a shortlist. A recruiter can alter the list, although the interface makes that awkward. Rejected candidates receive a standard message. The provider stores prompts for a stated period. Nobody has checked whether the team tends to accept the first ranking.
That account is more useful than the product label because it exposes the people, data, decisions and practical influence. Human involvement is not established by placing a person near the end of a process. You need to know what they can see, what they can change, how much time they have, and what happens when they disagree.
Do the same for a lower-consequence workflow. An internal assistant drafts meeting summaries from transcripts. The summary is checked before circulation. It cannot send messages, change a record or make a decision. The risks and likely obligations are different. “AI” is not one operating condition.
Keep legal classification and operational judgement separate
The European Commission’s AI Act timeline is the right place to confirm the current application sequence. It is not a substitute for legal advice on a particular system. Classification may depend on purpose, context, role and technical facts that a general article cannot resolve.
Operational judgement asks a related set of questions:
- What decision or action can this workflow influence?
- Who could be affected if it is wrong?
- Which data enters, leaves or persists?
- What is the human reviewer genuinely able to do?
- Which cases sit outside the approved boundary?
- Who can pause the workflow without negotiating with five teams?
These questions do not make a system compliant. They make the system legible enough for the right legal, security, data-protection and operational review to happen.
A deadline-day meeting can still produce a useful decision
Imagine a small team using an assistant to draft replies to supplier enquiries. It retrieves approved policy text and a person reviews every reply. The team has a six-week pilot behind it, but the evidence set contains mostly simple English-language requests. Attachments were excluded. Nobody measured whether reviewers caught plausible but incorrect policy references.
The wrong choices are not limited to “switch it off” and “roll it out”. A proportionate decision could be:
Keep the assistant in the existing team for four weeks. Exclude attachments, payment changes and non-English messages. Add twenty known difficult cases to a regression set. Record reviewer changes and any policy citation error. The operations lead owns the stop decision.
That decision might later prove too cautious or not cautious enough. What matters is that its scope and review trigger are visible. The date prompted the meeting; it did not supply the answer.
NIST’s AI Risk Management Framework offers a useful voluntary structure around governance, context, measurement and management. NIST also states that the framework is being revised. Use it as a way to improve the questions and records, not as a badge or a claim that the workflow has been certified.
The evidence should travel with the decision
Regulatory work often becomes a folder of policies separated from the product behaviour. Product work becomes a backlog separated from the risk discussion. When the two drift apart, a later reviewer sees a decision but not the conditions that made it reasonable.
Keep a small record beside the workflow: purpose, owner, affected people, system and configuration, data boundary, evaluation set, known failures, human-control design, current release boundary, decision date and next review trigger. Link to specialist advice rather than paraphrasing it into certainty.
I built the AI Workflow Decision Kit for this awkward middle: enough structure to locate the missing evidence, without disguising a working record as legal clearance.
Before the next AI meeting
Take one live AI workflow and describe it without using the product name or the phrase “AI-powered”. Name the input, action, affected person, reviewer, possible consequence and stop owner. Then place the current legal question beside that description and send both to the appropriate specialist.
If the description cannot be completed, that is the next piece of work. Do not fill the gap with a broad assurance from the vendor deck.
Sources and limits
- European Commission: AI Act application timeline — used for the current sequence and the 2 August 2026 application point. The Commission page is an official overview, not a classification or legal opinion for a particular workflow; live amendments and implementation decisions must be checked again.
- NIST: Artificial Intelligence Risk Management Framework — used for the voluntary governance, mapping, measurement and management structure. NIST guidance is not EU law, certification or evidence that a particular deployment is safe, and NIST says AI RMF 1.0 is being revised.
Sources reviewed 7 September 2026. Recheck the law, guidance and actual system before release or a material deployment decision.