The critical path is an access request
Ask a team why their AI pilot has not reached production and you will usually hear about the model. It hallucinates. It needs fine-tuning. The context window is too small. The retrieval is not good enough yet.
Then look at the project's actual history — the gaps between commits, the weeks where the status stayed amber — and the picture changes. The model was adequate by week three. What consumed the remaining four months was getting a service account approved, getting it the right scopes, getting a non-production copy of the data that had the same shape as production, and getting someone with authority to accept that an automated process would write to a record that auditors read.
None of that is AI work. All of it is on the critical path.
Why this keeps surprising people
A pilot is designed, usually without anyone saying so, to avoid every one of these questions. You export a sample. You run it on a laptop or in a sandbox account somebody already had. You show results to people who are pleased. At no point does the pilot touch the production permission model, because touching it would have slowed the pilot down, and the whole point of the pilot was to be fast.
So the pilot proves the easy half and leaves the hard half entirely untested. The demo and the production system share a model and share nothing else. When somebody asks "how long to productionise this?", the honest answer is that nobody knows, because the project has not yet attempted the part that takes the time.
This is why the second estimate is always worse than the first. It is not that the team was optimistic. It is that the first estimate was made before anyone had discovered which approvals exist.
The questions that set the schedule
These are worth asking in the first week, not the fourteenth. Each one has a named human answer and a lead time, and those lead times do not run in parallel with each other as neatly as a plan assumes.
| Question | What it actually determines |
|---|---|
| Who can create a service account in this system? | Whether you can run anything outside a developer's own session |
| What scopes will it be granted, and who signs that off? | Whether the agent can read what it needs, or only some of it |
| Is there a non-production environment with realistic data? | Whether you can test at all before you test on customers |
| Who owns the records the system will write to? | Whether a write is allowed, and under what review |
| What is the audit requirement on an automated change? | Whether each action needs a logged, attributable reason |
| Who can approve an outbound call to a model provider? | Whether data leaving the estate is a one-week or one-quarter conversation |
The answers are rarely no. They are usually "yes, with a review board that meets fortnightly". That is a schedule, and it belongs in the plan on day one, where it can be worked in parallel with the build rather than discovered after it.
Plan access as work, not as a precondition
The common failure is treating access as something that happens before the project — a box ticked during mobilisation. It is not a box. It is a workstream with its own dependencies, its own owner, and its own risk of slipping, and it should appear on the plan next to the engineering, not above it.
A few things that make it go faster:
- Ask for the production shape immediately, even if you will not use it for weeks. Lead times are the problem, not effort. An approval requested in week one and granted in week six costs nothing. The same approval requested in week six costs five weeks.
- Name the write before you name the model. Read-only access is usually straightforward and usually insufficient. The interesting question — the one that attracts governance — is always what the system changes. Surface it early, while it is still a design discussion rather than a launch blocker.
- Get a realistic non-production environment or admit you do not have one. A sandbox with 200 synthetic records will not tell you how the system behaves against the duplicate, malformed, half-closed reality of production. If that environment does not exist, that is a finding to report, not a detail to work around quietly.
- Separate "we are allowed" from "we are configured". Approval granted is not the same as credentials working, and the gap between them is frequently another two weeks of ticket.
What this means for how you buy
If you are commissioning this kind of work, the proposals that quote the shortest timeline are usually the ones that have not asked these questions yet. A plan that says eight weeks with no mention of access, environments or audit is not a faster plan. It is the same plan with the slow part left out, and you will meet the slow part anyway — later, with less room to absorb it.
Ask instead what the delivery team believes the approval lead times are, and what happens to the date if they are wrong. A team that has done this before will have an answer, and the answer will be uncomfortable in a specific way rather than confident in a general one.
The models are, for most enterprise use cases, no longer the constraint. The constraint is a permission, and the permission has a queue.