Standing Up the Function: First Ninety Days and Beyond

The instinct when standing up a function is to build a framework covering everything. It produces a long project and nothing usable, because the requirements differ per system in ways that are only discoverable by working on one.

Start with a single AI feature, chosen deliberately. The best candidate has three properties: it matters enough that failures have visible consequences, it is already in production so real usage data exists, and the team owning it is willing rather than conscripted.

That last property is worth optimising for even at the cost of the first two. A willing team gives you access, honest failure examples and a collaborator. An unwilling one gives you a political problem before you have any results to point at.

Build the whole practice for that one system: evaluation set, thresholds, gate, and the reporting. Then use what it produced as the template and the argument for the second.

The reason this sequencing works is that the artefacts are far more persuasive than the proposal. A demonstration that this feature degrades on a specific population, or that a provider update moved behaviour last month, changes minds in a way that a framework document does not. Find that first, then generalise.

A sequence that produces something defensible in a quarter, deliberately front-loading the parts that cannot be bought.

Weeks one to three: understand the system and gather reality. What does it do, what does it touch, what has already gone wrong. Read production logs and support tickets, because those contain the failure modes nobody wrote down. Establish what the team currently does for quality, since it is rarely nothing.

Weeks three to six: build the evaluation set. Real cases from production, hard cases deliberately oversampled, labelled by someone competent, with a held-back portion. This is the slowest step and the one that determines everything downstream, so resist compressing it.

Weeks six to eight: establish the baseline. Run the current production version several times to get both its performance and its variance, which is what the tolerance bands need. You now know what the system actually does, which is often the first time anyone does.

Weeks eight to ten: set thresholds with the team, before any change is pending, and get them agreed by whoever will be inconvenienced by them.

Weeks ten to thirteen: wire the gate into the release path, run it on real changes, and publish the results.

The test at ninety days is whether a change has actually been held, or whether the team can point to a regression the gate caught. Without that, you have a measurement practice rather than a control.

The placement question has the same structure as the AI governance one, and the same trade-offs.

Inside the engineering team that builds the feature. Best access, fastest feedback, most technical credibility. The weakness is independence: a function assessing its own team's work under the same delivery pressure will, over time, find fewer problems. Not through dishonesty but because the incentive gradient is real.

As a separate QA or quality engineering function. Independence, consistent standards across systems, and the ability to compare. The weakness is distance, which shows up as slower feedback and less technical depth on any particular system.

Inside risk, compliance or a second-line function. Strongest independence and the clearest reporting line for anything a supervisor will examine. The weakness is technical depth, and a tendency to test whether the process ran rather than whether the system works.

No placement is correct in general. What matters is that two properties hold together: the function can access the system deeply enough to test it properly, and it can report a bad result to someone who is not the person whose release it blocks.

Where both cannot be arranged, the honest response is to name which one is missing and what compensates for it, rather than to proceed as though the function is independent when it is not.

The dependency order, which is not the order teams usually attempt.

Everything rests on knowing what the system does and what has gone wrong, gathered from logs and tickets rather than from the design document.

That produces the evaluation set, which is the slow step and the one everything else depends on.

The baseline comes next, and it needs repeated runs because you are measuring variance as well as level.

Only then can thresholds be set meaningfully, because a threshold without a baseline is a guess.

And only then does the gate have anything to enforce.

Teams routinely start at the bottom, building a gate and a dashboard before there is an evaluation set worth gating on, and then discover the gate has nothing credible to say. The order matters more than the speed.

Resistance is normal and usually rational rather than obstructive, so it is worth diagnosing before responding.

The common objections, and what actually answers them.

It will slow us down. Often true initially, and the honest response is to make the fast path genuinely fast: a small tiered suite on every commit, the full one nightly. A gate adding twenty minutes to a release is tolerable; one adding two days is not, and will be circumvented.

The metrics do not capture what matters. Frequently correct, and it is an invitation rather than an obstacle. Ask what would capture it, and build that. A team that helped design the evaluation set defends it instead of arguing with it.

We already test this. Sometimes true. Find out what they do, keep it, and add only what is missing. Replacing a working practice with a new one loses goodwill and often loses coverage.

The model changed, not our code, so it is not our regression. True and irrelevant. The user experiences the degradation regardless of whose change caused it, and this objection is the clearest opening to explain the five change vectors.

The underlying move in all four is to arrive with evidence rather than with process. A demonstrated failure the team did not know about earns more cooperation than any amount of framework advocacy, which is the argument for starting with one system and finding something real.

A QA function should be able to answer whether it is working, and the obvious metrics are the wrong ones.

What not to report as success. Number of test cases, which measures effort. Pass rate, which the previous lesson established is ambiguous. Number of bugs found, which rewards volume over consequence and can be inflated trivially.

What is worth reporting.

Escaped defects: issues that reached users and were not caught by the gate. This is the direct measure of whether the practice works, and it requires an honest incident review that traces each production problem back to why evaluation missed it.

Detection latency: how long between a regression entering and being noticed. Falling latency is the clearest evidence the practice is maturing.

Coverage of consequence: what proportion of the system's high-consequence behaviours have a corresponding check. Better than raw case counts because it is tied to what matters.

Gate credibility: block rate, override rate, and whether overrides are trending up. A gate that never blocks and one that is always overridden are both failing, in different ways.

And the honest qualitative one: can the team answer what would happen if the model changed tomorrow. If nobody knows, the function has not delivered its core value yet regardless of what the dashboard shows.

Five failure modes account for most AI QA functions that are stood up and then quietly stop mattering.

It never blocks anything. The gate runs, results are published, releases proceed regardless. Within a quarter nobody reads the output. This is the most common death and it is a governance failure rather than a technical one.

The evaluation set decays. Nobody owns refreshing it, usage moves on, and the pass rate rises for the wrong reason. The function reports improving quality while users report the opposite, which destroys its credibility in one meeting.

It becomes a bottleneck. Full evaluation on every change, no tiering, and a queue forms. Teams route around it, and routing around becomes normal.

It measures only capability. Safety, security, groundedness and cost go unowned, so the function is blind to four of its five responsibilities and is eventually surprised by an incident in one of them.

And it is staffed as a part-time addition to someone's existing role. The work is real and continuous, and a person doing it alongside delivery work will deprioritise it exactly when delivery pressure is highest, which is when it is most needed.

The common thread: each is a slow failure that produces no obvious moment of collapse. Which is why the metrics in the previous step matter, since they are the instruments that make a slow failure visible while it is still correctable.

Once one system has a working practice, extending it is a different problem, and the temptation is to standardise too hard.

What should be shared across systems: the evaluation harness and tooling, the metric definitions so results are comparable, the red-team corpus and attack library, the reporting format, and the process for setting and changing thresholds.

What should stay per-system: the evaluation cases, which are inherently task-specific, the threshold values, which follow from consequence, and the segment definitions, since the populations that matter differ.

The distinction is between the machinery, which generalises, and the judgements, which do not. Teams that standardise the judgements produce thresholds that fit nothing well, and teams that standardise nothing rebuild the harness five times.

A reasonable operating shape at scale: a small central function owning the tooling, the standards and the cross-system comparison, with evaluation cases and thresholds owned by the teams closest to each system, and a review of those by the central function.

And prioritise by consequence rather than by coverage. Extending the practice to the highest-consequence system without one beats extending shallow coverage across everything, which is the same materiality principle that runs through the governance and regulated-industries cursus.

The honest summary: AI QA is conventional QA plus a probabilistic layer, the evaluation set is the asset, the gate is only real if it blocks, and the function dies quietly rather than loudly.