EU AI Act: the technical dossier, article by article, over the blog's on-premise LLM architecture

Sister post to the mapping onto ISO/IEC 42001. That one broke down the AI management system, the certifiable standard. This one breaks down the binding legal regulation that applies without any certification: the EU AI Act is direct law in all 27 Member States, with no transposition and with explicit penalties of up to 35 million euros or 7% of worldwide turnover. The main obligations for high-risk systems enter into force on 2 August 2026; each article applies from its own date, not from the date the organisation gets certified.

TL;DR

Regulation (EU) 2024/1689 (the EU AI Act, “Reglamento Europeo de Inteligencia Artificial”), published in the Official Journal on 12 July 2024, sets obligations by risk tier (prohibited, high, limited, minimal) and by role (provider, deployer, importer, distributor, authorised representative). The obligations for high-risk systems (Annex III: biometrics, critical infrastructure, education, employment, essential public and private services, law enforcement, migration, justice, democratic processes) enter into force on 2 August 2026 and are the category that applies to most LLM projects in a medium-to-large enterprise. This post maps, article by article, the obligations relevant to a high-risk LLM system deployed on-premise: each article states its requirement, identifies which blog post already describes the technical piece that materialises it, and closes with an auditable checklist that a provider hands to a national supervisory authority. The Annex IV technical dossier is reconstructed by pointing its nine mandatory sections at the corresponding technical runbooks. Also covered: the Art. 6 classification and how to decide whether a system falls in as high risk, the Art. 5 prohibitions (what is excluded by construction), the GPAI obligations of Art. 53 that affect anyone building on base models (Llama, Mistral, DeepSeek, Qwen) rather than their own, the full timetable of application dates (5 Aug 2024 entry into force, 2 Feb 2025 prohibitions, 2 Aug 2025 GPAI, 2 Aug 2026 high risk Annex III, 2 Aug 2027 high risk Annex I and systemic GPAI), the Art. 99 penalty table (up to 35 M€ or 7% of worldwide turnover for Art. 5 violations, 15 M€ or 3% for high risk, 7.5 M€ or 1% for incorrect information) and the five frequent compliance traps. The editorial thesis: the technical architecture described in this blog directly covers between 70% and 85% of the Regulation’s technical requirements; the rest is documentary and procedural discipline (FRIA, CE marking, signed declaration of conformity, EU database registration, incident reporting within legal deadlines) built on top of technical artefacts that already exist but running on its own circuit.

The analogy: the type-approval dossier for a new vehicle

A vehicle manufacturer cannot sell a new car in the EU without passing WVTA (Whole Vehicle Type Approval). The process is public and standardised: the manufacturer prepares a technical dossier with dozens of chapters (brakes, emissions, active and passive safety, lighting, noise, weight, dimensions, recyclable materials, driver assistance devices), submits it to a type-approval authority or a notified technical service, which audits the file and, if everything adds up, issues the type approval. The manufacturer then stamps the E mark (E1 Germany, E9 Spain, and so on) and the CE/UNECE plate on every vehicle of that type produced in series. Each vehicle also carries a service book with mandatory inspections, and serious accidents or systemic defects are reported to the competent ministry, which can order recalls.

The EU AI Act adapts exactly this industrial model to high-risk AI software. The provider prepares the Annex IV dossier (nine mandatory sections) with the full technical documentation of the system, runs a conformity assessment (self-assessment for most Annex III cases, notified body for the more sensitive Annex I ones), signs the EU declaration of conformity, registers the system in the European database, and applies the CE marking to the system when it is placed on the market. From there on it must keep a live post-market monitoring system and report serious incidents to the market surveillance authorities of each Member State within legal deadlines ranging from 2 to 15 days depending on severity. Failing to comply, penalties reach 35 million euros or 7% of worldwide turnover depending on which article was breached.

The analogy matters because it bounds expectations: this is not a one-off compliance job, nor a badge you buy. It is an industrial type-approval process, with cadences, evidence, signatures and criminal liability. And most of the technical evidence the dossier asks for already exists in any serious system described in this blog: data lineage, OTel tracing, continuous evals, guardrails, incident-driven retrain, a responsible-use policy. What is missing is assembling it in the correct legal format.

How it fits with ISO 42001, NIS2 and ENS

Before dropping into the articles, a reminder of the editorial position from the post on ISO 42001:

