This note goes through the parts of the Act that matter for logging. It's a summary, not legal advice.

Which systems are covered

The logging rules apply to high-risk AI systems. Annex III of the Act lists them by area of use, including hiring, credit scoring, education, access to essential services and critical infrastructure. AI built into products that are already regulated, such as some medical devices, comes under Annex I instead.

The classification is yours to make. The test is in Article 6 and Annex III, and if the answer isn't clear, get a lawyer to settle it before any engineering work starts.

What the articles require

Article 12 says a high-risk system must be able to record events automatically for as long as it's in use. The system writes its own logs. Notes kept by a person don't count.

Two other articles say how long the logs stay. Article 19 covers the provider, meaning the company that builds or supplies the system. Article 26(6) covers the deployer, the company that uses it. Both must keep the logs they control for at least six months.

Nowhere does the text say the logs must be tamper-proof. It does expect them to be useful later, when someone tries to reconstruct what happened. A log that could have been edited without leaving a trace is weak for that job.

When the rules start

The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the dates. For systems listed in Annex III the obligations apply from 2 December 2027. For AI inside products covered by Annex I, they apply from 2 August 2028.

That sounds like plenty of time. It's less than it looks, because logs can only be shown once they exist, and six months of retention means six months of the system running with logging switched on.

How the fines work

Article 99 sets the ceilings. Breaking the obligations for high-risk systems, logging included, can cost up to €15 million or 3% of worldwide annual turnover. A large company faces the higher of the two figures. A small or medium-sized company, start-ups included, faces the lower one.

There are two other levels. Prohibited practices can cost up to €35 million or 7%, and they have nothing to do with logging. Giving authorities incorrect or misleading information can cost up to €7.5 million or 1%.

All of these are maximums. National authorities set the actual amount case by case and take into account things like cooperation and what was done to limit harm.

What a usable log looks like

A few properties make a log much easier to rely on when the question finally comes:

• every request, model action and tool call is written automatically;
• each entry is linked to the one before it, so an edit or a deletion shows up when the log is checked;
• the latest link is also stored somewhere else, which is the only way to notice records removed from the end;
• someone can check all of this without reading the content, which matters when prompts contain personal data.

Logging is a single obligation. Risk management, human oversight, data governance and technical documentation are separate ones, and no logging tool covers them for you.

The articles, dates and fine levels are collected on one page: EU AI Act Article 12. Our own runtime handles the logging part for models running on your hardware: palimpsests.dev.

The common way to protect a log is to encrypt it. Then, to check it, you hand over the key. It works, but it gives the person doing the check far more than they asked for.

Two permissions instead of one

In PALA-1, the format Palimpsests writes, every record has a header and a body. The body holds the content and can be encrypted. The header holds a SHA-256 hash of the body and the hash of the previous record.

To check the log you only need the headers. You go through them in order and confirm two things for each record: that its body still matches the hash in its header, and that it points to the record before it. If anything was changed, removed or moved, one of those links breaks. The bodies are never decrypted.

So reading the log and checking it become separate permissions. You can give one without giving the other.

What a check can tell you

From the file alone, a check answers one question. Was anything inside it altered? If so, it names the first record where the chain breaks.

It can't tell you whether records were removed from the end. A shortened chain is still a valid chain. To notice that, the latest hash has to be kept somewhere outside the log, for example in a file you control or on a hardware token. That stored copy is called an anchor. With it, the check can also confirm that the log is complete.

Proving that the log existed by a certain date needs something else again: a signed statement from an outside witness.

A good verifier keeps these answers apart. If it was given no anchor, it should say completeness wasn't checked. A green result in that situation invites people to believe something nobody verified.

Trying it

The Palimpsests package has a demo that writes a small log and checks it:

pip install palimpsests
palimpsests demo
palimpsests pala verify palimpsests-demo.pala

Without an anchor, the last command reports that completeness wasn't checked and exits with code 2. Pass the right hash with --anchor and it exits with 0. Change one byte in the middle of the file and it exits with 1, naming the records where the chain broke.

Where this stops

Someone who holds both the encryption key and write access to the anchor can rebuild the chain and the anchor together. That's why the format is called tamper-evident and not tamper-proof, and why it helps to keep the anchor off the machine that writes the log.

