EU AI Act Compliance for Large Enterprises: Portfolio Governance at Scale

A large enterprise approaching EU AI Act compliance faces a problem that does not exist for a 50-person company: the sheer number of AI systems to govern. Across procurement, HR, finance, customer operations, and product divisions, a typical European corporate group runs dozens — sometimes hundreds — of AI-assisted tools, most of them purchased from third-party vendors, a minority built in-house. Each must be classified, documented, and managed. The compliance question is not just "what does Article 6 require?" but "how do we run this consistently across every business unit, without recreating the wheel forty times?"

That governance challenge is what this guide addresses. For a grounding in the Act's core structure, see What Is the EU AI Act?. For a practical guide sized to smaller teams, see EU AI Act Compliance for Smaller Companies.

---

Starting Point: Build an Enterprise-Wide AI Inventory

You cannot classify what you have not catalogued. The first step for any large organisation is a complete inventory of every AI system in use — across every business unit, legal entity in scope, and vendor relationship.

Under Article 6 of Regulation (EU) 2024/1689, classification into a risk tier requires knowing the system's intended purpose, the domain it operates in, and whether it meets the Article 6(3) filter conditions. None of that is possible without a structured register.

For a large enterprise, inventory work typically reveals three categories of systems:

Commercial AI tools deployed at scale — productivity suites with embedded AI (think M365 Copilot), HR platforms with automated screening features, finance systems with anomaly detection. Most land as minimal-risk or limited-risk (Article 50 transparency obligations). But any tool used for an Annex III purpose — credit decisions, recruitment screening, workforce management — inherits the full high-risk stack regardless of the vendor's marketing.

Third-party high-risk systems — specialist tools purchased for an Annex III use case: a CV-screening module in the ATS, a creditworthiness engine in the loan-origination workflow, a biometric access-control system in the facilities stack. For each of these, the enterprise operates as a deployer under Article 26 and must verify provider compliance, implement human oversight under Article 14, maintain logs for at least six months, and — for creditworthiness (Annex III 5(b)), health/life insurance (5(c)), or public-body deployments — complete a Fundamental Rights Impact Assessment under Article 27.

In-house AI systems — custom models built or fine-tuned internally, or third-party models rebranded and shipped under the company's name. The moment an organisation places a high-risk system on the market or into service under its own name or trademark, it becomes a provider under Article 16. Article 25 closes the loophole: if you substantially modify a third-party system or redeploy it for a purpose beyond its original intended use, you inherit the provider obligations even if you did not build it.

The Art 25 trap matters especially for large enterprises experimenting with rebranded GPAI models (Articles 51–55 govern the GPAI model itself; Article 25 governs what happens when the enterprise wraps it into a product).

---

Centralised AI Governance Function and Federated Ownership

Running compliance across a portfolio of dozens or hundreds of systems requires two structural elements: a central function that sets standards and owns the register, and federated accountability in each business unit that actually knows what the systems do.

The central AI governance function should be responsible for:

• Maintaining the AI inventory and classification methodology under Article 6
• Setting the enterprise-wide template for the Article 9 risk management system, Article 11 / Annex IV technical documentation, and Article 14 human oversight requirements
• Owning the Article 17 Quality Management System (QMS) — the documented organisational framework that governs how the enterprise develops, validates, and monitors high-risk AI across its lifecycle
• Coordinating with Legal and Data Protection on GDPR overlaps (especially the Article 27 FRIA, which builds on but is distinct from the GDPR Article 35 DPIA)
• Maintaining the org-wide risk register and audit log required for board-level and regulatory reporting
• Leading incident reporting workflows under Article 73, which sets hard timelines: 15 days from awareness for serious incidents, 10 days where a death has occurred, 2 days for widespread or catastrophic disruption

Federated AI owners — typically a compliance lead or product owner in each business unit — should be accountable for:

• Maintaining system-level records within the central register
• Conducting Article 9 risk management reviews on schedule
• Implementing Article 14 human oversight procedures appropriate to their domain
• Flagging new AI deployments and vendor changes before they go live
• Monitoring deployed systems and surfacing anomalies to the central function

A RACI that makes the central function responsible-and-accountable for the standard and each business unit accountable-and-responsible for its own systems is the operational pattern that works in practice. Without federated ownership, the central team is chasing 200 systems it does not understand. Without the central standard, every BU invents its own classification logic and documentation format.

---

Article 17 QMS at Scale

For enterprises with multiple in-house or rebranded high-risk systems, Article 17 requires a documented Quality Management System covering the full development and deployment lifecycle: design, testing, validation, deployment, monitoring, and update procedures. The QMS must address data governance, technical robustness, and post-market monitoring.

