EU AI Act Obligations for Enterprises Using AI Vendors

Enterprises that procure AI from vendors are not bystanders under the EU AI Act. They carry named, non-delegable duties under Article 26 that most have yet to operationalize. This article explains what those obligations require in practice and why they demand a structured third-party risk program rather than a one-time legal review.

What the EU AI Act actually requires of enterprises that deploy AI from vendors

The practical question for any risk professional is whether this regulation applies and when. The answer to the first is straightforward. If you use an AI vendor to evaluate EU job applicants, score EU credit, or process EU customer data from the U.S., you are in scope no matter where your servers sit.

The answer to the second is more complicated. The Act entered into force on August 1, 2024, and prohibited practices have applied since February 2, 2025. The high-risk obligations were pushed to December 2, 2027 and sector-specific obligations to August 2, 2028, a delay now enacted as Regulation (EU) 2026/1744. The sequence of obligations does not change even if the deadline does.

Which AI systems in a typical enterprise estate qualify as high-risk under Annex III

Most enterprises have already deployed AI systems that fall into the high-risk tier without recognizing their regulatory status. That is because Annex III categories map directly onto ordinary enterprise functions. Snowflake's EU AI Act guide lists the eight sectors: biometrics; critical infrastructure safety components; education and vocational training; employment and worker management; essential private and public services, including credit scoring and insurance; law enforcement; migration, asylum, and border control; and administration of justice.

Financial services exposure is concentrated. Credit scoring, fraud detection, AML transaction monitoring, and automated customer onboarding all sit in the high-risk tier under the "essential private and public services" category. CV screening, performance monitoring, and promotion and termination systems are explicitly enumerated, which means an HR SaaS platform using AI ranking is presumptively high-risk the moment it is switched on.

The classification problem compounds from there. Classification is not a legal exercise that sits upstream of vendor management. It is the first control the vendor program must execute, and Coverbase performs this function at the first stage of vendor onboarding by applying inherent risk scoring to flag which systems require heightened controls from day one.

What Article 26 actually assigns to deployers, obligation by obligation

Article 26 does not ask deployers to trust their vendors. It assigns them independent, non-delegable duties that persist regardless of what the vendor contract says. The first is to use the system in accordance with provider instructions. Deployers must operate the system only for its intended purpose as documented by the provider, and any deviation begins to shift regulatory status.

The second duty is human oversight with trained personnel. Deployers must assign individuals who are competent to understand the system's outputs, recognize anomalies, and intervene. The third duty is log retention. Deployers must retain automatically generated logs for at least six months, and CSA confirms this as a binding obligation.

The fourth duty is the Fundamental Rights Impact Assessment, which applies in sensitive use cases such as creditworthiness assessment, life and health insurance pricing, and public-sector decision-making. The fifth is notification. Deployers must notify individuals affected by the AI system, and this transparency obligation requires the deployer to have its own disclosure process rather than relying on a vendor's disclosure to cover the obligation.

How the deployer-becomes-provider trap converts a procurement decision into a conformity assessment obligation

If you modify a vendor's AI system, you may exit the deployer role entirely and inherit the full provider compliance architecture. The most concrete illustration sits in financial services. Fine-tuning a purchased credit-scoring model on a bank's own loan book constitutes a substantial modification, and the bank becomes the provider of record for a system already in production. What felt like a procurement decision becomes a conformity assessment obligation.

Holland & Knight specifies two triggers that reclassify a deployer as a provider. The first is putting the enterprise's own name or trademark on a system already on the market. The second is making a substantial modification. When either occurs, the enterprise inherits obligations it assumed the vendor had handled: conformity assessment, CE marking, EU database registration, technical documentation, quality management system, and post-market monitoring. That is the full Article 16 architecture, and it lands without warning on teams that thought they were buying software.

Article 25(4) adds a structural requirement that most enterprises have not addressed. The vendor contract is therefore not a compliance shield. It is a document that must be deliberately engineered to allocate obligations and preserve the deployer's classification.

Why the Article 26 duty list is structurally identical to a mature TPRM lifecycle

Every Article 26 obligation maps onto a stage of the vendor risk lifecycle that your third-party risk management program already owns. Human oversight assignment maps to control owner designation: the requirement for trained, competent oversight personnel is a control-owner assignment that the TPRM program must track, not an HR training exercise. Incident response maps to serious incident notification, which requires a pre-built escalation path that connects vendor monitoring alerts to a defined notification workflow.

The regulation reads, in effect, as a third-party risk program described in statutory language. An enterprise that already runs a mature TPRM lifecycle has the structural machinery. Because the Act's extraterritorial reach applies wherever an AI system's output touches EU data or decision-making regardless of the deployer's location, enterprises using AI vendors need to know not just which vendors they procure from but how those vendors' systems are classified and monitored in real time. This is the foundation of third-party AI risk governance that should integrate into the broader vendor intake and lifecycle management process.

The readiness gap that makes treating Article 26 as a TPRM problem urgent rather than theoretical

The largest obstacle to Article 26 compliance is not the complexity of the obligations. It is that most enterprises have not completed the prerequisite inventory that makes any obligation actionable. Without knowing which AI systems exist, who operates them, and which Annex III category applies, no deployer can assign oversight personnel, retain the right logs, or conduct a meaningful impact assessment.

The harmonized standards problem compounds the timeline. CSA notes that this delay compresses implementation windows even for the extended December 2027 deadline. Implementation for complex organizations typically takes 12 to 18 months, covering inventory, risk management, technical documentation, human oversight, and conformity assessment. Enterprises that have not started a structured program are already behind any realistic compliance schedule.

Shadow AI is the inventory problem's hardest edge. The program cannot begin with a legal review of known vendors. It must begin with the register.

