Written and maintained by CASRAI Editorial Board
Last updated
“AI governance best practices” gets searched a dozen different ways — “responsible AI governance framework,” “enterprise AI governance checklist,” “AI compliance program best practices,” “how to govern AI use in an organization,” “AI risk management best practices.” They’re all the same underlying question: what does an organization actually have to stand up, not just read about, to govern how it builds or deploys AI responsibly. CASRAI’s frontier-ai-safety cluster already has a deep-dive guide for each individual piece of the answer. This page is the checklist that ties them together in the order most organizations actually build them, so you can work down it once instead of hunting across six separate pages for the next step.
None of this is specific to frontier model developers. A hospital deploying a third-party clinical-documentation AI, a university standing up an AI-acceptable-use policy for students and staff, and a frontier lab shipping a new model are all doing versions of the same six things below — the scale and the specific regulatory triggers differ, but the structure doesn’t.
1. Stand up a governance committee
Before anything gets written down, decide who has the authority to approve, block, or escalate a given AI use case. Skipping this step is the most common failure pattern: a policy document exists, a risk register exists, but nobody can say who actually has sign-off authority for a specific AI deployment sitting in front of them today. Organizations use different bodies for this — a dedicated AI governance board, an existing ethics committee stretched to cover AI, or the audit committee folding AI oversight into its existing remit — and the right choice depends on decision authority, not just composition. CASRAI’s AI governance board vs. ethics committee vs. audit committee comparison walks through which body typically holds sign-off authority for deployment decisions versus which one runs ethics review.
Whichever body you choose, name specific accountable decision-makers for specific decision types rather than leaving “the committee” as a diffuse, unassignable owner — the same principle California’s SB 53 encodes in law for frontier developers specifically. CASRAI tracks this as its own element, accountable decision-maker, in NIKOLAI’s commitments and governance track (N9).
2. Adopt a governance framework
A committee needs a structure to apply consistently, not case-by-case judgment calls that don’t generalize between reviewers. That structure is the governance framework: risk tiers, what triggers each tier, and the escalation path when a use case crosses a threshold. CASRAI’s AI governance framework template covers the four components — council, tiers, escalation, review cadence — in the detail this checklist item deliberately skips.
3. Document a usage policy
The framework governs how AI use cases get evaluated; the usage policy is the plain-language document that tells every employee what’s allowed and what isn’t before they ever reach a governance review. Acceptable-use and prohibited-use clauses, disclosure requirements when AI is used in a work product, and what happens when the policy is violated all belong here. CASRAI’s responsible AI usage policy template lays out a working structure for both clause types rather than starting from a blank page.
4. Run risk assessments and keep a risk register
Once the committee and framework exist, individual AI use cases need to actually be assessed against them — and the assessments need somewhere to live where they can be tracked, revisited, and rolled up across teams rather than existing in whichever reviewer’s inbox last touched them. CASRAI’s AI risk assessment framework and risk register guide gives a starting template for the register itself, including the mitigations — access controls, monitoring, red-teaming, output filtering, and the like — that get logged against each risk. CASRAI tracks this category of mitigation as its own safeguard element, part of NIKOLAI’s mitigations and security track (N6), alongside adjacent fields like coverage level and robustness level that describe how strong a given safeguard actually is.
5. Establish an audit function
A risk register that’s never independently checked tends to drift — entries get closed by the same team that opened them, findings go unverified, and the register stops reflecting reality. An internal audit function is what keeps the rest of the program honest: it checks whether the committee’s decisions, the framework’s tiering, and the register’s entries actually match what’s happening in production. CASRAI’s internal audit function guide covers what this function does, how it differs from incident response and from third-party evaluation, and where it typically reports.
6. Prepare for incident reporting
The last piece is the one organizations most often build reactively instead of in advance: what happens when something goes wrong. Depending on jurisdiction and the kind of AI system involved, “prepare” can mean a specific statutory clock. California’s SB 53, for example, sets a default 15-day reporting duty to the Office of Emergency Services once a qualifying critical safety incident is discovered, with a separate, faster 24-hour duty for the most urgent category. Knowing which clock applies, who internally gets notified first, and what a compliant report has to contain is not something to figure out for the first time during an actual incident. CASRAI’s SB 53 critical safety incident reporting guide covers the statutory detail. NIKOLAI defines this reporting structure as its own incidents track (N7), including a dedicated incident-reporting-deadline element for tracking which clock applies to which incident type.
A shared vocabulary underneath every item on this checklist
Every practice above assumes a shared vocabulary for AI safety and governance terms — that’s what NIKOLAI, CASRAI’s own unendorsed dictionary, provides. A committee, a framework, a policy, a register, an audit function, and an incident-reporting process only work together if “safeguard,” “accountable decision-maker,” and “critical safety incident” mean the same thing to everyone using them, across teams and across the outside frameworks and statutes your program has to satisfy. NIKOLAI is CASRAI’s own reference vocabulary for that purpose — currently at version nikolai-v0.2, defining 64 elements across ten tracks, including the accountable-decision-maker, safeguard, and incident-reporting-deadline elements linked above. It is not a standard, and no lab, regulator, or evaluator has endorsed it; every crosswalk row NIKOLAI publishes against another organization’s published usage is a shadow mapping unless that organization has explicitly confirmed it through NIKOLAI’s own Mapping Declarations process. If your organization wants to confirm how these terms map to your own governance program’s vocabulary rather than relying on CASRAI’s shadow mapping, Mapping Declarations is where that gets done.
FAQ
Is there one official “AI governance best practices” framework we should just adopt wholesale?
No single framework covers all six pieces above end to end, and treating any one external framework as sufficient on its own is a common mistake. NIST’s AI RMF, for example, organizes guidance around four functions — Govern, Map, Measure, Manage — that map loosely onto the committee/framework, risk-assessment, and audit pieces of this checklist, but it doesn’t specify a usage policy or an incident-reporting clock the way a statute like SB 53 does. Most working programs combine a general framework with the jurisdiction- and sector-specific obligations that actually apply to them.
Do we need all six of these before we’re “covered”?
It depends what “covered” means for your organization. A committee with no documented framework behind it tends to make inconsistent, unrepeatable decisions; a framework nobody enforces is just a document. Incident reporting is the item most often skipped until it’s legally mandatory — but if any part of your organization touches a jurisdiction with a binding incident-reporting statute, that piece isn’t optional regardless of how mature the rest of the program is.
How is this checklist different from the AI governance framework template guide?
This page is the roundup: six practices in the order most organizations build them, each linking to CASRAI’s deep-dive guide on that specific piece. The framework template guide is one of those six deep dives — it goes into the council/tiers/escalation/cadence structure in the detail this page deliberately leaves out.
Does NIKOLAI replace our own internal policy vocabulary?
No. NIKOLAI is a reference vocabulary, not a policy template or a governance tool itself — it doesn’t run assessments, approve use cases, or file incident reports. It exists so that terms like “safeguard” or “accountable decision-maker” have a consistent, crosswalked definition your committee, your framework, and your incident-reporting process can all point to, which is a narrower and different job than the six practices above.
Where should a team with none of this in place actually start?
Start with item 1. A governance committee with named accountable decision-makers is the prerequisite for the other five items to mean anything — a framework, policy, risk register, audit function, or incident-reporting process all need someone with actual authority to own and enforce them.
