Impact assessment
Sizing AI risk before it ships: what an impact assessment asks, scoring likelihood against consequence, and why the use case — not the technology — sets the stakes.
Not every AI system deserves the same scrutiny. A tool that drafts internal meeting summaries and a tool that screens job applicants use similar technology and carry wildly different risk. The mechanism for telling them apart — and deciding how much governance each needs — is the impact assessment: a structured evaluation done before a system ships, and revisited as it changes.
The stakes come from the use case, not the model
This is the counterintuitive core: the same model is low-risk in one deployment and high-risk in another. The risk lives in what the system decides and whom it affects, not in how clever the AI is. An impact assessment therefore starts with the context, not the technology:
- Who is affected, and can they opt out? Employees, customers, the public? A person subject to an automated decision with no alternative is the highest-stakes case.
- What decision does it make or influence? Informational (drafts a summary) vs. consequential (approves a loan, ranks a candidate, flags fraud). Consequence sets the floor.
- How reversible is the outcome? A wrong draft is edited; a wrongful denial of a mortgage, a job, or care may be irreversible and legally actionable.
- Is the decision contestable and explainable? Can an affected person understand and appeal it? Regulators increasingly require yes.
- What's the scale? One reviewer's assistant vs. a system auto-deciding a million applications. Scale multiplies every other factor.
Scoring: likelihood × consequence
For each material risk (from Module 1's categories), score the inherent risk first — likelihood (how probable is this failure, given the technology and the use, before any controls?) against consequence (how bad if it happens, to whom?). The inherent score places the system in a tier — low, moderate, elevated, or critical — and the tier drives the governance response: how much review, which controls, whose sign-off, whether it ships at all. Then, once controls are chosen and operating, re-score the residual risk — what remains with the controls in place. The order matters: scoring 'given controls' first is circular, because you'd be using the controls to set the tier that decides the controls. Inherent risk decides what you demand; residual risk tells you whether it worked. This is the same likelihood×impact logic the security course used for findings, applied at the level of a whole system's societal and legal exposure. (The tier names are deliberately not the EU AI Act's — Module 2 introduces its unacceptable/high/limited/minimal tiers, which answer a different, legal question; reusing those words internally invites dangerous confusion.)
Consider Meridian's three systems through this lens: the analytics assistant (informational, internal, low consequence) → low, minimal governance; the support agent (customer-facing, can take actions like refunds, reversible-ish, moderate scale) → elevated, needs the guardrails (automated checks that block or flag bad inputs/outputs) and monitoring the technical courses teach — here, the controls you demand and verify; the HR screening tool (decides who gets interviewed, affects livelihoods, hard to contest, protected-class implications) → critical, the most scrutiny, and — you'll see in Module 2 — a specific regulatory category with legal obligations. Same company, same era of technology, three completely different governance answers.
The most common governance failure isn't a bad assessment — it's no assessment: a team ships an AI feature because it was easy, and nobody asked 'who does this affect and what if it's wrong?' until a journalist or a regulator did. An impact assessment as a required gate before deployment is the single highest-leverage governance control, because it catches the high-risk system before it exists, not after it harms.