Your AI Vendor's Compliance Doesn't Make You Compliant

A common pattern in 2026 procurement conversations:

"We're going to integrate OpenAI's API into our product." "What about the EU AI Act?" "OpenAI handles that."

This is wrong. It has always been wrong. It is going to get expensive in August when the EU AI Act starts enforcing and the regulator does not care that you thought OpenAI handled it.

The AI compliance frameworks — the EU AI Act, Colorado's AI Act, most state laws, the GDPR-style enforcement patterns these laws use — all distinguish between providers (who build AI systems) and deployers (who use them). The two categories have different obligations. Your vendor satisfying their obligations does not satisfy yours. This is true even when you are paying your vendor a lot of money. It is true even when they have a long compliance whitepaper.

This post is about what your vendor actually covers, what they don't, and what you should demand from them in procurement so you're not surprised in court.

Provider vs Deployer: The Foundational Split

Almost every AI regulatory framework — from the EU AI Act to Colorado's AI Act to emerging laws elsewhere — divides obligated parties into providers and deployers. The exact terminology varies (Colorado uses "developer" and "deployer"; the AI Act uses "provider" and "deployer"; some laws use different language entirely), but the conceptual split is consistent.

Provider. The party that builds an AI system, places it on the market, or puts it into service. For the EU AI Act, providers include foundation model labs (GPAI providers with their own specific obligations) and anyone building AI systems for sale or deployment. Providers are responsible for the design of the system, the documentation, the risk assessment, the conformity assessment, the technical specifications, and the system's intended uses.

Deployer. The party that uses an AI system in their work. Deployers are responsible for using the system appropriately, providing notice to affected individuals, conducting their own impact assessments where required, monitoring outputs, and handling incidents. A deployer relying on a provider's AI system is responsible for the deployer-side risks of that deployment.

The split is not optional. You cannot contractually transfer your deployer obligations to your provider. The regulator looks at the deployer for deployer obligations. The provider looks at the provider for provider obligations.

Where Your Vendor's Compliance Stops

