AI

EU AI Act Article 12: What Your RAG System Has to Log, and What Most Don't

·7 min read

Article 12 of the EU AI Act requires high-risk AI systems to technically allow for the automatic recording of events over the lifetime of the system. “Automatic” is doing real work in that sentence: the system has to generate the logs itself, and a documented manual process does not satisfy it.

The deadline moved — the obligation did not. The original date was 2 August 2026. The Digital Omnibus on AI, given final Council approval on 29 June 2026, deferred high-risk obligations to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in regulated products. Article 12 sits in the chapter that was deferred. Note that 2 August 2026 still matters for other reasons — Article 50 transparency duties were not postponed — but record-keeping is not among them.

Two reasons to build for it anyway. The substance of Article 12 was not weakened, only delayed; and the deferral exists largely because harmonised standards and national authorities were not ready, which is a statement about regulators’ readiness rather than about whether the requirement is coming.

Article 12 applies to high-risk systems, not to all AI. If your retrieval system touches hiring, credit, healthcare, education, essential services, or the other Annex III categories, this is likely your obligation rather than your vendor’s. If it does not, most of what follows is good engineering practice rather than a legal duty — worth reading in that spirit, not as something you must do.

This post maps the obligation to the records a retrieval layer can actually emit, and is explicit about the parts it cannot.

This is engineering guidance, not legal advice. Whether your system is high-risk, and what satisfies your obligation, is a question for your counsel.

Regulatory status last reviewed: 11 August 2026. The AI Act timeline has already moved once — the original 2 August 2026 date for high-risk obligations was deferred by the Digital Omnibus. If you are reading this well after the review date, verify the current position before relying on any date below.

What Article 12 actually says

Paragraph 1 is the core: high-risk AI systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”

Paragraph 2 says those logs must enable recording of events relevant to three things:

  • identifying situations where the system may present a risk under Article 79(1), or undergo a substantial modification
  • facilitating post-market monitoring under Article 72
  • monitoring the operation of the system under Article 26(5)

Paragraph 3 adds specific minimum records for biometric systems — the period of each use, the reference database checked against, the input data that produced a match, and identification of the people who verified the results. If you are not doing biometrics, paragraph 3 is not your problem; paragraphs 1 and 2 still are.

Two related obligations matter as much in practice:

  • Article 26(6) requires deployers to retain automatically generated logs for at least six months, where those logs are under their control. It follows the same deferred timeline.
  • Regulators read “appropriate to the intended purpose” in Article 12 as implying tamper-evidence. A log an operator can quietly edit is weak evidence.

Why the deployer position is the uncomfortable one

The obligation does not transfer with the software. If you deploy a high-risk system, you are accountable for these records regardless of who built it. You cannot buy your way out by choosing a vendor who says they are compliant — and a deferred deadline does not change who is on the hook when it arrives.

This has a direct architectural consequence that is easy to miss: if you cannot outsource the accountability, you cannot comfortably outsource the corpus either. An auditor asking “who could see this document on this date, and what did the model retrieve” needs an answer from records you hold, about data you control.

The question most RAG stacks cannot answer

Here is a realistic audit question:

On 14 March, this applicant was rejected. What did the system retrieve to produce that answer, who was the requesting user, what were they permitted to see, and was anything redacted before the model saw it?

A typical stack can answer part of it. Application logs have the request. The LLM provider has the prompt, maybe. But the retrieval step — which documents were eligible, which were excluded because the caller lacked permission, what was masked — usually leaves no trace at all, because retrieval is treated as a function call rather than a governed event.

That gap is the expensive one, because it is exactly where the decision was shaped.

Mapping the obligation to records

A governed retrieval layer produces most of this as a byproduct rather than as an add-on. Concretely, in Context Engine every tool call writes a row with:

Column What it evidences
tool_name, kind Which capability ran
actor_type, actor_id Who or what invoked it
source Which surface it arrived through
input_args The exact arguments, secrets stripped
output_result, output_truncated What came back
success, error_message Whether it worked, and how it failed
duration_ms, units Operational and cost signal for post-market monitoring
approval_id The human sign-off, when one was required
created_at Timestamped, indexed

Approvals are a separate row carrying principals, approver, approver_meta, expires_at, resolved_at and a frozen snapshot of the arguments. That last detail is the one that matters under audit: the arguments are captured when approval is requested and re-checked when it resolves, so an approved action cannot be swapped for a different one between the sign-off and the execution. Resolution is a single atomic update, so an approval cannot be spent twice.

For the retrieval side, the property that makes any of this meaningful is that access control is enforced inside the SQL predicate of every retrieval leg, before ranking. What a caller was permitted to see is a fact about the query that ran, not a filter applied afterwards that may or may not have been applied consistently.

And redaction runs before the audit row is written, so the record itself does not become the leak. A log full of the personal data you were supposed to be protecting is a new problem, not evidence of compliance.

Three things you still have to build

Being straight about the boundary is more useful than a checklist that implies more than it delivers.

1. Retention is yours. Article 26(6)’s six-month minimum is a policy decision about your database. The rows are timestamped and indexed on created_at, which makes retention and expiry straightforward to implement — but nothing enforces a retention period for you, and nothing stops a DELETE.

2. Tamper-evidence is not built in. The audit rows live in an ordinary Postgres table. A role with write access can update them. If your auditor expects append-only storage or hash-chained records, you need to add that — Postgres row-level security, a write-only role, periodic export to WORM storage, or a hash chain over the rows. Any claim that a plain relational table is tamper-evident should be treated with suspicion, including from us.

3. Linking retrieval to the decision is application work. The engine records what was retrieved and by whom. Tying that to the specific model output and the downstream decision requires a correlation id that your application threads through. Nothing else can do it for you, because only your application knows what a “decision” is.

Where to start

If you are inside the scope of Article 12, the sequence that gets you furthest fastest:

  1. Decide what a decision is in your system, and give it an id that appears in every record.
  2. Move access control into the query. If the retrieval layer cannot say what a caller was permitted to see, no amount of downstream logging reconstructs it.
  3. Redact before you log, not after. The audit trail is a read surface like any other.
  4. Pick a retention period and enforce it in the database, with expiry, not by intention.
  5. Decide whether you need tamper-evidence, and if so, add it deliberately.

Steps 2 and 3 are architectural — they are difficult to retrofit, because they change where filtering happens rather than what gets written down. The rest are policy and plumbing.

Context Engine is an open-source (Apache 2.0) Python library that runs in your own process against your own Postgres, which means the records stay in a database you control — the position Article 12 pushes you toward anyway. The full guide covers the audit and approval surfaces in detail.

Sources