A checklist for working out where an AI governance program actually stands. Every item is a statement that is either true today or is not, which makes it usable in a meeting in a way a maturity score is not.
It is derived from the domains in the AI governance framework and informed by the NIST AI Risk Management Framework and the GAO AI Accountability Framework. Both are voluntary guidance. It is LABUSA's checklist rather than either of theirs, and completing it does not make an organization compliant with anything.
How to use it
Answer each item yes or no, with no partial credit. Where the honest answer is "for some systems", the answer is no, because an item that holds for some systems and not others is exactly the gap the checklist exists to find.
Record who answered and when. Then count the noes rather than the yeses: the noes are the work.
Expect a first pass to produce a lot of noes. An organization that has never run this deliberately typically answers yes to between six and twelve items, and the useful output is the ordering rather than the total.
What this checklist is not
It is not a compliance instrument. Nothing here maps to a legal obligation, and answering yes to every item does not make an organization compliant with any statute, regulation or contract. Where an external obligation applies to you, it applies whatever this list says, and establishing which ones apply is a question for counsel rather than for a checklist.
It is not a maturity model. There is no score, no level and no target, because a number invites an organization to optimise the number. Two organizations answering yes to the same count of items can be in entirely different positions depending on which items they are.
It is not a substitute for assessing individual systems. The checklist establishes whether the machinery exists; AI risk assessment is how a specific use of a specific system gets a decision.
Leadership
- A named person is accountable for AI decisions at executive level.
- That person has declined at least one request, or would be willing to.
- There is a documented escalation route for decisions the owner cannot make alone.
- The governing body has been told what the organization's AI position is.
Inventory
- A written inventory of AI systems in use exists.
- It includes AI features inside products bought for other purposes.
- It includes tools staff use that the organization does not pay for.
- It has a named maintainer and a visible last-reviewed date.
- It was updated within the last six months.
Policy
- A written acceptable-use position exists and staff can find it.
- It states what is permitted before it states what is prohibited.
- A data rule states which categories of information may not be entered into an AI system.
- A member of staff could apply that rule to a specific tool and dataset without asking anyone.
- The policy set was reviewed within the last twelve months.
Risk
- A risk classification scheme exists and is written down.
- It sorts by consequence to a person rather than by technology or vendor.
- Every system on the inventory has been classified.
- Unclassified systems default to the middle tier rather than to no oversight.
- Residual risk is recorded and accepted by a named person.
Data
- You know what data reaches each AI system, including retrieved and attached content.
- You know where that data is processed geographically.
- Retention periods are known and, where possible, set deliberately.
- You know which suppliers may use your content to train a model, and it is in writing.
Privacy
- Someone with privacy responsibility has reviewed the systems handling personal data.
- Personal data entering AI systems is covered by your existing privacy notices.
- You can locate and, where required, delete personal data held in or by an AI system.
Security
- AI systems authenticate through your identity provider rather than separately.
- You know what each AI system can reach, and that it inherits user permissions.
- Access to AI systems is reviewed on the same cycle as other access.
- Use of AI systems is logged sufficiently to answer a question after the fact.
Vendors
- AI suppliers have been asked the training, retention and subprocessor questions in writing.
- Contract terms cover notice of a material model or terms change.
- Incident notification has a timeframe attached rather than being an undertaking.
- Existing suppliers who added AI features have been reviewed, not only new ones.
Testing
- Each system was checked against what it is actually used for before deployment.
- Someone can state how you would know if performance degraded.
- Evidence of that check is retained.
Human oversight
- It is written down where a person must review output before it takes effect.
- The threshold is keyed to consequence to a person rather than left to judgment.
- Reviewers have the information they need to disagree with an output.
- Reviewers have the authority to overturn one, in practice and not only on paper.
Monitoring
- Every consequential system has a review date rather than an open-ended approval.
- A trigger list exists covering model change, terms change and default-on capability.
- Somebody owns watching for those triggers.
- At least one system has actually been reassessed.
Incidents
- What counts as an AI incident is defined, and includes a wrong output that reached someone.
- There is a route to report one, and staff know it.
- Incidents are recorded rather than handled informally.
Documentation
- For each approved system you can show who approved it, when, and on what basis.
- Declined requests are recorded with a reason.
- The record would satisfy someone examining it a year later who was not there.
Training
- Staff have been told what is approved and where to ask, in a place they already look.
- The statement is current with the approved list.
- New joiners encounter it.
Continuous improvement
- A review cadence is set for the governance program itself, not only for systems.
- Something has changed as a result of a review.
- Lessons from one assessment are consulted before the next.
Scope it before you start
Decide up front what you are answering for. An organization with autonomous business units, a school district with individual schools, or a group with subsidiaries will get a misleading picture from a single pass, because the honest answer to most items differs by unit.
Run it per unit where governance is genuinely devolved, and centrally where it is not. If you are unsure which you are, that uncertainty is itself the first finding, and it usually resolves the moment somebody asks who would approve a new AI tool in the smaller unit.
Two practical notes on running the session. Answer it with the people who would actually know, which is usually a mix of technology, whoever handles privacy or records, and one or two people who use the tools daily. Answering it alone produces a confident set of yeses that the first system owner you ask will contradict.
And answer it about the organization as it is rather than as the policy describes it. The gap between the two is frequently the most useful thing the exercise produces.
Reading the result
Three patterns come up repeatedly, and each has a different first move.
Noes concentrated in inventory and policy. The program has not started. Begin at step two of the ten-step sequence, and do not write policy first.
Yeses in policy, noes in monitoring and documentation. The common shape. Governance was established as a project and never became an operation. The fix is review dates, trigger ownership and a record, not more policy.
Yeses everywhere except human oversight and incidents. Usually a technically strong organization that has treated AI as a systems question. The missing items concern people and consequences, and they are the ones a governing body will ask about first.
One caution about the third pattern. It is tempting to read a high count as being nearly finished, and the remaining items as tidying. They are not. Human oversight and incident handling are where governance either protects a real person or fails to, and they are also the two areas that cannot be retrofitted quickly after something has gone wrong.
Whatever the pattern, take no more than three noes into the next quarter. A gap list of forty items produces no action; a gap list of three produces three closed gaps and a shorter list next time.
Public bodies should also work through the four additional constraints in AI governance for public-sector organizations. Smaller organizations may find AI governance for small and midsize businesses a better-sized starting point than this list.
LABUSA runs this assessment with organizations and produces the gap list with an order attached, which is the part that is hard to do for yourself. If you would like the result reviewed with someone, get in touch, or read how our LABUSA approaches AI governance.