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 Annex III high-risk systems from December 2, 2027 (August 2, 2028 for high-risk AI in Annex I products). 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 without a written list it is easy to lose track of which AI systems are running, what data each one processes, and 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.
Prefer a file? Download the register as an Excel workbook (.xlsx), with a risk dropdown and the field guide on a second sheet, or as a Word document (.docx). Both are built from this page.
| 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 it gives you a published standard to point to when a customer or auditor asks how you track AI.
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 cover access to education, employment, housing, financial or lending services, insurance, health-care services, and essential government services and public benefits. 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 |
We'd fill two columns before any other: training data composition and issues flagged. A vendor who cannot or will not describe the composition of its training dataset cannot tell you whether the system's outputs are fair across groups, and that is the question a Title VII four-fifths check or a Local Law 144 bias audit will ask. An issues column that is blank in every row does not show that everything is fine. More often it means nobody is looking.
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 22, 2026 we re-checked every legal reference on this page against the source: the EU AI Act on EUR-Lex (Articles 11, 26, Annex III), the Digital Omnibus on AI (Regulation (EU) 2026/1744) on EUR-Lex, the Colorado legislature's SB 26-189 page (status: became law, signed act dated May 14, 2026), 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 Articles 22 and 30 of the GDPR on EUR-Lex. An October 8 review had already corrected the Article 70 citation (national authorities), the NIST GOVERN 1.2 citation and an August 2026 EU deadline that has moved.
Correction, October 22, 2026: an earlier version said the training data and issues columns are the ones "most often left blank in real registers" and the ones "regulators and auditors look at first", and that an inventory is "the first thing" customers and auditors ask for. We have no source for any of the three and removed them. The r/cybersecurity post we quoted on ISO 42001 has since been removed by the subreddit's moderators, so the quote is gone too. The list of Colorado consequential decisions now includes public benefits, as in the act's summary.
Correction, October 23, 2026: the summary at the top said the EU AI Act duties apply to high-risk systems from December 2, 2027. That date covers Annex III systems; for high-risk AI in products covered by Annex I, such as medical devices, they apply from August 2, 2028 (consolidated AI Act, Article 113).
Last reviewed: October 22, 2026.
Related reading
- Shadow AI policy template, with an approved-tool list that feeds this register
- AI risk register template: scored and pre-filled, one row per risk
- 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 compliance: what SB 26-189 requires in 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
- FCA AI guidance: good practice checklist for smaller firms
