Guide · EU AI Act
As of 3 October 2026 · after the Digital Omnibus
AI register under the EU AI Act: what it is and how to build one
An AI register is an internal record of every AI system your organisation uses, develops or offers – with its purpose, role, risk class, owner and review date. The AI Act does not expressly require one, but its obligations under Articles 4, 5, 6, 26 and 50 presuppose exactly this overview.
- An honest take on the obligation
- Example register with 4 entries
- RACI for responsibilities
- Two-minute maturity check
AI register
Demo Organisation GmbH · 4 systems
1 entry not yet assessed
What the register makes visible
- Art. 4 Who needs training
- Art. 5 Whether a practice is prohibited
- Art. 26 Where deployer duties apply
- Art. 50 Where an AI notice is needed
Next review: AI-003 in 3 months
Definition
What is an AI register?
An AI register – often also called an AI inventory or AI system record – is the central list of all AI systems in your organisation. For each entry it records which system it is, what it is used for, in which role your organisation acts, which data flows into it, whom its outputs affect, which risk class of the AI Act it falls into and who is responsible for it.
The decisive point is the intended purpose. The AI Act (Regulation (EU) 2024/1689) ties its obligations not to products but to what a system is used for. The same language model can be harmless in marketing and fall under Annex III in recruitment. A good register therefore has, when in doubt, one row per purpose rather than one per licence.
The register is not a form for an authority but a working tool. It answers three questions that management, data protection, the works council, customers and ultimately market surveillance will ask: Which AI is running here? Where is action needed? And who is taking care of it? If you can answer those in one file, you have taken the most important step towards AI Act compliance.
It covers everything that meets the definition of an AI system in Art. 3(1) – including off-the-shelf software, AI features a vendor has added to your CRM or office suite, and tools a single team pays for with a company card. When in doubt, include a tool and note why you consider it uncritical.
Legal position
Is an AI register mandatory?
The honest answer: the AI Act does not expressly require a general internal AI register in any particular format. In practice, though, you can hardly do without one.
The Regulation is built around individual systems. Almost every obligation starts with a question you can only answer if you know which systems are in use and for what. Without that, you can neither show that no prohibited practice is involved, nor plan training measures in a targeted way, nor prepare the deployer obligations for high-risk AI in time.
This affects every organisation that uses AI systems under its authority in a professional capacity – a deployer within the meaning of Art. 3(4). Only personal, non-professional use is excluded. Providers that develop AI systems or place them on the market under their own name have further obligations. Infringements of the Regulation’s obligations can be fined under Art. 99; the register is the simplest evidence that you have dealt with your AI use systematically.
Since the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), some dates have changed. The table shows which articles presuppose an overview, which details you need in the register for them and since when the obligation applies.
Scroll the table sideways →
| Provision | What it requires | What you need in the register | Applies |
|---|---|---|---|
| Art. 4 AI Act | Measures to promote the AI literacy of staff and others dealing with AI systems (since the Omnibus: take measures rather than ensure a particular level). | Which systems which user groups use and which training is documented. | since 2 Feb 2025 |
| Art. 5 AI Act | Ban on certain practices, e.g. emotion recognition in the workplace or social scoring. Further prohibitions apply from 2 Dec 2026. | Purpose and features of each system, so prohibited uses stand out. | since 2 Feb 2025 |
| Art. 6, Annex III | Classification as high-risk AI, e.g. in employment, education, creditworthiness or critical infrastructure. | Purpose, affected persons and a reasoned risk class. | from 2 Dec 2027 (Annex I: 2 Aug 2028) |
| Art. 26 AI Act | Deployer obligations for high-risk AI, including use in line with the instructions, human oversight, keeping logs and informing workers. | Role, owner, oversight arrangement, provider and where documentation is kept. | with high-risk obligations |
| Art. 27 AI Act | Fundamental rights impact assessment for certain deployers, e.g. public bodies or for creditworthiness assessments. | A flag for which entries need an impact assessment. | with high-risk obligations |
| Art. 50 AI Act | Transparency: notice of AI interaction, disclosure of deepfakes and certain AI-generated text, marking of synthetic content. | Whether people interact with the system directly or content is published. | since 2 Aug 2026 (para. 2: transition to 2 Dec 2026) |
| Art. 30, 35 GDPR | Record of processing activities (RoPA) and data protection impact assessment where risk to individuals is high. | Whether personal data is processed and a reference to the RoPA entry. | since 25 May 2018 |
Simplified overview, not legal advice. The wording of the Regulation as currently in force is authoritative.
Distinctions
AI register, EU database, transparency register, RoPA: what is what?
Four different things circulate under the label “AI register”. Only one of them is kept by your organisation itself – the others are public registers with their own purpose, or a data protection record.
Scroll the table sideways →
| Aspect | Internal AI register | EU database (Art. 49, 71) | Public-sector AI transparency registers | RoPA (Art. 30 GDPR) |
|---|---|---|---|---|
| Who keeps it? | Your organisation | The European Commission | The administration concerned, e.g. Germany’s federal government (bund.de) | Controllers and processors |
| What is in it? | All AI systems, including minimal risk | Only Annex III high-risk AI and systems for which providers rely on Art. 6(3) | AI applications a public body uses or develops, with a short description | Processing of personal data – with or without AI |
| Who enters data? | Internal owners and business units | Providers before placing on the market; public bodies as deployers for their use | The public body itself | Data protection owners in the organisation |
| Public? | No, internal; available to auditors on request | Largely public | Yes, to inform the public | No; available to the supervisory authority on request |
| Legal basis | No express obligation; practical basis for Art. 4, 5, 6, 26, 50 | Express registration duty under the AI Act | Initiative or rules of the administration; no requirement for companies | Express GDPR obligation (with exceptions for small organisations) |
| Relevant for | Every organisation that uses or offers AI professionally | Providers of high-risk AI, public deployers | Citizens and the expert public | Every organisation processing personal data |
For most organisations it comes down to the internal register plus the RoPA. The two should cross-reference: if an AI system processes personal data, put the RoPA number in the register and the AI system in the processing description.
Example
What a completed AI register looks like
Four typical entries for a fictitious “Demo Organisation GmbH” with 120 employees. The classifications are plausible examples for the stated purpose, not a legal assessment of the products.
| ID | AI system | Intended purpose | Role | Risk class | Rationale | Owner | Next review |
|---|---|---|---|---|---|---|---|
| AI-001Example | Microsoft 365 Copilot | Drafts, summaries and research in office documents, all departments | Deployer | Minimal | Internal productivity, no decisions about people. Art. 4 training and RoPA entry done. | Head of IT | 10/2027 |
| AI-002Example | Website chatbot | Answers customer questions about products and delivery status | Deployer | Transparency | People interact with the system directly: notice of AI interaction under Art. 50(1) is in place. | Head of customer service | 04/2027 |
| AI-003Example | Applicant tracking with AI ranking | Sorts incoming applications by fit for the role | Deployer | High risk | Annex III point 4 (employment). Prepare Art. 26 deployer obligations for 2 Dec 2027; instructions for use requested. | Head of HR | 01/2027 |
| AI-004Example | Meeting transcription | Minutes of customer meetings in sales | Deployer | Not yet assessed | Check whether the sentiment analysis feature is active – emotion recognition in the workplace would be prohibited under Art. 5. | Head of sales | 11/2026 |
Every entry should have at least these details
- Unique ID and nameSo contracts, tickets and the RoPA can refer to the entry.
- ProviderThe source of instructions for use, documentation and updates.
- Intended purposeDescribed concretely – it determines the risk class.
- RoleDeployer or provider, with different obligations.
- Personal dataYes or no, with a reference to the RoPA entry.
- Risk class with rationaleOne or two sentences on why you classified it this way.
- OwnerOne person – not a team, not a mailing list.
- Status and next reviewSo nothing gets left behind.
Every column, dropdown and example row is available as a ready-made Excel file – free and without an email address.
XLSX · no email
Responsibility
Who is responsible for the AI register?
The AI Act does not say who in the organisation keeps the register. A clear split has proven itself: a central function owns the structure, business units supply the content, and every system has a named owner.
Scroll the table sideways →
| Task | Management | AI lead / compliance | Business unit / system owner | IT | Data protection | Works council |
|---|---|---|---|---|---|---|
| Introduce the register, set goals and ownership | A | R | I | C | C | I |
| Define structure, fields and what counts as an “AI system” | I | A/R | C | C | C | · |
| Report new AI tools and describe their purpose | · | I | A/R | C | I | · |
| Assess and justify the risk class | I | A | R | C | C | · |
| Check data protection (RoPA, DPA, DPIA if needed) | · | I | R | C | C | · |
| Look for shadow AI (logs, SSO, expenses) | · | A | C | R | C | C |
| Plan AI literacy measures (Art. 4) | A | R | C | I | I | C |
| Approve new tools before use | I | A | R | R | C | C |
| Review the register regularly and report | I | A/R | C | C | I | · |
- RResponsible – does the work
- AAccountable – decides, owns the outcome
- CConsulted – asked beforehand
- IInformed – kept up to date
As with other compliance topics, overall responsibility for meeting the AI Act lies with management. It can delegate tasks, but not the responsibility.
Data protection officers advise and monitor under the GDPR; they should not keep the register themselves – otherwise they would be checking their own work.
Whether and how the works council must be involved depends on the case. AI tools that can evaluate the performance or behaviour of employees are a typical trigger.
How-to
Building an AI register: 7 steps
From the first conversation to an approved register, a mid-sized organisation with 10 to 30 tools usually needs two to four weeks alongside day-to-day work. The order matters more than the speed.
Settle ownership
Name a person or function to keep the register and get a mandate from management. Define which entities, sites and departments are in scope.
Who: Management, complianceOutcome: Owner named, scope definedDefine “AI system”
Use Art. 3(1) as a reference and write a simple internal working definition with examples. Rule of thumb for the start: better to include one tool too many and justify it as uncritical than to miss one.
Who: Compliance, ITOutcome: Working definition with examplesCollect the systems
Combine several sources: licence and purchasing lists, SSO and app overviews, expense reports and a short survey in each department. Ask about tasks (“What writes, translates, scores or sorts things for you?”) rather than about “AI”.
Who: IT, business unitsOutcome: Raw list of candidatesCapture the core details
Create one row per intended purpose and fill in the minimum details: provider, purpose, role, user group, affected persons, personal data and owner.
Who: System ownersOutcome: Register with core fieldsAssess role and risk class
Check in order: prohibited practice under Art. 5? Annex III area or regulated product? Transparency duty under Art. 50? Otherwise minimal. Write down the rationale; unclear cases stay “not yet assessed” with a short review date.
Who: Compliance with system ownerOutcome: Risk class with rationaleDerive obligations and measures
Every row leads to something: training for the user group, an AI notice in the chatbot, instructions for use and an oversight arrangement for high-risk systems, a RoPA entry and data processing agreement for personal data.
Who: Compliance, data protection, ITOutcome: Measures per systemApprove and embed upkeep
Have management acknowledge the register, set review dates and establish the rule: no new AI tool without a register entry. Easiest via purchasing and IT approval.
Who: Management, purchasing, ITOutcome: Approved register, upkeep process
Self-check
Maturity check: how far along is your AI register?
Six questions, two minutes. On the right you see which level your register is at and which steps make sense next. Your answers stay in your browser and are not stored.
Maturity
AI register · self-assessment
Answer the questions on the left – your result appears here.
Self-assessment for orientation only – not legal advice and no statement on whether your organisation meets the requirements of the AI Act.
Shadow AI
Spotting shadow AI: the tools nobody reported
A register that only knows the officially introduced licences is incomplete. In almost every organisation, staff also use AI tools – usually for good reasons, but without review. These signals help you find them:
- 01Effort: low
Sign-ins with Microsoft or Google accounts
Many AI services can be connected to the work account. Each consent leaves an entry with app name and permissions.
Where to lookEnterprise applications / OAuth consents in your identity service
- 02Effort: low
Small monthly subscriptions
AI tools at 20 to 30 euros a month often run through company cards or expenses, bypassing IT.
Where to lookCard and expense statements, supplier list
- 03Effort: medium
Browser extensions
Writing assistants, translators and “summarise” buttons sit right in the browser and read what is on the page.
Where to lookEndpoint management, browser policies
- 04Effort: medium
AI features in existing software
CRM, ticketing, office suite and HR software gain AI features through updates – often switched on by default.
Where to lookRelease notes, vendors’ admin consoles
- 05Effort: high
Traffic to AI domains
Network data shows which AI services are used, how often and from which areas.
Where to lookProxy, firewall or DNS logs – evaluated in line with data protection rules
- 06Effort: low
A no-blame survey
Ask about tasks rather than tools, and say it is about getting an overview, not sanctions. Otherwise the honest answers won’t come.
Where to lookShort questionnaire per department, 5 minutes
If your organisation analyses logs or usage data of employees, involve data protection and – where there is one – the works council beforehand. The goal is a complete register, not monitoring individuals.
Upkeep
Review rhythm and triggers
An AI register ages quickly: new tools arrive, vendors add features, purposes change. Two mechanisms keep it current – fixed triggers and a regular cycle.
Update it when …
- … a new tool arrivesIncluding trials and newly enabled AI features in existing software – before productive use.
- … the purpose changesIf a tool is suddenly used for HR decisions or with customers, the risk class may change.
- … the vendor changes something majorNew model, new data sources, more automation: re-check the rationale for the classification.
- … something goes wrongWrong decisions, data leaks or complaints from affected people are a reason to review the entry and oversight.
- … the law changesNew Commission guidelines or changes such as the Digital Omnibus with new dates.
- … a tool is retiredDon’t delete it – mark it “retired” so it stays traceable what was in use and when.
Regular cycle by risk class
| Risk class | Recommended review | What to look at |
|---|---|---|
| High risk | quarterly | Oversight, logs, instructions for use, informing workers |
| Transparency | every six months | Is the AI notice still visible? New channels or content? |
| Minimal | yearly | Purpose unchanged? New features? Training up to date? |
| Not yet assessed | within 4 weeks | Finish the classification – open entries are the biggest risk |
The intervals are a practical recommendation. The AI Act prescribes no rhythm for the internal register.
When the spreadsheet is no longer enough
As systems and contributors grow, Excel usually lacks change history, reminders and roles. That is when software mapping the same structure pays off.
Compare AI inventory softwareAI Inventory
3 systems registered
AI-based Application Screening
OpenAI · HR & Recruiting
Service Chatbot "Lia"
Microsoft · Customer Support
Marketing Copy Generator
OpenAI · Marketing
Website Translation Plugin
DeepL
Classify now →In practice
Common AI register mistakes
Most registers don’t fail on the law but on execution. These are the patterns we see most often:
Mistake: One row per product, whatever it is used for.
Better: One row per intended purpose – the risk class follows the purpose, not the licence.
Mistake: Only listing officially purchased tools.
Better: Actively search for shadow AI and AI features added to existing software.
Mistake: Entering a risk class without a rationale.
Better: One or two sentences of reasoning – when in doubt they matter more than the result.
Mistake: “IT” or “Marketing” as the owner.
Better: One named person per system, with a deputy.
Mistake: Set it up once, never touch it again.
Better: Define triggers and review dates, record the review date per entry.
Mistake: Keeping register and RoPA apart with no cross-reference.
Better: Put the RoPA number in the register and the AI system in the processing description.
Mistake: Marking unclear cases “minimal” to finish the list.
Better: “Not yet assessed” with a short review date – honestly open beats wrongly closed.
Mistake: Deleting retired tools.
Better: Mark them “retired” so the history stays traceable.
Open-Source Framework
simpleact-model-vendor-register
Open register for AI vendors and models: one entry per vendor and plan, with the questions that belong before the contract.
FAQ
Frequently asked questions about the AI register
More questions? We're happy to help. Send email · Get started
Sources and status
Last reviewed on · SimpleAct editorial team
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex
- Regulation (EU) 2016/679 (GDPR), EUR-Lex
This page is for orientation and is not legal advice. The wording in the Official Journal of the EU is authoritative. The examples are fictitious and not an assessment of the products named.
Changes to this page
- 3 October 2026 – Rebuilt as a guide: honest take on the obligation, distinction from the EU database, transparency registers and RoPA, example register, RACI, maturity check, status after the Digital Omnibus.
- 16 June 2026 – First version.
Further reading
- AI register template (Excel, free)
- Choosing AI inventory software
- EU AI Act deadlines after the Digital Omnibus
- Article 50 transparency obligations
- Determine risk classes
- Record of processing activities
- MLflow integration: import model versions and metrics
- AI policy: Word template for using your AI tools
- Technical documentation: Annex IV template
- AI literacy: training matrix and attendance record
Start your AI register today
Our free Excel template gives you the structure in minutes. When the register grows, SimpleAct takes over reminders, history and evidence.