AI Vendor Risk Assessment: 50-Point Template 2026

AI vendor risk assessment is the procurement discipline that distinguishes a defensible signing decision from a brochure read — and in 2026 it is the artefact that auditors, board members, and future engineering leaders will read three years from now to understand why your AI stack looks the way it does. The 50-point template below organises the assessment across five domains: security posture, compliance certifications, data handling, model provenance, and operational resilience. Each point is scored, severity-weighted, and gated.

The structure of this assessment matters more than any individual point on the list. The template is built so the output is a single severity-weighted score per vendor, a documented evidence trail per point, and a small set of hard go/no-go gates that disqualify a vendor regardless of total score. Together those three artefacts convert vendor risk from a relationship judgement into a reviewable procurement decision — which is the actual test the assessment is designed to survive.

This guide walks each of the five domains in turn — ten points per domain — followed by the severity weighting scheme and the scorecard gates. It assumes you have already filtered your shortlist to the top three to five vendors through the upstream scorecard described in our Stage 4 vendor selection playbook; risk assessment is the next gate in the same procurement track.

The average tenure of a senior AI executive in 2026 sits around eighteen months — meaningfully shorter than the typical AI vendor contract, materially shorter than the twenty-four-month roadmap window most teams plan against. That asymmetry is the single most under-appreciated feature of vendor risk assessment. The person who signs the contract is rarely the same person who renews it, defends it after a model-update breaks production, or migrates off it when the vendor strategy shifts. The artefact has to survive the person.

That changes how the assessment should be run. The output of a vendor risk assessment is not an opinion — it is a documented severity-weighted scoring artefact with named evaluators per point, an evidence file per point, and a hard go/no-go gate list applied independently of the weighted total. The procurement decision falls out of those artefacts; without them, vendor choice collapses into the relationship in the room on signing day, which is exactly what audit reviewers will flag eighteen months later.

The second reason this matters more than its budget line suggests: vendor lock-in compounds. A choice made casually at signing propagates through implementation, into integration depth, into the data the vendor accumulates about your usage, into the renewal negotiation, and into the cost and complexity of an exit. A deliberate 50-point assessment at signing produces optionality at every subsequent stage; a casual one produces a sequence of expensive renegotiations under duress.

Two failure modes show up reliably when teams skip the artefact work. The first is the relationship-driven approval — a vendor cleared because the AI lead worked with their CTO at a previous company, with the risk write-up produced after the decision to justify it. The relationship may be a fine signal, but a write-up authored after the decision is no longer an audit trail; it is justification. The second is the demo-driven approval — a vendor cleared because the demo was polished, even though demo capability is the easiest part of the offering to replicate and the operational reality is closer to a different vendor's. The 50-point template, the gates, and the severity weighting are designed to neutralise both failure modes.

Security posture is the first of the five domains and the one most likely to be over-relied on as a proxy for the rest. The ten points below cover authentication, encryption in transit and at rest, secrets handling, audit logging, network controls, and the incident response programme. Score each one against the evidence the vendor produces in response to the questionnaire, not against the marketing copy on the security page.

The grid that follows is the operating shape of the ten points. Five control families, each with multiple sub-points, scored from 1 to 5 with severity weights applied as described in Section 07. Evidence per point lives in the procurement file; unverified claims score below the floor.

The most-skipped sub-points across this domain are typically audit-log retention and SIEM export support. Vendors will often offer audit logs in their own console with no export pathway, which makes the logs useful to the vendor's support team but useless to your own security operations centre. A SIEM-ready export — JSON or CEF, ideally with a published schema — is the difference between a security feature you can build into your own detection and response stack and a security feature you can only inspect when you log into the vendor's UI.

The under-discussed point in the encryption family is cryptographic agility. Most vendors meet the headline AES-256 and TLS 1.2 requirement; few publish what their migration plan looks like when post-quantum cryptography enters the mainstream, or when an algorithm gets deprecated. A vendor that cannot describe their crypto-migration story is a vendor whose security posture is frozen at today's standards, which means it is degrading every year.

Compliance certifications are the second domain — ten points covering the certification programmes themselves, the sector-specific overlays (healthcare, finance, public sector), and the regional regulatory regimes (EU GDPR, UK, California, Singapore, Australia). The framing matters: certifications are a floor, not a ceiling. SOC2 Type II tells you the vendor has a security programme audited annually against the AICPA framework; it does not tell you the programme covers AI-specific failure modes, training-data provenance, or model-update governance.

