How to run AI in production

The decision clock belongs to you and moves as fast as your meetings: pick the workflow, write the case, set the stop rule. The clearance clock does not belong to you, and it is longer: vendor security review, the data protection impact assessment, third-party risk, the data processing agreement, procurement onboarding, and employee consultation where your markets require it. In most European companies of size, that track runs six to twelve weeks, and it, not the build, sets your go-live date. Start it in week one with a scope sketch, not in week six with a signed contract. If both clocks start on day one, 90 days ends with a workflow live. Start the clearance clock late and 90 days ends with a slide.

The autonomy ladder

Nobody sane goes from nothing to AI acting on customers in one step. Move the dial in one direction only, on evidence, in four rungs. One: it answers into a log and nobody sends it. Two: it drafts and a human sends. Three: it acts on a narrow slice with every case reviewed. Four: it acts with sampling, and the sample shrinks only when the numbers earn it.

Shadow mode is not a delay, it is your cheapest week: you find the wrong rules with no customer in the room, and your team learns to read the traces before anything is at stake. Two gates before rung three: the impact assessment is signed before the first real customer, not after, and the employee consultation your market requires is concluded, not merely opened. Both are legal preconditions in much of Europe, and both are the difference between a launch and a week-ten veto.

The strategy guide defines the translation: extract what your people know, author it as rules with owners and tests, make it live. Production adds three disciplines the extraction step hides.

Check the data before you trust the rule. The AI inherits every gap and duplicate in your systems of record, so go field by field on the workflow you picked: is the field the rule depends on actually populated, is it current, and when two systems disagree about the same customer, which one wins, in writing? Many of the misses you will spend week eight debugging are not rule failures. They are a stale record wearing a rule's clothes.

Check you are allowed to use what you are mining. Historic tickets and case notes were collected to serve customers, not to train an AI or build a test set. In Europe that makes reuse a purpose question with a legal test behind it, and it is your DPO's to answer before extraction starts, not after. The same applies to the evaluation cases you build from real interactions.

Demand two authoring surfaces over one system. Your experts author in plain language they own. Your engineers hold the same artifacts as code: versioned, reviewable, deployable through the tooling they already trust. If those are two different systems, you have rebuilt the handoff you were trying to delete. Ask any vendor to show both surfaces editing the same rule, and watch whether the change lands in one place or two.

And budget for the rulebook itself. Authored rules accumulate, contradict, and go stale, and every rule whose owner left the company is a rule nobody will dare touch. Put a quarterly review on the calendar next to the weekly one: retire what no longer earns its place, merge the near-duplicates, and reassign orphaned owners the week people move, not the quarter after.

It will not go wrong the way you designed it to. It goes wrong at 22:40 on a Saturday, to a customer who screenshots it. What you control is the ceiling on the damage and the speed of the recovery, and both are decided before go-live or not at all.

• The alarm What triggers it, and who receives it out of hours, by name. An alert that lands in a channel nobody watches on Sunday is a Monday-morning press clipping.
• The kill switch Tested, not designed. Someone has actually pulled it, timed it, and knows what the customer sees while it is off.
• The blast radius Caps on actions per hour and value per action, so a bad rule is expensive in the hundreds and not the millions before a human sees it.
• The rollback and the fallback Rollback to the previous behaviour version, timed in a drill. And the degraded modes designed in advance: what the AI does when a system is down, a tool errors, a model is rate-limited or deprecated, or it is simply not confident, including what the human it hands to actually receives.
• The notification Who tells the customer, and who tells the regulator, decided before you need them. The clocks are real: 72 hours to the supervisory authority for a personal data breach, 15 days for serious AI incidents and 2 for the worst of them. Your vendor contract has to commit them to telling you in time to make your own clock.

Oversight that holds up

The law asks whether the person overseeing has the competence, the authority and the time to reach a different answer. A reviewer with forty seconds a case and no mandate to overrule is not oversight, and a regulator will say so. Staff the review queue like it matters, because legally, it does.

Your DPO's full list

