Logging
What must be recorded, what may be recorded, and what a log that holds up in an incident looks like.
What belongs in a log
| Item | Why |
|---|---|
| Timestamp and case reference | Links it to the business event |
| System, model and version with checksum | Evidences which build decided |
| Parameters | Temperature, context length, template with version |
| Result or its identifier | What came out |
| Reviewer and review outcome | Evidences human control |
Those five can be kept without any plaintext input and cover most evidence needs. The content of the input belongs there only where a purpose, a legal basis and a retention period exist for it.
What the logs must deliver
- Unalterable, or with a traceable change history.
- Access-restricted, with their own permissions.
- Searchable, not merely storable. A log you cannot query does not help in an incident.
- With a defined retention period per data category.
- Kept separately from the business data, so deletion there does not invalidate the log.
The three evidence needs
| Need | What must be shown | Retention |
|---|---|---|
| AI Act, high risk | Operation per the instructions, oversight, input data | at least six months |
| GDPR | Lawfulness, data subject rights, erasure | by evidence need, often three years |
| Sectoral law | By area: accounting, professional conduct, product safety | per sectoral law |
The three periods differ and routinely conflict with the erasure duty. They belong set separately per data category, not as one period for everything.
Reproducibility is not the goal
A model run is not bit-reproducible on graphics cards. Forcing it costs throughput and still does not achieve it reliably. What is evidenced is therefore the result, not repeatability: model version, parameters, input reference, output, timestamp.
A log entry, concretely
{
"ts": "2026-08-25T09:14:22Z",
"case": "PO-2026-04417",
"system": "quote-check",
"model": "model-x-2026-06",
"model_checksum": "sha256:9f2c…",
"template": "procurement-quote-extract v3",
"params": {"temperature": 0, "context": 8000},
"result_id": "res-88f1c2",
"confidence": 0.91,
"reviewed_by": "m.huber",
"review_outcome": "accepted",
"changes": 0
}No plaintext, no personal reference in the log itself, and still fully answerable. The result itself sits in the business application with its retention periods.
What is demanded in an incident
- Period and extent of impact, derivable from the logs.
- Which model version and which template were in use.
- Whether and when a review took place.
- Which decisions rested on it and who owned them.
- When the incident was noticed, reported and resolved.
Anyone who can answer those five from the logs can answer questions. Anyone who has to reconstruct them cannot. See Preparing for audit.
A log schema that survives an audit
FREE ACCOUNT
Log schema and analysis queries
A complete schema for the log entry per request, with the queries an audit actually asks.
Access code2 items
Related courses and sources
BSI on the security of AI systems
Technical guidance on operating AI systems securely. Free, and unusually concrete.
For security and operations in German-speaking countries; unusually concrete for an official source.
ENISA publications
Reports from the EU cybersecurity agency, including on securing AI systems and on the threat landscape. Free and in a European frame.
For security leads who need a European frame of reference rather than an American one.