Your foundation model vendor — OpenAI, Anthropic, Google, Mistral, AWS Bedrock, whoever — has their own obligations as a provider (and as a GPAI provider, with the EU AI Act's specific GPAI rules). They are working hard to satisfy those obligations. Their compliance posture covers their work.

It does not cover:

How you use the model. If you integrate a frontier model into a hiring tool, the model is high-risk because of how you use it, not because of what the model is. The model vendor's obligations don't include classifying the hiring tool, conducting impact assessments on the hiring use case, or providing notice to candidates. Those are your obligations.

Your downstream documentation. As a deployer (or as a provider of the hiring tool you built on top of the model), you owe regulators documentation about your system — not about the underlying model. You need to describe the intended use, the risks specific to your application, the data you train or fine-tune on, the safeguards you've built, the monitoring you do. Your vendor doesn't write this for you.

Notice and disclosure to your users. Most AI laws require notice to people affected by AI decisions. The notice is from you, not from your vendor. Your users have no relationship with OpenAI; their relationship is with your product. You provide the notice.

Your impact assessment. Colorado's AI Act and the EU AI Act both require impact assessments for systems making consequential decisions. The assessment covers your system in your deployment context — not the underlying model. Your vendor cannot write this for you because they don't know your deployment context.

Your monitoring and operations. Post-market monitoring obligations require you to detect and respond to issues with how the AI is performing for your users. Your vendor monitors the model's general behavior; you monitor what happens when your specific product uses the model with your specific users on your specific data.

Your liability for outcomes. When something goes wrong in production — discriminatory hiring decisions, denied insurance claims, incorrect medical information — the affected person sues the deployer. Your vendor may have indemnity obligations to you under contract, but the regulator and the plaintiff name you in the action.

What Vendor Compliance Actually Provides

Your vendor's compliance is not useless. It provides genuinely valuable inputs to your own compliance.

Technical documentation. A foundation model provider compliant with the EU AI Act's GPAI rules must produce technical documentation describing the model's training data (in summary), capabilities, limitations, evaluation results, and intended uses. This documentation is what you reference in your own technical documentation downstream. Without it, your documentation is weaker.

Information for downstream providers. GPAI providers must share information with downstream providers that use their models. This includes intended uses, limitations of capability, expected risks, and known failure modes. You use this information to assess whether your deployment is appropriate and to plan your own risk mitigations.

Incident reporting infrastructure. Vendors with mature compliance programs have processes for incident reporting and response. When you experience an incident in production that may have its root cause in the model, you need the vendor to investigate. A compliant vendor has the process; an uncompliant vendor has chaos.

Compliance certifications and audits. Many AI vendors are pursuing SOC 2 Type II, ISO 27001, ISO 42001 (the AI-specific standard), and other compliance frameworks. These are useful inputs to your own compliance — they demonstrate that the vendor has its house in order at the levels they can attest to.

Contractual commitments. A vendor with strong compliance has a Data Processing Addendum (DPA), an AI-specific addendum, indemnification clauses, audit rights, and notification obligations. These are the contractual building blocks of your own compliance posture.

What You Should Demand in Procurement

The procurement conversation is where vendor compliance gets pinned down. Most companies have not been demanding enough. The procurement asks that work:

Technical and intended-use documentation. Specific documentation covering: model capabilities, known limitations, training data overview (consistent with their GPAI obligations), evaluation methodology and results, deployment guidance, recommended safeguards. This needs to be in a form that you can reference in your own documentation.

Change notification obligations. Foundation models change. Behavior shifts. Capabilities evolve. The vendor must notify you in advance of material changes to the model that could affect your downstream compliance. Without this, you discover changes in production and your compliance posture silently breaks.

Audit rights for high-risk uses. If you're deploying the model in a high-risk use case, you may need the right to audit the vendor's compliance posture, or at minimum to receive their compliance reports. Negotiate this in. The vendor's standard contract usually doesn't include it.

Indemnification for vendor failures. When something goes wrong because of a vendor-side failure — the model's behavior changed unexpectedly, a content filter failed, a system outage corrupted your data — you want indemnification. The vendor's standard liability cap is usually too low for AI applications; push for higher limits in AI-specific addenda.

Termination rights tied to compliance. If the vendor's actions make it impossible for you to comply (they discontinue a model, materially change behavior, fail to provide required documentation), you need the right to terminate without penalty. This sounds defensive; it is essential.

Compliance roadmap and transparency. What is the vendor doing to meet evolving regulatory requirements? When will they have their EU AI Act conformity assessment complete? What's their plan for new state laws? A vendor without a clear answer is a vendor whose compliance posture is going to break under your feet.

The Patterns of Failure

A few specific failure modes that show up repeatedly in vendor-driven compliance gaps:

The "they handle compliance" assumption. The procurement team signs a vendor agreement without involving legal or compliance. Six months later, the compliance team discovers the company is a deployer of a high-risk system with no documentation, no impact assessment, no notice posture. Remediation takes quarters.

The vendor change problem. The model the vendor was selling six months ago is not the model they're selling today. Behavior changed silently. Compliance documentation that referenced the old model is now misleading. You discover this when an incident report doesn't match what the model actually did.

The downstream documentation gap. Your vendor provides excellent documentation about their model. You assumed this was sufficient. The regulator wants documentation about your system — how you use the model, what safeguards you add, how you monitor outputs. You don't have it because you assumed the vendor's docs covered everything.

The notice mismatch. Your vendor's terms of service tell their users about their AI capabilities. Your users have no relationship with the vendor. Notice to your users is your responsibility, and the vendor's terms don't satisfy it. Your users are sometimes surprised to learn they were interacting with AI, and that surprise becomes a complaint, and the complaint becomes an enforcement action.

The cascading liability problem. Something goes wrong in production. You discover the root cause was vendor-side. You file an indemnification claim. The vendor disputes scope. Litigation takes 18 months. Meanwhile, the regulator and the plaintiffs are pursuing you, not the vendor. The contract limits your downside but doesn't eliminate your exposure.

When the Vendor's Compliance Actually Is Sufficient

There are some cases where leaning heavily on vendor compliance is appropriate, and it's worth being honest about them.

If you are integrating a foundation model into a non-high-risk product — a creative writing tool, a coding assistant, a brainstorming aid — your deployer obligations are limited. Notice ("this uses AI"), reasonable monitoring, and vendor-provided documentation are usually sufficient. The full impact assessment, conformity assessment, and human oversight machinery don't apply.

If you are reselling your vendor's product directly to end users without modification, you may be more of a distributor than a deployer. Your obligations look more like a reseller's — passing through documentation, providing the same notices, handling complaints. The bulk of compliance work stays with the original provider.

If your use case is genuinely minimal — a chatbot answering FAQ questions in a low-stakes context, an AI assistant for internal employees with no consequential decision authority — the obligations are correspondingly minimal and the vendor's compliance might be substantially what you need.

But for anything in the high-risk categories, anything that affects consumers' access to services, anything that makes or substantially influences consequential decisions — vendor compliance is the foundation, not the building.

The Operational Pattern That Works

Companies that handle AI vendor relationships well share a small set of practices.

They have an AI procurement standard that's distinct from their general software procurement. The questions are different, the contract terms are different, the documentation requirements are different. AI procurement runs through a workflow that includes legal review, compliance review, and risk assessment — every time.

They maintain a vendor compliance registry. For each AI vendor, they document: what the vendor provides, what compliance documentation they have, what obligations transfer to the deployer (the company), what monitoring is in place, when the contract is up for renewal. The registry is reviewed quarterly.

They have a single owner for each vendor relationship who understands both the technical capabilities and the compliance obligations. Without a single owner, the technical team negotiates the technical specs, legal negotiates the contract terms, and compliance discovers gaps months later.

They run annual compliance reviews against each vendor. As regulations evolve and vendor capabilities change, the compliance posture needs to be reassessed. The annual review is when the registry gets updated, contracts get renegotiated as needed, and gaps get identified before they become enforcement actions.

The Takeaway

"We use OpenAI" is a procurement statement. It is not a compliance statement. Your vendor's compliance covers their obligations under whatever framework applies to providers and GPAI providers. Your obligations as a deployer (and as a provider of any AI product you build on top) are yours to discharge.

The companies getting this right are demanding more from their vendors in procurement — documentation, notification, audit rights, indemnification, termination rights. They are also doing the work that is unambiguously theirs: classification, impact assessment, notice, monitoring, incident response.

Vendor compliance is necessary. It is not sufficient. The regulator does not care that your vendor has a good compliance whitepaper. They care whether your system, your deployment, your users, and your incident response meet the standard the law sets.

Do your own work. Demand the right inputs from your vendor. Don't be surprised in August.

Frequently Asked Questions

What's the difference between an AI provider and an AI deployer?

A provider builds the AI system or places it on the market. A deployer uses an AI system in their work. Under the EU AI Act and most state AI laws, providers and deployers have distinct obligations. Foundation model labs are providers. Most enterprise companies using AI are deployers of the foundation model labs' systems, but they may also be providers of their own AI products built on top. Many companies are both, for different systems.

If I use OpenAI or Anthropic, am I compliant by default?

No. Your vendor's compliance with their provider obligations does not satisfy your obligations as a deployer or as a provider of any AI product you've built on top of their system. You have separate, distinct duties around how you use the AI, what you tell your users, how you monitor outputs, and what risk assessments you do. Vendor compliance is a starting point, not a destination.

What does my AI vendor owe me for compliance?

Specifically: technical documentation sufficient for your downstream compliance, information about the system's intended uses and known limitations, support for incident reporting if something goes wrong, and contractual commitments that align responsibility appropriately. If your vendor cannot produce these in usable form, your compliance position is weakened. Demand them as part of procurement, not after.

Can I shift AI compliance risk to my vendor?

Partially through contract, not fully through law. You can contractually require your vendor to indemnify you for vendor-side failures, share documentation, and notify you of changes that affect compliance. But the regulator looks at the deployer for deployer obligations and at the provider for provider obligations. Contractual risk-shifting does not change who is legally liable under the statute — it just allocates the financial consequences between the parties.

What should I demand from AI vendors in procurement?

Five things. Documentation that supports your downstream compliance (technical specs, intended uses, limitations). Notification obligations when the vendor changes the model or its behavior. Audit rights for high-risk uses. Indemnification for vendor-caused compliance failures. Termination rights if compliance becomes impossible because of vendor actions. Get these in writing before signing. Adding them after the fact is much harder.