Why the Act demands new compliance infrastructure
AI systems can operate at high volume, change across releases, and produce outputs that require system-specific testing and records. Existing compliance controls remain relevant, but teams may need additional technical and operational evidence for the systems and obligations in scope. Three challenges recur.
1. Scale of decision-making
Sampling and automatic event logging answer different questions. Article 12 requires automatic logging capabilities appropriate to the system’s intended purpose and applicable events; it does not displace all sampling or prescribe continuous real-time capture of every event.
2. Technical complexity
Assessing whether an AI system complies can draw on machine-learning, security, legal, and data-governance expertise. One workable model is a compliance-owned program with engineering, security, product, and legal owners accountable for the technical and legal assertions in scope.
3. Evidence requirements
The Regulation calls for specific artefacts: Annex IV technical documentation, Article 9 risk-management records, Article 12 logs, and a conformity declaration. Article 12 requires automatic logging capabilities that support traceability; it does not prescribe cryptographic attestation or say that a log, by itself, proves a control was effective.
GDPR and AI Act work can share governance, data, security, and review infrastructure, but their scopes and duties are not identical. The organization should map Article 10 data governance, Article 14 human oversight, Article 15 robustness, and other applicable duties to named owners and evidence.
Key CCO responsibilities under the Act
The Regulation assigns obligations to providers, deployers, and other operators, not to the CCO title. An organization may ask a CCO to coordinate the program, but ownership should follow the operator role and the organization’s documented allocation. Five useful anchors are:
Risk classification and inventory management
Knowing exactly which AI systems are in use and how each is classified under the Regulation is the foundation of every other obligation. The inventory should cover:
- Complete AI inventory: every AI system in development, testing, and production, including third-party AI embedded in vendor products and procurement-acquired SaaS.
- Risk classification: map each system to prohibited (Article 5), high-risk (Annex III or Annex I products), limited-risk (Article 50 transparency), or minimal-risk categories.
- Role determination: document whether the entity is the provider, the deployer, or both for each system. This drives which obligations apply.
Quality management system oversight (Article 17)
High-risk AI providers must establish a quality management system (QMS) covering the entire AI lifecycle. Article 17 specifies the QMS must include:
- Strategy for regulatory compliance
- Techniques and procedures for design, development, and testing
- Examination, test, and validation procedures
- Technical specifications including standards applied
- Systems and procedures for data management
- Risk management system per Article 9
- Post-market monitoring system per Article 72
- Incident reporting procedures per Article 73
Documentation and record-keeping (Articles 11, 12, 18)
Article 11 requires technical documentation demonstrating compliance with all requirements. This includes system architecture, development methodology, training data descriptions, testing procedures, and performance metrics.
Article 12 mandates automatic logging capabilities over the lifetime of a high-risk system. The logging must support traceability appropriate to the system’s intended purpose, including events relevant to identifying situations that may create risk or constitute a substantial modification, and facilitate post-market monitoring.
Article 18 generally requires providers to keep specified technical documentation, QMS documentation, notified-body records where applicable, and the EU declaration of conformity available for national competent authorities for 10 years after the AI system is placed on the market or put into service. This is a documentation-retention rule, not a blanket 10-year rule for operational logs. Under Article 26(6), deployers keep logs automatically generated by a high-risk system and under their control for a period appropriate to the intended purpose of the system, of at least six months unless other applicable EU or national law provides otherwise.
Conformity assessment coordination (Articles 43 and 44)
Before a high-risk AI system is placed on the market, it must complete a conformity assessment. Most Annex III systems allow internal-control assessment (self-certification under Article 43); biometric identification and certain medical AI devices require third-party notified-body involvement. The CCO function coordinates the assessment process, ensures documentation completeness, and maintains the EU declaration of conformity.
Incident reporting (Article 73)
Article 73 requires providers of high-risk AI systems to report immediately once a causal link or reasonable likelihood is established. The general outer limit is 15 days from awareness; it is 2 days for a widespread infringement or serious and irreversible critical-infrastructure disruption, and 10 days where a person has died. Build detection, classification, authority-notification, and corrective-action procedures around the applicable trigger and route.
Post-market monitoring (Article 72)
Providers must establish post-market monitoring systems proportionate to the AI system’s nature and risks. This includes collecting and analyzing data on system performance, logging compliance, incident patterns, and user feedback, then feeding the result back into risk assessments and technical documentation. Article 72 closes the loop: the monitoring output is part of the audit file the regulator can request.
Building the AI compliance program
A robust AI compliance program requires four foundational elements:
1. Governance Structure
- AI governance committee with cross-functional representation
- Clear roles and responsibilities (RACI matrix)
- Escalation pathways for risk decisions
- Board-level accountability
2. Policy Framework
- AI acceptable use policy
- Risk classification standards
- Vendor AI assessment requirements
- Incident response procedures
3. Technical Infrastructure
- AI system inventory platform
- Automated logging infrastructure
- Risk assessment tooling
- Documentation management system
4. Monitoring and Assurance
- Continuous control monitoring
- Internal audit program
- Performance metrics and KPIs
- Third-party attestation strategy
Questions CCOs should be asking their organizations
The questions below are useful inside the AI governance committee to identify gaps before a competent-authority review:
Inventory and Classification
- Q1 Do we have a complete inventory of all AI systems, including AI embedded in third-party software?
- Q2 Has each system been classified against EU AI Act risk categories?
- Q3 Are we the provider, deployer, or both for each system?
Technical Compliance
- Q4 Do our high-risk AI systems generate automatic logs per Article 12?
- Q5 Where are logs stored, for how long, and who has access?
- Q6 Can we demonstrate human oversight mechanisms exist and function?
Documentation and Process
- Q7 Do we have technical documentation meeting Annex IV requirements?
- Q8 What process applies the immediate-reporting trigger and the 2-, 10-, or 15-day outer limit for each serious incident?
- Q9 When was our risk management documentation last updated?
Red flags indicating compliance gaps
The patterns below are the recurring gaps spotted in CCO programs during pre-audit reviews:
- No usable AI inventory. If the organization cannot produce and maintain an appropriately scoped inventory, including relevant AI inside SaaS, classification and oversight are impaired. The Act does not impose a one-hour inventory test, and Article 11 technical documentation is not itself a universal enterprise inventory requirement.
- No automatic logging capability. Spreadsheets and after-the-fact PDFs cannot replace the automatic logging capability Article 12 requires. Integrity controls may strengthen the resulting evidence, but the Regulation does not prescribe a general tamper-evident or cryptographic format.
- No documented scope or classification rationale. Maintain a documented scope and classification rationale for inventoried systems where relevant, and define the organization’s review and approval route.
- Shadow AI. Business units deploying tools like ChatGPT, Copilot or in-house copilots without compliance review. These still count toward the inventory.
- No incident playbook. Article 73 combines an immediate-reporting trigger with 2-, 10-, and 15-day outer limits from awareness; programs without a working escalation procedure can miss the applicable clock.
- Third-party AI blind spots. Using AI features in SaaS products without establishing the parties’ roles, intended use, relevant Article 25 value-chain information where that Article applies, and current provider documentation. GPAI Code participation is voluntary and is not a universal vendor-record requirement.
Audit-readiness checklist
Use this checklist to prepare for regulatory inspection or third-party audit:
EU AI Act Audit Readiness Checklist
Inventory and Classification
Technical Documentation (Article 11, Annex IV)
Logging Infrastructure (Article 12)
Risk Management (Article 9)
Quality Management System (Article 17)
Conformity and Declarations
Working with other stakeholders
EU AI Act compliance requires cross-functional collaboration. Here’s how to work effectively with key stakeholders:
| Stakeholder | Key Collaboration Areas | What the compliance function needs from them |
|---|---|---|
| CISO | Logging infrastructure, access controls, incident response, cybersecurity requirements | Technical logging architecture, security assessments, incident detection capabilities |
| General Counsel | Regulatory interpretation, liability analysis, contract requirements, enforcement monitoring | Legal opinions on classification, contract language for AI vendors, regulatory updates |
| CTO/Engineering | Technical documentation, system architecture, logging implementation, human oversight | AI system inventory, technical specifications, Article 12 logging implementation |
| Data/AI Team | Model documentation, training data governance, performance monitoring, bias testing | Training data descriptions, model cards, validation results, fairness assessments |
| Business Units | Use case identification, risk assessment input, user requirements, incident reporting | AI usage disclosure, intended purpose documentation, operational risk input |
| Procurement | Vendor AI assessment, contract requirements, third-party compliance | AI vendor inventory, contract amendments, provider compliance attestations |
Board and executive reporting on compliance status
Your board needs clear, actionable information about AI compliance status. Structure your reports around these elements:
Quarterly board report framework
1. Compliance Status Dashboard
Traffic-light summary of compliance across all high-risk AI systems. Include systems count, deadline proximity, and overall program health score.
2. Risk Exposure Summary
Quantify potential penalty exposure (€ amount), identify highest-risk systems, and summarize mitigation progress.
3. Incident Report
Summary of any AI-related incidents, near-misses, and corrective actions taken. Include trends analysis.
4. Resource and Investment Needs
Budget requirements for compliance infrastructure, staffing gaps, and third-party assessment costs.
5. Regulatory Developments
Updates on implementing acts, guidance from the AI Office, and enforcement actions in your sector.
Distinct assurance mechanisms
ISO/IEC 42001 management-system certification and EU AI Act conformity assessment answer different questions. The former is voluntary organizational assurance; the latter is the system-specific legal pathway required where the Act applies. ISO certification does not substitute for conformity assessment.
ISO 42001 Certification
Voluntary AI management-system standard that can organize governance evidence. The European Commission says its goals and definitions are not aligned with the quality-management system required by the AI Act.
- + Shows a scoped AIMS was assessed against ISO/IEC 42001
- + Supports internal control assessment
- + Market credibility signal
Planning boundary: Timing and cost vary materially with system inventory, risk classification, evidence readiness, internal capability, provider rates, and the obligations that actually apply. Scope these before setting a budget or deadline.
Conformity Assessment (Articles 43-44)
Mandatory assessment pathway for placing high-risk AI systems on the EU market. Internal control or notified body assessment.
- + Legally required for market access
- + Enables CE marking
- + EU Declaration of Conformity
External assessment: Article 43 determines when notified-body involvement applies. Scope, timing, and fees must be confirmed with an eligible body for the particular system; this guide does not supply a generic estimate.
What Article 12 logging requires
Article 12 is among the most technically demanding requirements of the EU AI Act. It mandates that high-risk AI systems be designed with automatic logging capabilities that:
- Record events throughout the system’s lifetime
- Enable traceability of the system’s functioning
- Facilitate post-market monitoring
- Support identification of risks and serious incidents
Retention depends on the actor and record type. Article 18 generally gives providers a 10-year retention period for specified compliance documentation. Articles 19 and 26 address automatically generated logs under the control of providers and deployers respectively; the Article 26 deployer period must be appropriate to the intended purpose and at least six months unless other applicable EU or national law provides otherwise.
Article 12 requires automatic logging capabilities rather than only manual documentation after the fact. Teams still need to decide which events and integrity protections are appropriate to the system’s intended purpose and other applicable law; Article 12 does not impose a general cryptographic or tamper-evident format.
For high-risk systems generally, Article 12 describes logging at a functional level: enough traceability to identify risk-relevant situations or substantial modifications and to facilitate post-market monitoring. It does not categorically require every input, output, decision trace, or human intervention to be recorded. The Act specifies additional minimum events for high-risk remote biometric identification systems, including the duration of use, the reference database, input data that led to a match, and the persons involved in verifying results. Depending on the system, a useful operational record may also include:
- System and control identifiers relevant to the recorded event
- Allow, block, or escalation outcomes when those events are relevant to the intended traceability purpose
- Human oversight interventions where the system design or another applicable rule calls for them
- System anomalies and error conditions
- Integrity metadata that helps a reviewer detect alteration of the record
How GLACIS helps CCOs maintain audit readiness
GLACIS can supply operational evidence that supports an Article 12 logging design and a broader audit-readiness program. Whether a deployment meets the Act depends on the system, the organization’s role, its full control environment, and the applicable conformity-assessment pathway.
Scoped Operational Records
Cryptographically verifiable records of what a configured supervision step reported for a covered event. Verification establishes integrity and key attribution for covered fields, not execution, source truth, control effectiveness, or legal sufficiency.
Framework Mapping
Map selected records to the control or requirement they may support, with reviewer-approved scope and gaps. Similar evidence can be reused, but each framework needs a separate applicability and sufficiency assessment.
Review Packages
Assemble the selected records, context, limitations and verification instructions a regulator, auditor, or customer can review. The package supports preparation; it is not a compliance determination.
Tamper-Evident Logging
Tamper-evident records that make later alteration detectable. This can support traceability and evidence integrity, but Article 12 does not require a particular cryptographic method and GLACIS does not itself establish conformity.
Frequently asked questions
What are the CCO’s primary responsibilities under the EU AI Act?
The Act assigns duties to providers, deployers and other operators, not to the CCO title. A CCO may coordinate inventory, role and classification work, quality-management and conformity evidence, incident reporting, post-market monitoring and board reporting, but ownership should follow the organization’s actual operator roles and governance allocation.
What documentation must CCOs maintain for EU AI Act compliance?
The Act assigns documentation and retention duties by operator role and system. A CCO may coordinate applicable Article 9, 11, 12, 17, 18, and 26 work, but should not be described as the statutory owner by title. Providers generally retain the Article 18 materials specified there for 10 years; deployers of covered high-risk systems keep logs under their control for an appropriate period of at least six months unless other EU or national law applies.
How should CCOs prepare for EU AI Act audits?
CCOs should establish a complete AI system inventory with risk classifications, define and implement automatic logging appropriate to each high-risk system’s intended purpose, document conformity-assessment evidence, prepare technical documentation and risk assessments, and conduct regular internal audits. Article 12 does not require a trace of every AI-related decision; the logging design should cover the risk-relevant events and monitoring needs the Act describes.
What incident reporting requirements does Article 73 impose?
Article 73 requires providers of high-risk AI systems to report immediately once a causal link or reasonable likelihood is established. The general outer limit is 15 days from awareness; it is 2 days for a widespread infringement or serious and irreversible critical-infrastructure disruption, and 10 days where a person has died. Establish detection, escalation, and reporting workflows for the applicable trigger, authority, and clock.
How does ISO 42001 certification relate to EU AI Act compliance?
ISO/IEC 42001 is a voluntary management-system standard. Certification may provide reusable governance evidence, but it is not an AI Act conformity pathway, does not substitute for Article 43 assessment, and does not itself create a presumption of conformity. Map each applicable legal requirement and use only suitable harmonised standards referenced in the Official Journal for any claimed presumption.
What should CCOs report to the board about AI compliance?
Board reports should cover: AI system inventory summary with risk classifications, conformity assessment status and upcoming deadlines, incident reports and remediation actions, compliance gap analysis and remediation roadmap, resource requirements for compliance infrastructure, regulatory developments and their business impact, and third-party audit findings. Reports should use clear risk metrics and traffic-light status indicators.
References
- European Union. “Regulation (EU) 2024/1689 of the European Parliament and of the Council.” Consolidated text current to 27 July 2026.
- European Parliament. “AI Act: deal on simplification measures, ban on nudifier apps.” Press release, 27 April 2026. europarl.europa.eu. See also Council of the EU, “Artificial intelligence: Council and Parliament agree to simplify and streamline rules,” press release, 6–7 May 2026. consilium.europa.eu
- European Commission. “AI Omnibus enters into force.” 27 July 2026. digital-strategy.ec.europa.eu
- European Commission. “Contents of the GPAI Code of Practice.” Digital Strategy, 2026. digital-strategy.ec.europa.eu
- European Commission. “Signatories of the GPAI Code of Practice.” Digital Strategy, 2026. digital-strategy.ec.europa.eu
- CEN-CENELEC. “AI standardization update — accelerated work program.” 23 October 2025. cencenelec.eu
- European Commission. “AI Office.” Digital Strategy, 2026. digital-strategy.ec.europa.eu
- ISO/IEC. “ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system.” December 2023. iso.org