AI Governance Handbook

About this handbook

This is the reference I use for AI governance work and reviews. It's organized around the loop most governance work follows: intake, triage, assess, decide, monitor.

• How to use it: start with program setup and the review workflow (sections 01 and 02), then jump to whatever the situation needs. The tools at the top work on any scenario.
• How it's kept current: legal sections show the date they were last checked and turn amber after 90 days. Laws in this area change monthly.
• What it leaves out: no employer's confidential details, ever. Lessons are written down without the company behind them.
• How it was made: built with Claude; the research is sourced and linked, and I review and update the content.
• Suggested cadences and thresholds are starting points, to adapt to an organization's own risk appetite.

A practitioner's reference, not legal advice. Confirm legal questions with counsel.

Program setup

Before the review workflow can run, a program needs five foundations: a named owner, a policy, an inventory, a committee for the big decisions, and people trained to use AI well.

A first 90 days

A suggested sequence for a new program or a new role. Adjust the pace to the organization.

The governance committee

• Members: a chair (often legal, risk or a senior business leader), plus legal, privacy, security, data or engineering, HR, and business representatives. The governance lead usually runs it.
• Decides: approval of high-risk uses, policy changes, risk appetite, and exceptions to policy.
• Meets: monthly, with a fast path for urgent decisions.
• Records: every decision, its conditions and its rationale.

A charter template is in Templates.

AI literacy and training

The EU AI Act has required providers and deployers to ensure staff AI literacy since Feb 2, 2025. Good practice everywhere is to train by role:

The review workflow

Every AI use, whatever the industry, goes through the same five steps. What changes is how deep each step goes, and that depth is set at triage.

Before intake: is AI the right tool?

Ask these first. A "no" doesn't always stop a project, but it should shape it.

• Is the problem clearly defined, and would a simpler, non-AI approach work as well?
• Is there enough good, lawful data for the job?
• Can errors be caught before they cause harm, and can people live with the error rate?
• Could you explain how it works to the people it affects?
• Does the benefit outweigh the cost of the oversight it will need?
• Is the use allowed at all? Check banned practices and sector rules.

What goes in the AI inventory

The inventory is the governance team's source of truth. Each entry typically records:

Who owns what

Unclear ownership causes most governance friction. A typical split, to adapt to your organization (R = does the work, A = accountable, C = consulted, I = informed):

For high-risk systems, the approval usually sits with a governance committee or a named executive rather than the business owner alone.

Risk triage

Triage decides how much review a use case gets. A use that shapes decisions about people in a regulated area is high-risk almost by default. Everything else is scored on data, audience, autonomy and scale.

The factors

Review depth by tier

When designing human oversight, place approval where the workflow crosses a consequence threshold rather than requiring sign-off on every AI step. Require approval or escalation when an action becomes:

• difficult to reverse
• materially consequential for a person or the business
• legally significant
• outside the authority approved for the system
• dependent on judgment the AI has not been authorized to make

Record these thresholds in the assessment's oversight section so testing and monitoring can check them.

Impact assessments

An impact assessment is the core document of the job: what the system does, who it affects, what could go wrong, and what keeps that in check. Build one template with modules, so a single assessment can satisfy several laws at once.

Assessments that overlap

What a good assessment covers

1. Purpose and context: the problem, the decision supported, what happens without it.
2. People affected: who, how many, where, and any vulnerable groups.
3. Data: inputs, outputs, sources, sensitivity, retention, where it's processed.
4. System: model or vendor, how it was built, known limits, intended and prohibited uses.
5. Risks: walk the NIST trustworthiness traits (section 10) and the relevant genAI risks.
6. Testing evidence: what was tested, how, and the results (section 05).
7. Controls: human oversight, notices, appeal route, access limits, guardrails.
8. Legal check: which laws apply and how each is met (section 09).
9. Remaining risk and decision: what's left after controls, and who accepts it.
10. Monitoring: metrics, thresholds, review date (section 07).

Walking through harms

The risk section is only as good as the list of people you thought about. For each group, ask how the system could help them and how it could harm them.

• Direct users: the staff or customers who operate it
• People decided about: applicants, borrowers, patients, policyholders
• Bystanders: people in the data or affected indirectly
• Vulnerable groups: minors, people with disabilities, people in hardship, non-native speakers
• The organization: legal, financial and reputational exposure

The full template is in Templates.

Testing and evaluation

Testing turns "we think it's fine" into evidence. Match the method to the risk: decision systems need fairness and accuracy testing; generative and agentic systems need adversarial testing too.

The core bias math

