Image: Unsplash, used under the Unsplash License.
TL;DR: A 12-field AI register template for tracking every AI system you use. It maps to NIST AI RMF GOVERN 1.6 (inventory AI systems), Colorado SB 26-189''s rule to keep compliance records for at least 3 years, and the EU AI Act duties that apply to high-risk systems from December 2, 2027. Copy the table, fill in one row per system, and review quarterly.
Organisations using AI are expected to know what they have deployed. That sounds obvious, but in practice most small teams cannot name every AI system they run, let alone explain what data each one processes or who is accountable when something goes wrong.
An AI register fixes that. It is a structured record of every AI system your organisation uses, with enough detail to demonstrate governance to auditors, regulators, and your own leadership. It is not a lengthy report. A single table, maintained consistently, is enough for most small teams.
The deadlines are real. Colorado SB 26-189 applies from January 1, 2027 and requires developers and deployers to keep records showing compliance for at least 3 years. The EU AI Act's rules for Annex III high-risk systems apply from December 2, 2027, after the Digital Omnibus on AI (Regulation (EU) 2026/1744) moved them from August 2, 2026. A register started now gives you a dated history before either date.
Who needs an AI register
EU AI Act providers and deployers of high-risk systems. Providers must draw up technical documentation before the system is placed on the market (Article 11). Deployers of high-risk systems must use them according to the instructions, assign human oversight, and keep the logs the system generates for at least six months (Article 26). An AI register is where a deployer records which systems fall in scope and who owns each one.
Colorado SB 26-189 developers and deployers. From January 1, 2027, both must retain records necessary to demonstrate compliance with the act for at least 3 years. A register with dated entries and archived rows is a simple way to keep part of that record.
NIST AI RMF adopters. GOVERN 1.6 in the NIST AI RMF reads: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." A register is that mechanism.
Any team wanting governance clarity. Even if none of the above frameworks apply to you today, a register answers the questions your legal team, your cyber insurer, and your largest customers will ask: what AI do you use, what decisions does it influence, and who is responsible?
The 12-field AI register template
Copy the table below into a shared document, wiki page, or spreadsheet. Add one row per AI system. The example row shows a fictional hiring-screening tool to illustrate how the fields work together.
| Field | Example entry |
|---|---|
| System name | TalentScore CV Screener |
| Vendor / provider | TalentScore Ltd |
| Version / model | v3.2 (GPT-4o fine-tune) |
| Purpose / use case | Rank job applicants by CV relevance before human shortlisting |
| Risk classification | High (EU AI Act Annex III, employment category) |
| Data inputs | Name, address, work history, education (CV text); no special category data |
| Output type | Ranked recommendation (score 0-100 per applicant) |
| Human oversight mechanism | Recruiter reviews all candidates within 10% of top score; no auto-rejection |
| Last review date | 2026-04-15 |
| Responsible owner | Head of People (J. Patel) |
| Compliance framework mapping | EU AI Act Annex III point 4 and Art. 26 / NIST AI RMF GOVERN 1.6 / UK Equality Act 2010 |
| Notes / action items | DPA signed 2025-11; bias audit due Q3 2026 |
Blank template (copy this)
| System name | Vendor / provider | Version / model | Purpose / use case | Risk classification | Data inputs | Output type | Human oversight mechanism | Last review date | Responsible owner | Compliance framework mapping | Notes / action items |
|---|---|---|---|---|---|---|---|---|---|---|---|
Image: Unsplash, used under the Unsplash License.
Field-by-field explanation
System name. The name your team uses internally. If the tool has a product name and an internal nickname, note both. Consistency here prevents duplicate entries appearing under different names during an audit.
Vendor / provider. The organisation that built or supplies the system. For open-source models you host yourself, record the model name and the repository or source. This field is essential for vendor risk management and data processing agreement tracking.
Version / model. AI systems change. A tool that was low-risk on version 2.0 may process different data on version 3.0. Recording the version at each review date lets you spot when a vendor update warrants a re-assessment.
Purpose / use case. One or two sentences describing what the system actually does in your organisation, not the vendor's marketing description. Be specific: "rank job applicants" rather than "assist with hiring".
Risk classification. Assign a tier using your chosen framework. Under the EU AI Act, high-risk systems are listed in Annex III and include employment screening, credit assessment, biometric identification, and several others. For internal purposes, a simple Low / Medium / High scale works for most teams, with High reserved for systems that influence significant decisions about individuals.
Data inputs. List every personal data category the system processes. This field links your AI register to your GDPR Article 30 records of processing activities. If the system processes special category data (health, biometric, racial or ethnic origin), note it here and flag for a data protection impact assessment if one has not been completed.
Output type. Describe what the system produces: a ranked list, a binary decision, a generated document, a risk score, a recommendation, or something else. This matters because regulators treat automated decisions differently from recommendations that a human must still act on.
Human oversight mechanism. How does a human review, override, or validate the system's output before it affects a person or a significant business decision? Be concrete. "Manager reviews" is not sufficient. "Manager reviews all outputs before action is taken, and can reject without providing a reason" is.
Last review date. The date you last verified that all fields in this row are accurate. A blank date means the entry has not been reviewed since it was created.
Responsible owner. The named person or role accountable for this system's governance. One name. Not a team, not a department. Someone who will respond when a regulator asks who is responsible.
Compliance framework mapping. List every framework or regulation this system is subject to. Common entries include EU AI Act Article 26 (deployers) or Article 11 (providers), NIST AI RMF, GDPR Article 22, UK Equality Act 2010, HIPAA (if health data is involved), and Colorado SB 26-189. This field makes it easy to pull all records relevant to a specific framework during an audit.
Notes / action items. Anything that does not fit elsewhere: contract renewal dates, pending audits, outstanding DPAs, known limitations, or planned changes. Date your notes so you can track what was known when.
How to use this template
Start with a single shared document. A Google Doc, a Notion page, or a Confluence table all work. You do not need dedicated software to begin. The goal is to have a record that exists, is findable, and is updated.
Add one row per system. If you have ten AI tools in use today, your register has ten rows. If fifteen of those tools are embedded in a single SaaS product you use (for example, AI writing suggestions in your CRM), decide whether to register the SaaS product as one entry or list each AI feature separately. For most small teams, one row per vendor product is enough.
Review the register quarterly. Set a recurring calendar event. Check whether any tool has changed version, whether any new tools have been adopted since the last review, and whether any oversight mechanisms described in the register are still actually in place.
Image: Unsplash, used under the Unsplash License.
Store the register with your data processing records. Your GDPR Article 30 Record of Processing Activities and your AI register cover overlapping ground. Keeping them in the same folder or document set makes audits faster and avoids inconsistencies between the two documents.
Archive rather than delete retired entries. Colorado SB 26-189 requires records showing compliance to be kept for at least 3 years. When you retire a system, move its row to an "archived" section with a retirement date rather than deleting it.
What frameworks require it
Image: Pexels, used under the Pexels License.
EU AI Act Articles 11 and 26 split the work: providers keep the technical documentation, and deployers of high-risk systems keep logs for at least six months, assign trained human oversight, and inform people affected by Annex III decisions. These rules apply to Annex III systems from December 2, 2027. An AI register is not the technical file, but it tells you which of your systems need one. (An earlier version of this page cited Article 70, which is about national competent authorities, not documentation.)
NIST AI RMF GOVERN 1.6 says mechanisms should be in place to inventory AI systems. The framework is voluntary, but customers and auditors use it as a reference, and an inventory is the first thing they ask for.
Colorado SB 26-189 requires developers and deployers of automated decision-making technology used in consequential decisions to keep compliance records for at least 3 years. Consequential decisions include education, employment, housing, financial or lending services, insurance, health-care services, and essential government services. A dated register with archived entries keeps part of that record in one place.
For the EU AI Act timeline, see the EU AI Act compliance checklist. For help classifying your systems before completing the register, the AI risk assessment tool walks through the Annex III criteria. If you are building your broader governance documentation, the AI acceptable use policy template and the NIST AI RMF implementation guide for small teams are natural next steps.
Completed example: what a filled AI register row looks like
Blank templates are easy to copy. Knowing what a fully completed row actually looks like is harder. The example below uses a fictional but realistic tool, a resume screening system, to show how every field should be populated in a register that would hold up to regulatory review.
| Field | Completed entry |
|---|---|
| System name | Resume Screener v2.3 |
| Vendor | HireIQ (OpenAI GPT-4o backbone) |
| Business owner | Head of Talent Acquisition |
| Risk classification | High (EU AI Act Annex III point 4 - employment decisions) |
| Use case | Rank incoming job applications by keyword match and suitability score (0-100) |
| Data processed | Applicant name, CV text, cover letter - no protected categories collected but inferred by model |
| Training data | HireIQ proprietary dataset; vendor has not disclosed demographic composition |
| Affected individuals | All job applicants for roles posted since March 2024 |
| Assessment completed | 2024-03-01, reviewed 2025-03-01 |
| Next review | 2026-06-01 |
| Human oversight | Hiring manager sees scores but is not shown ranking position; final selection requires manager approval |
| Regulatory obligations | EU AI Act Article 26 deployer obligations; Title VII adverse impact monitoring (four-fifths rule, 29 CFR 1607.4(D)); NYC Local Law 144 bias audit within one year before use |
| Issues flagged | Vendor declined to provide demographic composition of training data - flagged as gap, seeking alternative vendor |
The two columns that are most often left blank in real registers are training data composition and issues flagged. Those happen to be the two columns that regulators and auditors look at first. The training data field matters because discriminatory outcomes in hiring AI are frequently traceable to biased training data, and a vendor who cannot or will not describe the composition of their dataset is a vendor who cannot tell you whether your system produces fair outputs. The issues flagged column matters even more. A register where every row in that column is blank does not signal that everything is fine. It usually means nobody is looking.
What practitioners say
A May 2026 r/cybersecurity post, "Implementing ISO 42001: where do you even start?", put the register first. Its author wrote that the first problem is "a lack of knowledge surrounding where AI is present in businesses today," listing employees using ChatGPT without permission, copilots embedded in SaaS products, and vendors adding AI without announcement. The conclusion: "Without keeping track of your AI assets, it will be difficult to implement ISO 42001."
Our take
Based on the framework text cited above, no law makes you keep a document called an AI register. What the rules do require (Colorado's 3-year compliance records, the EU AI Act's deployer logs and oversight assignments, NIST's inventory recommendation) is very hard to produce without one. Start with the 12 fields, fill in owner and last review date for every row, and treat an empty issues column as a reason to look harder, not a pass.
How we checked this
On October 8, 2026 we checked every legal reference on this page against the source: the EU AI Act on EUR-Lex (Articles 11, 26, 70, Annex III), the Digital Omnibus on AI (Regulation (EU) 2026/1744), the Colorado legislature's SB 26-189 summary, the NIST AI RMF core on the NIST AI Resource Center, 29 CFR 1607.4 on the eCFR, NYC's Local Law 144 page, and the GDPR on EUR-Lex. The old page cited Article 70 (national authorities) as the documentation rule, NIST GOVERN 1.2 (trustworthy AI characteristics) as the inventory control, and an August 2026 EU deadline that has moved. All three are corrected. We removed an unsourced claim about what enforcement staff say about blank registers.
Last reviewed: October 8, 2026.
Related reading
- AI project intake checklist: 6-phase workflow for approving new AI tools
- EU AI Act compliance checklist
- AI acceptable use policy template
- Colorado AI Act SB 26-189 employer guide 2027
- NIST AI RMF implementation guide for small teams
- EU AI Act high-risk AI documentation templates for August 2026 (Articles
- One documentation set for EU AI Act, NIST AI RMF, and Texas TRAIGA