Six questions, and every one has to have an answer in writing before real customers arrive. On what lawful basis are we processing this data, and is it the purpose we collected it for? Is the impact assessment done, and dated before go-live? Where does the data live, where is it processed, and whose law reaches it? What is our retention period for the decision records, because two rules pull against each other: where the AI Act reaches you, deployer logs are kept at least six months, while data protection law says no longer than necessary, and your sector rules, anti-money-laundering and accounting above all, usually decide the real number. Who are the processors and sub-processors, including whichever model provider sits underneath? And when a customer asks why the AI did that, what do we hand them, and who is the human they escalate to?

Two operating demands close the pillar. The trace is itself personal data, so control who can read it. And it must export into your own logging stack, in a schema you can query, because evidence you can only view inside a vendor's console is evidence you do not hold.

The agent as an identity

An AI that acts is an actor inside your perimeter: give it its own auditable identity, never a shared service account, scope its access per task, and be able to revoke it in minutes without a change ticket. Then assume manipulation arrives inside the work, a ticket body, an attached document, a supplier email the AI reads, precisely because the AI reads your systems. That class of attack is not solved by better prompts. The durable answer is limiting what a hijacked turn is authorised to do, and the proof is a red-team exercise on a schedule, with the blast radius as the reported metric.

Environments and releases. A staging environment that mirrors production, high-risk changes to a slice of traffic first, and releases that roll back in minutes rather than meetings. None of this is exotic. All of it is routinely missing from AI deployments that would never have been accepted from ordinary software.

Models fail like any other dependency. They get rate-limited on your biggest day, repriced mid-contract, and deprecated on a provider's schedule rather than yours. Decide the fallback route in advance, and treat a model swap as a controlled change: re-tune, re-validate against your test set, a week of work, not a rewrite, and never a surprise.

Nights and weekends. Same-day rule changes are a weekday property. If you run 24/7, decide before go-live who can restrict or stop the AI on a Sunday without waking an executive, who owns rules out of hours, and what the documented downgrade path is. Otherwise your night shift spends the worst hour of the quarter watching something they cannot change.

And be honest about what "without a platform team" has to mean. Secrets management, access control, log search, scaling, isolation between environments: someone's product, or your side project. If it is your side project, budget the platform team you claimed you did not need, because the gap always gets staffed eventually, voluntarily or at 3am.

The strategy guide sets the bar: acting end to end on systems of record, not answering beside them. Production adds the governance test: every cross-system call inside one trace, permissions scoped per tool rather than blanket, and consequential actions gated before they execute. One customer case that touches four systems should read as one story, not four log files stitched together after the fact.

The contract is an integration too

Five things belong in it before signature, none negotiable after. The regulatory roles allocated in writing, because if your people author and brand the behaviour you may become the provider of that AI system under the EU AI Act, with the heavier obligations that follow. Processor terms with the content data protection law requires. The full sub-processor list, including whichever model provider sits underneath, where it processes, what it retains, and your right to object when it changes. An incident-notification commitment fast enough for your own reporting clocks. And an exit that returns your rules, context, test cases and decision records in a form someone else can run. If you are a regulated financial entity, this arrangement also goes in your register with a criticality classification and a tested exit plan, and no vendor assurance moves that accountability off you.

Read your outsourcing contract before counting savings

If a large share of your volume sits with a BPO on committed minimums, deflection may save you nothing until renewal, and the team leads who know your rules are employed by them, not by you. Either bring the BPO into the rule authoring with commercial terms that reward deflection, or start with a workflow where the savings are actually yours.

The whole promise of an operation your experts run is that a correction is an edit and not a project. That promise is only responsible with a test discipline underneath it, and the test discipline is simpler than it sounds.

Build the test set first. A few hundred real past cases with the answers you would have wanted, and every rule change runs against it before going live, against a pass bar agreed in advance. The same set is what tells you a new model is safe to switch to, what catches drift before a month of trend lines has to, and what turns "we think it improved" into evidence. Without it, same-day edits are same-day risk.

Tier the changes. The rule's risk decides who approves it: low-risk edits ship same day on a green test run, the refund threshold gets a second signature, and the highest tier goes to a slice of traffic first. Fast is not the same as unreviewed, and this is the sentence that turns your internal audit team from a blocker into a sponsor.

