Article 26 Is Not the Provider's Problem. It's Yours.

There is a widespread assumption in enterprise AI governance that if your vendor is compliant, you are compliant. The vendor signed the GPAI Code of Practice. The vendor has a compliance page on their website. The vendor sent you a data processing agreement.

Article 26 of the EU AI Act does not work that way.

The provider/deployer split

The EU AI Act creates two distinct obligation tracks that apply simultaneously and independently.

The provider — Anthropic, Microsoft, Google, IBM — must comply with Articles 51-56 for GPAI models and Articles 9-15 for any high-risk AI systems they place on the market. Their compliance documentation is their responsibility.

The deployer — your organisation, using those tools in your workflows — must comply with Article 26. Separately. Completely. Whether or not the provider signed anything.

This is not a technicality. The EU AI Act explicitly states that deployer obligations under Article 26 apply regardless of provider compliance status. A deployer using a fully CoP-compliant vendor still has their own Article 26 obligations to meet. A deployer using Meta Llama — which refused to sign the CoP — still has Article 26 obligations to meet.

The vendor's compliance posture changes the risk level and the availability of upstream documentation. It does not change whether you have deployer obligations.

What Article 26 requires from you

For every high-risk AI use case your organisation deploys, Article 26 requires the following before August 2, 2026:

1. Use the system within its intended purpose This sounds obvious. In practice it means documenting that the system is being used for what it was deployed for — and that any deviation from intended use has been assessed. If you purchased Copilot for productivity and a team is using it for CV screening, that deviation changes the risk classification of that deployment.

2. Assign human oversight Not nominal oversight. The EU AI Act specifies a natural person with "necessary competence, training and authority." This means documenting who is responsible, what their qualifications are, and what they are empowered to do when the AI system produces a questionable output.

3. Verify input data relevance To the extent you control input data, it must be relevant and sufficiently representative for the use case. For HR use cases, this means your training and testing data must be documented.

4. Retain automated logs for at least six months Every high-risk AI system that produces automated logs — which most enterprise AI deployments do — must have those logs retained for a minimum of six months and made available to competent authorities on request.

5. Complete a Fundamental Rights Impact Assessment The FRIA is required before first deployment of any Annex III high-risk system. It assesses impact on workers' rights, non-discrimination, privacy, and dignity. It is not a one-time exercise — it must be updated when the system or its context changes materially.

6. Notify affected workers Where AI is used in employment contexts — performance evaluation, scheduling, monitoring — workers must be informed that an AI system is being used in decisions that affect them.

7. Ensure transparency to affected persons Individuals subject to AI-assisted decisions must be informed. For credit assessment, for instance, applicants must know an AI system contributed to the decision.

8. Report incidents and serious malfunctions Deployers must have a process for identifying, investigating, and reporting incidents. This is an operational requirement, not a documentation exercise.

The evidence pack auditors will ask for

When a competent authority examines your Article 26 compliance, they will not accept a statement that your vendor is compliant. They will ask for your evidence.

The evidence pack for each high-risk use case needs to contain:

• Use case description and Annex III classification with documented reasoning
• Oversight assignment record — named individual, role, qualification
• FRIA completion record — date, assessor, findings, mitigation
• Log retention confirmation — system, retention period, access procedure
• Worker notification record — who, when, how
• Transparency disclosure evidence — what affected persons were told and when
• Incident reporting process documentation

This evidence is the deployer's output. No vendor produces it for you. No vendor can produce it for you. It is assembled from your operational data, your HR records, your system configurations, and your governance decisions.

What this means for your August 2 timeline

51 days is enough time to close Article 26 gaps if you start with a complete inventory. It is not enough time if you are still at the inventory stage.

The most common enterprise failure pattern is discovering high-risk use cases late — not because the use cases are new, but because nobody classified them. A CV screening workflow that has been running for two years is not exempt from Article 26 because it predates the enforcement date. The obligation applies to the operational deployment as of August 2.

Start with use case classification. Every AI tool, every workflow, every automated decision. Map each against the eight Annex III domains. The ones that land in employment, essential services, education, or any other domain — those are where your Article 26 work lives.

The vendor's compliance status tells you how much documentation help you have upstream. It does not change what you need to produce downstream.

See PromptKing's Article 26 Deployer Evidence Pack →