How to run an AI pilot that survives procurement
The demo goes well. The users are happy. Then legal asks where the data went, security asks who can see what, and finance asks what it costs per month. If you have not prepared for those three questions, the pilot stops there.
What happened
The pattern is consistent across deployments. Month one is technical: does it work. Month two is adoption: does anyone use it. Month three is institutional: procurement, legal, security and finance get involved, and they are not evaluating the model, they are evaluating whether the organisation can take on the risk. Most teams build for month one and are ambushed in month three.
Why it matters for deployment teams
Nothing about month three is technically difficult, and that is exactly the trap. Data residency, access control, retention and cost attribution are all solvable in a week if you start them in week one. They become unsolvable when they are discovered late, because by then the pilot has users, and unwinding it is a political problem rather than an engineering one.
What to do about it
Bring the three questions into the design. Data: write down, before you write code, which systems the model may touch and what leaves the network boundary — a one-page data flow diagram settles most legal reviews in a single meeting. Access: implement permissions at retrieval time, not as an afterthought, and be able to demonstrate it on request. Cost: instrument per-query cost from day one, because the first question finance asks is what happens at ten times the volume, and a number beats a promise.
The meeting you are not invited to
Two artefacts change the outcome. A one-page risk register listing what the system can do wrong and what mitigates each item, and a written data flow. Both are boring, both take an afternoon, and both turn a three-month review into a two-week one. Teams that skip them do not fail because the risk was unacceptable; they fail because nobody could describe the risk.