AI Governance
AI governance
This domain tests whether you can place an AI system inside an accountability structure: who approves it, which rules apply, and what evidence proves compliance. Expect questions on framework mapping (NIST AI RMF, ISO/IEC 42001, EU AI Act) and on the artifacts that make governance auditable.
Core rules
- Governance is a system, not a sign-off. NIST AI RMF's Govern function is continuous and feeds Map, Measure and Manage.
- ISO/IEC 42001 defines an AI management system: policy, roles, risk treatment, internal audit and continual improvement under a PDCA cycle.
- EU AI Act tiers: unacceptable (prohibited), high-risk (Annex III), limited-risk (transparency duties), minimal. General-purpose AI providers carry separate transparency and systemic-risk obligations.
- Every AI system needs an inventory entry, named owner, risk classification, approval record and reviewed documentation (model card, intended use, known limitations).
- Third parties stay in scope: vendor due diligence, audit rights, no-train clauses and incident-notification terms.
Worked example
A bank wants an LLM to draft creditworthiness summaries. Creditworthiness evaluation is an Annex III high-risk use. Reasoning: high-risk triggers a fundamental-rights impact assessment, human oversight, logging, data-governance duties and conformity assessment before go-live. The governance output is therefore not the model card alone - it is the risk-register entry, DPIA/FRIA, oversight design and approval by the accountable committee, with re-review on material change such as a new fine-tune or data source.
Traps
- Treating Govern as a one-time project gate rather than a recurring control loop.
- Classifying everything high-risk, which dilutes controls and budget.
- Assuming a vendor's compliance statement covers your deployment context.
- Forgetting that fine-tunes, RAG changes or new users can re-trigger classification review.