EY's 3% result needs a friction-transfer ledger
In short: EY's 3% clean-removal result is a triage signal; track where review, rework and recovery cost moves before deleting friction.
↗EY Megatrends — Why frictionless enterprises break firstOn 22 October 2026, EY reported that fewer than 3% of 18,796 O*NET tasks passed its strict test for friction that AI could remove cleanly. Redesign, stronger safeguards and new controls each covered far more work.
That is not an automation ceiling. EY's 3% result is a triage signal. I would add a friction-transfer ledger before deleting a delay: record where the review, rework and recovery cost will move.
EY's 3% result is not a capability forecast
EY mapped task statements from 923 occupations in O*NET 30.3, weighted them by US employment and applied predeclared percentile tests. Its four response categories can overlap.
| EY response | Employment-weighted tasks |
|---|---|
| Clean removal | fewer than 3% |
| Redesign | 24% |
| Stronger safeguards | 27% |
| New controls | 23% |
These are EY model outputs, not measured deployment outcomes.
The full methodology says clean removal remained the smallest response when thresholds changed, ranging from 0.4% to 5.5%. It also says task attributes were partly inferred from occupation-level data and its AI-supportability score does not measure the precise capabilities of current agents.
My friction-transfer ledger for an AI workflow
This is editorial judgement, not a Trigent or client deployment. I would require four entries before approving a friction removal: local time saved, downstream review or rework added, the recovery path if the output is wrong, and the owner who accepts that transfer.
Remove an approval from one team and its dashboard may get faster while another team's exception queue grows. Both effects belong in the same decision.
EY's model is useful only after local calibration
The study covers US occupational data, not one company's actual workflows, regulations or tool stack. EY treats its gates as decision-support signals and recommends decomposing tasks that meet several responses. I did not independently reproduce its classifications.
Use the article as a review template, not a universal percentage. The valuable question is not “Can AI make this step faster?” It is “Which cost disappears, which cost moves, and who can reverse the change?”
What's in it for you
- Stop local speed metrics from hiding downstream assurance work.
- Give every deleted check an owner and a recovery path.
Remove friction only after the whole value stream can show where its cost went.
