Who Owns EU AI Act Compliance in Your Organisation

The EU AI Act does not create a job title. It creates obligations — and each one lands on someone. Article 9 requires a risk management system with identified accountability. Article 17 requires a quality management system. Article 14 requires designated individuals who can intervene when a high-risk AI system needs human correction. Article 73 requires someone to make the call that an incident is serious enough to report to the competent authority within 15 days.

The term "AI compliance officer" has emerged as the practical label for whoever carries all of these. This page explains what the function actually requires: what it owns, how it interacts with the DPO and CISO, what the RACI looks like, and what happens at different organisation sizes.

---

Does the Act Mandate an AI Compliance Officer Title?

No. Regulation (EU) 2024/1689 does not use the phrase "AI compliance officer," and it does not require organisations to create a standalone role by any specific name. What it does is assign concrete obligations to the organisation as provider or deployer — and those obligations require a named human to own them.

The closest statutory analogue is the Article 22 authorised representative: a mandatory appointment for non-EU providers that places a high-risk AI system on the EU market. But for EU-based providers and for deployers, no comparable appointment is mandated by name. The practical answer is that someone within your legal entity must own the programme. What you call that person is up to you.

---

The Core Obligations the Role Must Cover

Building and maintaining the AI inventory

The AI compliance function owns the register. For each system, it must document the intended purpose, deployment context, technical profile, and the organisation's role (provider under Article 16, deployer under Article 26, importer under Article 23, or distributor under Article 24). Role is not self-evident — a company that builds an AI system on a third-party model and ships it under its own name is the provider under Article 25, regardless of who trained the underlying model.

Shadow AI is the persistent operational challenge: teams deploying tools without central oversight. The function needs a standing process for surfacing those tools and pulling them into the register before they become an undocumented liability.

Driving classification under Article 6

Once the inventory exists, classification is the critical gate. Article 6 sets the rules: does the system meet the criteria that make it high-risk? Does it fall within the Annex III areas — biometrics, critical infrastructure, education, employment and worker management, access to essential services, law enforcement, migration, or the administration of justice? And if it does, does the Article 6(3) filter apply — is the system genuinely narrow enough, procedural enough, that it poses no significant risk to health, safety, or fundamental rights?

Getting this wrong in either direction is costly. Overclaiming high-risk and over-engineering compliance for minimal-risk tools wastes resources. Underclaiming and skipping the high-risk stack on a system that actually qualifies exposes the organisation to fines of up to €15 million or 3% of worldwide turnover under Article 99(4). The AI compliance function owns these determinations, with input from legal (for the Art 6(3) assessment) and data science (for system capability scoping).

Coordinating the Article 9 risk management system

Article 9 requires a risk management system for every high-risk AI system: identification of risks, analysis, evaluation, and residual-risk controls — run throughout the system's entire lifecycle. The AI compliance officer does not run the risk assessments independently. They own the process: the methodology, the documentation standard, the schedule, and the sign-off chain. Data science leads provide capability assessments; business unit leads identify operational risks; legal covers regulatory exposure. The function synthesises these and maintains the Article 9 record.

Assigning human oversight per Article 26 and Article 14

Article 14 requires that high-risk AI systems be deployed with human oversight measures allowing responsible persons to understand, monitor, and where necessary override the system's output. Article 26 makes the deployer responsible for assigning qualified individuals to that function. The AI compliance officer identifies which staff roles interact with outputs in ways requiring real interpretive authority, and ensures those staff have the training and access to intervene. This feeds directly into the Article 4 literacy programme.

Owning Article 11 technical documentation

Article 11, read with Annex IV, requires technical documentation for every high-risk AI system before it goes to market or into service — nine content areas covering design, training data, performance results, risk management records, and human oversight provisions. This must be retained for ten years under Article 18.

The AI compliance officer is the custodian: setting the documentation standard, tracking outstanding sections from engineering and data science, maintaining version control, and ensuring the package is accessible to market surveillance authorities. For providers, this documentation is the foundation for the Article 47 Declaration of Conformity and the conformity assessment under Article 43.

Managing Article 4 AI literacy

