Incidents, Reporting & Regulators

Things will go wrong. A chatbot gives harmful advice. A tool leaks data. A model treats a group unfairly. Your reputation depends on how you respond, and in some cases the law sets deadlines for telling regulators or people. This lesson covers how governance fits into incident response, when and how to report, and how to talk to regulators.

Governance's role in incidents

Security leads the technical response. Governance leads the questions that follow. Who was harmed? What laws apply? Whom must we tell, and by when? What do we say publicly? What must change in our rules? You make sure these questions are asked early, and answered by the right people.

What to report internally

• Any serious harm or near miss from an AI system.
• Data exposure, even small.
• A significant unfair outcome for a group.
• A safety or legal complaint from a user or staff member.
• Misuse by a user or insider.

Make reporting easy. A short form, a named inbox and a promise of no blame for good-faith reports. Many serious problems start as small reports that nobody acted on.

A governance incident checklist

IN THE FIRST HOURS
[ ] Incident lead and legal/privacy contact are on the call
[ ] Facts recorded with times: what happened, who is affected, is it still happening
[ ] Containment decided: switch off, roll back, restrict
[ ] Evidence preserved: logs, prompts, outputs, versions, decisions

WITHIN THE FIRST DAY OR TWO
[ ] Legal and privacy decide if notice to regulators or people is required, and the deadline
[ ] Customer and contract duties checked
[ ] Holding statement agreed for staff, customers and press if needed
[ ] Affected people identified and support arranged

AFTER
[ ] Root cause and contributing factors written down
[ ] Policy, standards and controls updated
[ ] Test set and monitoring updated
[ ] Blame-free review held; actions owned and dated
[ ] Lessons shared across the organization; inventory and risk tier revisited

Talking to regulators

• Know in advance which regulators cover you, and who owns the relationship.
• Learn which events must be reported and the deadlines. These differ by law and region.
• Report accurately and promptly. Do not guess, and correct early errors.
• Keep a calm, factual tone. Show what you did to contain and prevent.
• Involve legal counsel before sending formal reports.

Communicating with the public

• Say what happened, in plain words, without blaming users or vendors.
• Say what you are doing and when you will update.
• Offer a contact and a way to get help.
• Do not promise it will never happen again. Promise what you will do.

Near misses are gifts

A near miss is something that nearly went wrong. A reviewer caught a harmful answer. A test found a leak before launch. Treat these as free lessons. Record them, find the cause and fix it. Teams that share near misses improve faster and have fewer real incidents.

Learn at the system level

After each incident, look beyond the single system. Do other systems share the same prompt, vendor, data or pattern? Should a tier change? Should a policy line be added? Governance owns this wider view.