The format, its specification and its independent implementations are described on PALA-1. A longer explanation of the check is on verify without reading.

Most agents already send their tool calls through something you run. That might be a gateway like LiteLLM, an MCP server or a coding agent like OpenCode. Version 0.12 of Palimpsests added small adapters for these. Each one passes the tool calls it sees to a local Palimpsests server, which writes them into a hash-chained log.

Setting up the server

pip install 'palimpsests[serve]'
palimpsests serve

By default the server listens on 127.0.0.1:11435. It stores hashes of the arguments and results, not the content itself. If you start it with an API key, give the adapters the same key in the PALIMPSESTS_SERVE_API_KEY variable.

LiteLLM

The LiteLLM adapter is one Python file, registered as a callback. It sees the tool calls the model asks for and the results that come back into the conversation:

import litellm
from palimpsests_audit import PalimpsestsAudit
litellm.callbacks = [PalimpsestsAudit()]

It never sees the tool itself run. A result marked ok only means it went back to the model.

MCP servers

For MCP servers that talk over standard input and output, the adapter is a small proxy. You put it in front of the server command in your client's configuration. Sitting in the middle, it sees both the request and the response of every tool call. It passes every byte through unchanged and never blocks a call.

OpenCode

OpenCode gets a plugin: a single JavaScript file you copy into .opencode/plugins/ for one project, or ~/.config/opencode/plugins/ for all of them. It reports the tools OpenCode actually runs. That includes calls the model wrote as plain text, which a server on its own wouldn't recognise.

What these records prove

Records from an adapter are marked as reported by the client. They show what the client said happened and when, and that nobody changed the report afterwards. They don't prove the tool actually ran. The server keeps them apart from the calls it handled itself, so anyone reading the log can tell the two kinds apart.

Where things stand

The LiteLLM and MCP adapters have been tested against a live server with made-up tool calls. Neither has been run on real traffic yet. For OpenCode 1.18.31, one reported call from a real session has reached the log. It was a failed file read, and it was recorded correctly. We haven't yet seen a successful result arrive the same way.

Client hook interfaces change between versions, so each adapter's README says which version its behaviour was checked on.

Setup details and limits for all three are on integrations. How to check the resulting log without the key is on verify without reading.

Palimpsests was built for exactly this. The model, its working state and the log all stay on the machine that holds the data. Here's what that looks like in practice.

Getting the software in

The machine has no internet, so the packages travel on a drive. On a connected computer, download them with pip. Then install from that folder on the isolated machine:

pip download palimpsests -d ./wheels
pip install --no-index --find-links ./wheels palimpsests

Releases are signed and ship with a list of their dependencies (an SBOM). You can check what you're carrying in before it crosses over.

Time you can't fully trust

Isolated machines drift. Some have no reliable clock at all, and the log doesn't pretend otherwise. Each record carries a time trust level: UNKNOWN, UNSYNCED, HW_RTC or NTP_SYNCED. A record marked UNKNOWN contains no wall-clock time at all.

The order of events doesn't depend on the clock. It comes from sequence numbers in the chain, so even if every timestamp were wrong you could still see what happened before what.

Keeping the anchor

A hash chain shows that nothing inside the log was changed. To also notice records removed from the end, you keep a copy of the latest hash somewhere else. Offline, that can be a file outside the log. Since version 0.11 it can also be a PKCS#11 hardware token, which the host can read but can't quietly overwrite.

If your rules ever allow a single link outside, the latest hash can also be sent to a SCITT transparency service as a signed statement. Only the hash leaves the machine.

Checking without the network

Verification works on the same machine or any other one, with no connection. It doesn't need the decryption key, because all it does is compare stored hashes:

palimpsests pala verify serve.pala --anchor <latest-hash>

Verification was measured on a test chain of one million records. On an Intel Core Ultra 9 machine running Windows 11, verifying with version 0.11 needed 4.77 GB of memory. Version 0.12 brought that down to 0.57 GB. On an integrated Intel Arc GPU, the engine's tool loop runs as fast as a hand-tuned llama-server, without a separate server process.

There's no measurement on a discrete GPU yet. The log implementation also hasn't had an independent penetration test.

More detail, including what we don't claim, is on air-gapped. The project itself is at palimpsests.dev.