AIG-020 AI System Event Logging
Description
AI systems record event logs that support post-incident analysis and audit. Each inference or decision event carries at minimum a request identifier, a timestamp, the model version in use, the input data type or identifier rather than the raw input, the output or output category, the confidence score where one exists, any human override or intervention and any system error or exception. For LLM and generative systems each request also records the session or user identifier, pseudonymised where data protection law requires it, the system prompt or prompt template identifier, the response or response category and any tool calls made; where the documented use case is safety-critical or makes decisions about people, the full prompt and response are logged. Read access to AI event logs is restricted to authorised security and operations roles and is itself logged. Logs are retained for the period applicable regulation requires, in line with the audit log retention in MON-003, and are protected from tampering.
Rationale
AI event logs are the primary forensic artefact when AI-driven decisions are challenged or when incidents require root-cause analysis.
Applicability (9 profiles)
The log design is the provider's. The deployer retains the automatically generated logs under its control for the Art.26.5 period of at least six months and controls read access to them.
Art.12(1) and (2) make logging a design property of the system rather than an operational practice: the system technically allows the automatic recording of events over its lifetime, at a granularity that serves the identification of risk situations and substantial modifications, post-market monitoring and the deployer's monitoring of operation. Art.16(e) keeps the provider responsible for the logs under its control and Art.21 is what they are produced under. For a remote biometric identification system under Annex III, point 1(a), Art.12(3) fixes the fields rather than leaving them to design, the start and end date and time of each use, the reference database used, the input data that led to a match and the identification of the natural persons who verified the results (extract row EU-AI-Art.12.2). Retention is MON-003.
Art.26(6) binds both seats and sets a floor: the automatically generated logs under the deployer's control are kept at least six months, longer where Union or national law requires it. Art.12(3) adds the fields a deployer of a remote biometric identification system under Annex III point 1(a) has to be able to produce, the period of each use, the reference database, the input data that led to a match and the identification of the persons who verified the result. That extract row, EU-AI-Art.12.2, maps partial to this control since migration 063 with the four fields named as the gap, so the deployer's log extends the minimum record by them. Annex III point 1 is in practice a public-authority area, which is why the fields sit on this profile and not on the base. MON-003 holds the retention schedule.
Framework Mappings (23)
| LOG-07 | Logging Scope | partial |
| LOG-15 | Input Monitoring | partial |
| LOG-16 | Output Monitoring | partial |
| LOG-07 | Logging Scope | partial |
| EU-AI-Art.12.1 | Logging and Record-Keeping — Automatic Event Logging Capability | full |
| EU-AI-Art.12.2 | Logging and Record-Keeping — Biometric Identification System Logging | partial |
| EU-AI-Art.16.4 | Provider Obligations — Log Retention | informative |
| EU-AI-Art.19 | Provider Obligations — Automatically Generated Logs and Their Retention | informative |
| EU-AI-Art.21 | Provider Obligations — Cooperation with Competent Authorities | informative |
| EU-AI-Art.26.5 | Deployer Obligations — Log Retention | full |
| A.6.2.8 | AI system recording of event logs | full |
| AML.M0024 | AI Telemetry Logging | full |
| AU-12 | Audit Record Generation | partial |
| AU-2 | Event Logging | partial |
| AU-3 | Content of Audit Records | partial |
| MG-2.2-007 | Deployed AI System Value Maintenance | MG-2.2-007 | partial |
| MS-2.8-003 | AI Transparency and Accountability Risks | MS-2.8-003 | partial |
| MS-4.2-004 | Trustworthiness Measurement with Expert Input | MS-4.2-004 | informative |
| MANAGE 4.1 | Post-Deployment AI System Monitoring | informative |
| MANAGE 4.3 | Incident and Error Communication | informative |
| MEASURE 2.4 | AI System Production Monitoring | informative |
| ASI01 | Agent Goal Hijack | informative |
| LLM09 | Vector and Embedding Weaknesses | informative |
Evidence (2)
AI system event logs demonstrating that inference events, model versions, output categories, confidence scores and human override events are captured and retained for the required period. For LLM and generative systems the sample also shows the session or user identifier, the prompt template identifier and any tool calls.
Example: Splunk log export for ai-underwriting-api (sample 100 events, 2026-04-01): each event containing request_id, timestamp, model_version, input_category, output_class, confidence_score, human_override_flag, and exception fields; log retention policy: 12 months
Test: Request a sample of AI event logs (minimum 50 events) and the log retention configuration. Verify: (1) each log event contains the required fields (request identifier, timestamp, model version, input identifier, output or output category, confidence score where applicable, override flag), (2) for LLM and generative systems each event also carries the session or user identifier, the prompt template identifier, the response or response category and any tool calls, with the identifier pseudonymised where data protection law requires it, (3) log retention meets the regulatory minimum and the organisation's stated requirement, (4) logs are stored in a tamper-evident or write-protected log store, (5) log access is restricted and access events are themselves logged.
Log access control configuration demonstrating that LLM prompt and response logs are restricted to authorised security and operations roles, with access logging enabled.
Example: Splunk index access control configuration for ai-llm-prompts index: read access limited to security-team and ml-ops-team roles, no access for general dev role; AWS CloudTrail showing last 30 days access by authorised accounts only, access log retention: 12 months
Test: Review access control configuration for the LLM log store. Verify: (1) read access is restricted to named security and operations roles, (2) developer roles do not have unrestricted access to full prompt/response logs, (3) access to the log store is itself logged and auditable, (4) no service accounts with overly broad access exist on the log store.
Questions (3)
Do your AI systems record an event log for each inference or decision?
AI event logs are the primary forensic artefact when AI-driven decisions are challenged or incidents require root-cause analysis. Logs must be protected from tampering and retained for the period required by applicable regulations.
What is the log retention period applied to your AI system event logs?
Answer with the retention actually configured on the AI event log store. The control requires retention to meet the period applicable regulation sets and to align with the audit log retention in MON-003; where a deployment is subject to the EU AI Act the deployer floor is six months. Longer retention carries its own data protection cost and should be set deliberately rather than by default.
Which fields are captured in your AI system event logs?
The first seven fields apply to every AI system. The generative fields apply where the system produces free text or media. Full prompt and response content is required only for the last case and has to be protected by access controls restricting it to security and operations roles.