The AI Act Vendor Questionnaire: What to Ask Your AI Providers (and the Red Flags)

If you're a deployer of a high-risk AI system — and most SaaS companies are deployers of at least one — you need to verify that your provider has done their job. This isn't a nice-to-have. Article 26(1) says you must use the system "in accordance with the instructions for use." If the provider hasn't given you usable instructions, you can't comply.

The clean way to handle this is a structured questionnaire you send to every AI vendor in your stack. This post is the template plus the red flags.

Why a vendor questionnaire (and not just trust pages)

Three reasons a written questionnaire still beats reading a vendor's trust page:

1. It's evidence. When a market-surveillance authority asks how you verified Article 26(1) compliance for your providers, "we read their website" is a weaker answer than "we sent the attached 25-question questionnaire and they returned signed responses on this date."
2. It surfaces gaps. Vendor trust pages publish what the vendor wants to publish. Questionnaires force them to answer what you need to know — which often isn't on the trust page.
3. It rebalances power. Once a few vendors realise their enterprise customers are sending questionnaires, they invest in the documentation. The questionnaire is the lever.

The implementation effort is modest. You write the questionnaire once, send it to every vendor, track responses in a spreadsheet (or a workspace), and re-send annually or on significant change.

The 25 questions, organised by category

The structure below is what we ship in Complair's vendor-assessment feature. It maps to the seven Article 26 obligations and the provider's Article 13 duty to provide instructions. You can copy it into a Google Form or send it as a PDF — both work.

Category 1 — System identification and intended use (5 questions)

Q1. What is the official name and version of the AI system?

Q2. Provide a one-paragraph description of the AI system's intended purpose.

Q3. What use cases is the system not intended for? List foreseeable misuse scenarios.

Q4. Is the system classified as high-risk under EU AI Act Annex III? If yes, which subcategory?

Q5. What deployment contexts is the system designed for (customer-facing, internal-only, hybrid, embedded in another product)?

Red flags: vague intended-use descriptions ("provides AI-powered insights"), no documented misuse scenarios, refusal to answer the Annex III question. Any vendor that won't tell you which Annex III subcategory they fall in either hasn't done the analysis or is hiding it.

Category 2 — Training data and provenance (4 questions)

Q6. What sources of data were used to train the system? Categories suffice (e.g., "publicly available web content," "licensed datasets from X," "proprietary customer data with consent").

Q7. Was personal data used in training? If yes, what was the legal basis under GDPR Article 6 and, if applicable, Article 9?

Q8. Was synthetic data used? If yes, what was the validation methodology to ensure it represents the target population?

Q9. Describe the data governance procedures applied to training, validation, and test datasets, in line with EU AI Act Article 10.

Red flags: "we don't disclose training data sources" (legitimate vendors at least give you categories), inability to explain the legal basis for personal data in training (likely GDPR-non-compliant), no separation between training/validation/test sets.

Category 3 — Bias, accuracy, and testing (4 questions)

Q10. What accuracy metrics does the system report (precision, recall, F1, AUC, etc.) and what are the current values for the system version we'd use?

Q11. Has the system been tested for bias across protected attributes (gender, age, ethnicity, disability, etc.)? Provide a summary of methodology and results.

Q12. What are the known failure modes or edge cases of the system?

Q13. What is the cadence of bias re-testing?

Red flags: "no protected-attribute testing performed" for any system used in employment, credit, or essential services (likely insufficient under Article 10 + Article 15), accuracy figures that don't disaggregate by relevant population subgroup, no documented edge cases.

Category 4 — Conformity and documentation (4 questions)

Q14. Has the system undergone conformity assessment under Article 43? Was it self-certified (Annex VI) or third-party (Annex VII)?

Q15. Is the EU declaration of conformity available? Can we receive a copy under NDA?

Q16. Is the system registered in the EU AI Act database (Article 49)?

Q17. Is technical documentation matching Annex IV available for review under NDA?

