Production Deployment

What Production deployment means

Production deployment is the point at which a workflow stops being a test and becomes part of daily work. Before it, a prototype has run on a sample of the organisation’s own material and someone has written down what it did and where it broke. After it, the workflow is connected to the systems it reads from and writes to, real people use it, and the organisation depends on its output.

The site’s audit methodology places it at step five, the last of the five steps. It describes the step this way: what the prototype proved is built for production, with oversight, logging, escalation and the point at which a person takes over designed into the build rather than added once something has gone wrong. The home page calls the same step Implement and scale, and the methodology page calls it Build and scale. All three names describe one step.

Two things in that description set this term apart from the way people often use the phrase. The first is that it follows a prototype. A workflow does not go straight from an idea to production. The second is that it is not a single leap. Scaling happens one proven workflow at a time.

What a Prototype has to prove first

The audit methodology is clear about the order. The prototype comes first, it is run on the organisation’s own work including the awkward cases, and the people who do that work judge the result. Their verdict decides whether step five happens. What comes out of the prototype is a working prototype and a documented result: what it did, where it broke, what a person still has to check, and whether it is worth building properly.

That last question matters. A prototype is allowed to fail, and a failed prototype is a cheap result. It tells the organisation, before anything has been rolled out or rebuilt around the idea, that the idea does not hold. Production deployment is the step that only happens when the answer is yes.

The production article gives the reason for the order in terms of cost. Finding a gap during a scoping exercise costs a conversation. Finding the same gap six weeks into a build costs a redesign. The earlier steps exist to move the discovery to where it is cheap.

What gets built in, not added later

The audit methodology names four things that are designed into the build at this step. Each one answers a question that a demo never has to answer.

Oversight. Where does a person look at what the workflow does, and how often? The workflow article asks for oversight to be a deliberate design decision, and says that where a system can send messages, change records or move money, someone should be able to say where a human in the loop has to approve.

Logging. What is kept after each run? The same article says a real workflow can reconstruct any single run after the fact: the input, what the model returned, what was approved and by whom, and what changed downstream. That is the audit trail, and it is what lets a named person be accountable for a run.

Escalation. What happens when the input is malformed, the confidence is low or a case falls outside what the workflow was built for? The workflow article says the right answer names an owner, a queue or a notification. This is the territory of exception handling.

The point at which a person takes over. Some steps are held for a person to decide. Others run on their own. The decision about which is which comes from the delegation ladder, and it belongs in the design, not in a hurried change after something has gone wrong.

The reason to design these in is the order of events. A workflow without them can look fine in a demo, where the input is tidy and nothing is at stake. The first real exception is the moment the missing pieces matter, and by then the workflow is live.

One proven Workflow at a time

The audit methodology says scaling happens one proven workflow at a time, each returning to step one for the next process rather than rolling a single result across an operation that was never mapped for it. It also says every phase is meant to justify the one after it.

This is the least glamorous part of the term and one of the most useful. A workflow that works on supplier invoices has shown it works on supplier invoices. It has not shown it will work on customer complaints, which have different input, different risk and a different person who has to check the result. Going back to step one for the next process means the next process gets mapped, scoped and tested on its own evidence.

It also keeps the running cost honest. The running cost article says the cheapest workflow to run is the narrow one, with a single process, a clear input, a clear output and a named owner. It warns that starting wide is the most expensive shape to run, and says to start with the narrowest process worth automating and widen it once figures from real use are in. A well-scoped workflow is the unit that production deployment is built for.

The Common stall between Demo and live

A project can pass a prototype and still go wrong at this step. The task and decision article names the usual way. A step that was scoped as Recommend, where the AI ranks or suggests and a person stays accountable, gets treated as Execute once the demo looks good. Nobody decides to remove the person. The tool proves reliable on the easy cases, and the review quietly stops.

The article says that catching this at the scoping stage costs an afternoon, while catching it after launch costs a rebuild and sometimes an apology to whoever the wrong call affected. The point for production deployment is that the level each step was given at scoping has to survive into the live build. If a step was sorted as Recommend, the live workflow has a named reviewer built in, and the design says so.

A Workflow is not finished when it goes live

The line in this page’s summary box comes from the running cost article: an AI workflow is not finished when it goes live. That article lists the ongoing work as monitoring, model updates, prompt changes and user training. It gives three reasons the work does not stop. Providers can change a model’s behaviour with an update. Source data can degrade. And users find new edge cases after launch.

In plain terms, someone has to look at the output every week, notice when it drifts, and fix the connection when another system changes its format. This is the ongoing side of the cost, and it is why the article says to budget for the run and not only the build. A build is a project with an end date. A running workflow has none, so the budget needs a recurring line.

It also explains why the term sits beside drift. A workflow that is live and unwatched does not stay as it was installed. It moves, because the world around it moves.

Why an owner matters more after launch

The ownership article puts the central claim of this page most directly: an AI tool that nobody owns does not fail on the day it goes live. It fails months later and quietly. Rolling out AI is a project with an end date. Owning it is a job with none, and most businesses only plan for the first.

