Monitoring and logging AI systems
What monitoring should tell you
Monitor whether the system continues to serve its purpose, which failures occur and whether technical and organisational safeguards work. Behaviour can change with the model, inputs, configuration or surrounding process. A deterministic system is not free of operational risk.
| Area | Example measurements | Prepare before operation |
|---|---|---|
| Quality | Error rates, corrections, differences between groups and change from baseline | Representative evaluation cases and justified acceptance criteria |
| Security | Permission changes, unusual actions and attempted data transfers | Escalation rules and a response owner |
| Operations | Availability, latency, integration failures and cost per completed case | Service objectives, alerts and a capacity plan |
| Human oversight | Overrides, escalations and incorrect approvals | Authority, decision context and a review process |
Thresholds are project decisions. A finding should trigger a defined action: review, restricted functionality, rollback or remediation. Avoid collecting metrics without a purpose or owner.
What the law requires
AI Act Article 12 requires high-risk systems to support automatic event recording appropriate to their purpose and risks. It is not a universal instruction to retain the full content of every prompt and response. Article 72 concerns post-market monitoring by providers of high-risk systems; deployers have their own obligations, particularly under Article 26. Check the role, system and relevant application date.
GDPR requires appropriate security, minimisation and accountability for processing. Article 22 concerns certain solely automated decisions with legal or similarly significant effects; it is not a general logging rule for every AI system. Cybersecurity and financial-sector requirements depend on the scope of the organisation and service.
Designing a record
Depending on its purpose, a record may include the event time, system identifier and version, action type, completion status, a reference to relevant input, review outcome and human intervention. Store input or output content only to the extent necessary and permitted. Protect logs against unauthorised access and alteration.
A hash can help compare content, but does not by itself establish anonymisation. Predictable values can be guessed and identifiers linked. Consider limiting content, pseudonymisation, separating identifiers and controlling access.
Retention matrix
| Record type | Basis for retention |
|---|---|
| Selected documentation held by a provider of a high-risk system | AI Act Article 18: ten years after placing the system on the market or putting it into service; this is not a general period for all logs |
| Automatically generated logs of a high-risk system under the provider’s or deployer’s control | Articles 19(1) and 26(6): a period appropriate to the intended purpose of at least six months, unless applicable EU or national law provides otherwise |
| Operational telemetry, prompts and responses from other systems | The specific purpose, risk, contract and applicable legislation; no universal five-year period |
| Personal data within any category | GDPR Article 5 minimisation and storage limitation; define the reason, scope, access and deletion process |
For each record type, specify the event that starts the period, owner, storage location, exceptions for litigation or incidents, and a verifiable deletion process. Apply AI Act retention duties after assessing their temporal applicability; this table does not bring them into effect early.
Verified on 6 September 2026: AI Act Articles 12, 18, 19, 26 and 72, GDPR.