An AI pilot is not ready for production because the demo worked.

It is ready when the organization can explain what it is, who owns it, what data it touches, how it is monitored, and what happens when something goes wrong.

That sounds obvious.

In practice, it is where many AI projects start to break.

The first version works. The team is excited. The internal sponsor wants to move quickly. The vendor says production is only a configuration step away. The business sees time savings and wants the benefit now.

Then nobody asks the production questions.

Not the model questions.

The business questions.

Four questions are not enough

Microsoft recently framed four useful questions for organizations deploying AI agents:

What AI agents are running across the business?

Who is using them, and for what?

What systems and data can they touch?

How are they being monitored?

Those are good questions.

They are also only the beginning.

They cover the agent layer. They do not cover the full production risk around ownership, client disclosure, data sovereignty, fallback, escalation, auditability, and policy.

Four questions can tell you whether something exists.

They do not yet tell you whether the business is ready to own it.

That is the difference between a pilot and production.

The missing layer is ownership

The uncomfortable part of AI governance is not writing the policy.

It is finding out who owns the answer.

Who owns the usage policy?

Who approves a new AI workflow?

Who decides what data can be used?

Who explains it to a client?

Who reviews the logs?

Who stops the workflow if it starts producing wrong output?

In many companies, the honest answer is not “IT.”

It is “we would need to investigate.”

That answer may be acceptable during an experiment. It is not acceptable in production.

Production means the answer exists before the incident.

The data question is usually where it fails

The one question many owners fail is not whether the AI touches too much data.

It is whether anyone mapped what the AI is allowed to touch in the first place.

There is a big difference.

If a company has a clear map, it can decide whether a workflow is safe, unsafe, acceptable with controls, or not worth the risk.

If the map does not exist, the company is guessing.

It may be a good guess. It may even be right most of the time. But it is still a guess.

And when a client asks whether their data passed through an external AI service, guessing is not enough.

That is where the pilot becomes a liability.

Not because AI failed.

Because the organization cannot explain what happened.

The ten questions

Before an AI pilot goes into production, I would want clear answers to these ten questions.

1. What AI systems or agents are running?

Not what was approved six months ago. What is actually running today, including small automations, browser tools, API scripts, vendor features, and internal experiments that quietly became useful.

2. Who is using them, and for what?

AI usage is not one category. A developer using AI for code assistance is not the same as a sales team uploading proposals, or a support team summarizing customer tickets.

The risk follows the use case.

3. What systems can they reach?

Can the AI read email, documents, CRM records, tickets, source code, financial files, customer data, or internal knowledge bases?

If nobody can answer that quickly, the production decision is premature.

4. What data is allowed, and what data is forbidden?

This is not only about sensitive data. It is about knowing the boundary.

Client data. Employee data. Financial data. Source code. Contracts. Health data. Credentials. Logs. Internal strategy documents.

The list needs to be explicit.

5. Where does the data run?

Cloud provider. Region. External API. Vendor tenant. Local server. Browser extension. Employee laptop.

These details matter for privacy, sovereignty, contracts, and incident response.

6. Who owns the policy?

If the policy belongs to everyone, it belongs to nobody.

Someone has to own acceptable use, exceptions, updates, training, and enforcement.

7. How is usage monitored?

Production systems need observability.

For AI, that means knowing who used the system, what workflow ran, which data sources were involved, what output was produced, and whether the output was reviewed.

Not every interaction needs to be stored forever. But there has to be enough traceability to answer a real question later.

8. What happens when the AI is wrong?

This is where many pilots are too optimistic.

Wrong answers are not theoretical. They happen. The important question is whether the workflow catches them before they reach a customer, a regulator, a production system, or a financial decision.

If nobody owns validation, nobody owns the risk.

9. What would you tell a client?

If a client asks, “Did our data go through an external AI service?”, can the company answer clearly?

Not with a vague assurance.

With a factual answer.

Which service, which data, which purpose, which controls, which retention policy, which human review.

If the company cannot answer that, the pilot is not ready for client-facing production.

10. What is the fallback?

If the model is unavailable, the vendor changes policy, the cost spikes, the output quality drops, or the workflow is suspended, what happens?

Do people know how to continue manually?

Is there a second provider?

Is there a local or private model good enough for degraded operation?

Can the workflow be stopped cleanly?

A pilot can live without a fallback.

A production system should not.

The pilot is not the problem

I am not against pilots.

Pilots are how companies learn. They reveal where AI helps, where it does not, where the data is messy, where the process is undocumented, and where the real work actually happens.

The problem is not the pilot.

The problem is pretending that a successful pilot is the same thing as a production-ready system.

Those are different gates.

A pilot asks: does this create value?

Production asks: can the organization own the consequences?

That is a much harder question.

Why this matters more with agents

This becomes more important as AI moves from chat to agents.

A chatbot may answer a question.

An agent may take action.

It may read a file, call an API, update a ticket, create a task, send a message, change a record, trigger a workflow, or prepare something another human will trust.

That changes the governance problem.

The risk is no longer only bad output. It is bad output attached to system access.

That is why the inventory matters. That is why monitoring matters. That is why ownership matters.

Once an AI system can act inside the business, “we think it is fine” is not a control.

The one-page readout

For small and mid-sized businesses, this does not need to become a six-month governance program.

That is usually the wrong starting point.

The useful starting point is a short diagnostic.

Ten questions.

One workflow.

One page.

What is known. What is unknown. What is safe enough. What needs control. What should not go to production yet.

That is often enough to separate a useful pilot from a hidden liability.

The goal is not bureaucracy.

The goal is to stop inventing the answer in front of a client, after something went wrong.

Final words

AI governance sounds abstract until a customer asks a simple question and nobody has the documentation behind the answer.

Where did our data go?

Who approved this?

What was the AI allowed to access?

Who reviewed the output?

What happens if it is wrong?

Those are not philosophical questions.

They are production questions.

If an AI pilot cannot answer them, it is not ready for production.

It is a liability with a launch date.