Risk categories
The vocabulary of AI risk a leader must command: the categories that recur across every framework, why AI risk is different, and the map this course builds on.
The other courses in this track teach people to build AI. This one teaches leaders to make sure an organization can build it safely, legally, and accountably — at scale, across many teams, under regulation. It has no technical prerequisite, because governance is an organizational discipline: it's about policies, roles, controls, and evidence, not code. But it will constantly reference the technical work, because a governance program's whole job is to demand and verify that work.
Why AI risk needs its own taxonomy
Organizations already have risk management — for finance, security, operations. AI doesn't fit neatly into any of them, because it introduces risks those frameworks weren't built for: a system that's probabilistic (it can be wrong unpredictably — including confidently fabricated content; the industry term is hallucination), opaque (you can't fully explain a decision), emergent (capabilities and failures you didn't design), and fast-scaling (one model touching millions of decisions). A leader who treats AI as 'just more software' will govern the wrong risks. The first job is a shared vocabulary.
Not fitting neatly doesn't mean starting from zero. Mature organizations already run serious risk programs — banks operate SR 11-7 model risk management, with model inventories, independent validation, and fair-lending review; insurers and health systems have regimes of their own. AI governance layers onto these rather than duplicating them: extend the existing model inventory to cover the new AI systems instead of building a parallel one, and map the framework functions you'll meet in Module 2 onto the validation and monitoring routines already running. The new taxonomy fills the gaps those frameworks weren't built for — it doesn't replace what already works.
The recurring risk categories
- Performance & reliability — the model is wrong, drifts (the system's behavior or data shifting over time until yesterday's controls no longer fit), or fails on the long tail. The 'reliability gap' the LLMOps course operationalizes; here it's a risk to be owned, not just an engineering problem.
- Fairness & bias — the system produces discriminatory outcomes across protected groups. The highest-stakes category for anything touching people (hiring, lending, healthcare), and the one regulators watch most closely.
- Privacy & data protection — personal data exposed, misused, or processed unlawfully. Intersects GDPR/CCPA and the security course's leakage work.
- Security — the system is attacked (injection, extraction, poisoning). The Securing AI course, viewed as organizational risk.
- Transparency & explainability — stakeholders can't understand or contest a decision. Increasingly a legal requirement, not a nicety.
- Safety & harm — the system causes physical, financial, or psychological harm, directly or through misuse.
- Accountability & legal — unclear who is responsible; regulatory non-compliance; liability. The risk that turns the others into consequences.
- Societal & reputational — misinformation, labor impact, environmental cost, brand damage. The risks that reach beyond the balance sheet.
Throughout, you'll build a real governance program for Meridian Group — a fictional 2,000-person company deploying AI in three places with very different risk profiles: a customer-support agent, an HR résumé-screening tool, and an internal analytics assistant. By the capstone you'll have produced its risk map (Module 1), a regulatory gap analysis (Module 2), a governance charter (Module 3), a control matrix (Module 4), and — in Module 5 — an incident-response plan and a program roadmap: the full toolkit you could take to your own organization on Monday.
Keep this frame throughout: the eval suites (evals: repeatable measurements of output quality on a fixed test set), red-team results (red-teaming: deliberately attacking your own system to find failures before others do), audit logs, and access controls the technical courses produce are the evidence a governance program requires. Governance doesn't replace that work — it makes the organization demand it consistently, verify it independently, and answer for it externally. The engineer proves a control works; the governance leader ensures every AI system has the right controls and can prove it to a regulator.