Building the AI vendor inventory that Article 26 compliance depends on

An AI vendor inventory is not a spreadsheet of vendor names. Each entry must answer a specific set of questions: what the system does, which Annex III category applies if any, whether the enterprise is a deployer or a provider, who is the designated oversight-competent person, and whether logs are being retained and for how long. Snowflake's guide frames the core regulatory question as whether the organization can show what each system does, which role it plays, what risk tier applies, and what controls are required. The register is the artifact that answers those questions.

External AI models must be managed the same way as internally developed ones. The three doors through which ungoverned AI typically enters, shadow sign-ups, feature additions on approved software, and business-unit integrations, must each have a detection and intake path that feeds the register. Without that path, the register decays the day it is built.

Rewriting vendor contracts to carry Article 26 obligations as enforceable controls

Standard SaaS agreements do not allocate Article 26 duties. Article 25(4) requires a written agreement specifying the information, technical access, and assistance the provider must supply to enable deployer compliance. This is a mandatory contract term for high-risk AI systems, not an optional addendum. The contracts should include four elements. Coverbase's contract management capability addresses this requirement by monitoring contracts against actual vendor behavior, not treating them as static documents executed at signature.

Continuous monitoring as the mechanism that keeps Article 26 obligations from decaying into point-in-time checkboxes

Article 26's monitoring and log retention duties are structurally incompatible with annual vendor assessments. The six-month log retention requirement is an evidence preservation obligation: logs must be available to demonstrate compliance at any point within the retention window, not assembled retroactively in response to an inquiry. Serious incident notification without delay requires a pre-built detection-to-escalation path, and that path cannot exist if monitoring is passive or periodic.

The DORA interaction makes this acute for financial entities. DORA has applied since January 17, 2025. That posture is what Article 26 implicitly requires, and Coverbase's approach reflects it: vendor assessment is not treated as a point-in-time event but as an always-on evidence collection process.

Handling agentic AI vendors and non-human identity risks that Article 26 does not yet explicitly address

Agentic AI vendors introduce a distinct compliance surface that Article 26's existing duty list does not explicitly address. The underlying obligations still apply with equal or greater force. A single AI agent may hold credentials for CRM, email, cloud infrastructure, and payment systems simultaneously, creating non-human identities with privileged access at scale that traditional identity and access management cannot handle through static policies. As of early 2026, the AI Office had published only preliminary guidance on AI agents, autonomous tool use, or runtime behavioral change, and the AI Act Service Desk FAQ acknowledges that regulatory considerations on agents remain preliminary.

Despite the absence of agent-specific guidance, existing obligations apply. The boundary between anticipated adaptive behavior and a substantial modification under Article 3(23), which would reclassify the deployer as a provider, is live compliance risk. For enterprises subject to SOX or similar financial controls, when agents can execute journal postings, change vendor master data, approve transactions, or bypass manual checks, identity lifecycle and least-privilege controls must apply to non-human identities with the same rigor as human users, including formal ownership, approved roles, and revocation paths. Coverbase's focus on non-human identity and SaaS plugin exposure addresses the oversight and access surface that Article 26 human oversight duties implicitly require for agentic vendors.

What a TPRM platform built for Article 26 compliance needs to do that generic GRC tools cannot

The Article 26 duty chain, inventory, classification, contract controls, oversight assignment, continuous monitoring, incident escalation, requires a platform that treats AI vendor risk as a lifecycle, not a form-completion exercise. Coverbase is purpose-built for regulated enterprises managing third-party AI risk across the full vendor lifecycle. Its AI models are tailored to each customer's own control frameworks rather than imposing generic logic, so the platform learns from team decisions and improves over time. Relevant capabilities include autonomous evidence gathering against vendor-supplied documentation, zero-touch assessment for low-risk AI vendors, AI-assisted analysis for complex or high-risk systems, continuous monitoring that feeds findings back into risk scores and contract management, and audit-defensible records that satisfy log retention and incident notification requirements.

For Article 26 specifically, Coverbase's continuous monitoring posture is structurally aligned with the always-on evidence collection the regulation requires. Its contract management capability addresses the Article 25(4) written agreement requirement by monitoring contracts against real vendor behavior rather than filing them at signature. For agentic AI vendors, its focus on non-human identity and SaaS plugin exposure addresses the oversight and access surface that Article 26 human oversight duties implicitly require.

When enterprises evaluate AI vendor risk management platforms, they also look at general GRC suites that offer vendor management modules. These typically cover questionnaire distribution, risk scoring, and document storage. Article 26 requires the former.

The three actions risk teams should take now, regardless of where the final deadline lands

The deadline uncertainty is real, but it does not change the sequence of work. Every action Article 26 requires must be completed before an AI vendor can be safely deployed, and none of the three foundational steps depends on a final enforcement date. First, complete the AI vendor inventory and classify every system against Annex III. This is the prerequisite for all other Article 26 controls and cannot be shortened or skipped. Second, audit and rewrite vendor contracts for the three Article 25(4) requirements: written specification of information and access obligations, change notification for material modifications, and right to audit. Standard SaaS templates do not satisfy these requirements and must be replaced before the next renewal cycle. Third, establish continuous monitoring with pre-built escalation paths for serious incident notification, particularly for any AI vendor touching financial services workflows where DORA's four-hour notification clock runs concurrently. A periodic review cycle is not compliant monitoring under Article 26.

The 12 to 18 month implementation timeline for complex organizations means teams starting now are working to the December 2027 deadline, not to August 2026. But the inventory and contract work are not compliance theater. They are the foundation of a functioning AI vendor risk program, and they hold their value regardless of regulatory timing.