The failure I kept hitting was strange: my logging was fine by ordinary standards. I had request traces, error rates, structured lines, retention, a dashboard. Then someone asked about a decision the AI system had made weeks earlier and I could not answer it. Not because the logs were lost, but because they were never about the decision.
The question was not "did the service return 200" but what input the system received, what it output, under which model version, at what time, and whether a person overrode the result. My logs described the server. The EU AI Act's logging duties for deployers, in Article 26, are about the high-risk system itself. I had instrumented the wrong object.
Server logs and system logs are different instruments
An HTTP access log tells you a request arrived and how long it took. It does not tell you the model classified an applicant as ineligible or that an operator reversed the recommendation. Those facts live one layer above the transport log. Because high-risk systems sit behind an ordinary web service, the ordinary tooling is right there and feels like enough. It is not. Article 12 sets automatic record-keeping on the provider side, and Article 26 includes deployer duties for keeping the logs the system generates. What those logs contain and how long they are kept are design decisions, not byproducts of a web framework.
The event schema I should have written first
A usable decision event needs an event type, a timestamp, a reference to the input, the output, the model version, the identity of any human who intervened, and a link to any override or stop action. Speccing that by hand, I under-specified easy-to-forget events like a human overriding an output, and said nothing useful about retention, which tends to be decided by whoever configured the log sink. I built LogPack to force those decisions into a draft. You paste how you run an AI system, and it returns an Article 26(6) logging design pack: a readiness read, a checklist of events to capture, and the retention gaps in your setup. That is all it does. It does not collect a log line, connect to your infrastructure, or watch the system run.
A design pack cannot store your logs
LogPack produces a design draft: a document about what your logging should look like, with an event checklist and the places where retention thinking is missing. The logger, storage, access controls, and deletion job are still yours. A one-line input cannot produce a serious event schema; a thin draft is feedback to go describe how the system actually runs. The more faithfully you log inputs and outputs, the more personal data you hold, and a logging obligation then balances against data-protection duties. The tool can flag retention as a gap, but it cannot choose a number for you.
The limits, stated plainly
This is a decision-support tool. It is not legal advice, it is not a certification, and it is not a live audit harness. It does not generate logs, verify your logs are complete, or decide whether Article 26 applies to you. That depends on classification under the Act, including the Annex III use cases, and on your role as a deployer. If your system is not high-risk, most of this design work does not apply.
I am referencing real obligations, not a deadline, not a fine, and not a guarantee that a filled-in checklist makes anything compliant. Article 26(6) is about deployers keeping the logs a high-risk system generates; Article 12 is about automatic record-keeping on the provider side. A draft helps you design the first of those. It does not perform it. If your logging is an access log plus a hope, the paste-first draft at LogPack gives you an event checklist to argue with.
FAQ
What does LogPack actually output?
An Article 26(6) logging design pack from a description you paste: a readiness read, a checklist of events to capture, and the retention gaps in your setup. A structured draft, not a running logger.
Does it collect or store my logs?
No. It has no connection to your infrastructure and generates no log lines. The logger, storage, and deletion job remain yours to build.
Is this legal advice or an audit?
Neither. It is a decision-support draft, not legal advice, not a certification, and not a live audit harness. It cannot verify your logs or decide whether the obligations apply.
Do I need it if my system is not high-risk?
Probably not. The logging duties here are tied to high-risk systems, including Annex III categories. If that is not your situation, most of the event checklist will not apply.
