Template
EU AI Act Article 12 - Logging and Traceability Template
Article 12 is where the documentation has to show that a run can be reconstructed outside your internal dashboards. The hard part is not having logs in principle. The hard part is having a record trail that another team can actually inspect, follow, and retain. For high-risk systems, that trail still has to fit into a broader Annex IV documentation package.
Who supplies what
What Article 12 expects, what the toolkit can add, and what your team still owns
Without connecting your agent, the toolkit can only show the trace and logging artifacts already present in the generated package. After adapter integration, it can preserve run records, tool telemetry, result and error artifacts, and trace anchors from real runs.
| Article 12 expects | Toolkit with generated package only | Toolkit after adapter integration | Still defined and approved by your team |
|---|---|---|---|
| A reviewable event trail | Shows compare-report data, retained case artifacts, and manifest-backed file integrity already present in the package. | Adds run records, tool telemetry, result artifacts, error artifacts, and trace anchors from real runs. | Define which systems must be logged, what counts as a complete record, and which gaps need compensating controls. |
| A link between the report and the underlying run | Can show report IDs, manifest entries, and retained artifacts already bundled together. | Can point from the report back to concrete run files and case-level artifacts from the connected agent. | Explain any external trace systems, storage layers, or identifiers that live outside the toolkit. |
| A record path after something goes wrong | Lets another team inspect the generated report, compare file, and retained artifacts already in the package. | Lets another team open the underlying run records and tool-level artifacts tied to the same cases. | Define who may access those records, under what workflow, and how incident or audit access is granted. |
| Retention and deletion controls | Shows retention-control output and the retained files already inside the package. | Can include the real run artifacts and telemetry files that your retention policy needs to cover. | Set retention period, deletion rules, export policy, and legal disclosure rules. |
Manual fields
What your team still defines around Article 12
The toolkit can preserve and package records, but it does not choose your retention posture or disclosure rules. Those decisions still belong in your logging policy and governance workflow. Article 12 therefore becomes one reviewed layer inside the larger high-risk package, not the whole package by itself.
| What you define | When you define it | Practical format to use |
|---|---|---|
| Retention period and storage location | Before you rely on the package for governance review or external handoff. | A simple policy statement naming how long records are kept and where the retained files live. |
| Access and disclosure rules | When the package may be opened by security, governance, counsel, or an external reviewer. | A short access matrix naming who can inspect which logging artifacts and under what trigger. |
| External trace-system references | Whenever your trace chain spans systems outside the toolkit package. | System name, identifier format, and the lookup path needed to continue the trace outside the package. |
| Known logging gaps and compensating process | When the connected adapter does not emit all of the logging depth you want. | One short gap note plus the manual or external process that fills it. |
| Legal export and deletion constraints | Before evidence is handed to another team or retained for a longer period. | Short policy text naming when records may be exported, redacted, or deleted. |
How this fits into the full package
Article 12 is evidenced through multiple logging and trace files
There is no single Article 12 JSON file in the package. The requirement is covered through the files below. Their layout is the toolkit's structured format for these requirements, not an EU-mandated form.
| File in the package | Why it matters for Article 12 | Open file |
|---|---|---|
| Compare report - compare-report.json | Main review file linking case outcomes, trace integrity, and retained artifacts. | Open file |
| Manifest - artifacts/manifest.json | Integrity index showing which files belong to the package and how they are anchored. | Open file |
| Source run record - _source_inputs/new/run.json | Example raw run record used to reconstruct a concrete execution path. | Open file |
| Retention controls - archive/retention-controls.json | Archive and retention observations attached to the package. | Open file |
FAQ
Frequently asked questions
What is the Article 12 - Logging and Traceability template page for?
This page explains what the Article 12 - Logging and Traceability template section usually needs to cover inside an EU AI Act package, which parts can be supported by structured evidence, and which parts remain owned by the provider, deployer, or legal reviewer.
Does this Article 12 - Logging and Traceability template page create a complete EU AI Act package?
No. It is one section-level guide. A review-ready package still needs the selected role and scope, the other applicable article-level sections, linked technical evidence, owner completion, and final human review.
What evidence should be linked to the Article 12 - Logging and Traceability template section?
Use evidence that is current, traceable to the relevant system version, and connected to real runs, retained records, or approved procedures. A weak package relies only on narrative text; a stronger package links the narrative to reproducible artifacts.
Who should review the Article 12 - Logging and Traceability template section before handoff?
The technical owner should confirm the system facts and evidence links, while compliance or legal reviewers confirm whether the section is sufficient for the selected EU AI Act role, scope, and conformity path.