Governance: what makes AI deployable
The model works in the demo. But legal, security, and your biggest customer all ask the same thing: where does our data go, who reviews mistakes, and who's accountable?
The idea inside
The feature's risk class sets the controls: data retention, PII handling, human review, audit logs, and a clear owner. Higher stakes means stricter controls, by design.
After this lesson
You can set the governance controls an AI feature needs to be deployable: retention, PII handling, human review, audit logging, and a risk owner, scaled to its risk class.
Where it leads
Inside this lesson
That's the real lesson stage, paused. Claim your pass to operate it.
See how AI actually works, end to end.
This lesson is one stop on the full arc. Unlock all of it, and keep it for life.
What you get
- The 34-lesson main path, a finishable route from a word to agents
- Goal tracks for using AI at work and building AI features
- Boss labs that make you apply a whole act, not just recognize it
- Spaced recall that brings each idea back before you forget
- Course memory: every term defined, with links to where it first appears
- A shareable capability card when you finish the main path
- Lifetime access on every device, every future lesson included
Not videos to watch. You predict, operate the machine, then prove it. That is why it stays.
99 interactive lessons and challenges. No videos, no code.
Free launch pass: lifetime access, no card needed
New here? The first lessons are free to try. Start with lesson 0.1
What this lesson shows
The feature's risk class sets the controls: data retention, PII handling, human review, audit logs, and a clear owner. Higher stakes means stricter controls, by design.
The question it opens with
The model works in the demo. But legal, security, and your biggest customer all ask the same thing: where does our data go, who reviews mistakes, and who's accountable?
The walkthrough, in the lesson's own words
- Set the controls for this feature. Get it to a state a regulated org could actually ship.
- The same controls aren't right for every feature. Predict which one needs the strictest governance.
- The feature's risk class drives the controls. Governance is designed in, not bolted on.
- It reads a patient's symptoms and suggests how urgently to seek care.
- Deployable. Short retention, redacted PII, a human reviewing every flagged answer, a full audit log, a named owner, and a vendor that doesn't train on your inputs. The risk class set every one of those.
- Still blocked. For a high-risk medical feature, each loose control is a reason a security review would say no.
- Don't store data you don't need (30 days or none), redact PII, put a human in the loop on every high-risk output, turn the audit log on, name an owner, and pick a vendor that doesn't train on your users' inputs. Each control is a gate, not a preference.
- This console is illustrative of how a regulated org reasons about a feature, not a substitute for legal or compliance advice.
- The triage assistant. It's customer-facing, in a regulated domain, and a wrong answer can hurt someone. That risk class is what forces tight retention, a human in the loop, an audit log, and a named owner.
- The blog-title brainstormer can be loose: it's internal, low-stakes, and a bad title costs nothing. You spend governance where the risk is, not evenly.
- A common reference is the NIST AI Risk Management Framework. It splits the work into four functions: Govern (set who's accountable and the policies), Map (figure out the feature's context and risk class), Measure (test and track how it actually behaves), and Manage (act on what you find, including pulling it if needed). Notice it starts with classifying risk, then sizes the controls to it.
- The EU AI Act writes this same logic into law: it sorts AI systems into risk classes (banned outright, high-risk, limited, minimal) and scales the obligations to the class, exactly like this console. A medical triage assistant is a textbook high-risk system under the Act. Its rules are phasing in through 2027 and beyond: duties for general-purpose models (GPAI, the models behind chatbots) came first, transparency rules like labeling AI content follow, and the strictest high-risk obligations were pushed out to late 2027 and 2028. The dates keep shifting; the risk-class logic is the part to remember.
- Governance is a legal checkbox you bolt on after launch.
- The feature's risk class drives the controls: retention, PII handling, human review, audit, and ownership, designed in from the start.
- Your team built a great feature and a big customer's enterprise security review is the last gate before the deal. What is that review actually checking?
- It asks where the data goes, how long it's kept, who audits the outputs, and who's accountable when it's wrong. A feature that can't answer those doesn't get bought, no matter how good the demo was. That's why governance is part of building it, not paperwork after.
- You can read a feature's risk class and set the controls that make it deployable in a regulated org: retention, PII handling, human review, audit, and ownership, designed in from the start.
Key takeaway
You matched governance controls to a feature's risk, and saw why a high-risk feature with no human review and forever retention is not deployable.
What you can do after this lesson
You can set the governance controls an AI feature needs to be deployable: retention, PII handling, human review, audit logging, and a risk owner, scaled to its risk class.
This is the written summary. The lesson itself is interactive: you predict, drag and operate the mechanism above, and the reveal answers you.