Daylite is the runtime enforcement and verifiable audit layer for AI agents in regulated enterprises. It is a self-hosted Rust binary that sits at the MCP tool-call boundary. It checks each agent action against policy before the action runs and decides whether it executes, then writes a tamper-evident, cryptographically signed record of what was requested, what policy decided, and what actually ran. It deploys in your VPC, on-prem, or in an air-gapped network.

How is Daylite different from Vanta, Drata, Credo AI, or OneTrust?

Those tools document and score policy. They map it to frameworks and produce reports, and they sit out-of-band from the running agent, so they cannot block a non-compliant tool-call. Daylite enforces policy at the tool-call boundary at runtime and produces cryptographic proof of what the agent actually did. Keep your governance tool for documentation. Daylite sits beneath it.

What does 'built on FIPS-validated cryptography' mean?

Daylite runs its cryptography through AWS-LC, a FIPS 140-3 validated cryptographic library. Daylite itself is not product-certified under CMVP, and we do not claim a CMVP certificate. Commercial enterprise procurement under SOC 2, HIPAA, and DORA accepts library-level validation. FedRAMP High and certain DoD contracts require product-level CMVP, which is on the roadmap.

How does an auditor use the evidence?

Your team runs one command to export the record. The auditor verifies the hash-chain offline with the verify tool, confirms no entry was changed after it was written, and reviews the decisions. The format is open, so there is no lock-in on the evidence itself, and no trust in Daylite is required to check it.

Where does Daylite run, and where does the data go?

Daylite is self-hosted and air-gap capable. It runs in your VPC, on-prem, or in a disconnected network. Data never leaves your environment. That disqualifies cloud-only governance tools in banking and defense, and it is why Daylite fits where they cannot.

How long does Daylite take to deploy?

Minutes. Docker ships today. Run the container, point your agents at the MCP proxy, and the policy gate and the hash-chain audit are live. A Helm chart for Kubernetes is on the roadmap.

July 31, 2026 · 9 min read

EU AI Act logging requirements for AI deployers: a practical checklist

Most EU AI Act coverage talks to the companies building AI. The logging obligations land just as hard on the companies using it. If your firm deploys a high-risk AI system in the EU, the Act expects logs to exist, expects you to keep them, and expects them to be useful when something needs explaining. This is a plain-language walkthrough of who holds which duty, and a checklist you can hand to engineering.

One caveat up front: the Act's high-risk obligations phase in over an extended timeline running into 2027, and the details are still moving. Treat this as orientation, not legal advice, and classify your specific use case with counsel.

The three-article structure of the logging duty

The record-keeping obligations for high-risk AI systems split across three articles, and confusion between them is where most bad summaries start.

Article 12, on providers, is a design duty. High-risk AI systems must technically allow the automatic recording of events over the system's lifetime. The logging must support identifying situations that present risk and must enable post-market monitoring. For remote biometric identification systems, the Act even names minimum log contents, including the period of each use and the input data.

Article 19, on providers, is a retention duty. Providers keep the logs their high-risk systems generate, to the extent the logs are under their control, for at least six months unless other law says otherwise.

Article 26, on deployers, is the one most companies miss. Deployers of high-risk systems must, among other obligations, keep the logs the system generates automatically, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months. The same article requires deployers to use systems per the provider's instructions, assign human oversight to people with the competence and authority to exercise it, and monitor operation.

What the logs are for, according to the Act

The Act is unusually clear about purpose. Logs exist so that risky situations can be identified, incidents can be investigated, post-market monitoring can run, and authorities can be answered. That purpose test is a better engineering spec than any format requirement, because it tells you what your log must be able to do after the fact: reconstruct what the system did in a given period, connect outputs to the inputs and versions that produced them, and show the human oversight that the deployer was obliged to assign.

