Governance, in practice, is one question: can you produce the evidence on request?
Day 53 of 60
By now you've produced a lot of safety work — threat models, policies, red-team logs, eval scorecards, a risk register. Governance asks a deceptively simple question about all of it: can you produce the evidence on request? A control you did but can't demonstrate is, for compliance purposes, a control you didn't do. Today you build the artifact that closes that gap: a requirements-vs-evidence gap analysis.
Compliance is evidence management. A framework gives you a checklist of required controls; your system either has documented evidence for each or it doesn't. The gap analysis turns "are we compliant?" — a vibe — into a ranked, defensible list of what's missing. It's a threat model's cousin, pointed at obligations instead of attacks.
Drawing on the EU AI Act's high-risk tier (Day 51), the recurring requirements include: a risk-management system, data governance, technical documentation, transparency to users, human oversight, accuracy / robustness / security, and post-market monitoring. Each is something an operator must be able to show, not just claim.
"Are we compliant?" invites a defensive yes. A gap list forces specificity: these controls are evidenced, these are not. That specificity is what a reviewer, auditor, or regulator actually wants — and what lets you write a remediation order instead of an excuse.
The checklist below captures the shape of high-risk obligations. Before you tie a real system to "EU AI Act compliance," confirm the current obligations against the official Commission / EUR-Lex text — wording and scope have evolved as the Act phases in.
In the Try This box is compliance_check.py — it checks a system's documented controls against a requirements checklist and prints the gaps. Run it, then replace the evidence map with an honest assessment of a real (or realistic) deployment you know. The output is the first page of any governance review: met vs. missing.
Pick one system and fill the evidence map honestly — including the controls you'd be embarrassed to admit are undocumented. Then write a one-line remediation order for each gap: who closes it, with what artifact, before deployment. That ordered gap-plus-remediation list is your governance deliverable for the week.
compliance_check.py from the Try This box and read its gap output.evidence map for one real deployment, list the gaps, and write a one-line remediation order for each — owner, artifact, deadline.A novice answers "are we compliant?" with a confident yes. An expert answers with a gap list and a remediation order — because compliance isn't a feeling, it's the ability to produce specific evidence against a specific requirement. Owning the gap analysis means owning the deployment decision: you can say exactly what must close before go-live, and prove it after.
Say this in an interview: "I treat compliance as evidence management. I map the system's documented controls against the framework's requirements, produce a ranked gap list, and write a remediation order for each gap. 'Are we compliant?' becomes 'here's what we can evidence and here's what's missing' — and I verify the obligations themselves against the official text, not memory."