The business case, security review and ownership questions to settle before moving an AI pilot into production.
Three reasons, usually together. No business case at real volume, because the pilot ran cheap and nobody modelled what volume costs. No security answer, because nobody wrote down what the system may read and do. No named owner, so there is nobody for the approval to land on. All three are preparable in advance and rarely are.
What the system can read and whose permissions apply, what actions it can take and which need human approval, what is logged, how it is stopped, and what happened when someone tried to break it. A policy document without controls behind it does not answer any of these, which is why reviews stall.
Take expected requests per period, average context length including retrieved content, and the model's pricing, then add the human review time that stays in the loop. Pilot figures mislead because pilots are low volume with short context. Caching and routing simpler requests to cheaper models change the number materially and are easier to design in before launch.
A named person on the business side who is accountable for outputs and can decide to switch it off, supported by whoever monitors quality. Not the vendor and not a committee. Approval frequently stalls precisely because this has not been agreed, and it is the cheapest gap to close.
Where the data is processed and whether it trains a model, how long prompts and outputs are retained at every hop, the full subprocessor list including the vector database and evaluation tooling, certifications by number rather than by logo, and the incident reporting window the contract commits to. Preparing these before the questionnaire arrives is usually worth weeks, because an incomplete subprocessor list restarts the review.
You need a written position, even if the answer is that the tool sits well below high risk. The EU AI Act can reach systems whose output is used in the EU regardless of where the company is based, and its transparency duties have applied since 2 August 2026, so they catch far more systems than the high-risk tier does. Write the classification with its reasoning and have counsel check it. We do the inventory and the technical classification; we are not a law firm and the legal interpretation stays with your counsel.
Better than finding out in production. Usually the gap is the data underneath rather than the model, and that is a different and more valuable project. The Express Scripts pilots were stalled on entity resolution, not modelling.
Most AI work does not die in the build. It dies between a working pilot and production, in a review nobody scoped, with no business case, no security answer, and no agreement on who owns it once it is live. This is the pack that closes those three gaps. Fill it in and the approval meeting becomes a decision instead of a list of new questions.
The business case, security review, and ownership questions to settle before moving an AI pilot into production, so the approval meeting is a decision rather than a delay.
Moving an AI pilot into production needs three things agreed: a business case with a measurable baseline, a security position covering what the system may read and do, and a named owner accountable after launch. Pilots stall because these are discovered during the approval meeting rather than prepared before it.
A pilot proves the thing can work. The case has to show it is worth running at volume, which is a different claim.
What the process cost in time, headcount, or error rate before. If the pilot did not record this, record it now from the pre pilot period, because every later number depends on it.
Pilots run at low volume with short context, which is the cheapest possible case. Model inference, retrieval, and review time at the volume you actually expect. This number surprises people and it is better to surprise them now.
Most production AI keeps a person on the consequential decisions. That review time is an operating cost and belongs in the case, not omitted to make the number look better.
Redeployed, or reduced. Sponsors ask and a case that dodges it loses credibility. Answer it plainly.
Maintenance, re-evaluation, and the upstream changes that break things. Inference is predictable; maintenance is not. Budget for the second year, because that is where these programmes get cancelled.
The single most common reason a working pilot does not ship. Answer these before the review rather than in it.
If retrieval ignores the asking user's access, the assistant can surface documents that person could not open. Permission aware retrieval is the answer reviewers are looking for.
A scoped tool list with an approval gate on anything touching customers, money, or a record of truth. Written down, not implied.
Prompts, retrievals, tool calls, and who the request was for. If an incident happens, this is the only thing that reconstructs it.
A kill switch, who can operate it, and how quickly. Reviewers ask this and a vague answer reads as an unmanaged risk.
Prompt injection, data exfiltration through tool calls, unsafe actions. Findings with reproduction steps, and what was fixed.
Approval often stalls here, because nobody has agreed who is accountable when the system is wrong at two in the morning.
A person, not a team. Accountable for outputs and for deciding when the system is switched off. Without this, the approval has nowhere to land.
An evaluation set and a threshold, checked on a schedule. Quality drift is discovered by a customer otherwise.
Who is told, who can pause it, and what the customer remedy is if something reached them.
When the system is re-assessed against its business case. Six months is typical. Systems nobody re-evaluates keep running long after they stopped being worth it.
Enterprise buyers and internal security teams send broadly the same questionnaire. It usually arrives late, goes to whoever is free that week, and comes back with answers that generate a second round. Writing these once removes weeks from the review.
The model provider, the region it runs in, and whether your prompts or outputs are used for training. Take the contractual answer rather than the marketing page, because the two often differ.
How long prompts, retrievals and outputs are held, by you and by each provider, and how deletion actually works. Zero retention usually carries conditions and a reviewer will find them.
Every third party in the chain, including the vector database, the evaluation tooling and anything doing document extraction. An incomplete list restarts the review rather than shortening it.
SOC 2, ISO 27001, HIPAA or whatever applies, for your own stack and for each provider, with a certificate reference and a date. A logo on a page is not evidence.
Who tells whom, how quickly, and what the contract commits you to. This is the question that most often sends a questionnaire back.
Some questions do not apply to how the system is built. A reasoned not applicable reads as competence. A blank field reads as evasion.
Nobody expects the sponsor to be a lawyer. They expect a written position counsel can check, and most pilots reach the approval meeting without one. This is the inventory and classification work that has to exist before counsel can give an opinion.
The EU AI Act can apply to systems whose output is used in the EU regardless of where the company sits. The Colorado AI Act takes effect on 1 January 2027, narrowed to disclosure duties and consumer rights. Sector rules may bind you harder than either. List them instead of assuming.
Most internal tools land well below high risk. What matters is that the classification exists in writing with the reasoning behind it, because we assumed it was low risk is not a position anyone can defend in an audit.
Risk management, data governance, logging, human oversight and a conformity assessment. High-risk obligations were deferred to 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in regulated products, so this is a project rather than a checkbox.
Transparency duties have applied since 2 August 2026 and catch far more systems than the high-risk tier does, including internal tools that generate content. Cheap to handle at design time and awkward to retrofit.
High-risk breaches reach 15 million euros or 3 percent of global turnover, and the 35 million euro tier applies to the prohibited practices in Article 5. The number matters less than the fact that an unclassified system has no defence.
Counsel owns the legal interpretation and should. This section gives them the system inventory and the technical facts to work from, which is the part that is usually missing when they are asked.
Cost per unit at real volume, the baseline, and year two. See section 1.
Access, permitted actions, logging, kill switch, and adversarial test results in section 2, and the questionnaire they are about to send you in section 4.
What data the system processes, where it goes, what is retained, and which obligations apply. Regulated sectors need this as evidence rather than assurance. The written risk classification is section 5.
What changes in their day, what the exception queue looks like, and who clears it. They are rarely consulted and frequently the reason adoption fails.
Three machine learning pilots at a pharmacy benefit manager had been deadlocked for over a year. The blocker was underneath the models rather than in them.
Three separate member ID systems, so records could not be matched
These surface whether a firm has taken anything to production before.
What is the cost per unit at our expected volume, and what assumptions is that built on?
What adversarial testing will you run, and will we get the findings with reproduction steps?
Who owns this after you leave, and what does handover include?
What would make you recommend we do not put this into production?
Three reasons, usually together. No business case at real volume, because the pilot ran cheap and nobody modelled what volume costs. No security answer, because nobody wrote down what the system may read and do. No named owner, so there is nobody for the approval to land on. All three are preparable in advance and rarely are.
What the system can read and whose permissions apply, what actions it can take and which need human approval, what is logged, how it is stopped, and what happened when someone tried to break it. A policy document without controls behind it does not answer any of these, which is why reviews stall.
Take expected requests per period, average context length including retrieved content, and the model's pricing, then add the human review time that stays in the loop. Pilot figures mislead because pilots are low volume with short context. Caching and routing simpler requests to cheaper models change the number materially and are easier to design in before launch.
A named person on the business side who is accountable for outputs and can decide to switch it off, supported by whoever monitors quality. Not the vendor and not a committee. Approval frequently stalls precisely because this has not been agreed, and it is the cheapest gap to close.
Where the data is processed and whether it trains a model, how long prompts and outputs are retained at every hop, the full subprocessor list including the vector database and evaluation tooling, certifications by number rather than by logo, and the incident reporting window the contract commits to. Preparing these before the questionnaire arrives is usually worth weeks, because an incomplete subprocessor list restarts the review.
Do we need an EU AI Act risk classification for an internal tool?
You need a written position, even if the answer is that the tool sits well below high risk. The EU AI Act can reach systems whose output is used in the EU regardless of where the company is based, and its transparency duties have applied since 2 August 2026, so they catch far more systems than the high-risk tier does. Write the classification with its reasoning and have counsel check it. We do the inventory and the technical classification; we are not a law firm and the legal interpretation stays with your counsel.
Better than finding out in production. Usually the gap is the data underneath rather than the model, and that is a different and more valuable project. The Express Scripts pilots were stalled on entity resolution, not modelling.
Inventory and classify the systems, then build the audit trail.