EU AI Act — the system inventory and risk record you need on file.

The EU AI Act is frequently discussed as if it requires every organization using AI to certify every system. That is not what it says. The regulation is structured around risk tiers, and the substantive obligations — technical documentation, conformity assessment, risk management — apply specifically to providers and deployers of high-risk AI systems as defined in Annex III and Article 6.

For deployers — organizations that use an AI system in their own context rather than placing it on the market — the key obligations are narrower than for providers (who build and sell AI systems) but still require meaningful record-keeping. Under Article 26, deployers must: use the AI system in accordance with its intended purpose as documented by the provider; implement appropriate human oversight; monitor the system for risks; and, for high-risk systems, maintain logs for the period required by applicable law.

The obligation that most enterprise deployers underestimate is Article 9 risk management. Article 9 does not simply require a risk assessment form — it requires an ongoing, documented risk management system with a defined lifecycle: identify, analyze, evaluate, mitigate, test, and monitor. Each step requires a record. The record is what an auditor asks for.

General-purpose AI (GPAI) models — foundation models like GPT-4, Claude, Gemini — have separate obligations under Title III of the Act. These obligations fall primarily on the model provider, not the deployer. However, deployers using GPAI as a base for a high-risk application retain their own deployer obligations under Article 9 and Article 26. The GPAI provider's compliance does not substitute for the deployer's risk management record.

Prohibited AI practices under Article 5 — social scoring, subliminal manipulation, real-time remote biometric identification in public spaces — are outright banned regardless of risk management records. If your system falls in these categories, the question is not what documentation you need; it is whether the system can exist at all.

Annex III of the EU AI Act lists the categories of AI system that are automatically classified as high-risk. The categories are: biometric identification and categorization; management of critical infrastructure (water, gas, electricity, roads); education and vocational training (access, assessment, evaluation); employment and worker management (recruitment, task allocation, performance monitoring, termination); access to essential private and public services (credit scoring, social benefits, emergency services); law enforcement; migration and border control; administration of justice; and democratic processes (voter profiling, influence on elections).

Most enterprise knowledge management AI — a document retrieval assistant, a customer service chatbot, a coding assistant — does not fall within Annex III. The question becomes relevant when AI is embedded in HR processes, credit decisions, or infrastructure management. An AI system that helps HR managers score job applicants is in the employment and worker management category. An AI system that helps a financial institution assess creditworthiness is in the essential services category. Both are high-risk.

The classification decision itself is evidence. Article 6(3) requires providers to register high-risk AI systems in the EU database. Deployers who determine that their system is not high-risk should document that determination — what criteria they applied, which Annex III categories they considered and rejected, and the basis for the decision. If a regulator later disagrees, a documented classification analysis is a better position than no record at all.

There is also a second pathway for high-risk classification under Article 6(1): AI systems that are safety components of products already subject to EU product safety legislation (medical devices, machinery, aviation). If your AI system is embedded in a regulated product, the product regulation may trigger high-risk classification independently of Annex III.

The classification review should be repeated when the AI system's purpose or scope changes. An internal productivity tool that expands into performance evaluation of employees has crossed into Annex III territory. Documenting the change — and the re-classification decision — is part of the ongoing risk management record.

Article 9 defines risk management as a continuous, iterative process — not a one-time assessment. The six requirements are:

1. Establish and maintain a risk management system. This means a defined process, not just a spreadsheet. The system must be documented, assigned to responsible parties, and reviewed on a defined cadence. Evidence required: a risk management policy or procedure document with version control and owner assignment.

2. Identify and analyze known and reasonably foreseeable risks. This requires enumerating what can go wrong — biased outputs, privacy leakage, misuse by end users, failure under edge conditions. The analysis should cover risks to health, safety, and fundamental rights. Evidence required: a risk register with each risk named, its source, and its potential impact.

3. Evaluate risks. Each identified risk must be assessed for likelihood and severity. The evaluation should consider the context of use — who uses the system, under what conditions, for what decisions. Evidence required: risk ratings with documented rationale, not just a score.

4. Implement risk mitigation measures. For each material risk, a control must be in place or planned. Residual risks — those remaining after mitigation — must be documented and accepted by a responsible party. Evidence required: a control plan mapping each risk to its mitigations, with implementation status and residual risk statements.