The practical challenge is that large enterprises already operate quality frameworks — ISO 9001, ISO/IEC 27001, and increasingly ISO/IEC 42001 (AI management systems). The good news is that Article 17 does not require a standalone QMS built from scratch. It requires that the relevant quality obligations are covered. ISO/IEC 42001 maps well to Article 17 and to the Article 9 risk management requirements, though it is important to be precise: ISO 42001 certification is voluntary and does not substitute for the Article 43 conformity assessment. It supports the technical file and the QMS evidence base; it does not replace the legal compliance procedure.

GDPR compliance programs are similarly worth integrating rather than running in parallel. Article 10's data governance requirements for high-risk AI (data quality, representativeness, bias testing) overlap naturally with GDPR data-minimisation and purpose-limitation obligations. The governance team should map these intersections explicitly rather than building two separate workflows.

---

Standardising the High-Risk Compliance Stack Across the Portfolio

Every high-risk system — whether the enterprise is acting as provider or deployer — requires a consistent set of documented outputs. Standardising these templates across the portfolio saves significant time and creates audit consistency.

Article 9 risk management system: A documented, iterative process covering risk identification, analysis, evaluation, and mitigation across the system's lifecycle. For deployers, this includes monitoring in the operational context, which may differ from how the provider tested the system.

Article 11 / Annex IV technical documentation: Nine documentation areas covering intended purpose, system architecture, training and validation data, performance metrics, risk management, and human oversight provisions. Providers compile and maintain this; deployers receive and review it. The documentation must be retained for 10 years under Article 18.

Article 14 human oversight: Each high-risk system must have documented oversight procedures: who reviews AI outputs, under what conditions, with what authority to override, and how override decisions are recorded. For a financial institution deploying a credit-scoring system under Annex III point 5(b), this means defined protocols for loan officers reviewing and overriding model recommendations.

Article 43 conformity assessment: Providers must complete the conformity assessment before placing a high-risk system on the market. Most Annex III categories (points 2–8: critical infrastructure, education, employment, services, law enforcement, migration, justice) use the internal self-assessment procedure under Annex VI. Point 1 (biometrics) generally requires the Annex VII notified-body route where harmonised standards are not applied.

Article 47 / Annex V Declaration of Conformity and Article 49 registration: Providers sign a Declaration of Conformity and register the system in the EU database (Article 71) under Article 49 before deployment. Deployers must verify these exist.

---

Procurement and Vendor Due Diligence

Most of a large enterprise's AI systems arrive through procurement. Building compliance checks into the purchasing process is more efficient than retrofitting documentation after a system is live.

Vendor due diligence for high-risk AI procurement should require, at minimum:

• Confirmation of the provider's role and a copy of the Article 11 / Annex IV technical documentation or a summary thereof
• The Article 47 EU Declaration of Conformity and Article 49 registration reference
• Evidence that the Article 9 risk management system has been conducted for the system as supplied
• Instructions for deployers under Article 13, including documented intended purpose, known limitations, and recommended human oversight protocols
• Contractual commitments on incident notification (the provider must report serious incidents to authorities under Article 73; the deployer must flag incidents to the provider under Article 26)

These requirements should be standard contract clauses in any procurement of an AI system that could be classified as high-risk. For systems that land as minimal or limited-risk, a lighter-touch due-diligence checklist — confirming Article 50 transparency obligations are met if the system is customer-facing — is sufficient.

---

Penalties: No SME Cap for Large Enterprises

Article 99 of the Regulation applies in full to large enterprises. There is no proportionality reduction of the kind available to SMEs and start-ups under Article 99(6), which caps fines at the lower of the fixed amount or the percentage for smaller operators.

For a large enterprise, the three penalty tiers are:

• €35,000,000 or 7% of total worldwide annual turnover (whichever is higher) for breach of Article 5 prohibited practices — relevant now, since the prohibition on social scoring, workplace emotion recognition, mass facial scraping, and real-time remote biometric identification in public spaces has applied since 2 February 2025.
• €15,000,000 or 3% of total worldwide annual turnover for breach of the high-risk obligations under Articles 16 and 26 and most other provider and deployer duties.
• €7,500,000 or 1% of total worldwide annual turnover for supplying incorrect or misleading information to a notified body or competent authority.

For a €10 billion revenue group, the 3% tier reaches €300 million. That exposure, combined with reputational and regulatory consequences, is the business case for investing in governance infrastructure now.

---

Deadlines and Why Large Portfolios Need to Act Now

Under the Digital Omnibus agreed in May 2026, the high-risk deadlines are:

• 2 December 2027 — stand-alone high-risk AI systems (the Annex III list)
• 2 August 2028 — high-risk AI systems embedded in Annex I regulated products (medical devices, machinery, vehicles)

The Article 5 prohibitions have applied since 2 February 2025. Any social-scoring system, workplace emotion-recognition deployment, or real-time remote biometric identification program already running is in breach today.

