Understanding your Article 26 register

Article 26 of the EU AI Act sets out the obligations of deployers — the companies that use high-risk AI systems in their operations, as distinct from providers who build the AI systems themselves. If you're using an LLM-powered product to screen job candidates, score loan applications, evaluate students, or any of the other high-risk uses listed in Annex III, you are a deployer.

The core deployer obligations include using the system according to the provider's instructions, assigning competent human oversight, monitoring system behavior in production, keeping automatically generated logs for at least six months, conducting a data protection impact assessment where appropriate, and cooperating with national supervisory authorities when asked. Article 13 and Article 14, working alongside Article 26, add transparency and human oversight requirements that the register also supports.

The AI register is the operational artifact that brings all these obligations together. It's the document — or the dashboard view, in your case — that proves you know what you've deployed, why, who owns it, what's flowing through it, and how it's being controlled.

When a regulator opens an inquiry, the first question is rarely about a specific algorithm. It's some version of: “Show us your inventory of AI systems, their purposes, their risk classifications, and the controls applied to each.” Without a register, that conversation begins on the back foot. With a register, you hand over an artifact, and the conversation moves to specifics.

The same principle applies to customer audits, board oversight conversations, internal risk reviews, and acquisition due diligence. The register is the answer to “what AI are you running, and how do you know it's under control.”

The AI Act defines eight categories of high-risk AI systems in Annex III. If your deployment falls into any of these, the full weight of Article 26 obligations applies:

• Biometrics — remote biometric identification, biometric categorization, emotion recognition systems
• Critical infrastructure — safety components of water, gas, electricity, road traffic, or similar systems
• Education and vocational training — admission decisions, evaluation, assessment, monitoring during exams
• Employment, workers management, and self-employment access — recruitment, screening, performance evaluation, task allocation, monitoring
• Access to essential private and public services — credit scoring, dispatching of emergency services, eligibility assessment for public benefits, insurance risk assessment for health and life
• Law enforcement — risk assessment, lie detection, evidence reliability evaluation, profiling
• Migration, asylum, and border control — risk assessment, travel document verification, examination of applications
• Administration of justice and democratic processes — assistance in interpreting and applying the law, influencing election outcomes

If your AI system doesn't fall into any of these categories, it's still worth recording in the register — but the full Article 26 obligations don't attach. Quantlix supports the classification “Not high-risk” for these cases, with a brief reasoning so the auditor understands the choice.

A few common cases worth flagging: a customer support chatbot is typically not high-risk; an AI-powered resume screener is high-risk (Employment category); an AI tool that evaluates which students pass an exam is high-risk (Education); a basic content recommendation engine is typically not high-risk; an AI deciding whether to approve a loan is high-risk (Credit scoring). When in doubt, document your reasoning in the classification notes — auditors care about the thought process, not just the answer.

Article 26 obligates the deployer organization, but the obligations don't manage themselves. The AI Act requires that natural persons be assigned to oversee high-risk systems, with the necessary competence, training, authority, and support.

In practice, the accountable person for any given AI system is the senior individual within the deployer organization who owns it operationally. Different organizations make different choices here. A common pattern is:

• For employment-related AI, the Head of Talent or Chief People Officer
• For credit and financial AI, the Chief Risk Officer or Head of Credit
• For customer-facing AI, the Head of Product or Head of Customer Operations
• For internal operations AI, the business unit head whose process the AI supports

What matters is that the accountable person has the authority to pause, modify, or retire the system if needed, and the training to understand its behavior. A junior engineer who built the system is rarely the right answer; the executive who depends on the system's output usually is.

The Quantlix register asks for the accountable person's email and role. We recommend updating this whenever ownership changes — auditors care about current accountability, not who built it three years ago.

Every Quantlix deployment automatically captures information that the register requires. You don't need to maintain these fields manually — they update as the system operates:

• The model provider and model version in use (OpenAI, Anthropic, Bedrock, and others)
• The list of sub-processors in the data flow, with their region of operation
• Volume metrics — calls per day, peak load, monthly cost
• The runtime policies applied to the deployment (PII redaction, content filters, budget controls)
• PII categories detected at the boundary, from the redaction system
• Trace history showing what was processed and what was enforced, with tamper-evident audit logging
• Policy versions in effect at each moment in time

These auto-populated fields represent the operational reality of the system. They're the answer to “what is this AI actually doing, right now,” and they're what makes the register defensible — the data is captured live, not transcribed from memory after an inquiry.

A handful of fields require human judgment and can't be derived from runtime data. These are the ones you'll set when you create a deployment, and update as the system evolves:

• Purpose — what does this AI do for the business, in plain language?
• Annex III classification — which high-risk category does it fall into, and why?
• Geographic scope — which countries does it operate in, and who is affected?
• Intended users — who uses it, and who is downstream of its decisions?
• Accountable person — who owns this system operationally?
• Conformity assessment — has the AI system gone through a conformity assessment, with what result, by which body?
• Declared data categories — what categories of data do you intend to send into this AI?

The system prompts you to complete these when you create a new deployment, and reminds you to review them annually — or sooner if you change ownership, scope, or use case.

When you receive an inquiry from a national supervisory authority — or when a customer's procurement team asks for evidence of your AI governance — the AI Register page has a single button: Export AI Register. It generates a regulator-ready PDF showing every deployment, every classification, every accountable person, every policy in effect, with current sub-processors and last-review dates.

The PDF maps each field to the specific Article 26 obligation it satisfies, so the recipient doesn't have to translate from your internal vocabulary to the legal framework. CSV and JSON exports are also available for downstream tools.

We recommend generating a fresh export each time you respond to an inquiry. The data is captured live, so the export reflects the current state rather than a stale snapshot. Every export is logged in your audit trail so you have a record of what was sent and when.

The register is only as good as the last time it was reviewed. The AI Act doesn't specify a review cadence, but supervisory authority guidance and emerging industry practice converge on annual review at minimum, with additional reviews when the system's scope, accountable owner, or use case materially changes.

Quantlix marks each deployment with a next review date and sends a reminder to the accountable person 30 days before it's due. Treat those reminders as a hard prompt, not a soft one — a register with overdue reviews is the first thing a regulator notices, and the easiest thing to fix in advance.