Implementing 42001 makes it easier to demonstrate articles 9-17 of the EU AI Act, but it is not equivalent to legal compliance. The table of legal obligations and the chain of criminal liability come from the Regulation, not from the standard. An organisation certified against 42001 that deploys a high-risk system without CE marking, without registration in the EU database, without a signed declaration of conformity and without a documented FRIA breaches the Regulation even with the certificate on the wall.

The four risk categories and the Art. 6 classification

The Regulation classifies systems into four risk tiers. The choice of category belongs to the provider and must be documented in the dossier, with technical and legal justification.

The Art. 6 test for deciding whether a system is high risk:

1. Is it in Annex I? (products regulated by the listed harmonisation legislation: machinery, lifts, toys, medical devices, and so on). If the AI system is a safety component of an Annex I product, it is high risk.
2. Is it in Annex III? (eight areas: biometrics, critical infrastructure, education, employment, essential public/private services, law enforcement, migration/asylum, justice/democratic processes). If the system falls in any of those areas it is high risk, except if the Art. 6.3 exception is invoked (systems performing a narrow procedural task, improving the result of a previous human activity, detecting decision patterns without influencing the final decision, preparatory tasks).

The Art. 6.3 exception requires formal documentation justifying why it does not apply. In other words, even falling outside is not free: you have to demonstrate why.

For the typical LLM systems covered in this blog:

• Customer support chatbot for banking, insurance or healthcare: probably high risk if it automates contractual decisions about the customer, limited risk if it only informs.
• Internal HR assistant (CV screening): high risk (Annex III, employment area).
• Medical assistant (diagnostic support): high risk (Annex III, healthcare services area).
• Fraud detection system: high risk (Annex III, financial services area if it affects access to credit).
• Code copilot for developers: minimal risk (does not affect third parties’ fundamental rights).
• Internal LLM as a service with no productive use: minimal risk.

The category decision is not an opinion: it is documented and justified in the dossier.

Timetable of application

The obligations arrive in stages. The dates are inflexible:

2 August 2026 is the date that matters to most enterprise LLM projects. We are in June 2026: less than two months to go.

Article-by-article mapping

The sections below follow the structure of the Regulation. For each article the requirement is stated, the blog’s technical artefact that covers it is identified, and it closes with an auditable checklist.

Art. 5 — Prohibited practices (in force since 2 Feb 2025)

What it requires. It prohibits placing on the market, putting into service or using AI systems that:

• Manipulate behaviour through subliminal or deceptive techniques that distort decision-making.
• Exploit vulnerabilities related to age, disability or socio-economic situation.
• Implement social scoring by public authorities.
• Perform individual predictive policing based on profiling.
• Perform indiscriminate facial scraping to build facial recognition databases.
• Infer emotions in workplaces or education, except for medical or safety reasons.
• Perform biometric categorisation inferring sensitive attributes (race, political opinion, sexual orientation, and so on).
• Real-time remote biometric identification in public spaces by law enforcement, with strict exceptions (terrorism, kidnapping, missing persons) subject to prior judicial authorisation.

The blog’s stack. No piece of the blog facilitates these practices; the OSS catalogue described is oriented towards legitimate tasks. But the provider must explicitly document why the system does not fall under these prohibitions. It cannot be assumed.

Checklist.

• Prohibition analysis documented per system, with a written statement of non-applicability.
• If the system uses facial biometrics or emotion analysis: specific legal analysis with a formal opinion.
• Annual legal review, or on any change of functionality.

Art. 6 — Classification of high-risk systems

What it requires. Determine whether the system is high risk by being in Annex I (safety component of a regulated product) or Annex III (8 areas). If it is in Annex III, assess the Art. 6.3 exception where applicable.

The blog’s stack. The forensic post and the six-stage pipeline describe systems that are typically high risk (multi-tenant chatbot affecting service decisions in a regulated sector).

Checklist.

• Art. 6 analysis signed by the organisation’s legal officer.
• If Art. 6.3 is invoked: formal documentation of the exception.
• Re-assessment if the functionality changes (for example, the assistant moves from informing to deciding).

Art. 9 — Risk management system

What it requires. An iterative system, planned and executed across the whole lifecycle. Identify foreseeable risks, estimate risks under normal use and foreseeable misuse, evaluate emerging risks in post-market monitoring, adopt mitigation measures, communicate residual risks. Effectiveness testing is done under realistic conditions.

