Your Use-Case Approval Is Still on Last Quarter's Slide. Production Already Drifted Off It.
The CAB pack still says the use case is internal only: summarise the knowledge base for staff, no customer channel, no writeback. Risk rated the residual as low. Legal signed the DPIA against that boundary. Six months later, the same model sits behind a public assistant that answers policy questions, then offers to open a CRM case if the visitor seems frustrated. Nobody updated the slide. Production moved three times while the approval card stayed on last quarter's deck.
That gap is not a rare failure. It is how most enterprise AI programmes grow. The intended use is approved once as a narrow statement. Delivery then stacks deltas that each look small, until the live system no longer matches the risk story governance still cites in audits.
Use-case approval is usually a one-shot gate. A product owner writes a short intended-use statement. Security and privacy review a form. A committee stamps a version. The artefact goes into SharePoint beside the architecture diagram. From that moment the organisation treats the approval as current, even when nobody reopens it.
Ops does not work that way. Release trains ship weekly. A platform team swaps the model when a cheaper provider lands. Support adds a Slack channel because the web widget felt slow. A sales engineer wires a sandbox CRM write so demos look real, then the same wiring reaches staging with production credentials. Each change has a ticket. None of them reopen the use-case card.
Governance teams are not asleep. They are measuring what the process told them to measure: whether a form was filled, whether a residual risk was accepted, whether training was logged. The process never asked whether production still matches the declared purpose. So the registry looks green while the system has already left the approved envelope.
Scope creep rarely arrives as a new business case. It arrives as 'just one more integration.'
None of these need malice. Product pressure rewards shipping. Each delta has a local owner who can argue it is still 'the same chatbot.' The registry has no trigger that forces that claim to be tested.
The first casualty is the risk register. Residual risk was accepted for a staff-only summariser. The live system is a customer channel with write access to CRM. The residual is not the one the CRO signed. Attestations and insurance questionnaires that cite the old use case inherit the same fiction.
Privacy artefacts age badly. A DPIA that never contemplated customer identifiers in the prompt path, or retention of chat logs for model evaluation, will not help when a regulator asks what lawful basis covers the new flow. Vendor DPAs that limited processing to 'internal knowledge assistance' sit awkwardly beside production telemetry that includes customer content.
When something goes wrong, blame fragments. Security points at the original approval. Product points at accepted change tickets. Legal points at an outdated DPIA. Nobody owns the gap between the slide and the pipeline. Incident response wastes hours reconstructing which purpose was actually authorised.
Treat the use case as a living control object, not a ceremony.
Give every production AI service a use-case ID and version. Store declared purpose, channels, data classes, tools, model/provider, jurisdictions, and kill criteria. Make the deploy pipeline refuse a release unless the build declares that ID and version. If the running config drifts from the registry entry, the release fails closed.
Define hard triggers, not soft reminders. New customer-facing channel. Any write tool. New personal data class. Model or region change. New jurisdiction. Agent loops or tool chaining. Crossing a trigger opens a change record that must update the use-case version before promote. 'Looks like the same bot' is not a bypass.
Do not rely on documents alone. At runtime, assert the active channel, tool allowlist, and data sources against the declared purpose. If a service starts accepting CRM write calls while the registry still says read-only retrieval, block or quarantine and page the owner. Purpose becomes an enforceable policy, not a PDF.
Quarterly (or after every major release), require the product owner and a control owner to attest that production matches the current use-case version. Attach evidence: traffic by channel, tool call histograms, data-source inventory, model ID in use. An attestation without evidence is theatre.
Write the stop conditions into the use-case card itself. If a new channel ships without re-approval, suspend that channel. If a write tool appears outside the allowlist, revoke the credential. If personal data classes exceed the declared set, freeze ingestion. Practise those kills the same way you practise other incident controls, so they are not theoretical.
Enterprises do not fail because they forgot to approve AI. They fail because approval was a gate at the start of a road that kept being rebuilt. The slide from last quarter is not a control. A versioned purpose, wired into deploy and runtime, with triggers that force re-review when production expands, is.
If your governance pack still points at a use case that production left months ago, the next audit will not be the first to notice. Your customers and your incident logs will get there first. Update the registry to match reality, or pull production back to what you actually approved. Either choice is governance. Leaving the slide frozen while the pipeline keeps moving is only theatre.
