Ask AI vendors 25 questions about the system you will receive

An EU AI Act vendor checklist should identify the exact AI system, plan, intended purpose, operator roles, model route, evidence, and operating responsibilities in the proposed configuration. A company-wide “AI Act ready” answer cannot settle those facts.

Ask each supplier for scope, evidence, and the consequence of a gap. The checklist turns procurement and legal review into system-level contract and release decisions.

Define the purchase before reviewing answers

Write the business result, users, affected people, data, sources, outputs, actions, region, and proposed release. Name the vendor product, plan, models, integrations, and service limits.

Use one answer record with four fields: response, scope, evidence, and buyer decision. A certification or policy can support the answer while the system configuration still requires separate proof.

Questions 1–5: roles and classification

1. What exact AI system and intended purpose are you proposing? Request the configured use, limits, and prohibited uses.
2. Which AI Act role do you believe each party holds? Include provider, deployer, GPAI provider, importer, distributor, and product manufacturer where relevant.
3. Which facts and legal provisions support that role map? Ask for the review date and assumptions.
4. How have you classified the system? Request the Article 5, Article 6, Annex III, GPAI, and Article 50 analysis that applies.
5. Which classifications or obligations remain uncertain? Candor is useful procurement evidence.

Questions 6–10: models, data, and suppliers

1. Which model and model version will process each task? Include fallback and routing rules.
2. Which third parties supply models, tools, hosting, connectors, evaluation, or support?
3. What information do upstream GPAI providers supply for downstream use? Request current documentation and restrictions.
4. Which data categories enter prompts, retrieval, logs, approvals, and outputs?
5. How do region, retention, training use, deletion, and provider changes work for each route?

The AI Act and GDPR role maps should remain separate. Use the same factual path and involve both legal owners.

Questions 11–15: instructions, evidence, and transparency

1. Which instructions for use, capabilities, limitations, and expected input will we receive?
2. Which technical documentation or system evidence is available for our duties?
3. Which performance and failure cases were tested for our intended purpose? Request populations, thresholds, and known limits where relevant.
4. How are direct AI interaction and generated content handled under Article 50? Ask for the applicable paragraph rather than a general label policy.
5. How can we identify the system, model, instruction, data, and configuration version behind an output?

Questions 16–20: oversight, logs, and incidents

1. What must a human reviewer understand, see, and be able to do?
2. How are reviewer identity, payload, refusal, override, execution, and outcome recorded?
3. Which logs are generated, who controls them, and how can we export them?
4. How do you detect, investigate, report, and correct serious incidents or material risk?
5. What happens during model failure, connector failure, duplicate events, partial execution, or rollback?

Skybridge taught us to ask about refusal states. An approval request can fail before a pending record exists, while generated prose implies success. Procurement should test the state machine, not only the demonstration.

Questions 21–25: changes, contract, and exit

1. Which model, purpose, data, performance, or interface changes trigger new testing and notice?
2. Could our customization, branding, or changed purpose alter provider responsibility under Article 25?
3. Which evidence and cooperation will each party provide to meet its duties?
4. How are legal changes, guidance, authority requests, and corrective actions handled?
5. At exit, how do we receive documentation and logs, transfer credentials, preserve continuity, and verify data deletion?

Put required evidence, notice periods, restrictions, and cooperation into the contract. A roadmap promise should remain a gap until delivered and tested.

Score evidence without inventing a universal grade

Use four evidence levels:

Do not add every number into one score. A missing prohibited-practice screen, required provider document, or access boundary may block release. A minor documentation preference may not.

Compsia prepares a system-specific trust pack that maps every control to its configuration, status, test, and evidence. Buyers should expect the same specificity from every supplier. The AI vendor security questions cover the complementary security review.

Use the final procurement meeting as an evidence exercise. Give the vendor one realistic failed-source case and one denied-action case. Ask them to show the product behavior, resulting log, operator view, and recovery process. A live test often reveals which answers describe the current product and which describe a planned control. Record the exact version demonstrated.

Vendor-checklist questions

Is a vendor's EU AI Act statement enough?

It is one input. Validate the scope, legal role, product plan, configuration, intended purpose, and evidence needed for your own duties.

Should every supplier answer all 25 questions?

Use the questions relevant to the component and system. A connector provider and a high-risk system provider hold different information.

Can procurement rely on the AI Act Compliance Checker?

The Commission's beta tool supports orientation and expressly disclaims legal-advice or official-assessment status. Record its assumptions and obtain qualified review.