GenAI Governance Playbook
A practitioner playbook for governing enterprise GenAI: operating model, system inventory, risk-tier classification, model cards, runtime guardrails, incident response, and regulatory alignment
GenAI governance is where enterprises stall between maturity levels 2 and 3, and where they take the greatest reputational and regulatory risk when they fail. This playbook covers the operating model, inventory + classification workflow, model and data card templates, runtime guardrail deployment, incident response, and cross-mapping to the EU AI Act, NIST AI RMF, ISO 42001, and SOC 2 — organized as sequenced practitioner actions, not compliance theater.
Licensed under CC BY 4.0 · Author: Framework Research Team · Download Markdown
1. Executive summary
GenAI governance is not a written policy sitting on Confluence. It is a running system with inventory, classification, controls, telemetry, and incident response — operating alongside GenAI development in production. Organizations that treat governance as a document produce artifacts that fail conformity assessments; organizations that treat it as an operating system move up the maturity model faster and take less regulatory risk.
This playbook assumes you have adopted (or plan to adopt) the Generative AI Maturity Framework and are working to move from level 2 (Exploring) to level 4 (Integrated) on the Governance & Risk dimension. It sequences the practitioner actions that separate teams with defensible governance from teams with governance decks.
Regulatory alignment matters, but no single framework "solves" governance. The EU AI Act is binding for EU deployment; NIST AI RMF is voluntary but the shared language most peers use; ISO/IEC 42001 is certifiable and increasingly cited in enterprise procurement. All three (plus SOC 2 for security controls) overlap and complement. Adopt what your obligations require and align the rest to the framework you already use for other risk domains.
2. Operating model — three lines of defense, adapted
The three-lines-of-defense model from financial services adapts cleanly to GenAI:
First line — the delivery teams. Product and engineering teams building GenAI systems. Own day-to-day risk decisions: which model to use, what data to include, what guardrails to apply, when to escalate. Responsibility for identifying and mitigating risks in their own systems.
Second line — the governance function. Central team (AI Governance Office, Responsible AI Team, or existing risk / compliance function extended) that sets standards, reviews high-risk deployments, maintains the AI system inventory, and coordinates cross-team risk positions. Independent of first-line delivery pressure.
Third line — internal audit. Periodic independent assessment of both first- and second-line effectiveness. Reports to Audit Committee. Frequency: annually for organizations at maturity level 3+; less formal review at level 2.
The most common anti-pattern is collapsing the second line into IT or into a single "AI Ethics" role without independent authority. Governance without authority to block a launch is not governance. Ensure the second-line function reports to a level that can defensibly say no to first-line commercial pressure — typically the Chief Risk Officer, General Counsel, or Chief Technology Officer with a documented mandate.
3. AI system inventory
The AI system inventory is the foundational artifact of governance. Everything else builds on it. Under-invest here and you cannot answer basic regulatory questions ("show us your high-risk systems") without a discovery sprint.
3.1 What to inventory
Every AI system in development or production, whether built in-house or procured. Third-party GenAI features embedded in tools your organization uses count (Copilots, AI-augmented SaaS features). Employee use of consumer AI tools does not count as a "system" but is covered by the Acceptable Use Policy.
Each inventory entry captures: identifier, name, intended use, deployment status (development / production / retired), user population, data classes processed, model provider and version, third-party components, business owner, technical owner, risk tier, and last review date.
3.2 Keeping it current
The inventory decays fast without automation. Two mitigations: gate deployment on inventory registration (a production deployment that is not in the inventory is a policy violation), and audit quarterly by pulling from cloud-provider AI service dashboards, model-provider usage logs, and code-repository searches for known SDK imports.
For AI features embedded in SaaS, use procurement as the trigger point — any SaaS renewal or new subscription passes through a "does this include AI functionality" question in the procurement workflow.
4. Risk-tier classification
Every AI system in the inventory carries a risk tier that determines the depth of review it must pass and the controls it must implement. The tier borrows from the EU AI Act's framework because it is the most widely-recognized structure.
4.1 The four tiers
Unacceptable. Prohibited under EU AI Act Article 5 (social scoring, real-time biometric identification in public spaces, manipulative techniques exploiting vulnerabilities). Not permitted regardless of business justification.
High. Falls into an EU AI Act Annex III category (biometric ID, critical infrastructure, education access, employment decisions, essential services eligibility, law enforcement, migration, judicial administration) or produces outputs with material legal, financial, or safety consequences. Requires full technical documentation, conformity assessment, and human oversight per Article 14.
Limited. Customer-facing or Confidential-data-processing systems with low-consequence outputs. Requires transparency (users know they are interacting with AI per Article 50), input/output guardrails, and documented model card.
Minimal. Internal productivity assistance with no Confidential+ data processing and no consequential outputs. Team-lead sign-off and inventory registration suffice.
4.2 Classification workflow
The proposing team drafts a classification with reasoning. The second-line governance function reviews and can escalate to committee if borderline. Classification is documented and revisited on material change (upstream model version change, prompt scaffold change, new data source, new user population, or 12 months elapsed).
The most common misclassification is limited-tier for systems that produce automated decisions affecting individuals (loan pre-qualification, resume filtering, benefits eligibility) — those are almost always high-risk. When in doubt, classify up and let the review process bring it down with reasoning.
5. Model cards and data cards
Every production AI system requires a model card and data card as a launch prerequisite. Not launch-day paperwork — launch prerequisite. If the card cannot be produced, the system cannot ship.
Model card contents. Model identity (provider, family, version), intended use, in-scope users, out-of-scope uses, training data summary (for open-weights or in-house fine-tunes; sourced from provider technical documentation for hosted models), known limitations, evaluation results (accuracy, groundedness, bias, robustness), cost profile, cybersecurity considerations, and human oversight mechanisms.
Data card contents. For every dataset used in training, fine-tuning, retrieval, or evaluation: provenance (source, license, collection methodology), composition (record count, distribution, biases), quality metrics, PII handling, retention terms, and appropriate uses.
Cards are versioned alongside the system. A model or prompt-scaffold version change requires a card update; the previous version card is retained for audit. Automation matters here — teams that generate cards manually update them once; teams that generate cards from CI + inventory + eval-harness output keep them current at negligible marginal cost.
The EU AI Act's technical documentation requirement (Article 11, Annex IV) maps directly to a rigorous model card. NIST AI RMF calls the same artifact by different names but with equivalent content requirements. ISO 42001 requires equivalent documentation as evidence of an AI management system.
6. Runtime guardrails
Written policy is a necessary starting point; it is not enforcement. Enforcement lives in runtime guardrails that fire at inference time regardless of the developer's good intentions.
Reference layered defense: input filtering (PII detection, prompt injection classification, off-topic classification), output filtering (toxicity, harm categories, PII leakage prevention), tool allowlists (each agent can invoke only pre-authorized tools), per-action budgets (max steps, max cost, max wall-clock per task), and human-in-the-loop approval for irreversible actions.
Vendor landscape: NVIDIA NeMo Guardrails (open-source, Colang DSL), Guardrails AI (open-source Python library + validator hub), Lakera Guard (SaaS, security-first, hosted threat intelligence), Protect AI (Layer) (broader AI-security platform). Most mature deployments run one vendor for prompt-injection defense plus in-house rules for domain-specific policies. See /vs/guardrails-vendors for detailed selection guidance.
Guardrail configuration is versioned. Rule additions and threshold changes are auditable. Every P1/P2 incident should either add at least one guardrail rule or explain why an existing rule would have caught it and did not — the postmortem is not complete otherwise.
7. Incident response
GenAI incidents fall outside the categories your traditional incident-response process is likely designed for. Extend, do not replace.
7.1 GenAI-specific incident categories
In addition to standard security incidents, track: hallucination-driven harm (a GenAI output causes material harm), prompt injection compromise (input hijacks system behaviour), model or prompt data leakage (confidential data leaks through outputs, memory, or vector-store retrieval), runaway agent (autonomous system exceeds intended envelope), guardrail bypass (safety filter fails to trigger), model misuse (approved system used for prohibited purposes), vendor incident (third-party provider incident affecting your data), and regulatory finding (regulator or auditor identifies a compliance gap).
7.2 Notification windows
Under the EU AI Act (Article 73), serious incidents involving high-risk systems must be reported to the relevant market surveillance authority within statutory windows (15 days for infringements of Union obligations to protect fundamental rights; 10 days for widespread infringements; 2 days for interruption of critical infrastructure). GDPR personal data breach notification (Article 33) runs in parallel at 72 hours. Track both.
For US operations, monitor state consumer notification laws and sector-specific regulators (SEC for public companies, OCC for banks, FDA for medical devices, etc.). Non-EU jurisdictions with equivalent AI legislation (Canada AIDA, Brazil, California SB 942) are adding notification obligations through 2026-2027.
7.3 Evidence preservation
For any incident with regulatory, legal, or customer-communication implications: preserve full prompt / completion logs for the affected time window, model and prompt version identifiers in use at incident time, guardrail configuration in use at incident time, user identifiers per your identity retention standard, all incident-channel communications, and the postmortem document. Retention: minimum 3 years, longer per applicable regulations.
8. Regulatory alignment — the practical cross-map
You do not need to implement four separate governance programs. The overlap between EU AI Act, NIST AI RMF, ISO 42001, and SOC 2 is substantial; the differences are in emphasis, evidence, and audit.
EU AI Act. Binding law with product-obligation structure. Determines what you legally must do for systems placed on the EU market. Concrete artifacts: technical documentation (Annex IV), event logging (Article 12), human oversight (Article 14), post-market monitoring plan (Article 61), serious incident reporting (Article 73). GPAI providers face additional obligations (Articles 53-55) including training-content summaries and copyright compliance.
NIST AI RMF. Voluntary, organized around Govern / Map / Measure / Manage. Provides shared vocabulary for internal risk management. The Generative AI Profile (AI 600-1, July 2024) extends the RMF with GenAI-specific risks and mitigations. Use as your internal common language even if you are not US-based.
ISO/IEC 42001. Certifiable AI management system standard. Third-party certification is emerging as a procurement differentiator. Structure follows ISO Annex SL (same shape as ISO 27001), so if you already run an ISO 27001 program, 42001 is a natural extension. Complementary companion standard: ISO/IEC 23894 (AI risk management guidance).
SOC 2. Not AI-specific but essential for the underlying security posture. Trust Services Criteria cover the controls that any AI system inherits (access, encryption, logging, incident response). SOC 2 Type II reports are the baseline enterprise buyers expect.
The /tools/compliance-mapper provides control-by-control cross-mapping across all four frameworks. The /tools/governance-checklist provides an 80-item self-assessment scoring your program against each framework in real time.
9. Governance metrics
What to measure to know your governance program is real, not theater:
- Inventory completeness. Percentage of production AI systems in the inventory. Target 100%; anything less is unknown risk. - Classification currency. Percentage of high-risk systems whose classification was reviewed in the last 12 months. Target 100%. - Model card currency. Percentage of production systems whose model card matches the deployed model + prompt version. Target 95%+. - Guardrail coverage. Percentage of production systems with layered guardrails (input filter, output filter, tool allowlist, budget). Target 100% for high-risk; 80%+ for limited. - Eval-gated release rate. Percentage of releases that pass the CI-gated evaluation before deployment. Target 100%; exceptions require documented business justification. - Incident response time. Median time from incident detection to first substantive containment action. Target: 30 minutes for P1, 2 hours for P2. - Postmortem-to-eval ratio. Percentage of P1/P2 postmortems that resulted in at least one added evaluation entry or guardrail rule. Target 100%. - Regulatory-notification compliance. Percentage of notification-triggering incidents where notification landed within the statutory window. Target 100%.
Report these to the Audit Committee (or equivalent) at your maturity-appropriate cadence — quarterly at level 3, monthly + real-time dashboard at level 4+.
The /tools/governance-checklist gives an 80-item interactive self-assessment across EU AI Act, NIST AI RMF, ISO 42001, and SOC 2 — with per-framework scoring in real time.
10. Recommended reading
- /framework/dimensions/governance — the framework dimension this playbook operationalizes. - /vs/eu-ai-act-vs-nist-vs-iso-42001 — head-to-head framework comparison. - /tools/compliance-mapper — control-by-control cross-mapping. - /tools/governance-checklist — 80-item self-assessment. - /tools/policy-generator — download AUP, Data Handling, Model Approval, Incident Response policy templates.
References
Cite this whitepaper
Generative AI Maturity Framework. (2026). GenAI Governance Playbook: A practitioner playbook for governing enterprise GenAI: operating model, system inventory, risk-tier classification, model cards, runtime guardrails, incident response, and regulatory alignment (Version 1.0). https://genaimaturity.net/whitepapers/genai-governance-playbook-2026
@techreport{GenaiGovernancePlaybook20262026,
title = {GenAI Governance Playbook: A practitioner playbook for governing enterprise GenAI: operating model, system inventory, risk-tier classification, model cards, runtime guardrails, incident response, and regulatory alignment},
author = {{Generative AI Maturity Framework}},
year = {2026},
month = {8},
note = {Version 1.0},
url = {https://genaimaturity.net/whitepapers/genai-governance-playbook-2026}
}