Red flags: no answer on conformity assessment for a high-risk system, refusal to share the EU declaration of conformity, "we'll register before August 2, 2026" (we're past the planning window). Note: Annex IV documentation under NDA is normal — full publication is not required.

Category 5 — Logging, oversight, and retention (4 questions)

Q18. Does the system generate per-event logs as required by Article 12? If yes, what events are captured?

Q19. What is the log schema and retention period for logs generated on our behalf?

Q20. Can we, as deployer, retrieve and store the logs for the Article 26(6) ≥6-month retention requirement?

Q21. What human-oversight features are designed into the system, in line with Article 14? Can a human meaningfully intervene before the output is acted on?

Red flags: logs not exposed to the deployer (you can't satisfy Article 26(6) without them), retention shorter than 6 months by default, "human oversight" that's just a UI button with no real intervention capability, oversight that requires the user to understand the model internals.

Category 6 — Data processing, incidents, and contracts (4 questions)

Q22. Is a Data Processing Agreement available that meets GDPR Article 28?

Q23. Where is data processed and stored geographically? What is the cross-border transfer mechanism (SCCs, adequacy decision, EU-US Data Privacy Framework)?

Q24. What is the incident notification process and timeline? What constitutes a "serious incident" under your definitions?

Q25. Will the vendor notify us of material changes to the AI system that could affect its risk classification or our deployment?

Red flags: no DPA available (GDPR-non-compliant by default), data processed in jurisdictions without a recognised transfer mechanism, incident notification timelines longer than the deployer's own 15-day Article 73 reporting window (creates a structural impossibility), no commitment to notify on material changes (you'll find out when something breaks).

Three vendor responses that mean "do not deploy"

Some answers should end the procurement conversation:

1. "We do not provide our customers with instructions for use." Article 13 makes this a provider obligation. A vendor that refuses to provide them is asking you to absorb their compliance obligations. Walk.
2. "We're working on AI Act compliance and will be ready by August 2." It is April 19, 2026. There are 105 days left. A vendor not done by now is unlikely to be done by then.
3. "Our system is not high-risk because we use a human-in-the-loop." This is a misunderstanding of the regulation. Annex III applies based on use case, not autonomy level. A vendor that gives this answer hasn't read the Act and probably hasn't built the documentation.

How to operationalise the questionnaire process

Three things make this scale:

1. Send the questionnaire on every new vendor evaluation, not just for high-risk systems. Even minimal-risk vendors get a 5-question abbreviated version. The discipline matters more than the volume.
2. Re-send annually plus on material change. Article 26(5) requires you to monitor; the annual re-send is the cheapest evidence of monitoring.
3. Track responses in one place, with timestamps. This becomes your Article 26 evidence vault. Spreadsheet works for the first 5 vendors; after that, you want a workspace that does the chasing automatically.

A note on vendor pushback

Some vendors — usually larger US-headquartered ones — will respond to a questionnaire with "please refer to our trust page." That's not always sufficient. A trust page typically answers ~40% of the questions above. The other 60% (especially logs, retention, deployer access, and incident process) usually aren't published.

The polite escalation: "Thanks for the trust page. We've reviewed it and there are 12 questions in our deployer due-diligence questionnaire that aren't answered there. Could you forward to your trust or compliance team for written response within 14 days?" Most enterprise vendors comply once asked directly. The ones that don't are themselves a red flag.

How Complair handles this

Complair's vendor-assessment feature sends this exact questionnaire (lightly customisable) to your providers via email, tracks who's responded and who hasn't, surfaces flagged answers (red flags above) for review, and stores the signed responses in your evidence vault tagged to the relevant AI systems and Article 26 obligations.

The point isn't the tool — the point is that the questionnaire process is non-optional under Article 26. If you do it manually with a spreadsheet, that works. If you do it with a workspace, it scales. If you don't do it at all, your Article 26 file will have a hole in it that any procurement team or market-surveillance authority will notice.

If you're starting from zero, the path is: list your AI vendors, classify which deployments are high-risk (free classifier), send this questionnaire to the high-risk ones first, work through the rest in priority order. A team of 5–20 people typically has 4–8 AI vendors in scope and finishes the round in two weeks.