EU AI Act Article 55 (GPAI): The Obligations Your Board Hasn't Read
EU AI Act Article 55 (GPAI): The Obligations Your Board Hasn't Read
BoardSight Research Brief · Reading time: 10 minutes Category: Research · Published: April 16, 2026 · Author: James Waddell, Cognitive Corp
Abstract
The EU AI Act is the most-discussed AI regulation in the boardroom and the least-read. Most directors are aware of the risk-tier architecture and the prohibited-practice list. Fewer have engaged with Chapter V, which governs general-purpose AI (GPAI) models — including the foundation models that most organizations now consume as vendors. Article 55, which layers additional obligations on "GPAI models with systemic risk," is the slice of the Act where board attention is lowest and exposure is rising fastest. This brief walks through what Article 55 actually requires, why deployers (not just providers) are implicated, and what boards should document when they sign a contract with an OpenAI, Anthropic, Google, Meta, Mistral, or any other GPAI provider whose model is embedded in the organization's products, internal tooling, or revenue-bearing workflows.
1. Why Article 55 is where the boardroom exposure concentrates
The EU AI Act's core architecture — prohibited practices, high-risk systems, transparency obligations — is well-covered in general-counsel briefings. Article 55 sits one layer deeper, in the Chapter V regime for GPAI models. It is the layer most boards have not engaged with because it reads, on first pass, as a provider obligation. It is not.
Article 55 applies heightened obligations to GPAI models deemed to carry "systemic risk" — defined by compute thresholds (the current threshold is 10²⁵ FLOPs for training compute) and by Commission designation. The obligations include model evaluation, adversarial testing, serious incident tracking, cybersecurity protection, and ongoing reporting to the EU AI Office.
The deployer-side exposure arises in three ways:
Contractual flow-down. Providers of systemic-risk GPAI models are inserting flow-down obligations into enterprise contracts. Customers deploying the model in EU-facing products or workflows inherit duties around data provenance, use-case restrictions, incident reporting to the provider, and cooperation with audits. Boards that have not read the contract cannot know whether these flow-downs create conformance obligations the organization is not operationally equipped to meet.
Deployer fine-tuning. An organization that fine-tunes or adapts a GPAI model can become a GPAI provider itself under the Act, depending on the scale and purpose of the modification. This is not hypothetical — several 2025 enforcement actions have pivoted on whether a post-training pipeline constituted "substantial modification." A board that does not understand whether the organization is a deployer, a provider, or both is flying blind on its own regulatory classification.
Serious-incident disclosure. Article 55 requires serious-incident tracking and reporting. When a deployer's use of the model produces a serious incident, there is a reporting chain — internal to the deployer, upstream to the provider, and upward to the Commission. Boards without an incident classification protocol and a reporting cadence cannot credibly respond when the chain activates.
2. What "systemic risk" actually captures in 2026
As of April 2026, the Commission has designated a small set of GPAI models as carrying systemic risk — the largest frontier foundation models from the major US and European labs. The list is not static; the threshold is being actively debated and the Commission has signaled willingness to expand designations based on capability benchmarks rather than compute alone.
Practically, any board whose organization uses a frontier model from OpenAI, Anthropic, Google, Meta, Mistral, or their major competitors is touching an Article 55 regime. Any board whose organization has built internal LLM-based tooling on top of a frontier model is also touching it. Any board whose organization is exploring a proprietary foundation model is inside the provider regime and should be treating Article 55 as a direct obligation.
The set of organizations that are outside Article 55 is shrinking monthly.
3. The contractual architecture directors should expect
A board reviewing a material GPAI vendor contract in 2026 should expect — and if they do not see, should ask for — the following:
Provider attestations. The provider attests that the model meets the Article 55 evaluation and adversarial testing requirements, and that the organization's use does not breach any of the provider's usage policies tied to those attestations.
Flow-down of use-case restrictions. The contract enumerates use cases that are prohibited or restricted, including any aligned with Annex III of the Act (high-risk use categories).
Audit rights and cooperation clauses. The contract grants the deployer audit rights commensurate with the deployer's own governance obligations, and obligates the deployer to cooperate with provider audits mandated by the Commission.
Incident reporting cadence. Serious-incident definitions, reporting triggers, response timelines, and upstream flow of information to the provider and then to the Commission.
Data provenance terms. Training-data provenance disclosures from the provider, and deployer obligations on the data it supplies (through fine-tuning, retrieval-augmented workflows, or operational prompts).
Termination for material non-conformance. A termination right if the provider's Article 55 posture lapses — for example, if a Commission designation changes or an incident pattern suggests a conformance failure.
A board that sees a contract without these clauses is looking at a vendor agreement that predates the Act or has been papered through with minimal governance engagement. Either way, the contract is a documentation problem for the deployer.
4. The deployer's own operational footprint
Signing a good contract is step one. Running the operational footprint is step two, and is where most deployer boards are weakest. Five operational questions a board should be able to answer:
Use-case inventory. Which specific use cases are running the GPAI model, which are in production, and which are pilots? Is each use case classified against Annex III?
Prompt and RAG governance. What data flows into the model through system prompts, user prompts, and retrieval-augmented pipelines? What sensitive data categories are excluded by policy, and how is the policy enforced?
Human-in-the-loop configuration. For each use case, where is the HITL checkpoint, and what is the escalation path?
Model update management. When the provider updates the underlying model, how does the organization re-validate its use cases? What changes in model behavior trigger a management review?
Incident protocol. How is an AI-related incident defined, detected, classified, reported internally, and reported upstream to the provider and (if triggered) to the Commission?
A board that cannot answer these with documents in the room has not operationalized the Chapter V regime — regardless of what the contract says.
5. The "US-domiciled, sells in EU" trap
Article 55 and the Act's deployer obligations apply extraterritorially. An organization domiciled outside the EU that places AI-enabled outputs on the EU market is a deployer under the Act. This catches many US and APAC organizations that have not yet internalized the regime.
The subtle version of the trap: an organization whose products are generally not targeted at EU customers but whose SaaS platform happens to be reachable from the EU and whose AI features are enabled by default. The Commission has signaled enforcement intent against this pattern, particularly where AI features affect consumer-facing decisions.
Boards of US-domiciled organizations should not assume they are outside the regime. The reachability test is the operative standard, and the burden of proof on "not targeting the EU" sits with the organization.
6. What boards should document this quarter
A four-item list for the next two board meetings:
The GPAI vendor map. Which GPAI models are in use, by which business units, at what scale? Which are EU-facing? Which are designated systemic-risk?
The contract review status. For each material GPAI vendor, what is the Article 55 posture of the contract, and what is the remediation plan for legacy contracts?
The deployer classification memo. Is the organization a deployer, a provider, or both? Which use cases risk reclassifying the organization as a provider through fine-tuning or substantial modification?
The incident protocol. Is there a documented AI incident classification and reporting protocol? Has it been exercised? Who is the named responsible person for upstream reporting?
These four documents close most of the Article 55 documentation gap for a deployer. They are not a full compliance program — that is a management responsibility — but they are the board's monitoring backbone.
7. How Article 55 interacts with ISO 42001 and NIST AI RMF
Article 55 is a regulatory regime. ISO 42001 is a management system standard. NIST AI RMF is a risk management framework. The three do not conflict; they layer.
ISO 42001 provides the procedural backbone that demonstrates the organization has a management system capable of operationalizing Article 55 obligations. NIST AI RMF provides the substantive risk categorization that maps to Annex III and the Article 55 systemic-risk analysis. The Act tells the organization what to do; ISO 42001 tells it how to do it repeatably; NIST AI RMF tells it how to think about the risk taxonomy.
A board that has adopted ISO 42001 and mapped its AI portfolio against the NIST AI RMF is well-positioned to meet Article 55 deployer obligations with modest additional documentation. A board that has done neither is looking at a months-long program to build what the Act presumes already exists.
8. Implication for BoardSight clients
BoardSight's Board AI Oversight Audit includes a Chapter V / Article 55 posture assessment as a standard component for any organization with EU exposure. The audit produces the vendor map, the contract review status, the deployer classification memo, and the incident protocol described above. For organizations with material GPAI exposure, the audit can be scoped as an Article 55 readiness engagement directly.
The Act is in force. The GPAI regime is live. Boards that have not read Article 55 are not yet in breach — but they are increasingly unable to answer the Caremark question when the question is Chapter V.
Further reading inside the BoardSight library: ISO 42001 for Boards: The Operational Companion to Caremark · The D&O Pricing Shift: How AI Failures Are Being Underwritten in 2026 · The Board AI Competency Gap: A Diagnostic Framework for Director Capability · EU AI Act: What Audit Committees Need to Know in 2026
Sources referenced: EU AI Act (Regulation 2024/1689), particularly Chapter V and Articles 53-55; EU AI Office guidance (2025); Commission designations of GPAI models with systemic risk (2025-2026); ISO/IEC 42001:2023; NIST AI Risk Management Framework 1.0; Annex III of the EU AI Act; Marchand v. Barnhill, 212 A.3d 805 (Del. 2019).