An AI governance checklist is a list of controls you can verify, each with an owner and evidence, that shows your company knows which teams call which AI models, with which data, and at what cost. This one has 12 checks in four groups for model API usage. Each check states what "done" looks like, who owns it and what an auditor would ask to see, and the groups map to the four functions of the NIST AI Risk Management Framework.
What this checklist covers
It is an operational checklist for model API usage: API keys, model access, data boundaries, spend and incident response. It does not cover bias and fairness testing, transparency and explainability, model validation or the impact of AI decisions on people. For those, use the NIST AI Risk Management Framework (AI RMF 1.0, released January 26, 2023) and its Generative AI Profile, NIST-AI-600-1, released July 26, 2024.
The 12 checks at a glance
How the checklist maps to the NIST AI RMF
The NIST AI RMF organizes AI risk management into four functions. The mapping below is approximate: each NIST function is broader than the three checks placed under it.
If your organization already reports against the NIST AI RMF as its AI governance framework, these 12 checks can sit under those four headings as the API-usage controls.
Group 1: Keys and identity (Govern)
1. Every key belongs to one project with a named owner
A key shared across five services can't be revoked without breaking all five. Scope keys to one project each, as in one project, one key.
- Done when: the key inventory lists a project and a named owner for every active key, and no key is used by more than one service.
- Owner: platform team.
- Evidence: the key inventory export, plus a sample of five services showing five different keys.
2. Offboarding revokes AI access the same day
The offboarded contractor's key is the most common gap. Add AI keys and console roles to the offboarding checklist next to email and SSO.
- Done when: the offboarding checklist has a line for AI keys and roles, and the last three leavers were processed within one business day.
- Owner: IT, with the platform team revoking keys.
- Evidence: the offboarding tickets for the last three leavers with revocation timestamps.
3. Sandbox is separate from production and has a fixed budget
Experiments run in their own project with their own key and a budget small enough that a runaway loop can't become a month-end surprise, for example USD 50 per team per month.
- Done when: no sandbox key can reach production budget, and every sandbox project has a fixed allocation.
- Owner: engineering managers.
- Evidence: the project list showing environment and budget for each project.
Group 2: Models and data boundaries (Map)
4. Each project has a model allowlist with a recorded reason
A support-summary project may only need Claude Haiku 4.5. Adding a more expensive model should be a ticket with a reason, and a call to a model outside the list should fail.
- Done when: every project has an explicit allowlist, and a test call to a model outside it returns an error.
- Owner: the project's tech lead, approved by the platform team.
- Evidence: allowlist export per project, change tickets, and the failed test call.
5. Data classes are mapped to permitted vendors and models
Engineers should not decide case by case whether customer records can go to an external model. A one-page table answers it: data class, permitted vendors or models, required preprocessing such as redaction.
- Done when: the table is approved, versioned, and each project is tagged with the highest data class it sends.
- Owner: security or privacy.
- Evidence: the signed table with its version date, and the project-to-data-class list.
6. Each vendor's data terms are recorded
Retention period, use of data for training and processing region differ between providers and between plans of the same provider. Record them per vendor and plan, with a link to the terms version you reviewed.
- Done when: every AI vendor and plan in use has a row in the register, reviewed in the last 12 months.
- Owner: legal or procurement.
- Evidence: the vendor register with links and review dates.
Group 3: Spend and attribution (Measure)
7. Every project has a hard spending limit
The first sign of an overrun should come from the limit, before the invoice arrives. Name the person who decides what happens when a project reaches it: top up, wait, or switch to a smaller model.
- Done when: every production and sandbox project has a configured limit and a named budget owner.
- Owner: the budget owner for each project.
- Evidence: the limit configuration, and a record of what happened the last time a project hit its limit.
8. Each request can be traced, and retention matches your audit period
For any call you should be able to name the project, key, model, status and token counts. Check how long your tooling keeps those records; if it is shorter than the period your auditors sample, export them on a schedule.
- Done when: a request ID from an application log can be traced to its record, and the retention or export period is written down.
- Owner: platform team.
- Evidence: one request traced end to end, and the documented retention or export job.
9. Spend is reconciled monthly by project
Convert usage from every provider into one unit and reconcile the invoice total against the sum of project usage. How to read your AI bill covers the line items.
- Done when: the monthly report ties the invoice to project totals, and any variance above an agreed threshold has a written explanation.
- Owner: finance, with data from the platform team.
- Evidence: the last three monthly reconciliations.
Group 4: Intake, incidents and review (Manage)
10. New AI services enter through one intake path
Checks 4 to 7 happen before the first key is issued: allowlist, data class, vendor terms, budget. Expense reports are the cross-check, since an AI charge without an intake ticket is shadow AI.
- Done when: every AI service added this quarter has an intake ticket, and the expense report review found no AI charges without one.
- Owner: platform team with procurement.
- Evidence: intake tickets and the expense review result.
11. A leaked-key runbook exists and was rehearsed
The runbook lists revoke, trace and reissue steps, plus who notifies whom. Rehearse it and time it.
- Done when: the runbook is published and was rehearsed in the last 12 months with time-to-revoke recorded.
- Owner: security on-call.
- Evidence: the runbook and the rehearsal record with timestamps.
12. Access is reviewed every quarter
Revoke keys with no traffic in 30 days, close projects without an owner and confirm the admin list.
- Done when: the review is signed off within two weeks of quarter end.
- Owner: platform team.
- Evidence: the signed review with the list of revoked keys and role changes.
Where to start by company size
Running this checklist on ATP Token
ATP Token covers the checks that live in the API path. Data classification (check 5) and vendor terms (check 6) remain your policy documents, and the intake, runbook and review processes (checks 10 to 12) remain your process. ATP supplies the records those processes use.
For check 8, the 7-day request log is a debugging view. If your audit period is longer, call the Console API's request logs endpoint on a schedule and keep the results in your own storage.
Set up a team with budget caps
