A procurement team switches on an AI screening tool. HR begins using a CV-ranking feature. Customer service deploys a chatbot connected to account data. None of these decisions starts with a regulatory filing, yet each should trigger the same question: which systems need AI registration and what evidence must the organisation retain?
The answer is not simply every tool with AI in its marketing. Under the EU AI Act, formal registration applies to defined categories and actors. In practice, however, organisations also need a broader internal AI register. Without one, compliance teams cannot reliably identify the systems that do require entry in the EU database, assessment, monitoring or board oversight.
AI registration means two different things
The EU AI Act creates a formal registration requirement for certain high-risk AI systems in the EU database. This is a legal obligation, not an optional inventory exercise. It is principally governed by Article 49 and supported by the information requirements in Annex VIII.
Organisations also use the term AI registration to mean recording every relevant AI use case in an internal governance inventory. This is not the same as the EU database registration, but it is the operational prerequisite for it. A legal team cannot classify systems it does not know exist, and an auditor cannot test controls against an inventory maintained in disconnected spreadsheets.
Treat these as connected but separate records. The internal register should capture the full population of AI systems, models, features and material use cases. The regulatory register identifies the subset that must be recorded in the EU database, with the required provider, system and conformity information.
Which systems need AI registration in the EU database?
The core category is a high-risk AI system. Providers must register high-risk systems in the EU database before placing them on the market or putting them into service, subject to the Act’s applicable dates and any relevant transitional provisions.
High-risk status arises through two main routes. First, an AI system can be a safety component of a product, or itself be a product, covered by EU product-safety legislation listed in Annex I, where that product requires third-party conformity assessment. Examples may include AI components used in regulated machinery, medical devices or certain transport products.
Second, an AI system may fall within an Annex III use case. These are the categories most likely to concern mainstream employers, public bodies, financial services firms and essential-service operators. They include AI used in biometric identification or categorisation, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border management, and the administration of justice or democratic processes.
An HR system that ranks applicants, filters CVs or makes recommendations affecting recruitment is a clear example requiring careful Annex III analysis. So is an AI system used to assess creditworthiness, prioritise emergency services, allocate benefits, monitor worker performance or support decisions by public authorities. The label attached by a supplier is irrelevant. The intended purpose and the real deployment context determine the assessment.
The Article 6(3) exception is narrow
Not every system that appears to sit within Annex III is automatically high risk. Article 6(3) provides a limited exception where the system does not pose a significant risk of harm to health, safety or fundamental rights. The exception may apply where an AI system performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing or influencing human assessment, or performs a preparatory task.
This is not a shortcut for low-effort classification. If the system profiles natural persons, Article 6(3) does not apply. Nor is a human-in-the-loop label enough on its own. Where an employee routinely accepts the tool’s recommendation, or where a supposedly preparatory score materially shapes who receives an opportunity or service, the case for exemption weakens quickly.
Where a provider relies on this exception, it must document its assessment. The organisation should retain the intended purpose, process map, affected individuals, evidence of human oversight, risk rationale and approval decision. An unsupported statement that a tool is merely assistive will not withstand scrutiny.
Public-sector deployers have a direct registration duty
Registration is not solely a provider responsibility. Public authorities, EU institutions, bodies, offices and agencies, and organisations acting on their behalf, have registration obligations when they deploy certain high-risk AI systems listed in Annex III. They must register their use of the system in the EU database.
This matters for suppliers selling into the public sector and for private organisations delivering services under public authority arrangements. Contract wording may allocate operational tasks, but it cannot remove the underlying statutory responsibility. Establish early who will register what, which information will be supplied, and how changes to the deployment will be governed.
Systems that still belong in your internal register
Many systems will not require EU database registration, but leaving them outside the governance process is a poor control decision. General-purpose AI tools, internal copilots, customer-facing chatbots, forecasting tools and supplier-provided AI features may create data protection, security, consumer, employment or contractual risks even where they are not high risk under the EU AI Act.
General-purpose AI model providers have separate obligations under the Act, including technical documentation, information for downstream providers, copyright-policy and training-content-summary requirements. Those obligations are not the same as high-risk system registration. A deployer using a general-purpose model does not normally register that model in the EU database merely because it is a large language model.
The practical test is broader than formal registration. Record systems that process personal data, influence people, make or support consequential decisions, interact externally, generate content published under the organisation’s name, access confidential information, or are embedded in a material business process. Also record AI capabilities within established software products. A CRM, HR suite or security platform can become an AI governance issue through a feature update rather than a new procurement.
A complete register should distinguish the legal entity acting as provider, deployer, importer, distributor or authorised representative. It should capture the system’s intended and actual purpose, supplier, model or component dependencies, data categories, jurisdictions, affected groups, owner, risk classification, assessment status, controls, incidents and review date. This turns a list of tools into a defensible governance record.
Build the classification workflow before the deadline
The common failure mode is to begin with a questionnaire sent across the business, receive partial answers, then attempt a legal classification months later. That approach produces an inventory of names, not evidence. A controlled workflow is more reliable.
Start by assigning a business owner and accountable executive for each system. Confirm whether the organisation develops the system, deploys it, resells it, materially modifies it or simply uses a supplier service. The answer affects the applicable duties.
Then document the system boundary. Assess the whole decision process, not just the model. What input data is used? Who receives the output? Can the output influence a decision about an individual? What happens when the system fails, drifts or is challenged? These facts determine whether Annex III, Article 6(3), transparency duties or other obligations may apply.
Next, make a recorded classification decision. For high-risk systems, link the decision to the relevant Annex category, conformity assessment evidence, technical documentation, instructions for use, risk-management outputs, human-oversight controls and post-market monitoring arrangements. For systems assessed as outside scope or exempt under Article 6(3), preserve the reasoning and set a review trigger.
A change in model, data source, purpose, user group or decision authority can invalidate the original assessment. Registration and classification therefore need change control, not an annual tick-box review. Endaxi AIG is designed around this operating model: one record can connect inventory data, legal classification, risk assessments, controls, approvals and audit evidence without forcing teams to rebuild the case across separate tools.
Registration is evidence, not the end of governance
Submitting information to the EU database does not prove that a system is compliant. It records that a defined system is being placed on the market, put into service or deployed in a regulated context. The underlying obligations remain: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, cybersecurity, monitoring and incident handling.
For deployers, the immediate discipline is to obtain usable evidence from providers rather than accepting a generic compliance statement. Request instructions for use, intended-purpose documentation, applicable conformity information, known limitations, human-oversight requirements and change notifications. Map these inputs to your own deployment conditions and retain a clear decision trail.
The most useful question for a compliance committee is not whether the organisation has an AI register. It is whether every material system has an owner, a defensible classification, proportionate controls and a known next action. That is the point at which registration stops being an administrative task and becomes governance that can withstand a regulator, auditor or board challenge.