TL;DR: A 12-field AI register template that satisfies EU AI Act Article 70 documentation requirements, Colorado SB 26-189 three-year retention rules, and NIST AI RMF Govern 1.2. Copy the markdown table below, 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 urgency has increased. EU AI Act Article 70 obligations for high-risk AI system documentation apply from August 2026. Colorado SB 26-189 requires deployers to retain records of algorithmic decision-making systems for at least three years. If you have not started your register yet, now is the right moment.
Who needs an AI register
EU AI Act Article 70 deployers and providers. If you deploy a high-risk AI system, as defined by Annex III of the EU AI Act, you must maintain technical documentation covering the system's purpose, risk controls, data inputs, and human oversight arrangements. An AI register is the practical home for that documentation.
Colorado SB 26-189 deployers. Colorado's AI Act requires deployers of algorithmic decision-making systems to retain records for three years. A register with dated entries and archived rows satisfies that retention requirement without building a separate filing system.
NIST AI RMF adopters. The NIST AI RMF Govern function, specifically Govern 1.2, identifies an AI system inventory as a foundational control. Without a register, you cannot map risk posture, assign accountability, or demonstrate governance maturity to enterprise clients.
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 Art. 70 / NIST AI RMF Govern 1.2 / 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
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 70, 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. A 30-minute review is enough for a team using fewer than 20 AI systems. 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.
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 three-year retention of records relating to algorithmic decision-making. When you retire a system, move its row to an "archived" section with a retirement date rather than deleting it.
What frameworks require it
EU AI Act Article 70 requires providers and deployers of high-risk AI systems to maintain technical documentation that regulators can request. The August 2026 deadline for high-risk system obligations means organisations should have their documentation in place before that date. An AI register is not the full extent of Article 70 documentation, but it is the practical starting point that organises the information you need to produce more detailed technical files.
NIST AI RMF Govern 1.2 establishes that organisations should maintain an inventory of AI systems as a governance baseline. Without a register, you cannot assign accountability, prioritise risk management effort, or demonstrate governance maturity in procurement questionnaires or SOC 2 audits.
Colorado SB 26-189 requires deployers of consequential decision-making systems to retain records for at least three years. That retention obligation applies to systems making or informing decisions about employment, education, lending, insurance, and housing. A dated AI register with archived entries satisfies that requirement without building a separate filing system.
For more on the August 2026 deadline, see the EU AI Act August 2026 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; EEOC adverse impact monitoring required; NYC Local Law 144 bias audit annually |
| 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 signals that nobody is looking. Enforcement staff who have reviewed AI governance records describe blank issues columns as a red flag, not reassurance. If your register has no issues flagged across 20 systems over two years, the honest interpretation is that the register is not being taken seriously.