Eighteen months to December 2027 is less runway than it appears for a large enterprise. Building the inventory across hundreds of systems, agreeing classification decisions with business units that resist the "high-risk" label, negotiating documentation from vendors who are themselves still assembling it, standing up the QMS, and completing Article 43 conformity assessments for in-house systems — this work runs sequentially in practice, even when attempted in parallel. Organisations that waited for the original August 2026 deadline are already behind schedule on the mechanics.

The sensible sequencing is: complete the inventory and tier-one classification pass, identify every Article 5 risk to remediate immediately, identify the high-risk systems where the enterprise is the provider (highest compliance burden), then address deployer obligations for third-party high-risk systems, and finally institutionalise the governance structure so ongoing monitoring, incident reporting, and post-market review run continuously.

---

How Confir Helps

Confir is purpose-built for the compliance mechanics described above. Its rule-based, deterministic engine — not AI-powered, by design, because a compliance product must be explainable and audit-defensible — covers the four areas large enterprises need across every system in the portfolio:

• AI inventory and classification: register each system, answer the Article 6 / Annex III plain-English questions, and get a documented risk tier and role determination.
• Four compliance areas across every system: AIRC (risk classification), AITR (data and technical robustness, Articles 10/11/15), AITO (transparency and human oversight, Articles 13/14/27), AIGM (governance and post-market monitoring, Articles 9/72/73).
• Org-wide risk register and audit log: a single view across all registered systems, with an immutable log for board reporting and regulatory inspection.
• Article 27 FRIA workflow for public-body and creditworthiness/insurance deployers.

The classification logic is the same for the first system and the fiftieth. Same intake, same finding, same documentation format — which is what makes it scale.

---

Frequently Asked Questions

Does the EU AI Act apply to non-EU companies with EU operations?

Yes. Regulation (EU) 2024/1689 applies to providers and deployers wherever established if their AI systems affect persons located in the EU. A US-headquartered corporation operating in Germany or France is in scope for every system deployed in those markets. Importers placing non-EU AI systems on the EU market take on verification duties under Article 23 and can inherit provider responsibilities under Article 25 if the original provider is not EU-established.

What makes the enterprise compliance challenge different from a smaller company's?

Scale and role complexity. A smaller company typically has a handful of AI tools and operates almost exclusively as a deployer of third-party systems. A large enterprise has a portfolio across dozens of business units, often acts as both provider and deployer for different systems, runs vendor relationships where it must negotiate documentation it has no contractual right to receive under older contracts, and must coordinate across legal entities, jurisdictions, and functions. The governance architecture required is genuinely different.

Our enterprise has ISO/IEC 27001 and is pursuing ISO 42001. Does that cover the EU AI Act?

Partially. ISO/IEC 42001 maps well to Article 17 (QMS) and Article 9 (risk management system) and produces evidence that supports the technical file under Article 11 / Annex IV. But ISO 42001 certification is voluntary and does not constitute the Article 43 conformity assessment — the EU's mandatory pre-market procedure for high-risk systems. You still need the Article 43 procedure, the Article 47 Declaration of Conformity, and Article 49 registration. Treat ISO 42001 as a strong input to compliance; it does not replace it.

Are in-house AI systems built on third-party GPAI models treated as high-risk?

Classification follows the system's intended use, not its underlying technology. A system built on a foundation model is classified under Article 6 by what it does: if it screens job applicants, it falls under Annex III point 4(a) and is high-risk. If it summarises internal documents, it is likely minimal-risk. The GPAI model obligations under Articles 51–55 remain with the model's provider (OpenAI, Mistral, etc.). Article 25 is the watch point: if your enterprise places the resulting system on the market or into service under its own name, it becomes the provider of that system and inherits the full Article 16 obligation stack.

What does Article 14 human oversight actually require in practice for a large enterprise?

Article 14 requires that high-risk AI systems are designed and deployed so that a natural person can effectively oversee, understand, and where necessary override the system's outputs. For a large enterprise, this means documented procedures at the system level: who is the assigned overseer, what training have they received (Article 4 AI literacy obligations have applied since 2 February 2025), what interface or report makes the AI output interpretable, under what conditions must a human review trigger, and how are override decisions logged. The oversight procedure must match the risk profile of the specific system and deployment context.

What are the Article 73 incident reporting timelines for large enterprises?

Article 73 governs the provider's duty to report serious incidents to the relevant national market-surveillance authority. Timelines are: 15 days from becoming aware of a serious incident; 10 days where the incident has caused or may have caused a person's death; 2 days for widespread infringement or serious and irreversible disruption of critical infrastructure. An incomplete report is permitted initially, with completion to follow. The deployer's role under Article 26 is to monitor, flag risks and serious incidents to the provider, and maintain logs for at least six months. Deployers do not report directly to authorities under Article 73 — that obligation rests with the provider.

---

Related guides

• Article 8 high-risk compliance requirements
• Article 6 high-risk classification pathways
• Article 6 risk classification decision tree
• risk classification levels across Articles 6-11
• Articles 6–29 compliance obligations checklist
• Article 43 conformity assessment procedures