Article 4 has been in force since 2 February 2025. The AI compliance function typically owns the literacy programme: mapping which staff roles interact with AI systems at compliance-relevant risk levels, designing role-appropriate training (executive awareness, operational user, technical practitioner), and maintaining completion records for audit. The Article 4 standard is already live — it is one of the obligations national supervisory authorities are most likely to probe before the high-risk deadlines arrive.

Post-market monitoring under Article 72

Article 72 requires providers of high-risk AI systems to operate a post-market monitoring system throughout the system's lifecycle — collecting and reviewing data on performance, identifying post-deployment risks, and updating the Article 9 risk management system accordingly. The AI compliance officer does not typically own the monitoring infrastructure (that sits with engineering and data science) but owns the governance framework: the monitoring plan within the technical documentation, the escalation thresholds, and the review schedule.

Incident reporting under Article 73

Serious incidents — those that result in death, serious harm, or pose a threat of serious harm — must be reported to the competent authority in the member state where the incident occurred. Under Article 73, the initial report is due within 15 days of becoming aware of the incident; 2 days if the incident involves widespread infringement or serious disruption of critical infrastructure; 10 days if a person has died.

The AI compliance officer owns the triage process: the criteria for what constitutes a serious incident under Article 3(49), the internal escalation chain, the threshold decision, and management of the regulatory reporting timeline. This requires pre-built processes — not an improvised response after something has already gone wrong.

---

RACI Across Functions

In most organisations, AI Act compliance is not a single-function exercise. Here is how the work typically divides:

---

Relationship to the DPO and CISO

The DPO

The Data Protection Officer — mandatory for many organisations under GDPR Article 37 — is the closest structural analogue to the AI compliance function. Both sit at the intersection of technology and regulation, both need cross-functional authority, and both interact with a supervisory authority. But the mandates differ: the DPO operates under GDPR 2016/679 with statutory independence and formal appointment; the AI compliance function has no equivalent independence requirement.

The substantive overlap is real. Article 27 FRIAs build on GDPR DPIAs — Article 27(4) expressly allows the FRIA to build on an existing DPIA. Where an AI system processes personal data, the DPO must be involved in the Article 9 risk assessment and the Article 27 FRIA. For organisations with multiple high-risk systems, the combined workload requires either dedicated AI compliance capacity or explicit prioritisation — not an assumption that one person can absorb both.

The CISO

The CISO's mandate overlaps with Article 15 (accuracy, robustness, and cybersecurity) and with the security dimension of Article 9 risk assessments. For AI systems covered by NIS2 — those that are components of critical infrastructure — the CISO's NIS2 obligations and Article 15 run in parallel. The AI compliance officer does not own the security controls directly, but must verify those controls satisfy the AI Act standard and ensure that finding is documented in the Article 9 and Article 11 records. A working relationship, not a hand-off.

---

Reporting to the Board

A market surveillance finding, a serious incident under Article 73, or a significant fine under Article 99 — these are board-level events. The AI compliance officer needs a reporting line that reaches senior leadership before concerns become enforcement matters. In practice: a quarterly report to the executive team or audit committee, covering the register state, open compliance gaps by system, literacy programme status, and any near-miss events. Format matters less than the fact that the information reaches decision-makers who can act on it.

---

The Reality at Smaller Companies

For a company with 20 to 80 staff, a dedicated full-time AI compliance officer is rarely economical. The practical arrangement is a designated person — often within legal, compliance, or IT — carrying the AI Act mandate alongside their existing responsibilities. This works when the AI portfolio is small and relatively low-risk. It works less well when the organisation has several high-risk systems in active development.

The practical floor for a competent part-time arrangement is roughly: one system in high-risk scope, a clear documentation methodology, and tooling that automates the assessment workflow rather than requiring everything to be built from scratch in spreadsheets. Without that support infrastructure, the role's documentation burden alone exceeds what a part-time designation can absorb.

How Confir helps

Confir gives the person carrying the AI compliance function — whether that is a dedicated officer or a legal or IT lead with a parallel mandate — one structured system to run the programme. Classification and role determination follow Article 6, Annex III logic via a plain-English questionnaire; the rule that fires is visible and explainable. Documentation is built and version-controlled in the system. The Article 27 FRIA and the Article 11 / Annex IV technical documentation pack are generated directly from the assessment record. The risk register and compliance health score give the board-facing view without a separate manual report. The engine is deterministic and rule-based — the same intake produces the same finding — which matters for a compliance product that may itself come under scrutiny.

