Why a small AI agent pilot takes months to approve

A team wants to try an AI agent on one narrow task. Sorting incoming requests, perhaps, or drafting first answers to routine questions. The pilot is small. It runs for a few weeks and touches one process. And still the approval takes months.

This is common in government and in regulated sectors. One team reported that every small AI use in their organisation needed a written proposal, a business sponsor, a cost sign-off from finance, several governance rounds, a security review and a data-protection impact assessment. Most of their projects stopped before they shipped. Another team, at a financial firm, reported that governance approval was one of their biggest hurdles with agents. The worry was concrete: could the agent create the wrong users, or give the wrong rights?

It is easy to blame the process. That is not quite fair. The reviewers have a real job to do.

An AI agent is not a chat window. It is a program that reads, decides and acts through tools. If you need the short version, see what an AI agent is. For a reviewer, this means the risk is not only in what the model says. It is in what the system can reach.

A security or privacy officer who gets a pilot request does not know the system. They cannot test it in an afternoon. So they ask questions. Each question goes back to the pilot team. The team asks the supplier. The answer comes back, and it often raises two new questions. Each round costs a week or two.

This is where the months go. Not into the review itself, but into the waiting between rounds.

When you look at what reviewers ask, the list is short. It changes a little between organisations, but the core stays:

What runs where? Which parts run on our machines, and which run somewhere else? What leaves the building? Which data goes out, to whom, and over which connection? Who can read the code? Can we, or someone we trust, inspect what the software does? What can it touch? Which systems, accounts and rights does the agent get? Who owns it? Who is responsible, who pays, and who decides when it stops? None of these is a hard question. But each one needs a clear, specific answer. "It is secure" is not an answer. "Data is encrypted" is half of one.

Pilot teams often prepare the wrong document. They write about the benefit: hours saved, faster service, less routine work. That is the case for the business sponsor. It is not what the reviewer needs.

A reviewer is not asked whether the pilot is a good idea. They are asked whether it is safe enough to try. A strong value case does not answer that. Sometimes it makes things worse, because it suggests a team that will push for more scope before the basics are clear.

The pilots that move faster do one thing differently. They bring the answers to the standard questions on day one. They do not wait to be asked. The reviewer can then spend their time on judgement, not on collecting facts.

A good answer is short, specific and checkable.

For "what runs where", it names the components and the machines. For "what leaves the building", it lists each outbound connection and why it exists, and says which ones the team controls by configuration. For "who can read the code", it names the licence and where the source is. For "who owns it", it gives a person and a role, not a department.

A good answer also admits limits. If one part depends on an outside service, say so. Reviewers trust a team that names its own gaps. They are wary of a pack where everything is perfect. It also helps to answer early who checks the system that runs the agent, not only the agent itself; see who audits the harness.

A small pilot should look small in the paperwork. Limit the data to what the task needs. Use test or low-risk data where you can. Give the agent only the tools the task needs. Set an end date and a stop criterion. Each limit removes a question from the reviewer's list, or makes the answer shorter.

There is a tension here. Teams want the pilot to prove real value, and real value needs real data. But the first approval is easier when the scope is narrow. A wider second phase can follow once the first one has a track record.

Before you submit, write one page. Each line is a statement your team fills in:

The agent does this one task: ___, for this team: ___. These components run on these machines: ___. These outbound connections exist, for these reasons: ___. These connections are set by our configuration, and we can switch them off: ___. The agent can use these tools and accounts, and no others: ___. The source code can be inspected by ___, under this licence: ___. The pilot uses this data, and no other: ___. The owner is ___, the pilot ends on ___, and we stop it early if ___. Hand this page to the reviewer with the request, not after the first question.

Several of these lines are short to write for EpicStaff. EpicStaff runs on your own infrastructure, so the "what runs where" line names machines you already manage. For the connection lines: EpicStaff connects out only to the providers you configure keys for. Tools do what you tell them: a tool you build or enable that reaches the internet is your choice and your configuration. For the tools line: in EpicStaff, an agent reaches another system only through tools your team attaches to it — Python tools (your own, or ready-made ones EpicStaff ships) or an MCP server your team connects. For the code line: EpicStaff is source-available under PolyForm Perimeter 1.0.0: read it, run it, modify it for your own use. The main restriction is providing others a product that competes with EpicStaff — free or paid. Inspection is not restricted. Other terms apply, including notice requirements when you pass the software on; see LICENSE.md. The task, data and owner lines stay with your team: they describe your pilot, not the software.