Vendor AI Act Flow-Down: The Contractual and Technical Attestations to Demand From Model and Tool Suppliers

Your AI Act compliance is only as good as your suppliers’ paperwork — and most procurement contracts signed in the last two years do not oblige a single vendor to hand it over.

If you deploy a model you did not train, or a tool built on top of one, a large share of what a supervisor will eventually ask you to evidence does not exist inside your own estate. The technical documentation, the event logs, the test and evaluation results, the version history — they sit with the vendor, because they were never yours to hold. The Act anticipates this and lets the obligations flow down the value chain. The catch is that they only flow if you make them flow, in the contract, in language a supplier’s legal team cannot quietly read around at renewal.

Why your obligation is hostage to a vendor’s opacity

As a deployer, or as a downstream provider who integrates someone else’s model into your own system, you carry duties you can only discharge with inputs from upstream. You are expected to use the system according to its instructions, to keep the logs it generates, to feed a serious-incident report, and — if you place the integrated system on the market — to assemble your own technical documentation. None of that is possible if the supplier’s answer to “show me the evidence” is “trust us, it is compliant.” That leaves you holding an unevidenced obligation, which in supervisory terms is indistinguishable from no compliance at all.

The clock matters here. Obligations for providers of general-purpose AI models have applied since 2 August 2025. The obligations on standalone high-risk systems were due to bite from 2 August 2026, but under the Commission’s Digital Omnibus proposal they are expected to shift to 2 December 2027 — treat that later date as provisional until the amending text is published in the Official Journal, and verify it against the final version. Either way, the procurement decisions that determine whether you can meet those duties are being taken now.

What the Act actually makes flow down

Article 25 governs responsibilities along the AI value chain. Its operative sentence is the one to memorise: where a third party supplies an AI system, tools, services, components or processes that are used in or integrated into a high-risk system, that third party must, by written agreement, specify the necessary information, capabilities, technical access and other assistance needed for the downstream provider to comply. The Act gives you the hook. It does not write the schedule of what “necessary information” means for your deployment — you do.

Article 25 also tells you when a supplier’s choices become your problem in a harder way: if a party puts its own name or trademark on a high-risk system, makes a substantial modification that keeps it high-risk, or changes the intended purpose such that it becomes high-risk, that party is treated as a provider with the full provider obligation set. A silent model swap or a repackaging exercise can move the regulatory burden onto you without anyone signing anything. The written agreement is where you pin that down. There is a carve-out for genuinely free and open-source components, which is exactly why you cannot assume the carve-out applies without checking the licence and the systemic-risk position.

The attestations to write into the contract

A flow-down schedule that actually protects you asks for specific, retrievable artefacts, not a warranty of “AI Act compliance” in the abstract. The ones that earn their place:

• A role and classification declaration. How the vendor classifies the system — high-risk, GPAI, GPAI with systemic risk, or none — and the reasoning. This is the assumption everything else rests on, so get it in writing and dated.
• Documentation access. For a high-risk system, the technical documentation to the Annex IV standard and the instructions for use under Article 13. For a general-purpose model, the downstream information pack under Article 53(1)(b), structured to Annex XII. A right to receive it and to retain a copy for your own records.
• Conformity evidence. The declaration of conformity and CE marking where the system is high-risk, plus any notified-body involvement. Not a claim that it exists — the document.
• Logging access. Article 12 requires high-risk systems to record events automatically over their lifetime. You need a contractual right of access to those logs, an agreed retention period, and an export format you can actually reconcile and hand to a supervisor.
• Change notification. Advance notice of retraining, a new model version, or any substantial modification that could alter the classification or invalidate the documentation you have filed.
• Incident cooperation. A duty to supply the data you need to meet the serious-incident reporting regime under Article 73 inside its timelines, not on the vendor’s own schedule.

Do not take the attestation on trust

A signed warranty is a starting position, not evidence. The point of the technical review is to test whether the paperwork the vendor promised can actually be produced and whether it says what it needs to say. Ask for the log export during evaluation and check that it contains the event detail Article 12 implies, rather than an access summary. Take the model or system card and hold it against the Annex XII headings, line by line, to see where the gaps are. Confirm that the API returns a model and version identifier, and that you can pin a version — without version pinning, a silent upstream change can invalidate the documentation you assembled without any signal to you. This is the same discipline that lets you treat technical documentation as living code generated from your pipeline rather than a PDF that is stale the day it is signed.

General-purpose models are a different negotiation

Model providers do not owe you an Annex IV file. They owe downstream integrators the Annex XII transparency pack — capabilities, limitations, integration guidance — plus, under Article 53, a copyright policy and a public summary of training content to the AI Office’s template. You then have to build your own Annex IV for the system you place on the market, assembled partly from what the model provider gives you. If all you can extract is a code-of-practice-level summary, you have a documented gap between what you must file and what you were handed, and that gap is yours to close. It is also where the AI Act and the Cyber Resilience Act start pulling on the same suppliers, which is why the sharper procurement teams are running one supplier due-diligence exercise that pushes both secure-by-design and AI Act evidence down the chain, rather than two disconnected ones. For AI-enabled products the two regimes’ assessments collide on the same conformity work, and treating them together saves duplicated effort.

Where the leverage is

The only moment you have real negotiating power over a supplier’s documentation is before you sign, or at renewal. After that, “provide the Annex XII pack and the Article 12 logs” is a request for goodwill, not a contractual right. So the work is unglamorous and immediate: build the flow-down schedule once, attach it to every new AI procurement and every renewal, and refuse to accept an abstract compliance warranty in place of the named artefacts. This matters most for CTOs and procurement leads integrating third-party models into regulated products, and for the compliance owner who will carry the obligation regardless of who negotiated the contract.

A supplier’s silence is not a neutral state. It becomes your unevidenced obligation the moment a supervisor asks — and by then the contract is already signed.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.