NYC bias audits and the federal four-fifths rule both compare selection rates between groups. The same math works for loan approvals, insurance offers and other yes-or-no outcomes.

A ratio below 0.8 is the traditional red flag for adverse impact under the federal Uniform Guidelines on Employee Selection Procedures. It's a rule of thumb, not a safe harbor, and small samples need statistical tests too.

Security risks for generative AI

Governance and security overlap most here. The OWASP Top 10 for LLM Applications (2025) is the standard checklist:

A test plan template is in Templates.

Vendors and contracts

Most AI arrives through vendors, but the legal responsibility stays with you. Due diligence finds the risks; the contract is where you fix them.

Contract clauses to ask for

The due-diligence questionnaire is in Templates.

Watch the marketing too. The FTC has kept pursuing deceptive AI capability claims, including in business-to-business sales materials (Holland & Knight, Aug 2026). Ask vendors to back up what they claim.

Monitoring

Approval is a snapshot. Data drifts, vendors swap models and people start using tools in new ways, so every approved system needs metrics, a review date and clear triggers for a fresh look.

What to measure

For generative and agentic systems, monitor behavior as well as system health. A service can report healthy while the AI makes unsupported claims, uses the wrong tool, crosses an authority boundary, exposes sensitive data, frustrates users or leaves tasks incomplete. Review production traces for these patterns. Recurring failures should become regression tests, while monitoring continues to watch for them in live use.

Triggers for reassessment

• The vendor changes the model, or you retrain your own
• A new use, user group or affected population
• A new data source, or a new location for affected people
• A new law or regulator guidance that applies
• An incident, or a pattern of complaints
• A metric crosses its threshold
• The scheduled review date arrives

Incidents and privacy

The most common AI incident is personal or confidential data pasted into an unapproved tool. Under GDPR that can be a personal data breach, with 72 hours from becoming aware to notify the regulator unless the risk to people is unlikely.

Key GDPR rules

• What a breach is: a security failure that leads to accidental or unlawful loss, change, disclosure of or access to personal data. Sharing data with an AI provider the company has no contract with can count as unauthorized disclosure.
• Notify the regulator without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to put people at risk. If late, explain why (Art. 33). Details can come in phases.
• Document every breach, including the ones you don't report.
• Tell the people affected without undue delay if the risk to them is high, unless the data was encrypted, the risk was removed, or individual notice would take disproportionate effort (Art. 34).
• Automated decisions: people have a right not to be subject to decisions based solely on automated processing that have legal or similarly significant effects, with exceptions and safeguards such as human intervention (Art. 22).

First response

Privacy laws that reach AI

Laws and regulations

There's no single US AI law. Instead, broad state laws, sector rules, chatbot laws and long-standing anti-discrimination and consumer protection law all apply. The EU AI Act sets the strictest baseline for anything touching the EU.

EU AI Act at a glance

Maximum fines run up to €35M or 7% of global turnover for banned practices, and €15M or 3% for most other breaches (SIG summary, Aug 2026).

Beyond the US and EU

Most countries rely on existing law plus voluntary frameworks. South Korea is the main exception, with a comprehensive AI law now in force.

Frameworks

Frameworks give a program its structure and give you a shared vocabulary with auditors and regulators. Most US programs are built on the NIST AI RMF; ISO/IEC 42001 is what companies certify against.

NIST AI RMF: the four functions

Seven traits of trustworthy AI

The RMF's goals for any system, and a checklist for the risk section of an assessment:

1. Valid and reliable
2. Safe
3. Secure and resilient
4. Accountable and transparent
5. Explainable and interpretable
6. Privacy-enhanced
7. Fair, with harmful bias managed

The 12 generative AI risks (NIST AI 600-1)

ISO/IEC 42001 in brief

A certifiable management system standard for AI, built on the same structure as ISO 27001. Its clauses cover context, leadership, planning, support, operation, performance evaluation and improvement, plus an annex of AI-specific controls such as impact assessments, data management and third-party relationships. If your company holds ISO 27001, 42001 will feel familiar.

OECD AI Principles

Five values-based principles that many national policies build on: inclusive growth and well-being; human rights and democratic values, including fairness and privacy; transparency and explainability; robustness, security and safety; and accountability.

Writing and templates

Governance writing gets quoted back, forwarded without context and sometimes read by lawyers later. Write every piece as if it will be.

Five rules for every piece

