Getting an AI pilot past a privacy review board
A client's AI Review Board blocked an HR timesheet agent on privacy grounds. I found the one risk the board actually cared about and wrote a narrow fix for it, and the board approved the pilot.
- Organization
- EY, for an enterprise client
- My role
- Senior Technology Consultant, AI Strategy
- When
- 2024 to 2025
- Result
- Pilot approved; about 10 hours a week of manual review reduced to spot checks (team lead's estimate)
The problem
The client’s HR team wanted to pilot an AI agent that reviewed timesheets before payroll, running in the background to flag variances and anomalies like missing punches and unusual overtime. It touched hourly pay data, and the client’s AI Review Board had blocked it on privacy grounds. HR needed the time back, and the board wouldn’t move on compliance.
My job wasn’t to be HR’s advocate. It was to get to a decision both sides could live with: a defensible approval, or a clear reason the pilot should stay dead.
What I did
First I checked whether the pilot was worth fighting for. The HR team lead estimated manual timesheet review took about 10 hours a week across several analysts, which was enough to justify the effort.
Then I asked the vendor specifically how their architecture handled data and whether they could change it. I interviewed board members about why the policy existed, and read it against similar clauses in the client’s other vendor contracts. The pattern was consistent: the board wasn’t worried about the agent processing pay data. It was worried about the vendor retaining that data to train its models.
With retention isolated as the actual risk, I brought Legal and the vendor together to draft a contract addendum that prohibited retaining or training on the client’s data, and took that back to the board.
Result
The board approved an exception for the pilot. The agent ran in the background before payroll, and the analysts’ manual review shrank to spot checks.
What I took from it
A blanket no usually protects against one specific risk. Finding that risk let us write a narrow fix for one use case instead of asking the board to loosen the whole policy, which it never would have done.