# The EU AI Act is clumsy. Producing the evidence for it shouldn't be.

> Every deliverable the AI Act asks a software team for is a question about the past: what did you decide, why, what did you reject, and who was actually watching the agent?

A compliance project answers those with archaeology. letopis answers them with a lookup, because the answer was
recorded while the work was happening. That is the entire difference, and it is not a small one.

Canonical page: https://dirahq.sh/letopis/ai-act

Regulation (EU) 2024/1689. AI omnibus in force since 27 Jul 2026. High-risk obligations deferred to 2 Dec 2027.

- Penalty ceiling for these obligations: €15M or 3% of worldwide turnover (Art. 99(4); prohibited practices carry €35M or 7% under Art. 99(3))
- Deployer log retention: ≥ 6 months
- Technical documentation kept: 10 years
- CRA reporting starts: 11 Sep 2026
- Harmonised standards: late 2026 / early 2027

## Application timeline

| Date | What happens |
| --- | --- |
| 2 Feb 2025 | Prohibited practices bite. Article 4 AI literacy applies to every provider and deployer — softened by the omnibus to *support the development of*, not ensure. |
| 2 Aug 2025 | GPAI models, governance, penalties. The model provider's problem, not yours — until you build on one. |
| 2 Aug 2026 · in force | The Act is generally applicable, and being enforced. The AI Office and national authorities start enforcing. Article 50 applies: your chatbot says it is a chatbot, and generated output carries a machine-readable mark. |
| 2 Dec 2026 | Article 50(2) catches systems already on the market. The omnibus's new prohibition — AI-generated CSAM and non-consensual intimate material — applies from the same day. |
| 2 Dec 2027 | High-risk under Annex III: risk management, technical documentation, record-keeping, human oversight. Annex I products follow on 2 Aug 2028. |

The delay is real, and narrower than the headlines. The AI Omnibus — Regulation (EU) 2026/1744 — was adopted on 29 June 2026, published in the
Official Journal on 24 July, and has been in force since 27 July: it moved Chapter III for Annex III systems by
sixteen months and Annex I by a year, and moved nothing else. Article 50, Article 4, the prohibitions, GPAI and
enforcement all kept their dates — and sixteen extra months do not hand you back the March you failed to record.

## The AI Act moved. The Cyber Resilience Act did not.

Regulation (EU) 2024/2847, Article 14.

On **11 September 2026** the CRA switches on its reporting regime. If you make a product with digital elements
available in the EU — software counts — an actively exploited vulnerability or a severe incident starts a clock
measured in hours, not weeks.

And it reaches backwards. Article 69(3) applies this duty to everything already on the market, not only to what you
place there after the main obligations land in December 2027. The regulation most teams filed under *next year* has
its first hard date next month.

- **24h** — early warning to your CSIRT and ENISA, from becoming aware
- **72h** — full notification: what it is, what is affected, what you are doing
- **14d** — final report once a fix exists — root cause and corrective measures

What a 24-hour clock actually asks of your record:

- **What changed, and when** — the affected code's change history, anchored to commits that provably exist in the
  remote. You have hours to state the product, the version and the window — not a week of git archaeology.
- **Who — or what — wrote it** — which harness produced the change, under whose identity, and how many engaged
  minutes a human spent on it. A line written by an unsupervised agent at 02:40 is a different report from one a
  reviewer signed.
- **Why it was built that way** — the final report wants root cause and corrective measure. The recorded rationale
  — and the option that was rejected — is what turns *we changed it* into an account of why this fix is the right
  one.

letopis does not detect exploitation, does not judge severity, and does not file anything with ENISA or your CSIRT.
It is not a scanner and not a compliance workflow. It answers the questions the report asks about the past — which,
on a 24-hour clock, is the one part you cannot buy on the day.

## Compliance is not a switch. It is a depth of evidence.

Gold is stamped 585, 750 or 999 for how much of it is actually gold. A proba hallmark is stamped for how much of the
change is actually evidenced. Each rung turns a row below from `—` into `✓`.

**585 · proba app only** — Five minutes, no CLI. The code host's own view — and weak provenance, labelled as such.
Answers 3 / 8 questions.

**750 · + dira on the workstation** — The layer a code host structurally cannot see: who ran which agent, and for
how many engaged minutes. Answers 6 / 8 questions.

**999 · + zavet in the repo** — The rationale — the one thing Annex IV asks for by name, and the one thing nobody
writes down. Answers 8 / 8 questions.

| Question | Article | 585 | 750 | 999 |
| --- | --- | --- | --- | --- |
| Was CI green at the merge commit? | Art. 17 | ✓ | ✓ | ✓ |
| Did somebody other than the author approve it? | Art. 14 | ✓ | ✓ | ✓ |
| Was branch protection bypassed to land it? | Art. 17 | ✓ | ✓ | ✓ |
| Which harness wrote this change? | Annex IV §2(a) | ~ (inferred) | ✓ | ✓ |
| How many minutes did a human actually supervise it? | Art. 14 · 26(2) | — | ✓ | ✓ |
| Is that record non-repudiable, or just a line of text? | Art. 14 · 26(2) | — | ✓ | ✓ |
| What was the design rationale, and what was rejected? | Annex IV §2(b) | — | — | ✓ |
| Were recorded decisions respected, or quietly reverted? | Art. 17 | — | — | ✓ |

## Run all four books and this is the honest overall state

Not a score, and not a percentage of the Act. Four numbers, each of which you can check against the rows above and
below.

