Almost everything written about adopting artificial intelligence assumes an organization that can decide quickly, tolerate a bad output, and change a process without asking anyone. Very few organizations are like that, and none of the heavily regulated ones are.
In a regulated organization the constraints are real rather than cultural. A wrong answer can be a reportable event. The approval path was designed for software that produces the same output twice. Someone has to be accountable by name for a decision, and "the model suggested it" is not a defence. The people whose job is to say no are doing their job correctly when they say it.
So the usual advice fails, and it fails in a specific way: it tells you to move fast and iterate, in an environment where the first visible failure spends credibility you cannot re-earn for a year. What follows is the sequence I would actually run, and the reasoning behind each step. It is opinionated and you may disagree with parts of it.
The thesis
Adoption fails on evaluation, not on capability. Almost every stalled programme I have seen or heard described stalled because nobody could say what a correct answer looked like, which meant nobody could tell whether the thing was working, which meant nobody would sign off on it going near a real decision.
The model is rarely the constraint. The constraint is that "good" was never written down, and in a regulated setting an unwritten standard is indistinguishable from no standard.
Which yields the uncomfortable corollary: the highest-value early work in an AI programme is not building anything. It is producing a written, agreed, testable definition of correctness for one narrow task. That work is unglamorous, it demos badly, and skipping it is why programmes die in month seven with a working prototype nobody will approve.
Step one: pick the task where being wrong is cheap and being right is visible
Not the most valuable task. Not the one the executive sponsor mentioned. The one where a wrong output costs almost nothing and a right output is obvious to a person who is not paying attention.
Two axes, and you want the corner where both are favourable:
- Cost of being wrong. Drafting an internal summary somebody will read anyway is cheap. Anything that touches a customer record, a payment, a filing, or a safety decision is not.
- Frequency. Something that happens fifty times a day generates enough evidence to evaluate honestly within a fortnight. Something quarterly will not tell you anything for a year.
The instinct is to start where the money is. Resist it. The purpose of the first task is not value, it is earning the right to do the second one. You are buying evidence and institutional confidence, and paying for them with the cheapest thing you own.
A test for whether you have chosen well: if it goes badly, can you say so out loud in a meeting without anybody's job being at risk? If not, pick something else.
Step two: write down what correct means, before building
Three questions, in writing, agreed by the person who owns the process rather than the person building the system:
- What must this produce? Usually easy, usually the only one that gets answered.
- How will we know it is right? The one that carries everything, and the one nearly everybody skips.
- What must it never do? The one that prevents the expensive category of failure.
If the second question cannot be answered in plain language, the task is not ready. That is not a delay, it is the single most useful finding available, and it is usually cheaper to discover in a meeting than after two months of building.
The third question deserves more respect than it gets. "Never invent a number" and "never guess at a date" are one-line rules that eliminate whole classes of failure, and they are almost never written down, because they feel too obvious to state. They are not obvious to a system that will otherwise fill the gap.
Why this is different in a regulated organization
In an unregulated setting you can defer this and let the market tell you. In a regulated one, the written definition of correct is also the artifact that lets a control function evaluate the system at all. Without it, a reviewer has no basis to approve and will correctly decline. The specification is not bureaucracy here. It is the thing that unblocks you.
Step three: build the smallest thing that can be judged
Not a pilot, which tends to mean a demo with a hopeful roadmap attached. Something narrow enough to finish, real enough to run against actual inputs, and instrumented so you can count how often it is right.
Two design rules matter more than any modelling decision:
Never let the component that produces an answer also decide whether the answer is good enough. A system that grades its own homework will pass. Self-reported confidence is a feeling, not a measurement, and treating it as a threshold is how bad outputs reach real records.
Separate observation from interpretation. Ask the model for what it can directly observe. Do the reasoning that has one correct answer in ordinary code you can read, test, and argue with in a review. This sounds like an architectural nicety and it is actually the difference between a system whose failures you can explain and one whose failures you cannot.
Step four: measure the failures you would not notice
Accuracy on a benchmark is close to useless here. The number you need is the rate of the failure that looks fine.
This is the central practical insight and it is worth stating bluntly: these systems do not fail loudly, they fail plausibly. A crash is cheap because it is visible and somebody fixes it that afternoon. A confident, well-formatted, subtly wrong answer is expensive because it flows downstream and is discovered a month later by an auditor.
So measure, specifically:
- The confidently-wrong rate. How often does it produce something incorrect while reporting no uncertainty? This is the only number that predicts whether the thing is safe to widen.
- The refusal rate, and whether it is refusing the right things. A system tuned to be careful often becomes useless rather than safe, and the two are easy to confuse from a summary statistic.
- What a human reviewer actually changed. The edits are the specification you failed to write.
Set the threshold for widening before you see the results. Deciding what "good enough" means after you know the score is how programmes talk themselves into shipping.
Step five: design the human step so it is real
"A human reviews the output" is the most common control in these systems and the most commonly fictional. A reviewer facing forty plausible items with no indication of which are doubtful approves all forty within a week. The control exists on the diagram and not in the world.
To make it real, the system has to do the unglamorous work of being uncertain out loud: surface what it was unsure about and why, show its source, make the assumptions it made visible rather than silent, and route genuinely ambiguous cases to a queue rather than filing them with a guess.
A concrete version of that principle: if a system has to assume something in order to proceed, the assumption belongs in a visible field, not buried in the logic. A reviewer can scan a column that says an assumption was made. Nobody can scan for an assumption that left no trace.
Step six: widen along one axis at a time
Once the first task is measurably working, there are three directions to expand and taking two at once makes any regression impossible to attribute:
- Volume. Same task, more of it. Safest, and it usually surfaces the input variety your evaluation set was missing.
- Autonomy. Same task, less review. Only defensible once you have a real measurement of the confidently-wrong rate.
- Scope. A new task. Start again at step two. It is a new definition of correct, not an extension of the old one.
The tempting move after an early success is all three at once, because that is when confidence peaks and scrutiny relaxes. It is also when the first serious failure happens, and after that the programme spends a year being careful.
What I would refuse to do
Stated plainly, because a sequence is defined as much by its exclusions:
- Start with the highest-value process. Highest value means highest cost of being wrong, and you have no evidence yet.
- Begin with a platform decision. Choosing tooling before one task works is committing before learning anything, and the decision is usually cheap to revisit later and expensive to make early.
- Adopt a maturity model. They describe organizations that already succeeded, in the order it looked like afterwards. They are a retrospective, not a plan.
- Run a proof of concept with no definition of success. It will succeed, because an undefined bar is always cleared, and it will teach you nothing.
- Let enthusiasm set the sequence. The loudest internal advocate is a genuine asset and a poor prioritization function.
Where this generalizes, and where it does not
The sequence holds anywhere the cost of a wrong answer is high and the approval path is long: healthcare operations, government administration, legal services, energy, logistics, education administration, manufacturing quality. The vocabulary changes and the structure does not.
It generalizes less well where being wrong is genuinely cheap and iteration is free. If you can ship to a small group, be wrong publicly, and fix it the same day, much of the above is overhead and you should ignore it.
And an honest limit: none of this makes a system reliable at a task it is simply not suited to. A clear specification for the wrong idea produces a well-documented failure. The method makes correctness legible. It does not make a bad plan good.
The short version
Pick something where being wrong is cheap and being right is visible. Write down what correct means before you build, and treat the inability to do so as your most useful early finding. Build the smallest thing that can be judged. Measure the failure that looks fine, not the one that crashes. Make the human step genuinely possible. Then widen along one axis at a time.
The whole sequence exists to serve one goal, which is worth keeping in view when the pressure is to move faster: build the kind of failure you can see. Everything expensive in this field comes from failures that looked like successes for a while.