AI Engineering and Product: SOPs
Six procedures covering release gating, eval-set hygiene, guardrail changes, rollback rehearsal, the autonomy boundary review and the AI-specific incident path.
Markdown. No sign-up, no email.
Shipping learned behaviour needs different procedures from shipping code, because the failure mode is different. Code breaks loudly. A model degrades quietly, and the first person to notice is usually a customer three weeks later.
These six exist to make that degradation visible before it ships.
SOP 1: Release gating#
Run: every release, without exception.
- Run the current held-out set against the candidate.
- Attach the diff by category, not a single score.
- Block if any category falls below its floor, even when the blended number improved. A blended improvement that hides a collapsed category is the most common way a bad release passes.
- Record the model version, the prompt version, the guardrail version and the eval-set version together. Any one of them alone cannot reproduce a result.
- A named person accepts the release. Not the agent that ran the eval.
SOP 2: Eval-set hygiene#
Run: quarterly, and whenever training data changes.
The held-out set is the most valuable thing this function owns and the easiest to ruin.
- Version it. An eval result is meaningless without knowing which set produced it.
- Anything that leaks into training leaves the set. A contaminated eval reports confidence rather than quality, and a team acts on that confidence.
- Refresh the distribution as real usage shifts. A set assembled at launch measures a product that no longer exists.
- Keep an untouched holdout, sampled from real traffic, that nobody optimises against.
SOP 3: Guardrail change protocol#
Run: per change to what the system refuses, escalates or will not say.
Guardrails are policy expressed as code, so they change like policy: proposed, reviewed, tested against the red-team suite, released. Never edited live. A guardrail edited in production has no review trail, and the first evidence that it was wrong arrives as an incident.
Every guardrail change reruns the adversarial category of the eval before it ships.
SOP 4: Rollback rehearsal#
Run: once per release cycle, on the assumption the next change will need it.
Roll a model change back in a controlled window and time it. The number this produces is what decides how boldly the team can move: a team that knows it can revert in ten minutes ships differently from one that has never tried.
An unrehearsed rollback path is an assumption, and assumptions fail at exactly the moment they are needed.
SOP 5: Autonomy boundary review#
Run: quarterly, per feature.
For each feature, restate in writing what it may do without a person and what it must hand over. Then check the boundary has not moved by accident, which is the usual way it moves.
Widening what a system does unsupervised is a decision, made by a person, recorded. It is never a consequence of a model upgrade. This is the single line most likely to drift, because each individual widening looks small.
SOP 6: AI incident path#
Run: on any of the following.
| Incident type | Route |
|---|---|
| Confident and wrong output reaching a customer | This function plus Support, same hour |
| Refusal of a legitimate request | This function. Track the rate; a spike means a guardrail is over-broad |
| Prompt injection succeeding | Security first, then here. Treat as a security incident, not a quality bug |
| Silent quality drift detected | Roll back first, diagnose second |
| Cost per outcome inverting | Finance and here. A feature can be correct and still not viable |
Post-incident, the eval set gains a case reproducing the failure. An incident that does not become a test case will happen again, and the second occurrence is always more expensive because the first one was survivable.
The regulatory step that now applies#
Since 2 August 2026, EU AI Act Article 50 requires that a person interacting directly with an AI system is told so, and that generated content is marked. Any feature shipping to EU users carries that disclosure as a release-gate item rather than as a later addition. Systems already on the market before May 2026 have until 2 December 2026 to meet the machine-readable marking requirement. Checked 9 August 2026.