Filter by Category

How to Draft Enforceable AI Vendor Contracts Under the EU AI Act for U.S. Companies Serving EU Customers

U.S. companies selling into the EU must align AI vendor contracts with the EU AI Act’s risk-based duties—especially for high-risk systems with mandatory compliance controls. The Act reaches many U.S. providers and deployers through its extraterritorial scope when AI outputs are used in the EU. This article explains how to draft enforceable AI vendor agreements that allocate EU AI Act responsibilities, audit rights, technical documentation, incident reporting, and downstream customer flow-downs.

Why the EU AI Act changes U.S. vendor contracting

The EU AI Act is a product and governance regime for artificial intelligence that applies based on where an AI system is placed on the EU market or where its outputs are used in the EU—not where the vendor is incorporated. For U.S. companies selling software, APIs, platforms, or “AI-enabled” services to EU customers, the practical consequence is straightforward: if you cannot prove compliance through documentation, controls, and contractual allocation of responsibilities, you may lose deals, face customer indemnity demands, and assume regulatory exposure you did not price.

Unlike many U.S. frameworks, the EU AI Act is built around defined roles (e.g., “provider,” “deployer,” “importer,” “distributor”) and risk tiers (unacceptable, high-risk, limited-risk transparency duties, and minimal-risk). Contracts are where those roles become enforceable obligations—especially in multi-vendor AI stacks where one party provides a foundation model or API and another embeds it into a business workflow for EU end users.

Step 1: Identify whether the contract touches “AI systems” and which risk tier applies

Start with a short schedule that pins down: (1) what is being supplied (model, API, hosted app, on-prem software, fine-tuning services, monitoring), (2) the intended purpose, (3) the deployment context, and (4) whether the system is likely high-risk under the Act’s categories (for example, employment, education, creditworthiness, certain public services, and other regulated use cases). This schedule should be binding and used to control scope creep.

Drafting tip: Define “intended purpose” and forbid undisclosed high-risk use

A common failure point is a broad license that allows the customer to use the AI “for any purpose.” Under the EU AI Act framework, intended purpose drives compliance duties and documentation. A vendor contract should:

(a) Define intended purpose with specificity (e.g., “customer support summarization for internal agents,” not “customer communications”).

(b) Require written approval for “material change” to intended purpose, including any use that would reclassify the system as high-risk.

(c) Include an express prohibition on unacceptable-risk uses (e.g., prohibited manipulation/social scoring-type uses) and any prohibited practices as the Act evolves through guidance.

Step 2: Allocate EU AI Act roles—don’t assume “vendor” and “customer” are enough

EU AI Act compliance turns on who is the “provider” (typically the party placing the AI system on the market under its name) versus the “deployer” (the party using it). In an AI supply chain, your company might be:

Provider (you brand and offer the system to EU customers), even if you rely on upstream models.

Deployer (you use a third-party model to deliver a service, and the output is used in the EU).

Importer/Distributor (less common for pure SaaS, more relevant for packaged software/appliances sold into the EU).

Contract language should explicitly designate roles for the specific product and use case, and then map the operational duties to the party best positioned to perform them. If you leave roles ambiguous, you invite a regulator and your counterparty to assign the most burdensome obligations to you after the fact.

Example clause concept: “EU AI Act Roles and Cooperation”

Include a cooperation clause requiring each party to provide timely information reasonably necessary to support the other’s compliance (e.g., technical documentation extracts, instructions for use, logs, and post-market monitoring inputs), with clear timelines and confidentiality protections.

Step 3: Build a compliance schedule for high-risk systems (or contracts that may become high-risk)

If the AI system is high-risk—or could become high-risk based on customer configuration—your contract should attach a “High-Risk AI Schedule.” Even if your product is not currently high-risk, sophisticated EU customers will request many of these commitments as a gating item.

Key high-risk controls to address in contract

1) Risk management and quality management system. Contractually commit to maintaining documented policies and controls proportionate to your role (provider vs deployer). Avoid overpromising “full compliance” if you do not control deployment.

2) Technical documentation and recordkeeping. Provide a deliverables list: system description, model/feature documentation, limitations, performance metrics, known failure modes, cybersecurity measures, and change logs. Tie these to delivery and update triggers (e.g., “upon major version release,” “within X days after material change”).