1. Match the decision exactly. Write down what was agreed, not your own version of it. If you disagree, raise it separately.
2. Lead with the action. The first sentence says what the reader must do or know.
3. Be concrete. Name the data, tools and people. "Customer account numbers and support tickets" beats "personal data."
4. Leave out what isn't true yet. Don't imply approval, safety or compliance you haven't confirmed.
5. Give a next step. Who to contact, what happens next and by when.

By document type

Words to watch

Templates

Fill in the [brackets] and cut whatever doesn't apply. Copy puts the text on your clipboard.

AI USE-CASE INTAKE

1. Requester and team:
2. Tool or vendor name (and version, if known):
3. What problem does it solve? What happens today without it?
4. Who will use it, and roughly how many people?
5. Who is affected by its outputs? (employees / applicants / customers / patients / public)
6. Does it make or support decisions about people? Which decisions?
7. Data going in: (personal / sensitive / confidential / customer / none)
8. Where do outputs go, and who sees them?
9. Does it take actions on its own? Which ones?
10. Where is data stored and processed? (countries)
11. Does the vendor keep or train on our data? Retention period?
12. Does a person review outputs before they're used? How?
13. Where are the affected people located? (states, countries)
14. Contract status: (signed / in negotiation / free self-signup / none)
15. Target launch date and why that date:

For governance use: risk tier [ ]  reviewer [ ]  decision [ ]  next review [ ]

ID,System name,Vendor,Version or model,Business owner,Purpose,Decisions supported,People affected,Locations of affected people,Data used,Sensitive data (Y/N),Customer-facing (Y/N),Takes actions (Y/N),Risk tier,Date triaged,Assessment link,Approval status,Conditions,Next review date,Notes

AI GOVERNANCE COMMITTEE CHARTER

Purpose
Oversee how [Company] develops, buys and uses AI, so benefits are realized and risks stay within agreed limits.

Scope
All AI systems and uses in the AI inventory, including vendor tools.

Members
Chair: [name, title]
Members: legal, privacy, security, data/engineering, HR, [business units]
Secretary: AI governance lead (agenda, minutes, decision log)
Quorum: [number] members including the chair or delegate

Responsibilities
- Approve or reject high-risk AI uses, with conditions
- Approve the AI policy and changes to it
- Set and review risk appetite and tiering criteria
- Grant and review exceptions to policy
- Review incidents and monitoring trends
- Report to [executive team / board] quarterly

Decision-making
[Consensus / majority]; the chair decides if there's no agreement. Dissent is recorded.

Meetings
Monthly; urgent decisions by [fast-path process] within [n] business days.

Records
Every decision, its conditions and rationale go in the decision log.

Review
This charter is reviewed yearly. Last reviewed: [date]

AI IMPACT ASSESSMENT: [system name]
Owner: [name]   Assessor: [name]   Date: [ ]   Risk tier: [ ]

1. Purpose and context
   - Problem solved and decision supported:
   - What happens without the system:
   - Intended uses / uses that are out of scope:

2. People affected
   - Who, how many, where:
   - Vulnerable groups (minors, patients, people in financial hardship, etc.):
   - Harm walk-through: for each group, how could it help, and how could it harm?
     (allocation, quality of service, stereotyping, privacy, safety, economic,
      autonomy, access)

3. Data
   - Inputs, outputs, sources:
   - Sensitive data involved:
   - Retention, location of processing, access:

4. System
   - Model or vendor, version:
   - How it works, in plain language:
   - Known limitations and failure modes:

5. Risks (rate likelihood and severity for each)
   - Validity and reliability:
   - Safety:
   - Security and resilience:
   - Accountability and transparency:
   - Explainability:
   - Privacy:
   - Fairness and bias:
   - Generative AI risks that apply (confabulation, data leakage, etc.):

6. Testing evidence
   - Tests run, method, sample, results (attach):

7. Controls
   - Human oversight (who reviews what, and when):
   - Notices to affected people:
   - Appeal or correction route:
   - Technical guardrails and access limits:

8. Legal check
   - Laws that apply and how each is met:

9. Remaining risk and decision
   - Risk remaining after controls:
   - Recommendation: approve / approve with conditions / reject
   - Conditions:
   - Accepted by: [name, title, date]

10. Monitoring
   - Metrics and thresholds:
   - Next review date:
   - Reassessment triggers:

TEST PLAN: [system name]

Questions this testing must answer
- [e.g. Do outcomes differ by group?]
- [e.g. How often does it make up answers?]

Methods (see Testing section)
- Method: [ ]  Data or prompts: [source, size]  Pass threshold: [ ]
- Method: [ ]  Data or prompts: [source, size]  Pass threshold: [ ]

Groups or scenarios covered
- [Demographic groups, edge cases, languages, attack types]

