LINKEDIN ARTICLE — DRAFT

G9 - Go-Live Isn't the Finish Line. It's Where Your Monitoring Gets Tested.

Thresholds set before launch come from staging data and vendor defaults. Real traffic will disagree with staging somewhere — the only questions are where, and whether you find it deliberately or during an incident.

Where this gets hard

• False-positive rates are unknown at go-live, so alerts either flood and get ignored, or trickle and get trusted too much.
• Baselines computed on pre-production data can misdescribe production reality from day one.
• ‘Green for ninety days’ gets read as assurance, when nobody has proven the dashboard would go red.
• Post-launch attention fades exactly as the interesting behaviour starts: hypercare stabilises the software, then everyone leaves.
• With no defined end state, monitoring ‘settles in’ forever without anyone ever certifying that it works.

Where to start

• Structure the first ninety days deliberately: prove the pipeline, tune the thresholds, then challenge the system.
• Reconcile capture completeness daily in the first fortnight, and validate the baseline against real traffic — re-establishing it openly if staging lied.
• Triage every alert and classify it true or false, with threshold changes made under audited change control.
• Challenge on purpose: run the first robustness and bias campaigns, test your overseers, and rehearse an incident with the clock running.
• End with a decision: an evidence pack and a formal certification to steady state — or an extension with reasons. Never a fade-out.

The companion consulting document on our website includes a phased 90-day assurance plan and the certification evidence-pack checklist.

Part of RMAT's 12-part series on AI governance — Governing AI with Evidence. The companion consulting document — detailed checklists, a risk table, a maturity self-assessment and a 90-day action roadmap — is available on our website. #CEO #CIO #CTO #Risk #Governance # AI #Artificiall Intelligence