5. Test the system. Article 9(5) requires testing against the intended purpose and against probable misuse. Testing must occur before deployment and when the system changes. Evidence required: test records including scope, methodology, results, and sign-off.

6. Monitor post-deployment. Deployers must monitor the system for risks that emerge in production — particularly risks to fundamental rights. This is not a requirement for continuous technical monitoring; it is a requirement for a process to detect and respond to post-deployment risk events. Evidence required: a monitoring plan and records of reviews conducted.

Article 11 requires that providers of high-risk AI systems prepare a technical documentation file before placing the system on the market. For deployers who have customized a foundation model or fine-tuned a system for their own context, the boundary between provider and deployer obligations becomes relevant — but the documentation requirement follows the responsibility.

The technical documentation file must cover: a general description of the AI system and its intended purpose; the design specifications, including the algorithms used and the design choices; the development methodology; the data governance practices (sources, preprocessing, training and validation datasets); the testing results; and the risk management records from Article 9.

The file must be retained for ten years after the system is placed on the market or put into service — whichever is later. This is a legal records retention obligation, not a suggestion. Organizations that delete documentation after an AI system is retired may find themselves unable to respond to a regulator request five years later.

Where organizations typically have gaps: training data governance is the most common weakness. Documenting what data was used, where it came from, how it was validated, and what consent or licensing applies requires upstream engagement with data teams that most organizations have not yet built into their AI development process. The second most common gap: testing records. Test plans exist; signed test records with defined pass/fail criteria do not.

The technical documentation file is also what an auditor requests first. If the file does not exist, or exists only as a loose collection of documents rather than a structured, version-controlled record, the audit starts poorly. Building the file progressively as the system is developed is far less effort than reconstructing it after the fact.

Drel is an AI security review platform. It is not a conformity assessment body, and it does not certify EU AI Act compliance. What it produces is a structured risk management record for each assessed AI system — the same type of record that Article 9 requires.

The Drel assessment output maps directly to Article 9's requirements. Risk identification (Article 9, clause 6.1.2 equivalent): Drel enumerates the risks applicable to the assessed system based on its architecture, data flows, and intended use. Risk analysis and evaluation: each risk is rated for likelihood and severity in the context of that system. Risk treatment: Drel produces a control plan identifying required controls and flagging control gaps. Evidence pack: the complete assessment output is packaged as an audit-ready dossier — a structured record that supports the technical documentation file requirement.

The clearance decision — the output of the Drel review — is a risk disposition: cleared, conditionally cleared (with required controls), or not cleared. This disposition is the kind of documented risk acceptance or rejection that Article 9 requires from a risk management system.

What Drel does not produce: a conformity assessment (that requires a notified body for applicable categories), a legal opinion, or a regulatory guarantee. The evidence pack supports the Article 9 obligation; it does not replace the conformity assessment process where that process is required.

General-purpose AI models — GPT-4, Claude, Gemini, Mistral, and similar foundation models — are subject to separate obligations under Title III (Articles 51–56) of the EU AI Act. These obligations fall on the model provider: technical documentation of training, copyright policy, energy consumption data, and — for systemic-risk GPAI models (those trained with more than 10^25 FLOP) — adversarial testing and incident reporting.

Deployers who use a GPAI model as the base for an AI application benefit from the GPAI provider's obligations — if the provider is compliant, the deployer is not required to re-document the model's training process. However, the deployer retains their own obligations. If the application built on top of the GPAI model is a high-risk AI system under Annex III, the deployer must still maintain a technical documentation file and an Article 9 risk management record for the application layer.

The AI Office — the EU body responsible for supervising GPAI model providers — is distinct from the national market surveillance authorities that oversee high-risk AI system deployers. An organization that both provides a GPAI model and deploys high-risk AI applications may be subject to oversight from both. Most enterprise deployers will interact only with national authorities, not the AI Office directly.

The practical implication: when you use a GPAI API (OpenAI, Anthropic, Google) to build a product, request and retain the provider's documentation about that model's training, intended purposes, and known limitations. This becomes part of your technical documentation file's section on the AI system's provenance and design specifications.