Article 12 Logging and Automatic Record Keeping
Article 12 requires high risk AI systems to automatically keep detailed logs and records of their operation. These logs serve multiple purposes: they provide evidence of the system’s performance, they enable detection of problems or misuse, they support audit investigations and they meet regulatory requirements for transparency and accountability.
The logging requirement is automatic. The system must be designed to generate logs without requiring human intervention. A system that only logs when someone remembers to request logs does not meet Article 12. The system must be configured from deployment to continuously record relevant information about decisions, data inputs and any anomalies.
What must be logged? Article 12 specifies that logs must include high-level system functioning data and information about individual decisions made by the system. For a high risk employment decision system, this includes records of each employment decision made by the system (hire, no hire, promote, no promote), the data inputs used, any overrides of system recommendations by humans, and performance metrics. For a high risk credit system, logs must include loan decisions, applicant data, reasons for approvals or rejections and any overrides.
The logs must be maintained in a format that is accessible and auditable. A system that logs decisions but stores them in encrypted or inaccessible formats does not satisfy Article 12. The organisation must be able to retrieve and review logs to verify system performance, investigate concerns and respond to regulatory requests.
Retention periods are specified. According to Article 12, logs must be kept for a period proportionate to the risks and consequences of the high risk system. For employment decisions, if decisions are irreversible or have long-term consequences for workers, retention must be long enough to allow workers to challenge decisions. A typical expectation is retention for at least five years, though specific requirements depend on the system’s purpose and consequences. A system making permanent decisions might require longer retention than a system making temporary recommendations.
Access control matters. Not all employees should have access to all logs. Organisations must implement controls limiting who can view, modify or delete logs. This prevents unauthorised modification of audit trails. Log tampering, where historical records are altered to hide problems, undermines the entire purpose of logging. Access controls and audit trails for the logs themselves (who accessed which logs when) are essential.
Performance monitoring through logs is essential. The organisation should establish procedures for regular log review. Monthly, the organisation might extract summary statistics from logs: how many decisions did the system make, what was the distribution of decisions (approvals versus rejections, for example), did any concerning patterns emerge? If logs show unusual spikes in rejections or unexpected demographic imbalances in decisions, this signals a problem requiring investigation.
Anomaly detection using logs is powerful. If the system is designed to alert when certain conditions occur, logs provide the evidence. If the system should never make decisions without human review for certain categories, the logs should show that this rule was followed. If the system should automatically reject applications with certain data quality problems, logs should confirm this happened.
Consider a practical scenario. A bank implements a high risk credit decision system. Article 12 requires automatic logging of every loan decision, including applicant data, system recommendation, whether the loan officer approved or rejected the recommendation and the final decision. Logs are stored in a secure database with access controls limiting who can view them. The logs are kept for seven years because of the long-term consequences of credit decisions. Monthly, the compliance team reviews logs, extracting statistics on approval rates by applicant demographic characteristics, geographic region and loan type. If approval rates diverge significantly between demographic groups, this signals potential fairness concerns requiring investigation.
Six months into deployment, the log analysis reveals that the system’s loan approval recommendations show a significant gender imbalance. Approval recommendations for male applicants are 15 percent higher than for female applicants with similar financial profiles. The anomaly is detected through systematic log review. The organisation immediately pauses expansion of the system, investigates the cause (likely a problem with training data), retrains the model, validates the new model against gender bias and redeploys with additional monitoring.
Logs also serve regulatory purposes. National authorities enforcing the EU AI Act will likely request logs as evidence of compliance. When regulators investigate whether a system operated according to deployed instructions and whether human oversight was actually exercised, they review logs. Complete, reliable logs become evidence of compliance. Incomplete or absent logs suggest non-compliance.