"Who in my organization is actually accountable under the EU AI Act?" is among the most common questions GRC leads and compliance engineers raise once they have completed initial classification work. The answer, as established in Regulation (EU) 2024/1689 — the EU AI Act — depends on a distinction the regulation draws clearly but that engineering organizations frequently collapse in practice: the difference between a provider and a deployer, and the obligations that attach to each role.
Six persistent misconceptions shape how engineering organizations approach internal accountability under the regulation. Each one, left unaddressed, tends to produce either over-engineering — taking on obligations that do not apply — or under-engineering, treating deployer requirements as less demanding than the regulation generally provides. What follows addresses each directly, drawing on the regulation's text and supporting practitioner analysis.
Six Misconceptions About EU AI Act Accountability
Misconception 1: "We bought a third-party AI tool, so compliance is the vendor's responsibility."
The EU AI Act draws a clear distinction. A provider (Article 3(3)) is an entity that develops or places an AI system on the market under its own name or trademark. A deployer (Article 3(4)) is an entity that uses an AI system under its authority in a professional context — which describes most engineering organizations using commercial AI development tools.
The deployer category carries its own independent set of obligations under Article 26 of the regulation. Among the requirements Article 26 generally addresses for deployers of high-risk AI systems:
Use the system in accordance with the provider's instructions for use (Art. 26(1))
Assign human oversight to natural persons with the necessary competence, training, and authority (Art. 26(2))
Retain automatically generated logs for at least six months, unless other applicable law specifies otherwise (Art. 26(6))
Monitor the system's operation and notify the provider of issues per Article 72 (Art. 26(3))
Before deploying the system in a workplace context, notify affected workers and their representatives (Art. 26(7))
Ensure that input data is appropriate in quality to the system's intended purpose (Art. 26(5))
Maintain AI literacy for all staff involved in operating or overseeing the system (Art. 26(4), cross-referencing Article 4)
Whether a specific AI coding or development tool qualifies as a high-risk AI system — and therefore triggers these obligations — depends on the risk classification analysis under Articles 5 and 6 and Annex III. As generally understood, most general-purpose AI coding assistants are not currently classified as high-risk under Annex III; however, organizations should conduct and document that classification for each system in scope.
Misconception 2: "The Quality Management System under Article 17 is an IT documentation project."
Article 17 requires providers of high-risk AI systems to establish a documented quality management system. The regulation specifies that this system should address: regulatory compliance strategy, design and development procedures, data management practices, risk management processes aligned with Article 9, post-market monitoring arrangements, and incident reporting and communication procedures.
Article 17's QMS requirement is a governance structure that assigns accountability across organizational functions for an AI system's lifecycle — not a documentation artifact assigned to one team. The EU AI Act Service Desk guidance on Article 17 notes that QMS requirements should be proportionate to organizational size and may be embedded within existing quality management frameworks where those already exist under other applicable law.
In practice, Article 17 QMS accountability typically spans at least three functions:
Legal or compliance: regulatory compliance strategy, incident reporting procedures, and relationship with notified bodies and national competent authorities
Engineering or platform engineering: technical documentation, testing and validation procedures, post-market monitoring mechanisms, and accuracy and robustness controls (Article 15)
Data or ML engineering: data governance procedures aligned with Article 10, dataset management, and acquisition and annotation process documentation
No single function should own the QMS in isolation. The regulation requires it to be documented as a system — with defined coverage, named owners, and verifiable processes proportionate to the organization's risk profile.
Misconception 3: "Article 26 only applies to HR or hiring systems — not to developer tooling."
Article 26 applies to all deployers of high-risk AI systems as defined in Article 3(4), regardless of the application domain. High-risk AI systems are defined in Article 6 and Annex III, covering specific sectors and use cases — employment and access to employment (Annex III, point 4) is one listed category, but not the only one.
For most general-purpose AI coding assistants, Annex III's current list does not automatically classify them as high-risk. Two important considerations apply, however. First, Article 25(1) provides that a deployer is reclassified as a provider — and assumes the full provider obligation set — when it makes a substantial modification to a high-risk AI system or changes its intended purpose in a way that brings a system into a high-risk category. Second, the European Commission may update Annex III's list of high-risk AI use cases over time under Article 7.
For engineering organizations, the practical implication is: classify each AI system in scope against the regulation's current definitions, document the classification and its reasoning, and establish an internal review process triggered by material modifications or changes in use.
Misconception 4: "The EU AI Act requires every organization to appoint a Chief AI Officer."
The regulation does not mandate a Chief AI Officer or equivalent internal governance role for most organizations under its current text. Article 22 defines an 'authorised representative' requirement — but this applies specifically to providers located outside the EU, functioning as a market access provision with defined scope. It is not a general internal governance mandate for all organizations subject to the regulation.
However, the regulation's requirements across Articles 9, 17, 26(2), and 4 create accountability obligations that collectively require a governance function to own them. Legal commentary including analysis published by Zunic Law and reviewed on Lexology describes the emergence of an AI Officer function as an organizational best practice — comparable in structure to the DPO model introduced under GDPR, though without the same explicit legal mandate for most organizations under the EU AI Act's current text.
Whether this function becomes a standalone role or remains distributed across existing legal, compliance, and engineering leadership depends on organizational size and risk exposure. The regulation generally allows flexibility in governance structure design, provided the accountability outcomes — documented risk management, traceable QMS, competent oversight personnel, and verifiable AI literacy — are demonstrably met.
Misconception 5: "Our legal team can manage all EU AI Act compliance."
The regulation explicitly assigns obligations that require operational engineering capability. Article 26(2) requires human oversight to be assigned to persons with technical competence and the authority to intervene in or halt a system's operation — a requirement that cannot be met solely through legal drafting. Article 26(5) requires that input data quality be verified as appropriate to the system's intended purpose — a data engineering accountability. Article 9's risk management system requires continuous technical performance assessment, not solely regulatory analysis.
EU AI Act compliance, as generally structured in practitioner frameworks including the technical implementation blueprint published on Zenodo (Das, 2025), involves at minimum a shared governance model across functions:
Legal and compliance: regulatory strategy, documentation framework, national competent authority liaison, and reclassification monitoring under Article 25
Engineering: technical controls, monitoring infrastructure, log retention implementation (Art. 26(6)), and human oversight designation and verification (Art. 26(2))
Data teams: data governance procedures per Article 10 and input data quality verification (Art. 26(5))
Risk management: risk management system design and maintenance per Article 9, escalation procedures, and anomaly identification
Misconception 6: "Modifying a purchased AI system does not change our compliance obligations."
Article 25(1) of the regulation states that a deployer is reclassified as a provider — and assumes provider obligations — when it makes a substantial modification to a high-risk AI system. Article 3(23) defines 'substantial modification' as a change that affects the AI system's compliance with the regulation's requirements or alters its intended purpose.
Modifications that may approach or cross this threshold in engineering contexts include:
Fine-tuning a foundation model on proprietary data for a specific high-risk use case
Integrating an AI system with additional decision-making components that materially change the scope of its outputs
Extending a system to an application domain not covered in the original conformity assessment
Changing an AI system's intended purpose such that the modified system falls within an Annex III high-risk category
When reclassification occurs under Article 25, the organization assumes provider obligations including conformity assessment (Article 43), CE marking, EU AI database registration (Articles 48-49), and the full technical documentation package under Annex IV. Identifying modification thresholds before significant engineering work is, as generally recommended in compliance analysis, more tractable than retrospective reclassification assessment.
Role-Obligation Reference for Engineering Organizations
The following table summarizes the primary obligation areas and the internal functions generally expected to carry accountability for each. This is intended as a starting framework for governance design — not a legal mapping. The appropriate accountability structure for any specific organization depends on its risk classification, size, and whether it operates as a provider, a deployer, or both.
A Practical Starting Framework
Map each AI system in scope to the provider/deployer distinction using Article 3's definitions, and document the reasoning for each classification.
Review Article 25 reclassification triggers before any material modification — including fine-tuning, integration changes, or scope extension — and establish internal thresholds for triggering a reclassification review.
For AI systems where your organization operates as a deployer of a high-risk system: assign named owners for each Article 26 obligation, starting with human oversight designation (Art. 26(2)) and log retention (Art. 26(6)).
For AI systems where your organization operates as a provider: map the Article 17 QMS requirements across legal, engineering, and data functions, and identify which existing governance processes can absorb each element.
Establish a cross-functional accountability structure — even a lightweight one — that links each regulatory obligation to a named internal function with a documented review cadence.
According to Eurostat's 2025 enterprise AI adoption data (isoc_eb_ai statistical series), 20% of EU enterprises with 10 or more employees were using AI technologies — up 6.5 percentage points from 13.5% in 2024, with large enterprises (250+ employees) reaching approximately 55% adoption. This adoption trajectory means that accountability structures need to be designed proactively: organizations that establish governance frameworks before their AI use scales are generally better positioned to demonstrate proportionate compliance than those that build governance reactively.
Implementing traceable accountability structures for EU AI Act compliance — across human oversight, log retention, and quality management — requires tooling that makes governance obligations auditable. re-entry.ai is designed to help engineering organizations govern AI coding agents and development tools in alignment with the regulation's requirements.
This article is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for guidance on your specific situation.