A log that exists but cannot support reconstruction fails the purpose while technically existing. This is the same gap that shows up in vendor security reviews, where a policy asserting "we log everything" convinces nobody. The hierarchy of what actually convinces a skeptical reader is covered in what evidence buyers actually accept, and regulators sit at the demanding end of that hierarchy.

Why integrity matters more than volume

Nothing in the Act says "hash chain." But the obligations assume the logs will be relied on precisely when someone has an incentive to doubt them: after an incident, during an authority's request, in a dispute over what the system did. A record your own administrators can silently edit is weak evidence in exactly those moments.

The pragmatic bar: append-only storage, integrity you can demonstrate rather than assert, retention enforced mechanically rather than by habit, and export in a form a third party can verify. Fines under the Act reach into the millions of euros and percentages of worldwide turnover depending on the violation, so the cost asymmetry between building integrity in and arguing about it later is not close.

The deployer's checklist

Determine your role for each AI system: provider, deployer, or both. Duties differ.
Classify use cases against the high-risk categories with counsel. Logging duties follow classification.
Confirm with each provider what the system logs automatically, and get log access into the contract.
Decide where logs under your control land, and make that storage append-only.
Set retention at six months minimum, longer where purpose or sector law demands it, and enforce it mechanically.
Tie log entries to the humans assigned oversight, so oversight is demonstrable, not nominal.
For agentic systems, log at the tool-call boundary: request, decision, execution, authorizer.
Test reconstruction quarterly: pick a past day and rebuild what the system did from logs alone.

Where Daylite fits

Daylite is the logging and enforcement layer for the agentic case. It sits at the tool-call boundary, gates each call against policy, and writes every decision to an append-only, hash-chained, signed record with an export endpoint built for regulatory evidence, all self-hosted so the logs never leave your environment. For teams facing the Act as deployers of agents, that covers the hard rows of the checklist: boundary logging, integrity, retention, verifiable export. The classification and contract rows remain yours, and no tool changes that. For the broader review context these logs also serve, see what SOC 2, HIPAA and DORA ask of agent audit trails.

FAQ

Do the EU AI Act logging rules apply to us if we just use an AI product?

If you use a high-risk AI system in a professional capacity in the EU, you are a deployer, and Article 26 applies. The headline logging duty: keep the logs the system generates automatically, to the extent they are under your control, for a period appropriate to the system's purpose and at least six months, unless other EU or national law says otherwise.

What is the difference between Article 12 and Article 26 logging duties?

Article 12 is a design obligation on providers: high-risk systems must technically allow automatic recording of events over their lifetime. Article 19 then makes providers keep logs under their control. Article 26 is the operational obligation on deployers: keep the logs your use of the system generates. In practice one deployment involves both parties, and contracts should say who holds what.

How long must deployers keep AI system logs?

At least six months under Article 26(6), unless other applicable EU or national law provides otherwise, and longer where the purpose of the system justifies it. Sector rules can extend this substantially, so financial entities and healthcare deployers should not treat six months as the answer, only as the floor.

Are general-purpose chatbots covered by these logging rules?

The record-keeping obligations discussed here attach to high-risk systems as classified by the Act, mostly the Annex III use cases such as employment, credit, essential services, and biometrics, plus regulated products. Using a general-purpose model does not itself trigger them, but embedding one into a high-risk use case can. Classify the use case first, then decide what logging follows.

Do agent tool calls count as loggable events?

The Act speaks of automatically recorded events relevant to identifying risk and enabling post-market monitoring. For an agentic system, the consequential events are exactly its tool calls and the decisions around them: what was requested, what ran, what was blocked, and which human oversaw it. A log that cannot answer those questions will struggle to serve the purposes the Act assigns to it.

If AI Act questions are showing up in your customers' security reviews, the AI Security Review Kit maps your real stack to the AI-CAIQ, NIST AI RMF, and ISO 42001 from a 30-minute intake.

Written by Dmitrii Karataev. Twenty years in infrastructure and security. This article is general information, not legal advice. Corrections welcome: hello@daylite.ai.