Who runs it, and independence
- [Team; independent reviewer if required]

Results
- [Summary, numbers, failures found]

Decision
- [Pass / fix and retest / fail], approved by [name, date]

AI VENDOR DUE DILIGENCE: [vendor], [product]

Models and training
- Which models power the product, and who built them?
- What data were they trained on? Is customer data used for training? Can we opt out in the contract?

Data handling
- Where is our data processed and stored? Which subprocessors?
- Retention and deletion terms? Can we get deletion on request?
- Certifications: SOC 2 Type II, ISO 27001, ISO/IEC 42001?

Fairness (required for systems that make decisions about people)
- Have you tested for bias? Share the method and results by group.
- Will you support our independent testing or audit, including access to outcome data by group?

Transparency and oversight
- Documentation of intended use, limitations and known failure modes?
- Can a person review and override every output? Are inputs and outputs logged for audit?

Security
- Protections against prompt injection, data leakage and misuse?
- Incident notification timeline to customers?

Claims and change management
- What evidence supports your accuracy and capability claims?
- How and when are customers told about model changes?

Contract
- Audit rights, data-use limits, indemnification, exit and data return?

[COMPANY] AI ACCEPTABLE-USE POLICY

1. Purpose: why this policy exists, in two sentences.
2. Scope: who it covers (employees, contractors) and which tools (any AI that generates content, makes recommendations or takes actions).
3. Approved tools: where to find the current list; how to request a new tool.
4. Data rules: what may never go into AI tools (e.g. customer personal data, health data, credentials, unreleased financials) unless the tool is approved for that data.
5. Allowed uses: examples of encouraged, low-risk uses.
6. Prohibited uses: e.g. making decisions about people without approved review; presenting AI output as human-written where disclosure is required; banned practices under law.
7. Human responsibility: you own what you send, publish or decide, whatever drafted it.
8. Disclosure: when to tell customers or colleagues that AI was used.
9. Reporting: how to report mistakes or data shared by accident, without blame.
10. Training: required AI literacy training and when.
11. Consequences: what happens if the policy is broken.
12. Owner and review date.

Subject: Recap: [meeting topic], [date]

Hi [name],

Thanks for your time today. Here's what we agreed:

Decisions
- [Decision 1]
- [Decision 2]

Next steps
- [Owner]: [action] by [date]
- [Owner]: [action] by [date]

Open questions
- [Question] ([who will answer], by [date])

Let me know if I've missed or misstated anything.

[Your name]

To: [name]
From: [your name]
Date: [date]
Subject: [topic]: findings

Bottom line
[One sentence with the key number.]

What we found
1. [Finding], based on [evidence]
2. [Finding], based on [evidence]

Severity: [High / Medium / Low], because [reason]

Recommended actions
- [Action] (owner: [name], by [date])
- [Action] (owner: [name], by [date])

