Published on
- 4 min read
9 Governance Decisions to Make Before an AI System Goes Live
The pressure is real. The demo looked glorious, but the user will press go the moment the clock ticks. The staff who keep the lights on will lean on this system, not the slide deck. I want a path that doesn’t blow up when reality shows up. I want to sleep at night.
-
Intended use Owner: Product lead in partnership with Tech Lead Evidence to approve or pause: clear description of who will use the system, in what contexts, and what outcomes count as success or failure. Stakeholders sign off. No high-risk corner cases sneak in. First step: write a one-page intended-use brief with real users and real tasks. Get sign-off from product, security, and operations.
-
Risk classification Owner: Risk manager with input from engineering leads Evidence to approve or pause: a formal risk tier (low, moderate, high) anchored to data sensitivity, impact, and exposure. A defensible rationale for the tier and a plan to monitor changes. First step: map data types to sensitivity levels and attach a risk score. Review with compliance and legal if needed.
-
Data authority Owner: Data governance owner Evidence to approve or pause: a data-usage policy that spells out what data can be used for training and inference, retention limits, and data-access controls. A plan to prevent data leakage and misuse. First step: inventory data sources, label controls, and access permissions. Confirm data usage aligns with policy and regulator expectations.
-
Evaluation threshold Owner: QA lead with product owner Evidence to approve or pause: objective metrics and thresholds that define acceptable vs. unacceptable performance. A plan to test edge cases and a decision rule for launch pause. First step: choose a minimal viable set of metrics, define pass/fail criteria, and document how results will be tracked.
-
Human override Owner: Safety escalation owner Evidence to approve or pause: a clear, auditable path for humans to intervene when the system misbehaves. Records of overrides and reasons. A rollback plan. First step: draft an override protocol that specifies who can intervene, how, and within what time frame.
-
Monitoring Owner: SRE lead with product and security input Evidence to approve or pause: monitoring coverage for accuracy, drift, and failures; alert thresholds; and a plan for ongoing audits. Defined stop conditions if drift grows. First step: implement dashboards that track data drift, model outputs, and anomaly rates. Set alert levels and run a simulated incident.
-
Incident response Owner: Security incident response lead Evidence to approve or pause: a written playbook for incidents, including who to notify, how to contain damage, and how to recover. A post-incident review cadence. First step: draft a lightweight incident runbook with roles, timelines, and a rehearse window.
-
Change approval Owner: Change control board, with sign-off from product and compliance Evidence to approve or pause: a formal change process for every update, including rationale, risk assessment, and rollback options. A record of approvals. First step: establish a minimal change ticket template and require a go/no-go decision before deployment.
-
Retirement Owner: Product owner with platform lead Evidence to approve or pause: a plan for decommissioning the system when it ends. Data migration, resource cleanup, and customer notification. A sunset timeline. First step: draft a retirement checklist and set a hard decommissioning date with a gap for reversibility if needed.
The heart of this list is not a dry checklist. It’s a map of responsibility, risk, and real consequences. The governance decisions must be owned by people who can answer for their area and who can pause the launch if something doesn’t sit right. This isn’t about perfect safety; it’s about making tradeoffs explicit and auditable.
The story behind these decisions is simple: a public failure is rarely just a model problem. It is a product and management decision as well. We need a release plan that makes room for human judgment, clear lines of accountability, and a way to course-correct after the demo ends.
I know what it feels like to push a system toward live, to want the world to see the shiny demo rather than the messy path to reliability. I will be honest about the fear and the hope. I will demand evidence, not vibes.
One practical next step: pick one decision you’re ready to own today and draft the first-page evidence packet. Get a quick read from a peer outside your lane. If they can poke a hole and you can defend it, you’re on the right track.
After the Demo
The demo is over, and the real work begins. The people who will use the system are still watching, and the second effects show up. This is when the costs, the tradeoffs, and the small annoyances reveal themselves. We still have a choice worth keeping: open one reversible guardrail now, so we can learn and adjust after launch day.