The blog’s stack.

• The six-stage LLMOps pipeline, the iterative lifecycle.
• Evals: the layer after tracing, testing under realistic conditions with golden sets.
• Guardrails and safety in LLMs, operational mitigation measures.
• Retrain: closing the loop, management of emerging risks via incident-driven retrain.

Checklist.

• Risk management document per system, with identification, mitigation, and accepted residual risks signed off.
• Periodic review procedure (at least annual, or on substantial change).
• Link to the documented improvement loop.

Art. 10 — Data and data governance

What it requires. Training, validation and testing datasets that are relevant, representative, as free of errors and as complete as possible, taking into account the characteristics of the intended purpose. Document:

• Data collection and selection.
• Processing and annotation.
• Biases identified as likely to affect fundamental rights or cause discrimination; measures to prevent them.
• Identification of data gaps and how they are addressed.

The blog’s stack.

• Data versioning with DVC and lakeFS, the four data artefacts plus end-to-end lineage.
• RAG corpus curation: the active librarian, five layers: schema, dedup, PII, anti-contamination, lineage.
• LLM Guard: Vault and Anonymize, runtime anonymisation with restitution.

Checklist.

• Data governance document per dataset (training / RAG corpus / golden eval / enriched retrain).
• Bias analysis by protected category with metrics (parity ratio, equalized odds, calibration).
• PII / anonymisation / pseudonymisation procedure with measured F1.
• Justification of representativeness for the intended context.
• Verifiable chunk→trace lineage.

Art. 11 + Annex IV — Technical documentation

What it requires. A technical dossier with the nine Annex IV sections, drawn up before the system is placed on the market, maintained during operation, and available to authorities for ten years after the last operation. The nine sections:

1. General description of the system: name, version, purpose, integrator, intended hardware, instructions for use.
2. Detailed description of design and development: architecture, base models, training methods, design decisions with justification.
3. Information on monitoring, functioning and control: capabilities, limitations, expected accuracy, behaviour under normal use and foreseeable misuse.
4. Information on data: datasets used, sources, preparation methods, biases addressed.
5. Description of the monitoring system and metrics: traces, logs, dashboards.
6. Description of the QMS and the Art. 17 procedures.
7. FRIA where applicable (Fundamental Rights Impact Assessment, Art. 27).
8. Automatically generated logs that the system stores (Art. 12).
9. EU declaration of conformity under Art. 47, included.

The blog’s stack. It serves as a direct input for each section:

Checklist.

• Annex IV dossier complete, versioned, dated, signed.
• 10-year retained access guaranteed (immutable / WORM storage).
• Update procedure on substantial change.

Art. 12 + Art. 19 — Record-keeping (logs)

What it requires. A high-risk system must be technically capable of generating automatic logs during its operation. Those logs must allow:

• Tracing how the system behaved over time.
• Facilitating post-market monitoring (Art. 72).
• Enabling investigation of serious incidents (Art. 73).
• Supporting audits.

The provider must retain the logs for at least six months (or longer if national laws or the QMS require it). For remote biometric identification systems there are additional specific requirements.

The blog’s stack.

• LLM tracing with OpenTelemetry GenAI, the canonical substrate. Every request emits a span with trace_id, gen_ai.* attributes, costs, latencies and guardrail decisions.
• Prompt versioning: prompt_id + version travel as attributes.
• Guardrails and safety in LLMs: gen_ai.guardrail.* attributes record every decision.
• LLM Guard: spans per scanner with risk_score and action.
• Data versioning: dataset_hash and model_version propagated.

Checklist.

• OTel + backend (Tempo, Jaeger) running in production.
• Minimum 6-month retention (24-36 months suggested for financial regulation).
• WORM / immutable storage.
• PII in logs redacted (via LLM Guard Vault or equivalent). Logs are not exempt from the GDPR.
• Forensic query procedure with audited permissions.

Art. 13 — Transparency to deployers

What it requires. The provider gives the deployer instructions for use that are clear, complete and accessible, in comprehensible language, covering:

• The provider’s identity.
• Characteristics, capabilities, limitations (accuracy by category, technical specifications).
• Foreseen changes to the system and its metrics.
• Human oversight measures (Art. 14).
• Expected computational resources and hardware.
• When it applies, the expected lifetime of the system and of its maintenance.