Use the choice matrix below to assess each shortlisted vendor against the four certification families that matter most in 2026 AI procurement. Sector-specific certifications (HIPAA, HITRUST, PCI-DSS, FedRAMP, IL5) layer on top depending on the workload class.

The two AI-specific compliance signals worth weighting heavily in 2026 are ISO 42001 scope (the new AI management system standard) and documented EU AI Act risk-tier alignment. ISO 42001 is the first internationally-recognised certification that addresses AI-specific governance — training-data management, model lifecycle, AI incident response — rather than treating AI as a generic IT system. Vendors who hold ISO 42001 within their AI product scope are signalling that they treat AI governance as a distinct discipline from general information security; vendors who do not are not.

The EU AI Act risk-tier alignment matters even for non-European buyers because the regulation establishes the most concrete framework for AI risk classification globally — general-purpose AI obligations, high-risk system requirements, transparency obligations, and prohibited practices. A vendor who can articulate which risk tier their product falls into, and what obligations attach, is a vendor who has done the regulatory homework. A vendor who treats the EU AI Act as a problem for someone else's lawyer is a vendor whose compliance posture is reactive rather than programmatic.

Data handling is the third domain — ten points covering data residency, retention policy, deletion process, training opt-out, output-rights ownership, and the chain of custody from prompt submission to model output. This is the domain where AI vendor risk diverges most sharply from generic SaaS risk: the data submitted to an AI vendor is not just data being processed, it is data that may be used to train future models, may be retained as part of a fine-tuning dataset, and may surface in outputs to other customers.

The training opt-out clause is the single most-skipped control in 2026 AI procurement. Without an explicit opt-out in the contract — not just in the marketing copy — every prompt and document submitted to the vendor is potentially training data for future model versions. The clause has to be enumerated in the contract, named per data category, and verifiable.

Two operational notes on this domain. First, the training opt-out clause has to be enumerated rather than blanket. A single line saying "customer data will not be used for model training" is weaker than a clause that enumerates the data categories (prompts, documents, outputs, feedback signals, fine-tuning data, telemetry) and applies the opt-out to each named category. The enumerated version is harder to argue around at renewal and produces clearer audit evidence.

Second, deletion verifiability is more important than the deletion SLA itself. A vendor who deletes within 30 days but cannot produce a signed deletion attestation is functionally indistinguishable from a vendor who deletes within 90 days with attestation — and worse than a vendor who deletes within 45 days with attestation. The attestation is the artefact that satisfies the GDPR Article 17 right-to-erasure obligation; without it, the customer cannot demonstrate compliance to their own regulators.

Model provenance is the fourth domain — ten points covering the model's lifecycle from training corpus through fine-tuning, evaluation, deployment, and ongoing monitoring. Provenance assessment is the domain that most distinguishes serious AI vendors from less serious ones; the points below cannot be bluffed in an RFP response, and the vendors who answer them substantively are the vendors whose models you can defend in an audit.

The four signals that matter most in this domain are training data composition disclosure, RLHF process documentation, eval harness coverage, and output watermarking support. Together they tell you whether the vendor treats the model as a serious engineered artefact or as a black-box capability bolted on for the demo.

The training-data disclosure question is where vendors most often retreat into vague generalities — "diverse web corpus plus licensed datasets" is the typical answer. Push for the specifics: roughly what proportion is licensed corpora versus web crawl, what is the cutoff date per data source, what is the language distribution, what synthetic-data proportion was used, and what filtering pipeline was applied. Vendors who can answer those questions clearly are vendors with a serious data governance programme; vendors who cannot are vendors whose training pipeline is either undocumented or considered too sensitive to share. Neither of those is acceptable for AI procurement at scale.

On watermarking, the technology is maturing rapidly but adoption is uneven. The 2026 frontier is cryptographic watermarks that survive light paraphrasing on text and standard image transformations on visuals — and that publish a verification tool so the watermark can be checked outside the vendor's infrastructure. Vendors without any watermarking story are signalling that they have not engaged seriously with content-attribution challenges, which is a category of risk that is rising fast as regulators push for AI-generated content disclosure obligations.