- **8 / 8** — evidence questions on the ladder above, answerable by lookup rather than by interview
- **999** — the fineness every merged change can reach — the top of the assay scale, with nothing above it
- **6 / 6** — provisions in the table below whose deliverable falls out of the record as a byproduct
- **0** — runtime obligations covered. Article 12 inference logs, drift, your CE mark: another vendor's product

- **dira** — who ran which agent, under whose git identity, and the engaged supervision minutes — deduped across
  parallel sessions, signed at capture on the workstation.
- **zavet** — the design rationale, the assumptions and the option that was rejected — in the repo, reviewable in a
  PR, guarded against the next agent quietly contradicting it.
- **proba** — the per-merge process record, signed and immutable: CI at the merge commit, a non-author review, no
  bypass, and the fineness of the evidence behind all of it.
- **miara** — nothing. miara prices future work from evidenced history and makes no compliance claim at all — it is
  in the suite for your margin, not for your auditor.

Read together: every question the Act asks about the *past* has an answer, and every question about *runtime* still
needs a product we do not sell. That is not a certificate — nobody can sell you one. It is the difference between an
afternoon and a quarter on the day somebody asks.

## Six provisions, and which book writes the answer {#mapping}

| The Act says | What it asks for | Which in practice means | Written by |
| --- | --- | --- | --- |
| Annex IV §2(b) (via Art. 11 — technical documentation) | The design specifications: the key design choices, including the rationale and assumptions made, and the trade-offs behind the technical solutions adopted. | A dated, attributable record of each design decision and the option you rejected — captured when it was made, not reconstructed by whoever is still on the team. | zavet |
| Art. 14 · Art. 26(2) (human oversight) | The system is overseen by natural persons who are competent, trained and actually able to intervene. | Evidence that a human supervised this change, and for how many minutes — instead of a policy PDF asserting in general that humans supervise. | dira + proba |
| Art. 17 (quality management system) | Design control and design verification, change control, and procedures for keeping the records that prove both. | Per merged change: CI state at the merge commit, a review by someone other than the author, recorded decisions respected, branch protection not bypassed. | proba |
| Art. 12 · 19 · 26(6) (record-keeping & retention) | Automatic recording of events, traceable over the lifetime of the system, retained and produced on request. | Records that are tamper-evident and non-repudiable — signed at capture on the workstation, append-only afterwards, and still legible in six months or ten years. | the chain |
| Art. 25 · Art. 43(4) (substantial modification) | Modify a high-risk system substantially and you inherit the provider's obligations for it. | Knowing exactly what changed, when, and on whose authority — including the refactor an agent made at 02:40 that no human ever opened. | the chain |
| Art. 73 (serious incident reporting) | Report a serious incident to the authority without undue delay — 15 days at the outside, but two if the infringement is widespread or the incident risks serious injury, and ten where someone has died. | Reconstructing the decision and change history of one subsystem in an afternoon. `/zavet:why` answers with citations; a wiki search does not. | zavet /zavet:why |

None of the rows above is a feature built for the AI Act. Every one is a byproduct of recording the work properly —
which is why the chronicle was worth keeping before any of this was law.

## There are two AIs in your product, and only one of them is being logged

Every AI Act tool on the market instruments the model your users talk to. Almost nothing instruments the models
that wrote the code around it. Both sides of this line are in scope, and the left-hand one is where the design
rationale lives.

**Build time · the AI that built it — letopis lives here**

- Which harness wrote each change, cryptographically attributed rather than claimed
- Engaged supervision minutes per change, deduped across parallel agents
- Design decisions with rationale, rejected options and guarded scope
- Per-merge process record: CI, non-author review, no bypass, signed
- The full change history of the system, anchored to commits in the remote

**Runtime · the AI your users touch — letopis does not go here**

- Inference-time input and output logging under Article 12
- Per-decision explanations to the affected person
- Drift, bias and accuracy monitoring in production
- Your conformity assessment, your registration, your CE mark
- Buy that elsewhere. We will not pretend a git-anchored session says anything about a credit-scoring decision your
  model made at 4am.

## A chronicle has no opinions — least of all legal ones

The market for this is already full of dashboards that print the word *compliant*. Four things letopis refuses to
do, on purpose:

- **It is not a compliance badge** — No product can certify you against the AI Act, and a proba hallmark never says
  *compliant*. It states, at a declared fineness, what was observed. What that is worth is your auditor's call, not
  ours.
- **It is not runtime logging** — Article 12 governs the AI system your users touch. letopis records the AI that
  *built* it. If your product is high-risk you still need runtime logs — letopis is the half nobody has.
- **It is not legal advice** — Whether you are high-risk depends on what the system was deployed to do, not on the
  fact that agents wrote it. letopis will not tell you, and will not sell you a questionnaire that pretends to.
- **It is not retroactive** — The uncomfortable one. Evidence cannot be backfilled honestly — zavet marks
  reconstructed decisions unverified until a human confirms them. The only way to hold March's record is to have
  recorded in March.

Which is the whole argument for starting the chronicle on a quiet Tuesday, rather than in the week somebody asks.

## Start recording before you need the record

dira is free forever for solo work and open source. The rest of the chain is written on top of it.

---

See also [/letopis.md](https://dirahq.sh/letopis.md), [/letopis-compare.md](https://dirahq.sh/letopis-compare.md),
[/compare.md](https://dirahq.sh/compare.md).