The blog’s stack.

• The OSS catalogue for LLMOps, which components and with what function.
• OSS vs hyperscalers, lock-in analysis and documented dependencies.
• Anatomy of an LLM request, capabilities and limitations at forensic level.

Checklist.

• User manual in non-technical language for the deployer, plus a detailed technical manual.
• Accuracy metrics by category with thresholds.
• Change procedure with prior notification.

Art. 14 — Human oversight

What it requires. The system is designed to allow effective human oversight throughout the period of use, with interfaces and procedures that make it possible to:

• Understand capabilities and limitations.
• Detect malfunctions (automation bias awareness).
• Decide not to use the system’s output, to override it, to reverse it.
• For remote biometric identification: human verification before acting, by at least two people.

The blog’s stack.

• Guardrails and safety, line 3 (Tool GR) with human-in-the-loop for destructive actions.
• Evals, metrics on a human-accessible dashboard.
• OTel tracing, Langfuse with auditable human sessions.

Checklist.

• Oversight interface documented with use cases.
• Override / abort capability with no technical restrictions.
• Documented training for oversight personnel.
• Metrics of the effectiveness of the oversight (override rate, false-negative rate of the oversight itself).

Art. 15 — Accuracy, robustness and cybersecurity

What it requires. High-risk systems are designed and developed to reach an appropriate level of accuracy, robustness and cybersecurity, and to perform consistently throughout their lifecycle. The relevant accuracy metrics are declared in the instructions for use. Resilience against:

• Errors, faults and inconsistencies within the environment of use.
• Feedback bias during operation (feedback loops).
• Attacks that try to exploit the system’s vulnerabilities (data poisoning, model poisoning, model evasion, confidentiality attacks).
• Technical and organisational measures to detect, respond to and resolve vulnerabilities.

The blog’s stack.

• Quantisation fundamentals, accuracy vs efficiency with reported metrics.
• Continuous batching + KV cache, operational robustness.
• Guardrails: line 1 input + line 2 retrieval, defence against prompt injection and data poisoning via RAG.
• LLM Guard: PromptGuard 2 + injection scanners, direct adversarial mitigation.
• Evals: jailbreak resistance + adversarial, robustness metrics evaluated in CI.

Checklist.

• Declared accuracy metrics: F1 by category, accuracy, calibration, RAG faithfulness, hallucination rate.
• Robustness plan against adversarial inputs (Garak suite / Promptfoo redteam / PyRIT run periodically).
• Cybersecurity plan: vulnerability management, patching of the stack (vLLM, its deps, CUDA), secrets rotation.
• Analysis of potential feedback loops with drift monitoring.

Art. 17 — Quality management system (QMS)

What it requires. The provider has a written, systematic and proportionate QMS covering (without being limited to):

• Regulatory compliance strategy.
• Design, verification and quality control of the system.
• Testing and validation procedures.
• Data management.
• The risk management system (Art. 9).
• Post-market monitoring (Art. 72).
• Incident reporting (Art. 73).
• Communication with authorities, deployers and other stakeholders.
• Records: documentation, log maintenance.
• Resource management.
• Accountability: management responsibilities.

The blog’s stack. The QMS is not code, but it leans on code.

• ISO/IEC 42001 implemented (previous post) covers practically the whole content of Art. 17.
• Six-stage LLMOps pipeline as the reference operating procedure.

Checklist.

• QMS manual written, dated, signed, versioned.
• Annual internal audit plan with criteria and records.
• Management review agenda with signed minutes.
• If 42001 is implemented: documented QMS-42001 mapping.

Art. 26 — Deployer obligations

What it requires. Whoever deploys the system (uses it under their own authority, not necessarily the developer) has obligations of their own:

• Use the system in accordance with the instructions (Art. 13).
• Assign competent, trained human oversight (Art. 14).
• Ensure the input data under their control is appropriate.
• Monitor operation and notify the provider on detecting problems or serious incidents.
• Keep the logs under their control for at least 6 months.
• Inform the affected persons when the system is used on them to make decisions (and, in an employment context, also consult their representatives).
• For some Annex III cases: complete a FRIA (Art. 27).

The blog’s stack. In the case of the multi-tenant chatbot, the deployer is the client insurer. It must:

