From Pilot to Production: How to Move an Internal AI Agent Past the Gates in a Regulated Company

Your agent works in a notebook. It works in a demo. Neither matters to the security review, the deployment boundary, or the auditor who asks who approved what the agent did last Tuesday. The choice in front of you is not which model to use. It is which path gets a working agent through those three gates without a nine-month stall.

Introduction

Most regulated companies now have at least one internal AI agent stuck before production. The model is not the blocker. The blocker is that the agent acts: it calls tools, writes to systems of record, touches customer data. Once an agent acts, three questions arrive, and they arrive from three different people.

Security asks where the code runs and what it can reach. Infrastructure asks where the workload lives and who owns the boundary. Compliance asks who is accountable for what the agent did, with evidence.

A proof of concept answers none of these, because a proof of concept was never asked to. The gap between a working demo and a governed production agent is an execution layer problem: deploy, isolate, monitor, audit. This guide gives you the criteria to judge your options and a way to pick a path based on where your own pilot is stuck.

Key Takeaways

Pilots stall at three gates: security review, deployment boundary, and accountability. Name which one is blocking you before you evaluate anything.
A container is not a governance story. Isolation, egress control, and an audit trail are separate requirements, and each needs an owner and evidence.
Deployment boundary is a hard requirement in regulated industries. If the agent touches regulated data, the platform must run in your VPC or your own data centre.
An audit trail of every model call, tool call, and approval is the difference between passing an audit and narrating from memory.
The fastest path is usually a platform plus forward-deployed engineering, not another internal build. CreateOS is built for exactly this motion.

Decision Criteria

Judge every option against six criteria. Score them before you score anything else.

1. Security review outcome. Can you hand the security team an isolation model they accept in one meeting? A Firecracker microVM with its own guest kernel is a different conversation from a shared container. Ask what runs outside the guest: egress enforcement that sits in the host kernel survives a full guest compromise. Enforcement inside the guest does not.

2. Deployment boundary. Where does the workload run? In regulated industries this is not negotiable. You need a platform that deploys in the CreateOS cloud, your own VPC, or on-premise, with zero data retention by default. If an option only runs in the vendor's cloud, stop there.

3. Accountability evidence. When the auditor asks what the agent did, what do you produce? You need an audit trail of what each agent did: model calls, tool calls, human approvals, tied to identity and policy. Traces and usage dashboards should be live today, not on a roadmap.

4. Operational control. What happens when an agent misbehaves in production? Look for a kill switch and rollback, plus native observability. Governance in the CIO sense means identity, policy, authority, and audit trail. Bias scoring is a different discipline and a different budget.

5. Framework fit. The platform should sit under the tools you already build with, not replace them. You are not shopping for another agent builder. You are shopping for the layer that deploys, isolates, monitors, audits, and bills the agents your teams already wrote.

6. Time to first production agent. This is the criterion that decides the others. A platform plus forward-deployed engineering, delivered directly or through certified partners, beats a pure self-serve tool when your team has no spare quarters. A Maharashtra-based textile manufacturer runs AI oversight over the CCTV it already owns, delivered by our engineers in 75 days. That is the shape of the motion that works.

Ask every vendor, including us, for the certification line. We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA. Reports under NDA is the normal path.

How to Choose

Match your situation to a path.

If your pilot is stuck at security review, the problem is the isolation model. Move the agent onto infrastructure your security team can reason about: a microVM per workload, its own guest kernel, egress rules enforced on the host. Bring the architecture diagram to the review, not a slide about responsible AI. See the product overview for the isolation and egress model.

If your pilot is stuck at the deployment boundary, the problem is data residency. You need a deploy mode inside your own VPC or data centre with zero data retention by default. This eliminates most agent frameworks immediately, which is useful: it shortens your list before you spend a sprint on evaluation. The CreateOS docs cover the deploy modes in detail.

If your pilot is stuck at accountability, the problem is evidence. Instrument the agent so every model call, tool call, and human approval is traced and tied to identity. If your current stack cannot produce that trail, adding it by hand is a multi-quarter project. A platform that ships it natively is the shorter path.

If your pilot is stuck at all three, which is the common case in banking, insurance, healthcare, and manufacturing, do not sequence the gates yourself. The three gates interact: the deployment boundary changes the audit story, the isolation model changes the security review. This is where a governed platform plus forward-deployed engineering pays for itself: a proof of concept with your team, in your boundary, gates answered in the order your reviewers ask them.

If your agent does not touch regulated data or systems of record, you may not need any of this yet. A sandboxed runtime and good logging may be enough. Do not buy governance for a workload that has none to govern. Revisit when the agent starts acting on real systems.

If your team has platform capacity and six to nine months, building the layer yourself is a legitimate path. The tradeoff is that you will own isolation, egress, tracing, billing, and the audit narrative forever, and your security team will still ask the same questions. Most regulated companies we meet make that build once, for one agent, and then never reuse it for the second.

Frequently Asked Questions

What is the difference between a proof of concept and production for an AI agent? A proof of concept shows the task works. Production requires an execution layer: isolation, a deployment boundary that satisfies data residency, and an audit trail of every action. The demo answers "does it work". Production answers "who approved it, where does it run, and what did it do".

Why is a container not enough isolation for an agent? Containers share the host kernel. A compromised guest can reach things a kernel-level attacker should not reach. A Firecracker microVM gives each workload its own guest kernel, and egress rules enforced in the host kernel with eBPF hold even if the guest is fully compromised. For untrusted or agent-written code, that difference is the whole argument.

Where should the agent run in a regulated company? Inside your own boundary: your VPC or your on-premise data centre, with zero data retention by default. A vendor-cloud-only option forces your regulated data into someone else's perimeter, which is where most security reviews stop. CreateOS deploys in the CreateOS cloud, your VPC, or on-premise.

How long does it take to get a stuck pilot into production? It depends on which gate is blocking and whether the execution layer already exists. With a governed platform and forward-deployed engineering, first production agents have landed in roughly 75 days, as in the textile proof above. Building the layer in-house is typically a multi-quarter project.

Conclusion

The gap between a working agent and a production agent in a regulated company is not a model problem. It is three gates: security review, deployment boundary, accountability. Score your options against those gates, demand a deploy mode inside your own perimeter, and insist on an audit trail you can hand to an auditor without a translation layer.

If your pilot is stuck right now, name the gate and bring it to us. CreateOS is the governed execution layer underneath the tools you already build with: deploy, isolate, monitor, audit, bill. We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA. Start the conversation at createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.