AI Vendor Risk Assessment Template: Score Third-Party AI Tools Under the EU AI Act

When you buy a third-party AI tool, Regulation (EU) 2024/1689 (the EU AI Act) makes you — the deployer — accountable under Article 26, regardless of whether the vendor is compliant. This template is the instrument you fill in to turn the vendor's answers and documents into a numeric rating and a defensible go / conditional / no-go decision.

It is the buyer's risk-rating sheet, not the vendor's answer sheet. You send the AI vendor questionnaire first to collect evidence; then you transcribe those responses into the sections below, apply weights, and produce a decision your procurement team can sign and an inspector can reconstruct. Deployer breaches sit under Article 99(4): up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher.

Copy each section block into your own document. Complete all sections for any system that could be high-risk under Annex III; for clearly minimal- or limited-risk tools, Sections 1, 2, 3 and 8 are usually proportionate.

---

What This AI Vendor Risk Assessment Template Is (and How It Differs From a Questionnaire)

The Buyer's Risk-Rating Instrument, Not the Vendor's Answer Sheet

A questionnaire gathers evidence. This assessment weights that evidence into a score and a decision. The two work as a pair: send the questionnaire, receive the vendor's responses and documents, then record them here and rate each criterion. "Vendor" is not itself a legal category in the Regulation — the Act binds providers (Article 16) and deployers (Article 26) — so think of this as your deployer due-diligence record, the proof that diligence happened before deployment.

When to Use It in the Procurement Lifecycle

Run the assessment at three moments:

1. Procurement gate — before signature, as a condition of contract.
2. Renewal — at each contract renewal or annual review.
3. Material change — whenever the vendor announces a significant model change, retraining, or a change of intended purpose.

Why a Deterministic, Reusable Score Matters for Inspection

A consistent, rule-based scoring method means the same inputs always yield the same finding. That reproducibility is what survives a market-surveillance inspection — unlike an ad-hoc spreadsheet that rates differently depending on who filled it in. The field names below deliberately mirror register fields (system, provider, role, risk tier) so a completed assessment seeds your AI inventory directly.

---

Section 1-2: Vendor Identification and Intended-Purpose Context (copy-paste block)

Section 1 - Vendor and System Identification

Section 2 - Intended Purpose and Use Context

Why Your Use Context, Not the Vendor's Label, Drives the Rating

The same AI system can sit in different risk tiers depending on how you use it. Classify for your context — never accept the vendor's marketing label. Capture whether the deployment is in a workplace context, because Article 26(7) adds a duty to inform workers' representatives and affected workers before putting a high-risk system into use at work. These two sections become the seed records for your AI system register, so keep field names aligned with the register: system, provider, purpose, role, risk tier.

---

Section 3: Risk Classification - Prohibited, High-Risk, or Limited-Risk (copy-paste block)

Work through three steps in order. The first stop that fires sets the floor for your rating.

Step A - Rule Out Article 5 Prohibitions

First test Article 5. If the use is a prohibited practice — social scoring, untargeted facial-image scraping, emotion recognition in workplace or education, certain biometric categorisation — the rating is an automatic NO-GO. The Article 5 prohibitions have applied since 2 February 2025; this is a fixed date, not contingent on any standard.

Step B - Test Annex III High-Risk and the Article 6(3) Exemption

Then test Article 6(2) against Annex III: is the use within one of the eight Annex III domains — biometrics; critical infrastructure; education; employment and worker management (point 4); access to essential services including creditworthiness (point 5(b)) and life and health insurance (point 5(c)); law enforcement; migration and border; administration of justice?

Apply the Article 6(3) exemption test. A system in an Annex III area is not high-risk if it only performs a narrow procedural task, improves a completed human activity, detects deviation patterns without replacing human assessment, or does preparatory work — but it is always high-risk if it profiles natural persons.

Step C - Check Article 50 Limited-Risk Transparency

Then check Article 50: chatbots, emotion- and biometric-categorisation systems, and synthetic-content / deepfake tools carry transparency-disclosure duties even when they are not high-risk.

Freshness caveat — read before you date your classification. The Digital Omnibus political agreement (provisional 6–7 May 2026; COREPER text confirmed around 13 May 2026) agreed to defer stand-alone high-risk Annex III obligations (Article 6(2)) from 2 August 2026 to 2 December 2027, and Annex I product-embedded high-risk (Article 6(1)) from 2 August 2027 to 2 August 2028. As of June 2026 this is agreed but not yet law — it still needs a European Parliament plenary vote, formal Council adoption, and Official Journal publication. Until then the statute still reads 2 August 2026 for high-risk Annex III, so classify defensively against the earlier date.