From €600/year, self-serve, no implementation project.

---

Frequently Asked Questions

Is appointing an AI compliance officer legally required under the EU AI Act?

No, not by that title. Regulation (EU) 2024/1689 assigns concrete obligations to providers and deployers — including a risk management system under Article 9, human oversight assignment under Article 26, technical documentation under Article 11, post-market monitoring under Article 72, and incident reporting under Article 73 — but it does not mandate a role called "AI compliance officer." What it mandates is that these obligations are met. In practice, assigning them to a named function is the only way to ensure accountability. The Article 22 authorised representative is the one formal appointment the Act does require — but only for non-EU providers placing systems on the EU market.

Can our DPO cover the AI compliance function as well?

For many smaller organisations, yes — especially if the AI portfolio is modest and concentrated in lower-risk systems. The DPO already has regulatory expertise, cross-functional standing, and a relationship with senior leadership. The additional knowledge required — EU AI Act structure, Article 6 classification logic, Article 9 risk management methodology, Article 73 incident timelines — can be acquired. The real constraint is time: a multi-system high-risk portfolio creates ongoing documentation, monitoring, and governance work that can conflict with the DPO's existing GDPR obligations. Where both mandates are live, be explicit about capacity and prioritise accordingly.

What is the relationship between the AI compliance officer and the CISO?

Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. The CISO typically owns the security controls. The AI compliance officer's role is to verify that those controls satisfy the AI Act standard and ensure the finding is captured in the Article 9 risk management system and the Article 11 technical documentation. In organisations subject to NIS2, the overlap deepens — AI systems embedded in critical infrastructure carry both NIS2 security obligations and AI Act Article 15 requirements simultaneously. Plan for joint assessments rather than parallel ones.

When does the Article 4 AI literacy obligation apply?

Article 4 has applied since 2 February 2025. There is no further deferral for this obligation — it is already live. It requires providers and deployers to ensure staff have sufficient AI literacy for their roles. The standard is proportionate: an executive who approves AI deployments needs a different level of understanding than a data scientist building models or a customer-service agent using an AI tool. The AI compliance officer should have a literacy mapping completed, training in place, and completion records documented. This is one of the areas supervisory authorities can audit without waiting for the high-risk deadline.

What qualifications exist for AI compliance professionals?

The profession is still forming, and there is no settled credential equivalent to CIPP/E for GDPR. Relevant options as of mid-2026: IAPP AIGP (AI Governance Professional), ISO/IEC 42001 Lead Implementer or Auditor (valuable for the QMS and risk management methodology), and AI Act-specific programmes from specialist legal training providers. In practice, demonstrated experience working with the Regulation — having built a classification programme, managed technical documentation, or navigated an incident triage — is weighted more heavily than formal credentials in hiring decisions. That will shift as the market matures.

What does the RACI look like for a 30-person company that cannot afford a dedicated AI compliance officer?

At that scale, the role almost always falls to one person as a secondary responsibility — typically a head of legal, a compliance lead, or a senior IT manager. The key is to be explicit about who owns each statutory obligation rather than leaving it diffuse. Assign a named owner for the AI register, for Article 9 risk management, for Article 4 literacy records, and for the Article 73 incident triage chain. Even at 30 people, a serious incident that goes unreported because no one was clearly accountable creates direct regulatory exposure.

How does the high-risk compliance deadline affect planning now?

Under the Digital Omnibus agreed in May 2026, stand-alone high-risk AI systems (Annex III) must comply from 2 December 2027, and high-risk AI embedded in regulated products (Annex I) from 2 August 2028 — pushing back the original August 2026 date. But two obligations are already live: Article 4 AI literacy (since 2 February 2025) and Article 72 post-market monitoring obligations that attach to systems already deployed. Starting the inventory and classification programme now means that when 2027 arrives, the documentation and governance framework already exist. Starting in late 2027 means building under pressure, with regulators already in position.

---

Related guides

• AI policy template for Article 5 compliance
• provider and deployer obligations checklist
• SMB compliance requirements
• EU AI Act framework overview
• AI risk management tools comparison
• legal tech AI compliance guide