Sovergate
← Back to Blog
Compliance9 min read · 24 June 2026

Article 11 vs Article 12 of the EU AI Act: Documentation vs Logging

Both apply to high-risk AI systems. Both are about traceability. Both will be checked by regulators. But they are different obligations producing different artefacts — and you need both.

Two of the most frequently confused provisions in the EU AI Act are Article 11 and Article 12. Both apply to high-risk AI systems. Both are about traceability. Both will be checked by regulators. And teams routinely assume that satisfying one satisfies the other.

It does not. Article 11 and Article 12 are different obligations producing different artefacts on different timelines. You need both, and you need to understand the distinction before you build either.

This guide explains what each article requires, how they differ, where they overlap, and what a high-risk AI operator must actually produce to satisfy both.

The one-sentence distinction

Article 11 is a document you write once and maintain. Article 12 is a stream of records your system generates automatically, forever.

Article 11 describes the system. Article 12 records what the system did. One is static and human-authored; the other is dynamic and machine-generated. If you only have one, you are not compliant.

What Article 11 requires

Article 11 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to draw up technical documentation before the system is placed on the market or put into service, and to keep it up to date.

The technical documentation is a dossier. Its purpose is to demonstrate that the system complies with the requirements of the AI Act, and to give national competent authorities the information they need to assess that compliance. The detailed contents are set out in Annex IV, and include:

  • A general description of the AI system — its intended purpose, the people who developed it, and how it interacts with hardware or other software
  • The design specifications, system architecture, and the computational resources used to develop, train, test, and validate the system
  • Information about the data — training, validation, and testing datasets, their provenance, scope, and how they were labelled and cleaned
  • The risk management system required under Article 9, and the measures taken to address risks
  • A description of the human oversight measures in place under Article 14
  • The validation and testing procedures used, and the metrics for accuracy, robustness, and cybersecurity
  • A description of the logging capabilities — which is where Article 11 points directly at Article 12

That last point matters: Annex IV explicitly requires the technical documentation to describe the system's logging capabilities. Article 11 and Article 12 are wired together by design.

What Article 12 requires

Article 12 requires that high-risk AI systems technically allow for the automatic recording of events (logs) over the lifetime of the system.

Where Article 11 is a description, Article 12 is a live evidence stream. It mandates that the system itself generate records, automatically, for the entire time it is in operation. Those logs must support three regulatory purposes: identifying situations where the system may present a risk, facilitating post-market monitoring, and enabling operational oversight by deployers.

The phrase that does the work is technically allow. A manual process does not satisfy Article 12. A human writing notes does not satisfy it. The capability must be built into the system, generating complete, tamper-evident records every time the system runs.

We cover the full mechanics — what to capture, retention periods, tamper-evidence, and the GDPR intersection — in our complete Article 12 compliance guide.

Side-by-side comparison

DimensionArticle 11 — Technical DocumentationArticle 12 — Logging
What it isA written dossier describing the systemAn automatic stream of event records
Who creates itHumans — engineering, legal, complianceThe system itself, automatically
WhenBefore market placement; kept up to dateContinuously, over the system's lifetime
NatureStatic document, periodically revisedDynamic, generated in real time
Governing detailAnnex IVArticle 12(2)–(3), with Article 26(6) on retention
Primary audienceNotified bodies, market surveillance authoritiesAuditors, post-market monitoring, incident investigation
Core question it answers“How was this system designed and tested?”“What did this system actually do on this date?”
Failure mode if missingCannot demonstrate conformity at assessmentCannot reconstruct or defend any individual decision

Where they overlap

The two articles are not isolated. Three connection points are worth understanding.

The documentation must describe the logging.

Annex IV requires the Article 11 dossier to set out the system's logging capabilities. So your Article 12 implementation becomes a documented feature inside your Article 11 file. If your technical documentation claims a logging capability your system does not actually deliver, that is a discrepancy a regulator can find.

Both feed post-market monitoring.