What did not move: the Article 5 prohibitions (in force 2 February 2025), GPAI obligations under Articles 51–55 (in force 2 August 2025), and a new 2 December 2026 deadline (CSAM / "nudifier" ban plus content-marking under Article 50). These are fixed calendar dates and are not contingent on harmonised standards.

---

Section 4: Role Mapping - Vendor as Provider, You as Deployer, and the Article 25 Trap (copy-paste block)

The Vendor's Role: Provider (Article 16)

Confirm the vendor is the provider under Article 16 and you are the deployer under Article 26. The provider bears the primary obligation set for high-risk AI; you verify they met it. If you are unsure which role applies to you, work through provider versus deployer before scoring.

Your Role: Deployer (Article 26)

Score these Article 26 duties as line items:

For the full obligation set, see Article 26 deployer obligations.

The Article 25 Role-Shift That Makes You the Provider

Flag the Article 25 trap as a scored risk factor. If you put your own name or trademark on the system, make a substantial modification (defined in Article 3(23)), or change its intended purpose so it becomes high-risk, you are reclassified as the provider and inherit the full Article 16 stack: conformity assessment, Annex IV documentation, CE marking, EU database registration. A substantial modification does not require retraining — extending scope to a new use case or rebranding the vendor's system can cross the line. Require contractual notice from the vendor before any change that could trigger the shift.

---

Section 5: Documentation the Vendor Must Supply (copy-paste evidence checklist)

Instructions for Use (Article 13)

Instructions for use under Article 13 must be specific enough to let you implement Article 14 oversight: intended purpose, accuracy levels, known limitations, oversight measures, and deployment constraints. Thin instructions — "users should review outputs" — do not support your duty and should lower the score.

Technical Documentation (Article 11 / Annex IV)

Technical documentation under Article 11 follows Annex IV. As a deployer you verify it exists and request at least a summary; the full Annex IV file is primarily for national competent authorities. So the score should reflect "documentation confirmed and instructions adequate", not "full file in hand".

Conformity, CE Marking and EU Database Registration (Articles 43, 47, 48, 49)

Conformity assessment under Article 43 is internal control under Annex VI for most Annex III systems, with notified-body involvement under Annex VII generally for Annex III point 1 biometrics. The provider then issues an EU Declaration of Conformity (Article 47), affixes CE marking (Article 48), and completes EU database registration (Article 49; the database is established under Article 71) — request the registration identifier. Score a refusal or inability to evidence Article 13 instructions or confirm Annex IV documentation as a disqualifier for high-risk deployment.

---

Section 6-7: Data Protection / GDPR Overlap and Security & Robustness (copy-paste blocks)

Section 6 - Data Protection and GDPR Overlap

The EU AI Act Article 10 data-governance obligations (relevance, representativeness, bias evaluation of training, validation and testing data) sit on the provider. You score whether the Annex IV disclosure is sufficient to form a reasonable view, and whether the GDPR roles (controller / processor) are clear.

Section 7 - Accuracy, Robustness and Cybersecurity (Article 15)

Score the declared Article 15 accuracy, robustness and cybersecurity specifications and the Article 12 logging the system produces over its lifetime.

Logging and Incident-Handling Expectations

Under Article 73, providers must report serious incidents to the market-surveillance authority — generally within 15 days of awareness, 2 days for widespread infringement or critical-infrastructure disruption, and 10 days where a death has occurred. Capture the vendor's contractual notification timeline to you. Where personal data is processed at scale without a DPIA, or where Article 15 specifications are undeclared or untested, lower the score and flag for follow-up.

---

Section 8: The Risk-Scoring Matrix and Go / Conditional / No-Go Decision (copy-paste matrix)

The Scoring Matrix: Criterion, Weight, Score

Computing the Overall Rating

Multiply each score (0–5) by its weight and sum. For high-risk systems, classification and conformity carry the highest weight because a mistake there is the most expensive. Band the weighted total:

• High total → GO — proceed; attach the assessment to the vendor file.
• Mid total with open items → CONDITIONAL — proceed only with contractual remediation.
• Low total, or any hard disqualifier → NO-GO — do not deploy.

Hard Disqualifiers and the Decision Rule

These force a NO-GO regardless of the weighted total:

1. The use falls under an Article 5 prohibition.
2. No conformity assessment completed for a high-risk system.
3. The provider cannot evidence any Annex IV documentation.
4. No human-oversight mechanism is built in.
5. Serious incidents went unreported under Article 73.