3) Data governance and data quality. Where you train or fine-tune, address sources, representativeness, bias testing approach, and documentation. Where the customer provides training data, require representations about lawful collection, permissions, and absence of prohibited sensitive inferences (as applicable).

4) Human oversight. Specify required human-in-the-loop configurations where relevant, with customer responsibilities to staff, train, and maintain oversight. Tie breach to misuse and limit vendor liability for customer disabling required safeguards.

5) Accuracy, robustness, and cybersecurity. Include measurable service levels or “performance statements” (with disclaimers) and define security controls, vulnerability handling, and patch timelines.

Step 4: Contract for transparency duties (including user-facing disclosures)

Even outside high-risk, the EU AI Act includes transparency obligations for certain AI interactions (e.g., when users interact with AI or when content is AI-generated). For U.S. companies, the operational challenge is often that the EU customer controls the UI/UX. Your contract should therefore:

(a) Require the customer to display required notices to end users where the customer controls the interface.

(b) Provide vendor-supplied disclosure language and UI guidance as contract deliverables.

(c) Allocate responsibility for compliance testing of user journeys in EU locales (e.g., language localization and placement).

Step 5: Audit rights that are enforceable—and survivable

EU customers will request broad audit rights. Vendors often resist, but “no audit” can be a deal-killer for regulated industries. The goal is a tiered audit model that protects IP and security while meeting reasonable compliance needs.

Practical audit structure

1) Paper audit first. Provide SOC 2/ISO reports, AI governance summaries, and compliance attestations before on-site access.

2) Triggered audits. Allow deeper audits only upon defined triggers: regulator inquiry, material incident, credible noncompliance evidence, or high-risk classification.

3) Scope controls. Limit to relevant systems, reasonable hours, non-competitive auditors, and confidentiality obligations. Explicitly protect model weights, proprietary prompts, and security-sensitive details—offer “view-only” or escrow-style review where necessary.

4) Subprocessor flow-downs. If you rely on upstream model providers or hosting vendors, require them contractually to support audits or provide equivalent assurance artifacts. Otherwise, you may be contractually obligated to provide evidence you cannot access.

Step 6: Incident reporting, serious incident handling, and regulatory cooperation

AI failures can become regulatory events—especially for high-risk systems. Your agreement should define “AI Incident” and “Serious Incident” in operational terms (e.g., safety harms, discriminatory outcomes, unlawful decisions, security compromises affecting model behavior), not just “security breach.”

Contract essentials

Notification timelines. Use tiered timelines: rapid notice for suspected serious incidents; longer windows for non-material issues. Ensure feasibility—committing to unrealistic hours-based windows can create immediate breach.

Cooperation and evidence preservation. Require log preservation, prompt/output samples, and configuration snapshots, with privacy safeguards. Define who contacts regulators and who drafts customer/end-user communications.

Remediation obligations. Provide for patches, rollbacks, feature flags, and temporary suspensions; include a “safety stop” right where continued operation could cause harm.

Step 7: Change management and “substantial modification” controls

AI systems evolve quickly, and EU AI Act obligations can shift when a system is materially changed or used for a new intended purpose. Your contract should include a change control process that covers:

(a) Model updates, re-training, fine-tuning, and parameter changes;

(b) New features that impact decisioning, profiling, or ranking;

(c) Customer configuration changes that alter risk classification;

(d) Retesting and documentation refresh obligations.

In practice, tie major changes to a new compliance packet delivery and, if necessary, revised pricing for compliance-heavy deployments.

Step 8: Data protection and cross-border transfer alignment (GDPR still matters)

While the EU AI Act is not the GDPR, vendor contracts that ignore GDPR realities will fail in procurement. Align your AI contract with your data processing agreement (DPA) by addressing: training on customer data, retention limits, prompt logging, model improvement, subprocessor lists, and transfer mechanisms (e.g., Standard Contractual Clauses where needed). If you cannot train on customer data, state that clearly and make it a covenant to avoid later disputes.

Also address whether outputs contain personal data and who is responsible for data subject requests. If your system stores conversational histories, clarify whether you are a processor, controller, or independent controller for specific elements—then draft accordingly.