• Accept the provider’s instructions (the consultancy’s) and sign the terms.
• Configure human oversight on its side.
• Notify the provider when it detects drift or a serious complaint.
• Keep its own logs in addition to the provider’s.

Checklist (for the deployer).

• Contract with the provider covering SLAs, responsibilities, exit plan.
• Training programme for oversight personnel.
• Incident notification procedure towards the provider.
• Policy for informing affected persons (in the employment context, notification to representatives).
• FRIA where applicable.

Art. 27 — Fundamental Rights Impact Assessment (FRIA)

What it requires. Applicable to deployers that are public bodies or private entities providing public services, or that use systems to assess credit score or life insurance. Before first use, the deployer carries out a FRIA documenting:

• A description of the intended use.
• Period and frequency of use.
• Categories of affected persons.
• Specific risks of harm identified.
• Human oversight measures.
• Mitigation measures should the risks materialise.

The FRIA is notified to the market surveillance authority. Substantial changes force an update.

The blog’s stack. The FRIA is a governance document, not a technical artefact. The blog does not cover it directly. But the technical input is:

• The impact analyses from the ISO 42001 post, section A.5 are the natural starting point.
• The metrics from the evals post on fairness by category and groundedness feed the risk section of the FRIA.

Checklist.

• FRIA procedure documented, aligned with the AIIA in ISO 42005 (published as a complement).
• FRIA carried out per system before first use.
• Notification to the market surveillance authority.
• Periodic review, plus on substantial change.

Art. 47 — EU declaration of conformity

What it requires. The provider draws up a written declaration of conformity per high-risk system, stating:

• Identification of the system and the provider.
• A statement that it complies with Arts. 8-15 + Art. 17.
• Reference to the harmonised standards and common specifications applied.
• Where applicable, the notified body and the certificate.
• Place and date, signature and name of the authorised signatory.

It must be available to authorities for ten years. It is kept up to date.

The blog’s stack. A pure legal document. Template in Annex V.

Checklist.

• Declaration of conformity signed by an authorised person before market placement.
• Languages: at least the official EU language of the market where the system is placed.
• Re-signing procedure on substantial change.

Art. 48 — CE marking

What it requires. A high-risk system carries the CE marking visibly, legibly and indelibly. For digital systems with no physical part, the marking is included in the documentation or the interface. If a notified body was involved, its number follows.

The blog’s stack. CE marking on a software system typically materialises in:

• The product information or “About” page.
• The official product documentation delivered to the deployer.
• Metadata of the exposed API (custom HTTP header, OpenAPI info).

Checklist.

• CE marking visible in the product interface or official documentation.
• Notified body number attached where applicable.
• Update procedure on substantial change.

Art. 49 — Registration in the European database

What it requires. Before placing on the market or putting into service a high-risk Annex III system (except area 2, critical infrastructure), the provider registers it in the EU database of high-risk AI systems managed by the Commission. Deployers that are public authorities also register their use. Most registration data is public (transparency towards the public).

The blog’s stack. A pure administrative procedure. No technical part beyond having the dossier ready.

Checklist.

• Registration completed before first productive use.
• Update on substantial change.
• Portal access maintained (credentials, contact).

Art. 50 — Transparency to end users

What it requires. Applies to limited risk systems (and, complementarily, to some high-risk ones too):

• Chatbots and AI assistants: the person interacting must know they are talking to an AI, unless it is obvious from the context.
• Generated synthetic content (text, audio, image, video): marked as AI-generated in the output, in a machine-readable format.
• Deepfakes: explicitly declare that the content is artificially generated or manipulated.
• Emotion detectors or biometric categorisation: inform the affected persons.

The blog’s stack. Technical materialisation:

• A UI banner in the chatbot saying “You are talking to an AI assistant”.
• A disclaimer on every exportable response (PDF, email): “Generated by AI”.
• Watermarking of the output (perplexity-based, model-fingerprint), optional but useful for deepfakes.
• For generated audio, image or video, standard C2PA metadata.

Checklist.

• Mandatory UI banner.
• Disclaimer on exportable outputs.
• If it generates visual content: C2PA marking or equivalent.
• Procedure for use of the system on a person without their knowledge (for example, automated CV screening).

Art. 53 — Obligations of GPAI providers (in force since 2 Aug 2025)

What it requires. Providers of GPAI (general-purpose models trained with vast compute, typically foundational: Llama 4, Mistral, DeepSeek, Qwen, Gemma) must:

• Maintain technical documentation of the model, accessible to the AI Office and national authorities.
• Make information available to downstream providers that will integrate it.
• Comply with EU copyright (Art. 4 of Directive 2019/790): an opt-out mechanism for rightsholders.
• Publish a summary of the training content (Annex XI, copyright summary).

If the model has systemic risk (10^25 FLOPs threshold, or designated by the Commission), additional obligations apply (Art. 55): model evaluation, adversarial testing, incident reporting, cybersecurity.

The blog’s stack. For an organisation that uses GPAI models (Llama 4, Mistral) and does not train them from scratch:

• It is not a GPAI provider; it is a downstream provider integrating GPAI into its system.
• It must hold the GPAI technical documentation (Llama paper, Mistral docs) and reference it in its own Annex IV documentation.
• Analysis of the specific GPAI licence (Llama Community License, Apache 2.0, and so on).
• The post on modern alignment and continuous fine-tuning describe how a LoRA adapter on top of the GPAI does not turn the downstream party into a GPAI provider, as long as it does not train a new model from scratch.

Checklist (downstream provider).

• Inventory of GPAI models used, with version, source, licence, referenced documentation.
• EU copyright compliance analysis (Art. 4 of Dir. 2019/790).
• Mapping of responsibilities between the upstream GPAI provider and us as downstream.

Art. 72 — Post-market monitoring

What it requires. A documented post-market monitoring system proportionate to the risk, collecting data on performance throughout the lifecycle, including interaction with other AI systems. It allows the provider to:

• Assess continuous compliance with Arts. 8-15.
• Adopt the necessary corrective measures.
• Detect trends in real use (drift, abuse).

The monitoring plan is part of Annex IV and is maintained throughout the system’s life. The Commission publishes a template in 2026.

The blog’s stack.

• OTel tracing + Langfuse, the base.
• Continuous evals, operational metrics as online gates.
• LLM-as-judge, judges over production sampling to detect degradation.
• Incident-driven retrain, the closed improvement loop.

Checklist.

• Post-market monitoring plan documented per system.
• Operational metrics defined with thresholds and periodic review.
• Corrective action procedure on alert.
• Integration with Art. 73 (when an alert equals a serious incident).

Art. 73 — Serious incident reporting

What it requires. The definition of a serious incident (Art. 3(49)):

• Death or serious harm to health.
• Serious disruption of critical infrastructure.
• Infringement of legal obligations intended to protect fundamental rights.
• Serious damage to property or the environment.

The provider reports to the market surveillance authority of the Member State where the incident occurred. Deadlines:

The first report may be preliminary; the complete one follows later. Internal investigation is mandatory, as is cooperation with the authorities. Corrective action is proportionate.

The blog’s stack. The technical flow:

• OTel tracing provides the traceability for forensic investigation.
• Guardrails and safety emits the canonical incident_event (category, severity, trace_id).
• Incident-driven retrain materialises the corrective action.

Checklist.

• Incident reporting procedure documented with deadlines and templates.
• Designated person (typically DPO + AI Risk Owner) with responsibility and training.
• Annual dry-run of the procedure (drill).
• Technical integration between the guardrails / tracing layer and the notification channel.

The assembled Annex IV dossier: SVG of the complete file

The diagram shows the blog’s editorial asymmetry: seven of the nine Annex IV sections are covered directly by the technical stack. Only the FRIA (section 7) and the signed declaration of conformity (section 9, not shown in the SVG because it is a one-page document) are documentary gaps needing express administrative work. The main compliance effort is assembling and signing, not building from scratch.

Applied case: the multi-tenant chatbot assessed against the AI Act

We take the system from the forensic post, a multi-tenant customer support chatbot for insurers, and walk through it as the provider of the system.

Art. 6 classification: the chatbot helps customers understand products, check status and open tickets. It does not automate contractual decisions (it does not approve claims, it does not calculate premiums). Does it fall into Annex III area 8 (essential private services)? That depends on the use. If the insurer uses it only for informational support, it is limited risk (Art. 50 applies). If it uses it to assess claim declarations, it is high risk. Documenting the analysis is mandatory.

We assume high risk for the complete walkthrough:

• Art. 5 prohibitions: written statement of non-applicability. ✓
• Art. 9 risk management: per-system document with identified risks (hallucination, dialect bias, PII leakage, jailbreak), applied mitigations (RAG over a curated corpus, guardrails with 4 lines, LLM Guard Vault, continuous evals) and signed accepted residuals. ✓ (input: pipeline + guardrails + evals).
• Art. 10 data governance: governance of the four datasets (training adapter, insurer RAG corpus, golden eval, enriched retrain) with biases analysed, PII anonymised, lineage in place. ✓ (input: data-versioning + rag-corpus-curation + LLM Guard).
• Art. 11 + Annex IV: dossier with 9 sections drafted, signed, accessible for 10 years in a WORM bucket. ✓ (7 sections from the blog, 2 new).
• Art. 12 + Art. 19 logs: OTel + Tempo + Langfuse with 24-month retention, PII redacted by Vault. ✓
• Art. 13 transparency to deployers: user manual for the insurer plus a technical manual. ✓ (input: OSS catalogue + request anatomy).
• Art. 14 human oversight: Langfuse + Grafana dashboard, human escalation protocol for critical cases, training for the insurer’s staff. ✓
• Art. 15 accuracy, robustness, cybersecurity: F1 by category declared, Promptfoo redteam adversarial suite run monthly, stack cybersecurity plan (vLLM patching, secrets rotation). ✓
• Art. 17 QMS: ISO 42001 implemented and certified. ✓
• Art. 26 deployer: the contract with the insurer includes the deployer’s obligations. ✓
• Art. 27 FRIA: the insurer carries out a FRIA before first use (it is a private essential-service entity). ✓ (deployer’s responsibility, the provider assists).
• Art. 47 declaration of conformity: signed by the consultancy’s CTO before market placement. ✓
• Art. 48 CE marking: visible in the chatbot interface and in the official documentation. ✓
• Art. 49 EU DB registration: completed before first productive use. ✓
• Art. 50 transparency to users: UI banner “You are talking to an AI assistant”, disclaimer on exportable responses. ✓
• Art. 53 GPAI: Llama 4 documentation (the base model) referenced, plus EU copyright analysis and responsibility mapping. ✓
• Art. 72 post-market monitoring: documented plan, OTel + continuous evals + retrain already running. ✓
• Art. 73 incident reporting: procedure, designated owner, annual dry-run. ✓

Result: certifiable and deployable on the EU market on 2 August 2026. The key gaps (FRIA, CE marking, EU DB registration, declaration of conformity) are documentary work over technical artefacts that already exist, not new technical projects.

Penalties (Art. 99)

The penalty table is proportional to worldwide turnover or to an absolute cap, whichever is higher:

For SMEs and startups the caps are the lower of the two figures (not the higher). The proportionality mitigation exists but requires formal demonstration.

In addition, national authorities can order:

• Immediate suspension of the system on the market.
• A mandatory recall.
• Mandatory public communication of the penalty.

The five frequent compliance traps

Trap 1 — Assuming the GPAI model used already covers the obligations. The downstream provider remains responsible for the integrated system: neither Meta nor Mistral nor DeepSeek takes on the obligations of whoever builds on their models. The trap surfaces when the authority asks for the dossier and the team points at the Llama model card as if that were enough.

Trap 2 — Confusing ISO 42001 with EU AI Act conformity. Holding a 42001 certificate does not imply conformity: certification is not a FRIA, not CE marking, not EU database registration, not a signed declaration of conformity. Standardisation is progressing, but until ISO 42001 is published as a harmonised standard (it was not at the end of 2025), there is no presumption of conformity. The table of legal obligations runs on its own circuit.

Trap 3 — Forgetting incident reporting within the legal deadline. Fifteen days sounds long until an incident lands in the middle of the summer holidays. Two days for critical infrastructure is not negotiable. Without a documented procedure and an annual drill, the deadline is missed in silence. A penalty for misleading information (1% of worldwide turnover) follows if the incomplete reporting is discovered.

Trap 4 — Underestimating the deployer. The AI Act assigns obligations to both the provider and the deployer. A company that uses a hosted LLM integrated into its service (without developing it) is still a deployer with obligations of its own (Art. 26): human oversight, FRIA where applicable, notification to affected persons. The trap surfaces when the deployer assumes that “responsibility lies with the model provider”. It does not, not entirely.