Article 72 requires providers to monitor system performance after deployment. The Article 11 documentation establishes the baseline — what the system was designed to do and how it performed in testing. The Article 12 logs provide the live evidence of how it performs in production. Monitoring is the act of comparing the two.

Both are evidence in an enforcement action.

When a national authority investigates a high-risk system, they will ask for the technical documentation and the logs. The documentation tells them what you intended; the logs tell them what happened. Inconsistencies between the two are exactly what investigations surface.

A worked example

Consider a bank running an AI creditworthiness model — high-risk under Annex III, Category 5.

Article 11 is the file the bank prepares before deployment: a description of the model, the training data and its provenance, the validation metrics, the risk management measures, the human oversight design, and a description of how the system logs its decisions. The bank writes this once and updates it when the model changes materially.

Article 12 is what happens every time the model scores an applicant: an automatic, timestamped, tamper-evident record of the decision — the pseudonymised inputs, the output, the model version, whether a human reviewed it, and the final decision taken. The bank does not write these; the system generates them, continuously, for the lifetime of the model.

If a rejected applicant complains to a regulator eighteen months later, the bank needs both: the Article 11 documentation to show the model was designed and validated responsibly, and the Article 12 log to show exactly what the system did in that specific case on that specific date.

Common mistakes

Treating documentation as a substitute for logging

A thorough Article 11 dossier does not reduce your Article 12 obligation by one line. They are separate requirements.

Describing a logging capability you have not built

If your Annex IV documentation describes automatic, tamper-evident logging and your production system only writes rotating application logs, your own documentation has identified your non-compliance.

Letting the two drift apart

When the model is updated, both must move together. A new model version is a change to the system described in Article 11 and a new value in the Article 12 logs. If documentation lags behind what is actually in production, the inconsistency is the finding.

Assuming the provider handles both

If you deploy a third-party high-risk system, you have your own obligations under Article 26 — including ensuring the system actually generates the logs Article 12 requires. The provider's documentation does not discharge your operational logging duty.

What you need to produce, in practice

To satisfy both articles for each high-risk AI system, you need:

1.
An Annex IV technical documentation filewritten, maintained, and including an accurate description of your logging capability.
2.
An automatic logging implementationcapturing every decision, tamper-evident, retained for at least six months, with PII scrubbed before storage and data held in an EU jurisdiction.
3.
A consistency processso that when the system changes, both the documentation and the logging configuration are updated together.

Article 11 is a project your legal and engineering teams complete and maintain. Article 12 is infrastructure you install once and let run. Sovergate handles the second: the SDK instruments your LLM calls in two lines, scrubs PII locally, stores logs on German bare-metal infrastructure, and generates the audit-ready records your Article 11 documentation will need to describe accurately.

Frequently asked questions

Is Article 11 or Article 12 more important?

Neither — they are not substitutes. A regulator assessing a high-risk system expects both the technical documentation and the operational logs. Missing either is a compliance gap.

Does Article 11 apply to deployers or only providers?

The Article 11 technical documentation obligation falls primarily on providers. Deployers have related obligations under Article 26, including ensuring the system generates Article 12 logs and retaining those logs.

Can the same artefact satisfy both articles?

No. Article 11 is a human-authored description prepared before deployment; Article 12 is a machine-generated record produced during operation. They are different artefacts with different purposes.

Where is the detailed content of the technical documentation defined?

Annex IV of the EU AI Act sets out the required contents of the Article 11 technical documentation, including the requirement to describe the system's logging capabilities.

This guide is maintained by Sovergate, a European AI compliance platform providing Article 12 logging for companies using LLMs in high-risk contexts. It is for informational purposes only and does not constitute legal advice. Regulation referenced: EU Regulation 2024/1689 (EU AI Act), Articles 11, 12, 26, 72; Annex IV.

Last updated June 2026.

Ready to build the logging side of your compliance file?

Two lines of code. PII scrubbed locally. Data stored in Germany. Monthly compliance reports ready for your legal team.