The article describes what happens when a rollout closes. The project team disbands, so the person who understood how the tool was configured returns to their day job. The enthusiasm that carried the launch fades. And responsibility spreads out, because an AI tool touches several functions at once. Each function holds a slice, and nobody holds the whole.

What follows is slow and easy to miss. Output quality slips. Permissions granted for a pilot stay in place. Written rules go stale. An incident has no route to a person, so the first conversation about it starts from nothing, under pressure. The article’s conclusion is that an owner matters more after launch than before it, because that is when attention has gone elsewhere.

The audit methodology builds this into step five. The organisation names an internal owner for each workflow that goes live. An AI owner is one named person who can answer what the tool is for, who uses it, what it can reach and when it was last checked. The running cost article treats the same owner as part of the price of running a workflow safely.

Training the people who run it

The other requirement in step five is training. The audit methodology says the organisation sends the people who will run the workflow through training, so the operation belongs to the organisation rather than to whoever built it. What comes out of the step is workflows in production with their oversight defined, documentation the organisation owns, and staff trained to run and change what was built.

That wording is deliberate. A workflow that only its builder can change is a dependency, not an asset. The staff who run it need to understand it well enough to change it, and the internal champion is the person most likely to carry that understanding day to day.

What the Evidence says about Projects that ship

The production article gathers findings on what separates projects that reach production from those that stall. They are third-party findings that the article cites, not measurements the site made itself, and they should be read as signals and not as guarantees.

Organisations that did a formal readiness assessment before launching an AI initiative achieved a 45% higher success rate on their first AI production deployment. Projects that move from pilot to production repeatably share three traits: a named executive sponsor, a defined success metric tied to a real business outcome, and at least one internal champion. And projects that pair internal specialists with outside expertise succeeded at 67%, against 22% for projects built by an internal team alone.

None of the three traits is technical. They are organisational, which is why the article says a readiness assessment is the tool built to find out whether they are in place before a project starts. For this term, the practical reading is that production deployment is rarely decided by the model. It is decided by whether a sponsor, a measure and an owner exist when the workflow goes live.

A worked example

An illustration, not a case study. A small firm has run a prototype that reads incoming supplier invoices, pulls out the supplier, the amount and the due date, and checks them against the purchase order. The people in finance judged the result on real invoices, including the awkward ones, and said it was worth building properly.

Going live is not simply switching it on. The firm decides what is built in. Oversight: a matched invoice goes into a queue and a named person in finance approves it. Logging: every run keeps what was read, what was matched and who approved each exception. Escalation: a mismatched amount goes to that person every time, and an invoice in a layout the workflow does not recognise is flagged and not guessed at. The point of takeover: paying an invoice is never left to the workflow, because money that has moved cannot be called back at low cost.

The firm names an owner, the head of finance, who looks at the flagged items each week and repairs the connection when a supplier changes its invoice layout. The people who will run it day to day are trained to do so. Only then does the firm consider a second process, and when it does, it starts again at step one for that process, because the first result says nothing yet about customer queries.

None of this makes the workflow more clever. It makes it something the firm can answer for.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating production as automatic once a prototype exists, when it is a separate step that only goes ahead if the prototype’s verdict says so. The second is assuming a working demo is a production system, when a demo does not need oversight, logging or an escalation route and a live workflow does. The third is treating launch as the finish, when the ownership and running cost articles both say the ongoing work is where the risk and cost sit. The fourth is rolling one result across the whole operation, when the methodology scales one proven workflow at a time and returns to step one for each new process.

How we use it

We use the term for step five of the audit: the step that follows a prototype and only happens when the people who do the work have judged the result. What a prototype proved on the organisation’s own work is what gets built for production. Each live workflow gets a named owner, as the AI ownership page sets out. An audit is a diagnostic and not an implementation, so the page describes this step as what the organisation builds, owns and learns to run.

If you would like to talk through which of your processes are ready to go live and what each would need built in, a discovery call is a quick way to start.

Sources

• What predicts whether an AI project reaches production: the 45% figure for a formal readiness assessment, the three traits, the 67% against 22% comparison, and a gap found at scoping costing a conversation against a redesign six weeks into a build.
• How we audit: step five, the build for production with oversight, logging, escalation and takeover designed in, one proven workflow at a time, the named internal owner and trained staff.
• What happens when nobody owns the AI you’ve rolled out: an unowned tool failing months later and quietly, a rollout as a project and ownership as a job with no end, and an owner mattering more after launch.
• How much does an AI workflow actually cost to run?: a workflow not being finished at go-live, monitoring, model updates, prompt changes and user training, and the narrow workflow being cheapest to run.
• The difference between automating a task and automating a decision: a Recommend step treated as Execute once the demo looks good, and the cost of catching it at scoping against after launch.
• How to tell a real AI workflow from a chatbot in disguise: the failure path, the record of a run and human oversight as a design decision.
• Prototype, AI ownership, Internal champion, Drift, Exception handling, Human in the loop, Audit trail, Delegation ladder, Well-scoped workflow and Total cost of ownership: the neighbouring terms this page links to.