CONDITIONAL is a contractual gate: the vendor commits to supply the missing Article 13 instructions or Annex IV summary, to notify you before any Article 25-triggering change, and to meet incident-notification timelines — with audit rights and review dates recorded.

Tie the decision to penalty exposure so the rating has teeth. Deployer breaches sit under Article 99(4) (up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher); Article 5 breaches under Article 99(3) (up to €35,000,000 or 7%); supplying incorrect, incomplete or misleading information to authorities under Article 99(5) (up to €7,500,000 or 1%); SMEs and start-ups get the proportional cap under Article 99(6).

---

Using the Assessment in Procurement and Feeding the AI System Register

Wiring the Template Into the Procurement Gate

Treat the completed assessment as a procurement gate artefact: attach it to the vendor file, require sign-off before contract signature, and store the go / conditional / no-go decision with its evidence trail. The broader vendor assessment framework explains how to slot it into procurement workflow.

From Assessment to AI Inventory Record

Each completed assessment should create or update a record in your AI system register: system, provider, deployer role, risk tier, documentation status, decision, and next review date. For deployments built on third-party AI APIs (foundation models), note that the upstream GPAI chain (Articles 53 and 55, in force since 2 August 2025) is a separate workstream — see using third-party AI APIs — and mark the GPAI provider role and Annex XII downstream documentation as register fields.

---

How Confir Helps

Confir runs these vendor assessments deterministically. The same intake of vendor responses and evidence always produces the same finding, mapped to the firing Article, and rolls each assessment into an organisation-wide AI register — the reproducible, explainable record an inspection expects. The classification and scoring logic is deterministic and rule-based: the same logic every time, no model inference, no hallucination. Every score and decision traces back to the rule that produced it, so when an authority asks why a tool was rated no-go, you can point to the Article rather than to a black box.

---

Frequently Asked Questions

What is an AI vendor risk assessment template?

It is the instrument a deployer fills in to score a third-party AI tool and reach a procurement decision under the EU AI Act. It classifies the use (prohibited, high-risk or limited-risk), maps roles, checks the vendor's documentation, and weights each criterion into an overall go, conditional or no-go rating with a documented evidence trail.

What is the difference between an AI vendor risk assessment and a vendor questionnaire?

A questionnaire collects the vendor's own answers; the risk assessment is the buyer's rating instrument that scores those answers and the supporting evidence. You send the questionnaire first, then transcribe responses into the assessment, apply weights, and produce a defensible go, conditional or no-go decision. One gathers evidence; the other turns it into a decision.

How do you score AI vendor risk under the EU AI Act?

Build a matrix with columns for criterion, weight and score, with rows for classification, conformity evidence, documentation adequacy, role and Article 25 risk, data protection, and security. Weight high-risk criteria most heavily, sum to an overall rating, and apply hard disqualifiers (an Article 5 prohibition or missing conformity assessment) that force a no-go regardless of total.

Who fills in the AI vendor risk assessment, the buyer or the vendor?

The buyer fills it in. As the deployer under Article 26, you are accountable for evaluating whether a third-party AI system is fit to use, so the rating is your record, not the vendor's. The vendor supplies inputs through the questionnaire and documentation, but the scoring, weighting and final decision belong to you and your procurement team.

Does the EU AI Act require deployers to assess AI vendors?

Article 26 does not use the words 'assess your vendor', but it requires deployers to use systems within their intended purpose, implement provider-specified oversight, and monitor operation. Discharging those duties means verifying the provider completed conformity assessment and supplied adequate Article 13 instructions. The assessment is how you evidence that due diligence happened before deployment.

What happens if a vendor's AI tool is high-risk under Annex III?

You must verify the provider completed an Article 43 conformity assessment, issued an Article 47 declaration of conformity, affixed CE marking under Article 48, and registered the system under Article 49, and that the Article 13 instructions support your Article 14 oversight. Missing conformity evidence is a hard disqualifier. The high-risk deadline is currently 2 August 2026, with a proposed deferral to 2 December 2027.

What penalties apply if a deployer uses a non-compliant AI vendor?

Deployer breaches carry fines up to €15,000,000 or 3% of total worldwide annual turnover under Article 99(4). Using a prohibited Article 5 system carries up to €35,000,000 or 7% under Article 99(3), and supplying misleading information to authorities up to €7,500,000 or 1% under Article 99(5). SMEs and start-ups get the lower-of cap under Article 99(6).

---

Related guides

• The AI vendor questionnaire
• Vendor assessment framework
• Provider versus deployer
• Article 26 deployer obligations
• Your AI inventory
• Using third-party AI APIs