How to build an AI register
Before I write an AI policy, I want a list of the AI the business actually uses. The meeting assistant in a video tool may matter just as much as a model built in-house. If it captures sensitive discussions, someone needs to own the decision to use it.
An AI register brings those uses into one place. It gives the business a starting point for deciding what to assess, what to approve, and what needs closer attention.
Record the use as well as the product.
Include AI the organization built, bought, received as a feature in existing software, or adopted informally. Look for outputs that people rely on: drafts, summaries, rankings, recommendations, and predictions.
One product can support several uses with different risks. An assistant drafting an internal announcement and the same assistant summarizing employee complaints should not disappear into one vague row labelled “AI tool.”
Ask each team what it uses to write, summarize, screen, or predict. Compare the answers with vendor records, expenses, and available sign-in logs, using your approved internal review process. Check whether vendors have added AI features since the software was purchased.
Keep the first version usable.
For each use, record the system name, purpose, business unit, accountable business owner, technical or vendor contact, and whether it is built, bought, embedded, or adopted by staff. Add the people affected, the types of information entered, approval status and a next review date.
It should be possible to look at a row and know whom to ask about the use. If you cannot, the ownership gap is itself something to resolve.
NIST AI RMF GOVERN 1.6 calls for mechanisms to inventory AI systems, with resources aligned to organizational risk priorities. The framework does not prescribe the scoring method below. This is a suggested method for deciding where to spend review effort.
Use a simple first assessment.
Score data sensitivity, autonomy, and impact on people from 1 to 3. For this example, use these anchors.
Data sensitivity: 1 for public or non-sensitive inputs; 2 for confidential business information or ordinary personal information; 3 for sensitive personal information or highly confidential material.
Autonomy: 1 when a person checks the output before any use; 2 when checks are selective or the output materially shapes a later decision; 3 when the system acts with little routine human review.
Impact on people: 1 for limited, readily corrected effects; 2 for meaningful effects with practical ways to correct or challenge them; 3 where an error could seriously affect employment, credit, services, or safety.
Add the scores: 3 to 5 is Low, 6 to 7 is Medium, and 8 to 9 is High. In this illustrative method, a use that materially influences a significant decision about a person is High regardless of its total. Record the reason for any override.
The score is a queueing aid. It is not an ISO or NIST requirement, a complete risk assessment, or a legal classification under the EU AI Act or any other law.
Two fictional entries.
A recruitment platform ranks applications for a hiring team. In this example, data scores 2, autonomy-2, and impact-3. The total is 7, but the hiring use triggers the High override. The owner needs to examine the criteria, human review, and how an applicant could challenge an error.
A team adopts a meeting-notes app and uses it for sensitive discussions. Data scores 3, autonomy-2, and impact-2: a Medium total of 7. Its unapproved use and uncertain access settings still need prompt attention. A Medium score is not permission to leave an active exposure unresolved.
These examples are fictional. They do not describe client findings or verified rows in a published workbook.
Set review dates and triggers
For an initial policy, you could propose reviews every six months for High, twelve for Medium and twenty-four for Low. These are illustrative intervals to adjust for your business, not deadlines set by the frameworks.
Do not wait for the calendar if the purpose, data, vendor, or level of automation changes, or an incident occurs. A new AI feature can change what an existing service does.
For High-priority uses, I would normally require an impact assessment before approval, with the detail proportionate to the use. Confirm any separate legal assessment requirements. Link the assessment and the approval decision to the register entry.
Give the register a place in ordinary work.
Assign someone to maintain it. Add an AI question to new-tool requests and vendor reviews. Ask owners to confirm entries when services change. Track overdue reviews and high-priority uses still awaiting assessment.
Start with one team and the software it already uses. You can improve the fields after the first review. A small register with named owners is something the business can work with.
For help setting up an AI register or reviewing AI-enabled vendors, visit sholahassan.com/contact
Source: NIST AI RMF Core, GOVERN 1.6: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
Comments