The EU AI Act timetable has changed, but the work has not become simple. The Digital Omnibus delayed several major high-risk AI obligations, creating more time for technical implementation while leaving organisations with a separate challenge: human capability, management behaviour and defensible evidence cannot be built at the end of a programme. This article looks at how transformation teams should reinterpret the revised dates, sequence the work that cannot be compressed, and avoid mistaking a regulatory delay for permission to wait.
The revised timeline created relief.
It also created a planning trap.
The Digital Omnibus moved major obligations for stand-alone Annex III high-risk systems to 2 December 2027. High-risk AI systems embedded in regulated products move to 2 August 2028.
Programme teams gained time on some of the heaviest technical work.
Then many organisations made the wrong inference:
We can start later.
That conclusion ignores the work that does not compress.
Separate the dates before building the plan
The AI Act does not have one deadline.
Article 4’s AI-literacy obligation has applied since 2 February 2025. Following the 2026 amendment, providers and deployers must take measures supporting AI literacy among staff and other people who operate or use AI systems on their behalf.
Article 50 transparency requirements remained on the 2026 timetable, subject to the precise provision and any applicable transitional rule.
Major high-risk-system requirements now apply later.
Those facts produce a different sequence from the one many programmes originally assumed.
The technical peak moved right.
The people work did not disappear.
The biggest workstream is not always the longest
Technical documentation, classification, testing and conformity work can be enormous. They are also comparatively legible.
You can define deliverables. Add specialists. Run parallel workstreams. Increase budget. Recover part of a slipping schedule.
Human capability behaves differently.
People need repeated practice. Managers need to establish authority. Teams need to see that responsible challenge is supported. Evidence needs to remain current. Weak performance has to be remediated and tested again.
You cannot add ten contractors in the final month and manufacture judgment.
That makes capability work uncrashable.
Programme planning should treat it accordingly.
The backwards plan
Start from the point at which the organisation wants defensible evidence.
By then:
- the relevant population must be known;
- roles must be grouped by exposure and consequence;
- expected decisions must be defined;
- learning and practice must be built;
- an initial baseline must exist;
- the programme must run;
- poor performance must be remediated;
- people should be reassessed;
- managers must understand their authority-and-support obligations;
- evidence must be assembled and reviewed.
Now move backward.
-
The scope decision gates design.
-
Design gates build.
-
Build gates practice.
-
Practice gates evidence.
-
Evidence gates remediation.
Remediation requires time.
The calendar contracts quickly.
Scope by exposure, not by org chart
Article 4 reaches staff and other persons dealing with AI systems on an organisation’s behalf. That can include contractors, service providers and outsourced operators depending on the facts.
An employee-only population may therefore be incomplete.
A company-wide population may be equally unhelpful if everyone receives the same generic intervention regardless of role.
The transformation team needs an exposure model.
At minimum, map:
- System: Which AI system is being used?
- Role: Who operates, configures, supervises or relies on it?
- Decision: What action or judgment does it influence?
- Consequence: What happens when the output is wrong or misused?
- Control: What must the person check, escalate, override or stop?
- Evidence: What would demonstrate that the person can do that?
This produces tiers that can be defended.
It also prevents the programme from spending equal effort on radically unequal risks.
Run two tracks in parallel
Track 1: The operational evidence track
This includes inventory, role mapping, baseline measurement, programme design, practice and evidence.
It is visible. It can be planned.
Track 2: The management environment
This includes authority, support, incentives, escalation and the treatment of overrides.
It is less visible and usually more difficult.
Start it first.
Ask managers what happens when an employee rejects an AI recommendation and is wrong. Review actual incidents, not policy language. Check whether throughput targets discourage review. Determine whether employees can access expertise quickly.
A transformation plan that ignores these conditions may produce trained employees who sensibly refuse to use what they learned.
A workable sequence
Phase 1: Discover
Inventory AI use from real operating evidence: system logs, licences, workflow maps, vendor records, team interviews and customer-delivery processes.
Do not rely solely on a survey. People use tools they do not classify as AI, and unofficial use is often omitted.
Phase 2: Prioritise
Create exposure tiers.
Begin with roles where AI informs consequential decisions, where errors are hard to detect, or where people are likely to over-rely on polished outputs.
Phase 3: Baseline
Measure behaviour before intervention.
-
How often do people check?
-
What evidence do they use?
-
When do they escalate?
-
Where do they defer?
-
How confident are they when wrong?
Without a baseline, the organisation can report activity but not movement.
Phase 4: Build and practise
Develop role-specific experiences around actual decisions.
Do not reproduce the policy deck in a new format. Put people into the judgment.
Phase 5: Reassess
Measure retention and transfer after time has passed.
A strong score immediately after training may reflect familiarity with the exercise. Reassessment reveals whether the behaviour lasts.
Phase 6: Package the evidence
Assemble evidence for internal governance, customers and relevant reviewers.
Pressure-test it. Ask someone outside the programme to find the gaps.
Two failure modes
The document programme
Every deliverable is a policy, matrix, framework, register or presentation.
The programme looks complete because the folder is full.
Nobody has observed whether people make better decisions.
The orphaned programme
Legal owns interpretation. L&D owns content. IT owns systems. Risk owns controls. Operations owns the work. Sales owns customer pressure.
Nobody owns the outcome.
Cross-functional work does not become owned simply because a steering committee exists. Name one accountable executive and one operating owner.
The executive message
Do not brief leadership with:
We have more time.
That is technically true and strategically weak.
Use the more accurate statement:
The timetable moved for work we can accelerate with specialist capacity. It did not remove the work that depends on repeated human performance and management behaviour.
That changes the discussion.
The question is no longer whether to launch a training project.
It is whether the organisation will use the additional time to build defensible capability—or spend the final quarter producing evidence of activity.
The difference will be visible to regulators, customers and employees.
More importantly, it will be visible the first time an AI system is confidently wrong and a person has to decide what to do next.
See the sequence from exposure to evidence. The Cognistry EU AI Act page shows how role mapping, decision practice and evidence fit together.
