The EU AI Act's high-risk AI obligations — now scheduled to apply from December 2027 following the Digital AI Omnibus extension — represent the most operationally demanding compliance requirement that enterprise AI teams have ever faced.
They are demanding not because of their complexity, but because of their specificity. The EU AI Act does not ask enterprises to describe their AI governance. It asks for records of what AI systems actually did — records that are automatically generated, integrity-protected, and available for regulatory inspection.
This guide covers which AI systems are in scope, what Articles 9–17 require in terms of documentation and logging, and what the gap looks like between the records most enterprises currently hold and the records the regulation requires.
Step One: Is Your AI System High-Risk?
The EU AI Act creates a risk-tiered framework. The obligations discussed in this guide apply specifically to AI systems classified as high-risk under Article 6 and Annex III. High-risk AI systems include those used in:
Financial Services — credit scoring and creditworthiness assessment; life and health insurance risk assessment; fraud detection in banking and financial services.
Employment and HR — recruitment and selection tools that filter, screen, or rank job applicants; performance evaluation AI used to assess employees in ways that affect employment decisions; promotion and termination AI.
Education — AI used in admissions or academic assessment that determines access to educational institutions.
Law Enforcement and Public Services — risk assessment tools used by public authorities to assess individual risk, including recidivism assessment or benefits eligibility scoring.
Healthcare — clinical decision support systems intended to influence clinical diagnoses or treatment decisions for individual patients.
Critical Infrastructure — AI systems managing critical digital, water, transport, or energy infrastructure.
If your enterprise deploys AI in any of these categories — and most large financial institutions, insurers, and healthcare organisations do — you have high-risk AI systems in scope.
The Core Obligations: Articles 9 Through 17
Article 9: Quality Management System
Providers must maintain a quality management system (QMS) covering the full AI lifecycle — design, development, testing, deployment, monitoring, and decommissioning. This requires documentation of risk management procedures, testing methodologies, post-market monitoring protocols, and incident reporting procedures. The QMS must be documented with sufficient detail that an auditor can assess whether the system in operation matches the system that was designed and approved.
Article 10: Data and Data Governance
High-risk AI systems must be developed and operated using training, validation, and testing data that meets specific quality standards. This requires documentation of data sources, data governance procedures, dataset characteristics, and any known limitations of the training data that may affect the system's performance across different demographic groups or deployment contexts.
Article 11: Technical Documentation
Providers must prepare and maintain technical documentation that enables competent authorities to assess the system's compliance. The documentation must include a general description of the system and its intended purpose, design specifications and development process, a description of all changes throughout the lifecycle, and performance metrics and the conditions under which they were measured. Critically, this must describe the system as it currently operates — not as it was designed.
Article 12: Automatic Logging — The Critical Evidence Requirement
Article 12 is the provision that most directly maps to AI audit trail requirements. It states that high-risk AI systems must have the capability to automatically generate logs of the system's operation throughout its lifecycle, to the extent technically feasible.
The logs must:
- Enable monitoring of the operation of the AI system
- Facilitate, where relevant, post-market monitoring as referred to in Article 72
- Enable the ex post facto verification by competent authorities, by the notified body, or, for biometric identification systems, by judicial authorities
"Automatically generated" means: the logs must be generated by the AI system itself — not compiled retrospectively from other data sources, not assembled manually by compliance teams, not reconstructed from backup systems. The requirement is that the system produces its own evidence record at the time of each event.
"Ex post facto verification by competent authorities" means: the logs must be in a form that regulators can verify — including verifying that the logs have not been modified since they were created. An edit-in-place database log does not meet this standard. A cryptographically-chained, externally-witnessed event ledger does.
Article 13: Transparency and Information to Deployers
Providers must supply deployers with information sufficient for them to use the system compliantly — including intended purpose, performance specifications, known limitations, and required human oversight measures. This documentation must be updated when the system changes.
Article 14: Human Oversight
High-risk AI systems must be designed to enable effective human oversight. This requires not just a policy that says humans can override the AI, but a documented, operational process for human review with records showing when reviews occurred, what the reviewer decided, and what the outcome was. Human oversight records must be part of the AI event log — not a separate process with no connection to the AI decision record.
Article 15: Accuracy, Robustness, and Cybersecurity
High-risk AI systems must achieve appropriate levels of accuracy and robustness. Providers must document the metrics used to measure accuracy and the values achieved. This is the regulatory basis for requiring that AI systems produce and seal quality evaluation scores — not just the model's output, but the assessment of that output's quality.
The Gap Between "We Have Logs" and Article 12 Compliance
Applying Article 12's requirements to existing enterprise logging infrastructure typically reveals five categories of gap:
Gap 1: The logs are editable. Standard database logs can be modified by administrators. Article 12's "ex post facto verification" standard requires integrity protection that makes post-hoc modification detectable — not just controlled.
Gap 2: The logs are not automatically generated. Many compliance teams discover that their "AI decision logs" are actually reports generated by querying a database — not records automatically produced by the AI system at the time of each event.
Gap 3: Human oversight is not recorded alongside AI events. Article 14's human oversight requirement is typically managed as a separate process with no direct link to the specific AI event that triggered the review.
Gap 4: Quality evaluation scores are not captured. If the AI system produces a confidence score or a quality evaluation, and this score is not sealed alongside the output event, the Article 15 evidence record is incomplete.
Gap 5: There is no external attestation of record integrity. "We have an append-only log" is not the same as "we have an externally witnessed, write-once record that any auditor can verify."
What Deployers Need to Know (Article 26)
If you are a deployer — an organisation that uses a high-risk AI system provided by a third party — your obligations under Article 26 are distinct from the provider's obligations under Articles 9–17, but equally operational:
- You must implement the human oversight measures specified in the provider's instructions
- You must monitor the system's operation and report serious incidents to the provider and, if required, to the relevant authority
- You must retain logs of the system's operation for the period required under the applicable regulation
If your provider does not supply you with adequate logging capability to meet Article 26, you should require them to do so — or supplement their infrastructure with your own evidence layer.
The December 2027 Timeline: Why Starting Now Matters
The December 2027 deadline defines when compliance is required. It does not define when compliance becomes evidentially meaningful.
An AI system that begins sealing Article 12-compliant event records in July 2026 will have eighteen months of externally-witnessed history at the time of its first conformity assessment. That history is not just a compliance artefact — it is evidence of the system's actual operation over time: its accuracy patterns, its human override rates, its evaluation score distributions.
An AI system that begins sealing records in December 2027 has no operational history. Its conformity documentation is theoretical rather than empirical.
Regulators and notified bodies assessing high-risk AI systems are well-positioned to distinguish between enterprises that built evidence infrastructure early and enterprises that scrambled to meet a deadline. The historical record speaks for itself — or, if it does not exist, speaks by its absence.
Pre-mapped to Article-level controls. Ready for conformity assessment.
Provara's evidence ledger is built specifically for EU AI Act Articles 12, 14, and 15 compliance — automatically sealing every AI event, human oversight action, and evaluation score into a tamper-evident chain witnessed nightly into 7-year WORM storage. Evidence packets are pre-mapped to Article-level controls for one-click audit response.
Request a 30-minute technical demo →Related: EU AI Act deadline extended to December 2027 · What is an AI audit trail? · Tamper-evident AI logs explained