LANDMARK · 6 MIN · STEWARD
Incident governance
After this landmark, you can name the governance-level decisions an AI incident requires beyond the technical containment and fix covered in the Build ring.
You can still explore it. We’re showing the shared explanation and a related practical view without hiding the knowledge.
Build’s incident response landmark covers the technical first response, contain, diagnose, fix. Incident governance is the layer above that: deciding whether affected users or a regulator need to be notified, whether the incident reveals a gap in risk classification or the risk-appetite policy itself, and whether this specific incident is severe enough to require executive or board awareness.
These are judgment calls that shouldn’t be made unilaterally by whoever happened to be on call during containment; they need a predefined severity framework and a clear escalation path decided in advance, not improvised in the moment.
This is the canonical concept. It stays the same across learner lenses so personalization never changes the underlying facts.
What this looks like for you
If a company discloses an AI incident that affected you, that disclosure is a governance decision, not an automatic byproduct of the fix; it’s worth noticing which companies have a real process for this and which only disclose when forced to.
MAKE A DECISION
An AI system used internally for expense report review incorrectly flags a pattern of legitimate expenses as fraudulent, affecting several employees over two weeks before being caught and fixed. Beyond the technical fix, what governance-level questions does this raise?
CARRY THISFor an AI incident you’re aware of (at your organization or reported publicly), identify: was there a clear decision process for disclosure, or did it seem improvised? What would a predefined severity framework have changed?