This article summarises publicly available guidance from regulators and official sources. It is general educational information only and does not constitute legal or professional advice. Requirements vary by jurisdiction. Consult your regional authority or a qualified professional for advice specific to your situation.
An AI register can look like a simple software list until someone tries to use it to answer a real question. It is normal for a first draft to contain tool names but omit who owns each use, what information enters the system, where that information goes, or when anyone last checked the arrangement. This reference provides a usable starting template and explains what every column contributes.
In short: An AI register is a structured record of the AI systems a business uses, tests or has retired. The strongest version records purpose, ownership, people and data affected, human oversight, risk work and review status. Some fields reflect named regulatory or framework guidance. Others are practical additions that make the register useful. No single reviewed authority prescribes this exact spreadsheet for every business.
AI register template: the complete starter sheet
The following header row can be copied into a spreadsheet, database or governance platform. One row represents one distinct AI use, not necessarily one vendor. For example, an AI assistant used for marketing drafts and customer complaint analysis may warrant two rows because the data, affected people and review controls differ.
Register ID,AI system or tool,Provider,Use case and intended purpose,Business owner,Technical or admin contact,Teams and users,Affected people,Status,Start date,Input data,Output and decision role,Human oversight,Integrations and data flow,Hosting and transfer locations,Account contract and plan,Provider training and retention settings,Risk classification and assessment link,Controls restrictions and incidents,Last review and next review
A lightweight register can start with the first ten fields. The remaining fields become more valuable when a system handles personal or confidential information, influences decisions about people, connects to other business systems or becomes difficult to replace.
The template uses three evidence labels:
- Framework-backed: a named framework expressly supports maintaining this type of record.
- Authority-linked: a regulator's guidance makes the information relevant to demonstrating or examining a stated issue.
- Operational: an NTKAI editorial addition that helps a business run the register. It is not presented as a general legal requirement.
What each identity and ownership column records
| Column | What the field records | Why it is there | Basis |
|---|---|---|---|
| Register ID | A stable internal identifier, such as AI-014 | Names and suppliers change. A stable ID keeps assessments, incidents and approvals connected to the same record. | Operational |
| AI system or tool | Product name plus the relevant feature or model | A broad suite may contain several AI functions with different purposes and risks. Naming the feature prevents an entry such as “Microsoft” or “CRM” from hiding the actual use. | Operational |
| Provider | The organisation supplying or operating the system | This links the entry to contracts, privacy terms, security material and vendor reviews. | Operational |
| Business owner | The role accountable for the business use | A tool without an owner is difficult to review, restrict or retire. NIST's AI Risk Management Framework Playbook asks who is responsible for maintaining inventory details and recommends assigning an individual or team. | Framework-backed by NIST Govern 1.6 |
| Technical or admin contact | The person or service controlling accounts, settings and integrations | The business owner may understand the workflow while another person controls access and configuration. Separating the roles shortens investigation and change work. | Operational |
NIST describes an AI system inventory as an organised database of artefacts relating to a system or model. Its examples include documentation, incident plans, data dictionaries and contact details. The framework is voluntary, so its inventory guidance is a governance reference rather than a universal US legal obligation. NIST describes the voluntary status of the AI RMF.
What the use and people columns reveal
| Column | What the field records | Why it is there | Basis |
|---|---|---|---|
| Use case and intended purpose | The specific task, outcome and boundary of the use | “Writing” is too broad. “Drafting product descriptions from approved catalogue data, with staff approval before publication” makes the use reviewable. NIST Map 1.4 calls for the business value or context of use to be defined. | Framework-backed by the NIST AI RMF Core |
| Teams and users | Staff, contractors or functions with access | This supports licence administration, training decisions and investigation of unapproved use. | Operational |
| Affected people | Customers, applicants, workers, suppliers or members of the public whose information or interests may be affected | Users and affected people are not always the same. A recruitment team may operate a system whose outputs affect job applicants. | Operational, with jurisdiction-specific relevance |
| Status | Proposed, trial, approved, restricted, suspended or retired | A register that lists only approved systems cannot reveal trials, rejected products or systems awaiting removal. | Operational |
| Start date | The date the use entered trial or production | This establishes lifecycle context and helps distinguish a current deployment from a historic assessment. | Operational |
The intended-purpose field is the most important boundary in the register. A vendor name alone says almost nothing about how the business uses the product. Separate rows make sense when one product supports materially different workflows, data or affected groups.
What the data and decision columns expose
| Column | What the field records | Why it is there | Basis |
|---|---|---|---|
| Input data | Categories of information entered, uploaded, inferred or made accessible | This shows whether the use involves public material, internal documents, personal information, sensitive records, credentials or intellectual property. | Authority-linked in privacy contexts |
| Output and decision role | What the system produces and how the output enters a workflow | The field distinguishes a disposable draft from an output used to recommend, rank or decide something about a person. | Framework-backed and authority-linked |
| Human oversight | Who reviews outputs, what they check and whether they can change the result | “Human review” is too vague unless the reviewer, review point and authority to intervene are identifiable. | Authority-linked for some uses |
| Integrations and data flow | Connected systems, data sources, destinations and subcontracted services | This turns a product list into a map of where information enters and leaves the system. | Authority-linked in privacy and security contexts |
| Hosting and transfer locations | Known storage, processing and support-access locations, with a link to the evidence | This gives regional reviewers a place to examine international transfers without assuming that server location alone answers every legal question. | Authority-linked in relevant jurisdictions |
The data field works best as a controlled description rather than a copy of actual records. For example, “customer contact details and support transcripts” is useful register content. Pasting customer names or support conversations into the register creates another store of the information being governed.
“Human oversight” also benefits from precision. “Customer service manager checks proposed refunds above the internal threshold before the response is sent” records a control. “A human is involved” does not identify when review occurs or what the reviewer can change.
What the commercial, risk and lifecycle columns preserve
| Column | What the field records | Why it is there | Basis |
|---|---|---|---|
| Account, contract and plan | Account type, contracting entity, renewal reference and link to applicable terms | Free, consumer and business accounts may operate under different settings or terms. The register points to the evidence without duplicating a contract. | Operational |
| Provider training and retention settings | Whether submitted content may be used for provider training, available opt-outs, retention setting and evidence date | Provider terms and settings can change. Recording the evidence date is more useful than a permanent yes-or-no claim. | Authority-linked in privacy contexts |
| Risk classification and assessment link | Internal risk tier plus links to privacy, security, human-rights or other assessments | The register remains compact while the underlying reasoning stays available. A risk label without an assessment link is difficult to audit. | Framework-backed and jurisdiction-dependent |
| Controls, restrictions and incidents | Approved data, prohibited uses, access controls, known failures, complaints and links to incident records | This keeps operational boundaries and emerging evidence attached to the use. Detailed incident material can remain in a separate restricted system. | Framework-backed and operational |
| Last review and next review | The date, reviewer, outcome and planned review point | These fields reveal stale entries and create a visible maintenance cycle. NIST Govern 1.5 refers to ongoing monitoring, periodic review and documented responsibilities. | Framework-backed by the NIST AI RMF Core |
A register is an index, not a replacement for every governance document. Contracts, impact assessments, security reviews and incident reports can remain in their normal repositories, with stable links recorded in the relevant row.
Australian annex: why accountability and cross-border fields matter
For organisations within the scope of Australian privacy law, the accountability, data-flow and overseas-access fields provide a place to record facts raised by the national privacy regulator's AI guidance. They are not proof that a use complies with the law.
The Office of the Australian Information Commissioner says organisations selecting commercially available AI products should examine intended use, human oversight, privacy and security risks, who can access input or generated personal information, data flows and relevant product terms or settings. Its guidance also discusses policies, monitoring, training and transparency. Those topics support the template's purpose, owner, input-data, access, oversight, settings and review columns. Read the OAIC guidance on commercially available AI products.
The OAIC's APP 1 guidance says an APP entity can consider keeping records of steps taken under its accountability practices. It also discusses transparent management of personal information and information about collection, holding and security practices. This supports keeping links to assessments, controls, notices and review evidence, but the guidance does not prescribe this exact AI register. Read the OAIC's APP 1 guidance.
The OAIC's APP 8 guidance addresses disclosures of personal information to overseas recipients, accountability and relevant exceptions. A “hosting and transfer locations” field creates a place to record known recipients, support access and evidence for later assessment. Server location by itself does not establish whether a disclosure has occurred, a distinction the OAIC discusses in its guidance. Read the OAIC's APP 8 guidance.
For a business outside Australia, these columns can remain as operational fields or be adapted to the applicable local framework. The Australian sources do not create obligations in other jurisdictions.
How the same register connects to EU, UK, US and Canadian guidance
European Union
An internal AI register is not the same thing as the EU database for high-risk AI systems. Article 49 of the EU AI Act establishes formal registration duties for specified providers and, in narrower circumstances, certain deployers. Article 71 describes the EU database, while Annex VIII lists information associated with formal registration. Read the consolidated EU AI Act.
For an internal register, fields for provider, intended purpose, status, risk classification and assessment links help preserve the facts needed to determine whether more specialised analysis is relevant. Where personal-data processing falls within GDPR record-keeping or impact-assessment provisions, links to those records can sit in the assessment field rather than being recreated. Read the GDPR, including Articles 30 and 35.
United Kingdom
The Information Commissioner's Office says AI accountability work should identify risks to people's data-protection rights. Its AI guidance discusses documenting impact assessments, roles, safeguards, technical measures and decisions about whether processing presents high risk. These topics support the affected-people, owner, data, controls and assessment-link fields. Read the ICO guidance on AI accountability and governance.
The ICO identifies its separate AI and data protection risk toolkit as practical support for organisations examining risks to individuals. The register can link to a completed assessment or toolkit output, but a register row is not itself a data protection impact assessment. Open the ICO AI and data protection risk toolkit.
United States
The NIST AI RMF is voluntary, not a general federal register mandate. Its Govern 1.6 playbook expressly discusses AI system inventories, responsible maintainers, inventory scope and attributes such as documentation, data dictionaries, contacts and incident response plans. The core template therefore treats owner, purpose, status, documentation and incident links as framework-backed fields. Read NIST's Govern playbook.
Sector rules, state laws, contracts and procurement requirements may add different records. The register provides an index for that evidence but does not decide which regime applies.
Canada
Canada's federal, provincial and territorial privacy commissioners' joint principles for generative AI call for defined governance roles, impact assessments, demonstrable accountability and regular reassessment. Those principles support fields for ownership, affected people, data, assessment links and review dates when generative AI handles personal information. Read the Canadian privacy regulators' joint principles.
The principles are guidance from privacy authorities, not a universal specification for an AI register. Applicable federal, provincial and sector requirements require separate assessment.
Where regulator and framework guidance stops
None of the primary sources reviewed specifies this exact twenty-column template for every SMB in every jurisdiction. NIST expressly presents a voluntary framework. Privacy regulators discuss accountability, data handling and impact assessment within their respective remits. The EU AI Act's formal registration provisions apply to defined roles and system categories rather than every ordinary internal use of AI.
The choice of spreadsheet, review frequency, internal risk labels and approval states remains an organisational design decision unless a more specific applicable rule, contract or professional obligation says otherwise. Questions about coverage, classification or a particular legal duty belong with the relevant authority or a qualified adviser.
Questions the register makes visible
A useful register allows managers, vendors and advisers to ask:
- Is the recorded purpose specific enough to distinguish approved use from an unreviewed extension?
- Does each entry have a business owner and a person able to change access or settings?
- Are the people using the system different from the people affected by its output?
- What information enters the system, and which organisations or locations can receive or access it?
- Does human review occur before an output affects a customer, worker or applicant?
- Is the current risk label supported by a linked assessment?
- What event would trigger reassessment, restriction or retirement?
These are governance questions, not conclusions about legal compliance. The answers provide better source material for a privacy, security, procurement or legal review.
Who maintains the AI register
The register works best with one named custodian and separate owners for individual entries. NIST's inventory playbook recommends defining the individual or team responsible for maintenance. In a smaller business, the custodian may be an operations manager, privacy lead, security contact or senior administrator rather than a dedicated AI governance role. See NIST Govern 1.6.
The central custodian controls field definitions, follows up stale reviews and prevents duplicate records. Each business owner confirms the purpose, users, controls and status of their own entry. Technical administrators contribute account, integration and configuration evidence.
Event-driven updates are generally more reliable than waiting for an annual exercise. A new use, changed integration, new category of input data, provider-term change, significant incident or retirement can trigger a row update. A periodic review then catches changes that did not produce an obvious event. The precise cadence is an operational choice rather than a universal regulator-set interval.
How this was researched
This guide is researched against primary regulatory sources and official regulator guidance, checked against those documents as of the date shown, and written for a business with no dedicated compliance function. We report what a named authority has published and link the document so you can read it yourself. We do not tell you what your legal obligations are.
Read our full methodology and independence and disclosure policy.
Related reading: free AI acceptable use policy template, shadow AI audit checklist, AI data residency comparison, AI vendor due diligence checklist, AI vendor breach response plan template, guide to liability for AI-generated content, and AI governance by region.
Related reading: Claude AI Review: Pricing, Features, and Business Verdict and Is Claude Pro Worth It? An Honest Assessment for Business Users.
Free tools: AI Tool Pricing Tracker to check current pricing across the major AI platforms | AI Compliance Checker to check whether your AI tools meet your compliance obligations.
Try our free AI Policy Generator to generate a customised AI policy for your business.
Is an AI register the same as a software asset register?
No. A software asset register normally focuses on licences, devices, ownership and renewal. An AI register adds the purpose of each AI use, affected people, input data, output role, human oversight, risk work and evidence links.
Does every AI feature require a separate row?
Not necessarily. A separate row is useful when the feature has a distinct purpose, data flow, affected group, owner or control set. Several low-risk features can share an entry when their operating context is genuinely the same and the description remains clear.
Does keeping this register demonstrate legal compliance?
No. It organises facts and links that may support an assessment. Whether any law applies, and whether the recorded arrangements satisfy it, depends on the jurisdiction, organisation and use.
Does a free public chatbot belong in the register?
It can. Cost is not the deciding factor. A publicly available service may still process business information, produce material used in a workflow or expose the business to an unmanaged use that warrants recording.
Should rejected and retired systems remain visible?
A retained status record can explain why a system was rejected, restricted or retired and help prevent accidental reintroduction. Access to detailed incident or assessment material can remain limited, with the register holding only a link and concise outcome.
Methodology and source boundary
Need to Know AI reviewed primary materials from NIST, the OAIC, EUR-Lex, the ICO and Canada's privacy commissioners on 4 September 2026. The template is an NTKAI synthesis: authority-linked and framework-backed fields are identified beside their sources, while uncited fields are labelled as operational choices. No hands-on product testing, customer evidence or legal interpretation was used.
The information in this article is general in nature. It reflects a summary of publicly available guidance and does not constitute legal, privacy, or professional advice. Your obligations will depend on your specific situation, jurisdiction, and business circumstances. Do not rely on this article as a substitute for qualified legal or professional advice.
This template is provided as a general starting point for internal business documentation. It is general information only and does not constitute legal or professional advice. Requirements vary by jurisdiction and business circumstance. We recommend reviewing any template with a qualified legal or privacy professional before use or distribution.
For the next layer of analysis, use the AI risk assessment guide to examine a registered use in more detail.
AI risk assessment guide