Correct at the right layer. When the AI gets something wrong, three things could have failed: the rule, the data it read, or the integration it acted through. Only the first is fixed by authoring, and a loop that only edits rules will grind rules while the real problem is a stale record.

Expect the human work to get harder on day one. Take the easy half of the cases away and what remains is the hard half. Handling time per case rises, and so does the emotional load, because nobody gets an easy one between two difficult ones any more. Re-baseline handling time and occupancy for the new mix, re-cut the forecast, tell team leads their targets are changing and why, and check any bonus scheme tied to volume or handling time before it becomes a grievance. If your first sign of success is falling satisfaction and rising attrition on the human queue, you measured the easy half.

Anchor the loop in the team you already have. Your quality function already samples, scores and coaches, so point it at the AI with a scorecard rewritten for AI-handled work. It stops coaching one agent at a time and starts coaching the rule that governs thousands of cases, which is the highest-leverage version of that job that has ever existed. Run the weekly thirty-minute review with named rule-owners, and put the AI's KPI in their own objectives, because a cadence in nobody's targets is the first meeting cancelled in a busy month.

Containment is the most gamed number in AI operations, because it tells you what the AI kept and nothing about what it handed over. So instrument the handoff hardest: repeat contact rate, satisfaction on handed-off cases as a separate line from overall satisfaction, and whether your person inherits the full context or starts from zero. Containment rising while escalation satisfaction falls is not progress. It is a queue you made worse.

Then build the three altitudes the strategy guide promises the board, as actual plumbing. Daily: every action reconstructable, access-controlled because the trace holds customer data, for operations and compliance. Weekly: KPIs, drift and corrections shipped, for the function head and the rule-owners. Monthly: the three numbers as trends, for the CFO. Same data, three zoom levels, and the board number must drill down to individual decisions or it is not a number, it is a hope.

The monthly report itself follows three rules: baseline before launch, so value is distance from a measured starting point; count only what moved, hours actually redeployed rather than capacity theoretically freed; and carry the all-in run cost, including your own people's days, so the ROI survives due diligence. Then the two derived lines that make it a decision tool: cost per outcome, this month against last, and payback actual against projection.

Notice what makes it credible. The automation share is not 100 percent. The value is split into what a budget line will actually show and what it will not. The internal days appear even though no vendor would have invoiced them. There is a payback month, and there is a number that ends the project.

• The CFO The payback month, the all-in run cost including your own people's days, and what it costs to stop.
• The CIO This takes recurring rule changes off your queue. Here is the integration capacity I need, in weeks, and what I need access to before week one.
• The CISO and DPO Requirements collected before vendor selection, so this is a design conversation and not a veto, with the impact assessment dated before go-live.
• Employee representatives Consultation opened at the planning stage, what changes for the team, what the data will not be used for, and what is written down.
• The CEO How this avoids the failure they read about: the autonomy ladder, the always-human list, and measuring escalation quality rather than only deflection.

And size the first step to fit a budget you already control. A fixed-scope assessment and one workflow is an operating decision. A platform programme is a capital committee and a nine-month wait.

Production is an operating discipline, not a launch event. The companies that hold the gains are the ones that staffed the loop.

• Regulation (EU) 2026/1744, the Digital Omnibus on AI Official Journal 24 July 2026, in force 27 July 2026, amending Regulation (EU) 2024/1689 (the EU AI Act). High-risk obligations for standalone Annex III systems deferred to 2 December 2027; Article 50 transparency obligations apply from 2 August 2026 and were not deferred.
• Regulation (EU) 2024/1689, the EU AI Act Articles 4 (AI literacy), 25 (provider-role shift), 26 (deployer duties, including log retention of at least six months and worker information), 50 (transparency) and 73 (serious-incident reporting, 15 days, or 2 for the most serious).
• Regulation (EU) 2016/679, the GDPR Articles 5 (purpose limitation and storage limitation), 22 (solely automated decisions), 28 (processors), 33 (72-hour breach notification) and 35 (impact assessments before processing).

Verified July 2026. Regulatory positions move; check the current text before relying on any date here. The worked example is illustrative, not a client case.