What we don't know yet
- [Gap] (how we'll close it: [step])

Method
[Data sources reviewed, period covered, who was consulted.]

Decision needed: [the question], by [date]

Background
[Two or three sentences: what's proposed and why now.]

Options
A. [Option]: benefit [ ], risk [ ], cost [ ]
B. [Option]: benefit [ ], risk [ ], cost [ ]
C. Do nothing: benefit [ ], risk [ ], cost [ ]

Recommendation
[Option], with these conditions:
- [Condition, e.g. bias testing before launch]
- [Condition, e.g. human review of every adverse outcome]

Remaining risk and monitoring
[What could still go wrong, what we'll measure, how often, who owns it.]

Approval: [name, title]   Date: [ ]

AI RISK REPORT: [quarter]

Headline
[One sentence: overall posture and the one thing leadership needs to know.]

Program at a glance
- AI systems in inventory: [ ] (high [ ] / medium [ ] / low [ ])
- Assessments completed this quarter: [ ]
- Overdue reviews: [ ]
- Open high risks: [ ]
- Incidents: [ ] (reportable [ ])
- Staff AI training completion: [ ]%

Top risks
1. [Risk]: impact [ ], trend [up/down/flat], action [ ], owner [ ]
2. [Risk]: ...

Regulatory changes affecting us
- [Law or guidance], effective [date], what we're doing: [ ]

Decisions or support needed
- [Ask], by [date]

Reporting to leadership

Boards and executives want three things: how much AI we use, where the real risk is, and what they need to decide. Give them that on one page and keep the detail in an appendix.

• Lead with the headline. One sentence on overall posture, then the single most important item.
• Show trends, not just counts. "Open high risks fell from 6 to 3" says more than "3 open risks."
• Translate risk into business terms: customer impact, legal exposure, cost, delay.
• Name owners and dates for every top risk.
• End with the asks: decisions, budget or support needed.
• Be consistent quarter to quarter, so leaders can compare.

The one-page report template is in Templates.

Resources

The sources practitioners use most, grouped by what you'd reach for them for. Start with the three marked "Start here."

Frameworks and standards

Laws and official sources

News and legal trackers

Incidents and risk databases

Other playbooks to compare

Career and community

Governance platforms

Larger companies run inventories and assessments in software like these. Smaller ones use spreadsheets and documents.

Glossary

Plain definitions of the terms that come up most in governance work.

ADMT

Automated decisionmaking technology. California's term for technology that replaces or substantially replaces human decisions. CCPA regulations

Adverse action notice

The notice a lender must send when it denies credit or changes terms, giving the specific principal reasons. ECOA / Reg B

Adverse impact

A substantially lower selection rate for a protected group. Usually screened with the four-fifths rule.

AEDT

Automated employment decision tool. NYC's term for a tool that substantially assists or replaces discretionary hiring or promotion decisions. NYC LL 144

AI inventory

A register of the AI systems an organization uses, with owner, purpose, data and risk tier for each.

AI literacy

Enough understanding of AI for staff to use it appropriately. Required of providers and deployers. EU AI Act Art. 4

Bias audit

An independent evaluation of a tool's selection rates and impact ratios by group.

Confabulation

NIST's term for confident but false generative AI output, often called hallucination.

Controller

The organization that decides why and how personal data is processed. It carries the main GDPR duties. GDPR

Deployer

An organization that uses an AI system under its own authority, such as a company running a vendor's screening or chatbot tool. EU AI Act

Disparate impact

A neutral-looking practice that disproportionately harms a protected group. Unlawful in many settings unless justified. Title VII, ECOA

Disparate treatment

Treating someone differently because of a protected characteristic, intentionally.

DPIA

Data protection impact assessment, required for processing likely to be high-risk to people. GDPR Art. 35

Drift

When real-world data or behavior shifts away from what a model was built and tested on, degrading results.

Four-fifths rule

A group's selection rate under 80% of the highest group's rate is treated as evidence of adverse impact. A rule of thumb, not a safe harbor. UGESP

Excessive agency

When an AI agent has more permissions or autonomy than its job needs, so a mistake or attack can do real damage. OWASP

FRIA

Fundamental rights impact assessment, required of certain deployers of high-risk AI. EU AI Act Art. 27

GPAI model

General-purpose AI model: one that can do a wide range of tasks and is built into many products. EU AI Act

High-risk AI system

The EU AI Act category with the heaviest duties, including AI used in employment, education, credit and essential services. EU AI Act Annex III

Human in the loop

A person reviews or approves the AI's output before it takes effect. Only meaningful if they have the time, information and authority to disagree.

Human oversight

Measures that let trained people monitor, understand and override an AI system's outputs.

Impact assessment

A structured review of a system's purpose, the people it affects, its risks and its controls, before and during use.

Model card

A short document describing a model's intended use, performance, limits and testing. System cards do the same for a whole product.

Least privilege

Giving a person, system or agent only the access it needs, and nothing more.

Personal data breach

A security breach leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. GDPR Art. 4

Processor

An organization that processes personal data on a controller's behalf, such as a vendor. GDPR

Prompt injection

Instructions hidden in input, such as a document, email or web page, that hijack an AI model's behavior.

Provider

An organization that develops an AI system, or has it developed, and puts it on the market under its own name. EU AI Act

RACI

A chart of who is Responsible, Accountable, Consulted and Informed for each activity.

RAG

Retrieval-augmented generation: an AI system that looks up documents and uses them to answer. Grounds answers, but needs access controls on what it can retrieve.

Red-teaming

Structured attempts to make an AI system fail or misbehave, to find weaknesses before others do.

Selection rate

The share of a group that gets the positive outcome: selected ÷ total.

Shadow AI

AI tools employees use without the organization's knowledge or approval.

Special category data

Sensitive personal data with stricter rules, such as racial or ethnic origin, health, religion and sexual orientation. GDPR Art. 9

Supervisory authority

A national GDPR regulator, such as Ireland's Data Protection Commission.

Key sources: Orrick (EU Digital Omnibus), SIG (EU AI Act timeline), McDermott (Colorado), Nelson Mullins (IL, NYC, CT), Wiley (chatbot laws), Skadden (California), LiveCompliance (healthcare), Actuary.info (insurance), NIST AI RMF.