Vendor Due Diligence Questions Grounded in the Regulation

Before you deploy a high-risk AI system, you must conduct due diligence on the vendor and the system. Due diligence means asking specific questions grounded in the regulation, verifying the vendor’s answers and assessing whether the system is safe to deploy. This is not a formality; it is how deployers protect themselves and their users.

Your due diligence questionnaire should be grounded in the deployer obligations and the provider requirements that vendors must meet. Deployers should ask vendors about Articles 8 to 15 requirements (risk management, data governance, logging, documentation) even though deployers do not directly enforce those articles. The reason is that if a vendor has not built those capabilities into the system, the deployer’s job becomes much harder.

A good starting point is to ask the vendor to describe what they have done to comply with Article 9, the risk management requirement. What risks did they identify? What risk management processes did they use? What testing did they do? Can they provide evidence? Similarly, ask about Article 10 data governance. What data was the system trained on? Where did that data come from? Was it representative of the populations it will be deployed on? What known biases or limitations were identified?

Specific questions about deployer concerns

On Article 26 compliance, ask whether the system was designed and tested with human oversight in mind. Does the system provide clear outputs that humans can understand and contest? Can humans override the system’s decisions easily and in real time? Is the system’s logic transparent enough that humans can meaningfully oversee it?

On logging requirements, ask what the system logs. Does it record inputs, outputs and human decisions? Can logs be exported in a format your organisation can analyse? How long does the vendor retain logs and what is the process for accessing them? Does the vendor have responsibility for log retention or does the deployer?

On modifications, ask explicitly whether the vendor permits fine-tuning or retraining. If the vendor supports customisation, who is responsible for compliance of the customised system? If the vendor does not permit modification, your organisation must accept the system as-is.

On transparency, ask whether the vendor will provide machine-readable marking (for general-purpose AI systems) and what disclosures the vendor has made about the system’s capabilities and limitations. Ask for model cards, data sheets, or other technical documentation that explains how the system works.

Contractual anchors

Your due diligence questionnaire should flow into contract clauses that bind the vendor to their answers. If the vendor says the system was tested on representative data, the contract should state that the vendor represents this and is responsible if the representation is false. If the vendor says the system can be deployed in a specific use case, the contract should say the vendor warrants this and will indemnify you if the system fails to perform as represented.

Contracts should also allocate liability. Who is liable if the system causes harm because the vendor’s documentation was incomplete? Who covers costs if the system fails and must be removed? Who has the right to audit the system’s performance in production? These allocations matter enormously when problems occur.

Prioritising questions by risk

Not all due diligence questions are equally important. For low-risk systems, a simple questionnaire might suffice. For high-risk systems, deployers should ask extensive questions and demand detailed answers. For systems that will affect vulnerable populations (children, people with disabilities, people with criminal convictions), due diligence should be exceptionally thorough.

Consider a hierarchy: Articles 26 and 27 deployer duties are the foundation. Due diligence should verify that the vendor’s system supports deployer compliance with these articles. Articles 8 to 15 provider requirements are second-tier questions; deployers ask these to understand whether the vendor has built a trustworthy system. Questions about vendor financial stability, insurance, and incident response are third-tier; these matter but are less immediately critical to deployer compliance.

Red flags and escalation

Vendors should be able to answer basic questions about their systems. If a vendor cannot explain what data the system was trained on, that is a red flag. If a vendor refuses to provide any documentation or evidence, that is a red flag. If a vendor claims the system works perfectly and has no known limitations, that is a red flag; all systems have limitations. Red flags do not necessarily mean “do not buy”, but they signal that risk is higher and due diligence must be deeper.

If a vendor cannot or will not answer deployers’ due diligence questions, escalate within your organisation. Do not proceed without satisfactory answers or without risk acceptance from senior management. Escalation to senior management is appropriate because buying a system with unresolved due diligence questions is a business and compliance risk that senior leaders should understand.