Trap 5 — Leaving the FRIA until last. The FRIA (Art. 27) requires a fundamental rights impact analysis with qualitative dimensions (discrimination, privacy, social rights). It is not an afternoon’s document. It is carried out before first use, not after a problem is detected. Public deployers and private essential-service providers who leave it for “whenever they ask” take 4-8 weeks to produce a credible one, time they typically do not have when the inspection arrives.

What we have not covered (upcoming posts)

• Concrete templates for each document: EU declaration of conformity (Annex V), full Annex IV dossier section by section, FRIA, post-market monitoring plan, initial serious incident report. Material for a post along the lines of “The EU AI Act compliance folder in 12 templates”.
• Voluntary codes of practice published by the Commission under Art. 56, useful for limited-risk systems that want to demonstrate good behaviour without a legal obligation.
• Comparative analysis of notified bodies for systems requiring third-party conformity assessment (mainly Annex I).
• How compliance changes for LLM agents, systems with graduated autonomy, tool calling and the capacity to act. SC 42 and the AI Office are working on specific guidance.
• The complete map of national authorities designated under Art. 70, plus the sectoral authorities that retain jurisdiction (AEPD for privacy, CNMV for financial services, Banco de España for banking, AESA for aviation).

References

• Regulation (EU) 2024/1689 (EU AI Act) — Texto consolidado en EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689. Diario Oficial L 1689/12.7.2024.
• EU AI Act Explorer (AI Act Service Desk, Comisión Europea): https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer.
• AI Act Text portal (artificialintelligenceact.eu): artículos individuales con anotaciones.
• Anexo IV — Technical documentation: estructura de los nueve apartados obligatorios.
• Anexo V — EU declaration of conformity: plantilla obligatoria.
• Anexo III — High-risk AI systems: las ocho áreas que clasifican un sistema como alto riesgo.
• Anexo XI — Copyright training summary template: para GPAI providers.
• NIST AI RMF 1.0 (2023) — https://www.nist.gov/itl/ai-risk-management-framework.
• ISO/IEC 42001:2023 — sistema de gestión, complemento facilitador.
• ISO/IEC 42005 — Impact assessment AI (publicada 2025 como guía técnica para FRIA).
• Draft Commission guidance on serious incident reporting (2025) — borrador en consulta para Art. 73.

See also

• Hardening and secrets in the sovereign LLM stack: defence in depth — the technical hardening measures that back the dossier.

• ISO/IEC 42001: the operations manual for the AI system — the sister post on the management system that makes Arts. 9, 10, 11 and 17 of the Regulation easier to demonstrate.

• The six-stage LLMOps pipeline — the lifecycle that operationally materialises Arts. 9 (risk management) and 17 (QMS).

• Anatomy of an LLM request in production — the forensic case used as a compliance checklist in this post.

• Data versioning with DVC and lakeFS and RAG corpus curation — Art. 10 data governance.

• LLM tracing with OpenTelemetry GenAI — Arts. 12 + 19 (record-keeping) with canonical OTel.

• Guardrails and safety in LLMs — Arts. 14 (human oversight) and 15 (cybersecurity/robustness).

• LLM Guard: the sworn translator with a book of equivalences — Art. 10 + Art. 12 with PII redacted on the runtime path.

• Evals: the layer after tracing — Art. 15 (accuracy) and Art. 72 (post-market monitoring).

• Retrain: closing the feedback → dataset → adapter loop — Art. 72 continuous improvement + Art. 73 corrective action after an incident.

• The parallel catalogue: OSS vs hyperscalers — Art. 53 (GPAI obligations) and analysis of integrated GPAI providers.

• The OSS catalogue for LLMOps — Art. 13 (transparency to deployers) with a complete component inventory.

• Modern alignment: DPO, KTO, ORPO and SimPO — responsible adapter design (Art. 9 mitigation + Art. 15 robustness).

• Technical controls: the cross-mapping of ENS × ISO 42001 × EU AI Act — the technical zoom into the overlap of the three frameworks. A single tracing piece, a single guardrails piece and a single versioning piece materialise the technical requirements of ENS + 42001 + AI Act simultaneously when labelled with a common vocabulary.

• Incident response runbooks for LLMs with Keep + Kafka — the operationalisation of Art. 73 (reporting of serious incidents) with 2/10/15-day deadlines by severity, Keep YAML workflows and the WORM Kafka topic audit.actions as evidence for the competent authority.