How to Build an AI Register: The 12-Field Template for EU AI Act Compliance

An AI register is a structured inventory of every AI system an organisation uses — what it does, what data it processes, who is responsible, and what legal obligations apply. If your company is subject to the EU AI Act or sells to customers who are, the register is no longer optional. Enterprise buyer questionnaires, ISO 42001 audits, and market-surveillance regulators all expect one.

What an AI register is — and who asks for it

It is a living record of every AI system in your environment — including shadow AI deployed without formal procurement. Think of it as the AI equivalent of a GDPR Article 30 records-of-processing inventory, but scoped to AI systems and their risk profiles. The requesters are multiplying:

• Enterprise buyers. Vendor questionnaires now routinely ask: “List all AI systems that process personal data.”
• ISO 42001 auditors. The standard requires documented evidence of AI-system identification and risk assessment. The register is the primary deliverable.
• Regulators. Market-surveillance authorities can request AI-system documentation during inspections. Article 26 presupposes you know what you are deploying.
• Insurers and investors. Due-diligence processes for funding rounds and M&A now include AI-risk inventories.

The 12 fields every register row needs

A register that collects information nobody uses is a waste. Each row should capture the fields that downstream compliance activities require.

These 12 fields are not arbitrary. They map directly to what Article 26 requires for high-risk deployers (logging, oversight, data relevance), what enterprise vendor questionnaires ask, and what ISO 42001 auditors verify against.

Step-by-step: building your AI register

Step 1 — Discover

Most mid-market companies underestimate the number of AI systems in use. Start broad:

• Spend analysis. Pull 18 months of procurement and expense data. Search for AI, ML, GPT, copilot, automation, and similar terms.
• SSO logs. Identify applications where employees authenticate. Filter for recently added or unusual tools — shadow-AI candidates.
• Employee surveys. Ask department heads: “What AI tools do you use — including free tiers, browser extensions, and plugins?”
• IT asset inventory. Cross-reference with endpoint-management and network-access logs.

For a typical 300-person company, discovery surfaces 20–60 distinct AI tools. Many will be duplicates, personal free-tier accounts, or tools where AI is a minor feature rather than a primary function.

Step 2 — Intake

Create a structured intake process. For each discovered tool, the system owner submits:

• The tool’s name, vendor, and URL
• What it does and why it was adopted
• What data it receives or processes
• Whether it influences decisions about natural persons

This intake form becomes the raw material for classification. Keep it simple — a one-page form gets completed; a ten-page form gets ignored.

Step 3 — Classify

Walk each system through the AI Act’s risk-classification framework:

1. Is it a prohibited practice under Article 5? If yes, cease use immediately.
2. Does it fall within Annex III? Employment, education, credit, insurance, biometrics, critical infrastructure, law enforcement, migration, justice. If yes, it is high-risk unless an exception applies.
3. Does it interact with natural persons? If yes, Article 50 transparency obligations may apply regardless of risk tier.
4. Does it process personal data in ways that trigger a GDPR DPIA? If yes, coordinate the classification with the Article 35 assessment.
5. Otherwise, classify as limited or minimal risk and document the rationale.

Record the classification and rationale. “High-risk — CV screening and candidate ranking, Annex III(4)” is a rationale. “High-risk” is not.

Step 4 — Assign obligations

For each system, map the obligations that apply based on your role and risk tier:

• High-risk deployer (Article 26): Human oversight, input-data relevance, automatic logging (six-month minimum retention), worker notification, monitoring, instruction measures.
• High-risk deployer in public services / credit / insurance (Article 27): Fundamental-rights impact assessment obligations.
• Transparency (Article 50): Chatbot disclosure, synthetic-content marking, deepfake disclosure.
• AI literacy (Article 4): Training requirements for all users of AI systems.

Document which obligations are met, which are in progress, and which are gaps. The gap analysis becomes your compliance roadmap.

Keeping the register alive

A register built in January and untouched until December is a liability. The AI Act’s obligations are ongoing.

• Quarterly reviews. Schedule a 60-minute cross-functional review every quarter. Legal, IT, HR, and procurement attend. Walk through every entry: has the use changed? Has the vendor updated terms?
• Onboarding hooks. When a new SaaS tool is procured, the intake form is mandatory. No tool goes live without a register entry and risk classification.
• Offboarding hooks. When a tool is decommissioned, update the register. Phantom entries erode credibility during audits.
• Incident triggers. If a vendor reports a breach or an AI system produces an adverse outcome, review the register entry immediately.

The register is a living system. Treat it like your financial ledger — something that is always current and always auditable.

How the register feeds other compliance artefacts

The register is not an end in itself. It is the upstream source for downstream compliance work.

• GDPR DPIA (Article 35). Data-category and purpose fields feed directly into the DPIA. Coordinating the two avoids duplication.
• FRIA (Article 27). The register identifies which systems require a fundamental-rights impact assessment and provides baseline documentation.
• AI policy. The owner and obligation fields determine what the policy must cover. A policy without a register is a list of aspirations without a subject.
• Training programme. User and department fields tell you who needs training on what. Training a 300-person company on “AI” generically is theatre.
• ISO 42001. The register is the primary evidence artefact for AI-system identification and risk assessment.
• Vendor questionnaires. Enterprise buyers ask for a register. Having one ready is a competitive advantage.

Example register row

This row gives an auditor, a vendor questionnaire, or an internal stakeholder everything they need. Multiply it by every AI system in your environment, and you have a functioning register.

Frequently asked questions

How is an AI register different from a GDPR records-of-processing inventory?

A GDPR Article 30 records-of-processing inventory documents processing activities involving personal data. An AI register documents AI systems regardless of whether they process personal data. Many entries overlap — an AI tool processing employee CVs triggers both — but the register captures additional fields like risk-tier classification, provider/deployer role, and AI Act-specific obligations. Treat them as related artefacts, not duplicates.

We use AI embedded in larger platforms — do those count?

Yes. If a platform uses AI to influence decisions about natural persons — a CRM that scores leads, an HRIS with AI-assisted promotion recommendations — the AI component is in scope. Document the AI feature specifically, even if the platform is already tracked in your IT asset inventory.

What if we discover tools that procurement never approved?

Shadow AI is common and is precisely why the discovery step matters. The initial register process should be non-punitive: the goal is visibility, not blame. Once every tool is catalogued, you can apply risk classification and decide which tools to retain, remediate, or decommission.

How often should the register be reviewed?

Quarterly at minimum. Additionally, review any entry immediately when the vendor releases a material update, an incident occurs, the tool’s use changes scope, or new guidance affects its classification. The review-date field in each row creates accountability for this.

Can we build a register in a spreadsheet?

Technically yes, but spreadsheets do not enforce workflow, track ownership, or integrate with identity-provider data. As your AI footprint grows beyond 20–30 systems, manual tracking introduces version-control and accountability gaps. Renomira provides a structured register that maps fields to AI Act obligations and automates review cycles.