Operational resilience is the fifth and final domain — ten points covering service availability SLAs, incident response, change management, customer support, capability deprecation policy, and the financial-stability signals that predict whether the vendor will be around at the end of your contract term. The under-discussed point in this domain is deprecation policy: the written commitment around what happens when the vendor decides to stop supporting a capability you have built against.

Use the modes grid below to assess each of the five operational sub-domains; sub-points within each cover the more granular questions (named TAM availability, business-review cadence, credit policy details, executive escalation paths).

The deprecation policy is the under-discussed risk control in most procurement processes. The standard SaaS contract assumes the vendor will continue to support the capabilities you signed for through the contract term; the AI vendor contract has to handle a different reality, where a capability may be deprecated mid-contract because the underlying model has been retired, the vendor has pivoted strategy, or the capability has been folded into a more expensive product tier. A 12-month notice period with named migration support is the baseline; less than that and the contract is exposed to mid-term operational disruption with no recourse.

Financial-stability assessment matters more for AI vendors than for typical SaaS because the AI vendor market is going through a consolidation phase. Vendor acquisitions, strategic pivots, and outright shutdowns are happening more frequently than in mature SaaS categories, and the cost of a vendor going away mid-contract is materially higher because of the integration depth required for production AI workloads. Assess the financial-stability signals seriously; a vendor with eighteen months of runway and a single customer above 40% of revenue is a vendor whose contract you should price down significantly because of the risk premium.

Two operational discipline notes. First, the SLA service-credit formula has to produce real consequences. A vendor offering "service credit of 5% of monthly fees" for a multi-day outage is offering a token rather than a remedy; the credit needs to scale with outage duration and severity, with a cap that is high enough to incentivise actual operational investment. A sensible structure caps credits at 30% of monthly fees for severe outages, which is enough to be felt by the vendor's P&L without being existential. Second, the status page has to be public and historically searchable. A status page that only shows the current state and clears history is a status page designed to make the vendor look good rather than to be useful to customers; insist on a 12-month history at minimum.

The 50 points roll up into a single severity-weighted scorecard per vendor, with explicit go/no-go gates applied independently of the weighted total. The severity weighting scheme below uses four tiers — Critical, High, Medium, Informational — with weights that produce a maximum theoretical score of 100 across the 50 points. Vendors that clear the shortlist threshold (typically 75 of 100) and pass every gate move to contract; vendors that fall below the threshold or fail any gate are disqualified.

Severity weighting matters because not every point on the assessment carries equal procurement consequence. A vendor failing on watermarking support is a different category of risk from a vendor failing on cross-tenant data isolation; the scoring scheme has to reflect that asymmetry.

The threshold matters as much as the weighting. The default shortlist threshold is 75 of 100 on the weighted total — high enough to filter aggressively, low enough that one or two shortlisted vendors usually clear it. Set the threshold before scoring begins; setting it after produces a moving target that rationalises whatever shortlist the team wanted in the first place. Document the threshold and the weighting scheme in the procurement file as the second artefact after the 50-point scorecard itself.

The gate list applies independently of the score. Any single Critical-tier point scored at the floor (1 out of 5) is a hard disqualifier — auth, encryption, cross-tenant isolation, training opt-out, IP-clean training data. A vendor failing any of those at the floor is disqualified regardless of how well they score on the other 49 points. The gates are non-negotiable because the risks they cover compound across the rest of the portfolio; a single gate failure makes every other strength irrelevant.

The discipline that keeps the assessment honest over time is documenting the baseline and rerunning against it. Store the scored scorecard alongside the contract; on the renewal review, rerun the assessment and diff the new scores against the baseline. Where scores have moved — up or down — note the change, capture the evidence, and update the contract red-line for the renewal cycle. Teams that compound advantage in AI procurement are the teams that rerun the assessment; teams that compound regret are the ones that treat the original signing decision as final.

For teams running their first 50-point assessment, the practical starting point is to score the incumbent vendor first — the one already in production — to calibrate the scoring discipline before the shortlisted alternatives. The incumbent assessment becomes the baseline the alternatives are scored against, and the gaps in the incumbent often reveal which of the 50 points carry the most operational weight in your specific context. From there, the template scales cleanly to the rest of the procurement portfolio. Our AI transformation engagements include the full 50-point assessment as part of the procurement-and-renewal track.