Production-grade AI automation versus a proof of concept

A proof of concept and a production automation differ in four specific ways, and none of them is model quality. A proof of concept handles the path where everything works. A production system handles the path where a third-party API times out, where a document arrives in a format nobody anticipated, where a language model returns something confident and wrong, and where the person who understood the workflow has left. If a demo impressed you, what you saw was the happy path. The work is everything else.

Here is what actually separates them.

1. The exception path exists, and a human is on it

A demo shows a document going in and structured data coming out. A production system asks what happens to the one in twenty documents that fails a validation check. The answer cannot be “it guesses”, and it cannot be “it fails silently” — both produce errors that surface weeks later at reconciliation, when they are expensive to unpick.

What this looks like built: every automated decision has a confidence threshold, anything below it goes to a queue a person actually works, and the queue entry names the check that failed rather than saying “review required”. A person resolving an exception should be able to see in five seconds why it is in front of them.

2. Credentials are scoped to the job

A proof of concept runs on whatever token was to hand, which is usually an admin token, because that is the fastest way to get to a demo. That token then quietly stays in the workflow.

A production automation holds the narrowest credential that does the job, and someone has written down which systems it can reach. This is not paranoia: a workflow that reads a mailbox to extract invoices does not need permission to send mail, and the day something goes wrong, the difference between those two scopes is the difference between an incident and a non-event.

3. You can reconstruct what it did

Ask of any automation you are about to depend on: could you reconstruct what this did last Tuesday? Not “is there logging” — logging is usually there and usually useless. Could you answer which records it touched, what it decided, and on what input?

Systems without this are not debuggable, they are guessable. When a customer says they got the wrong message, or finance says a total is off, the answer has to come from a log rather than a theory.

4. There is a written evaluation set

This is the one most often skipped, and it is the one that makes changes safe. Before handover, a production system should have a written set of question-and-answer pairs, or input-and-expected-output pairs, drawn from the client’s own material and signed off by their team. It gets run before handover and re-run after any change.

Without it, “we improved the prompt” is an assertion. With it, it is a measurement. A retrieval assistant that answers thirty real questions correctly today and twenty-eight after a change has told you something you could not otherwise have known.

What this means for scoping

Most of the cost of a real automation sits in these four things, which is why a two-week proof of concept and a six-week production build are not the same work at different speeds — they are different work. If a quote looks surprisingly cheap, the question worth asking is which of the four is missing.

It is also why we scope in writing before building. The exception path, the credential scope, the logging requirement, and the evaluation set are decisions about your operation, not implementation details we can settle on your behalf.