# AI Vendor Risk Assessment: An Evidence-First Procurement Playbook Canonical: https://www.governatlas.com/guides/ai-vendor-risk-assessment Author: GovernAtlas editorial Published: 2026-10-28 Original editorial recommendations. Model-assisted research with primary-reference review. Not a certification, legal determination, product ranking or claim of performed testing. Company payment does not influence editorial findings. An AI supplier due-diligence method and free assessment worksheet: define the use, inspect evidence, test permissions and failures, document unresolved risks and retain a decision packet. ## How do you assess an AI vendor before a pilot becomes production? Review the exact service and intended use. Keep supplier assertions, source documents and observed trial results distinct. An unanswered question needs an owner and a consequence for the decision—not a hidden contribution to a score. ## What is an AI vendor risk assessment? An AI vendor risk assessment is a decision about a particular supplier service used for a particular purpose. It should explain what the system may do, what information it may receive, what could go wrong and who can accept the remaining uncertainty. A company-wide supplier approval does not replace a review of a new model, integration or use case. A familiar vendor can introduce an unfamiliar exposure through a new feature. Our proposed method separates four records: supplier identity, contracted service, intended use and supporting evidence. Record the product edition, deployment, model or model-selection policy, operating region and integration boundary. If an answer does not identify the offering it describes, retain the scope as unresolved rather than applying the answer to every plan. Name the person who can decide whether the uncertainty prevents a pilot. This is original GovernAtlas editorial guidance for procurement, security, data and operating teams. It does not calculate a universal risk score or establish compliance. NIST AI RMF 1.0 provides broader lifecycle context; its core functions are not an ordered procurement checklist. The sequence here is our recommended working method, not a claim that NIST requires these particular steps. - Use case and accountable decision owner - Exact product, edition and deployment - Permitted inputs, outputs, integrations and actions - Unknowns that could change the decision ## When should you review—and what should trigger another review? Begin before a pilot receives sensitive information or performs consequential actions. A bounded experiment with invented data can clarify requirements, but it still needs permitted users, an owner, a stop condition and a disposal plan. Calling something a pilot does not make a live patient record, confidential contract or production credential harmless. Define the permitted boundary before distributing access. Reopen the assessment when a relevant dependency changes: a model is replaced, an integration gains write access, a region changes, a data-use term changes, or an internal use becomes customer-facing. A scheduled review date helps allocate work; it should not be the only route by which a material change reaches an owner. Ask how the supplier makes a change visible before relying on a notification promise. For example, an assistant initially allowed to search an internal policy library may later gain permission to email a customer. That introduces a new recipient, action and recovery problem even if the model stays the same. The earlier permission should not silently cover it. Record who decides whether the changed workflow may resume and what evidence they need. This is an illustrative scenario, not a reported incident. ## Which evidence should you request from the supplier? Build requests around decisions rather than collecting the largest folder. For each important claim, retain its wording, owner, service scope, source date, evidence reference and the observation still needed. Distinguish a supplier assertion, an assurance report, an official policy and an observation from your own trial. They can be useful together without becoming interchangeable. A document received is not automatically a document accepted. For data handling, trace an input through the application, model provider, logs, support systems and downstream integrations. Ask separately about retention, training or improvement use, deletion, human access and the settings that enforce the proposed arrangement. An answer about one processing stage does not resolve another. Keep confidential artifacts in your controlled evidence system; use sanitized references in the public worksheet below. For assurance material, identify the entity, service, covered period and exclusions. For model behavior, ask about the test definition, version, relevant population or dataset and known limitations. A passing screenshot does not show whether the task resembles yours. The ICO source linked below is a UK data-protection reference and states that it is under review. It must not be treated as a current, worldwide compliance determination. - Service-specific data-flow record - Assurance scope, period and exclusions - Evaluation method, version and limits - Action permissions and denial evidence - Change, incident and exit responsibilities ## How do you test claims before approving a pilot? Choose authorized demonstrations that could change the decision. Start with an expected task, an out-of-scope request and a dependency failure. Use invented data and restricted test identities. Write the expected observation before the demonstration, preserve the configuration and record what happened, including an inconclusive result. This is a proposed test design; GovernAtlas has not executed these trials on the directory products. For a retrieval assistant, include one document the test identity may read and another it must not access. Check what reaches the model, response, logs and export. For a tool-using agent, test a prohibited action and a required approval. A refusal in the chat window does not establish that the downstream tool never executed. Connect the review to the detailed prompt-injection and data-access playbooks rather than substituting a generic demonstration. For reliability, rehearse an unavailable provider, partial output and a retry after an uncertain outcome. Ask who reconciles an action that may have happened twice. For behavior, use task-specific cases and retain uncertainty instead of importing an unexplained benchmark rank. Define acceptable observations for your own use and identify who accepts deviations. A supplier-run demonstration should retain its operator, environment and limits. ## How do you record a go, hold or restricted-pilot decision? Keep the decision separate from evidence collection. A reviewer can record that a document arrived without accepting its scope. Every questionnaire item may have an answer while one decision-critical uncertainty remains open. We recommend a concise decision record: intended use, permitted boundaries, material unresolved issues, accountable approver, conditions, evidence references and the event that should trigger reconsideration. Use a hold when an unresolved issue prevents an accountable decision. A restricted pilot can be useful when a narrower use removes an exposure and the restriction can be enforced. For example, an organization might allow only invented data while reviewing production-data terms. Record the mechanism and owner for the restriction. A request to be careful is different from an enforced control. A numerical completion percentage is not a safety conclusion. Seven answered topics and one unresolved action-permission boundary may matter more than a large collection of low-impact answers. Our working record counts review states only. It does not infer approval, rate a supplier or replace risk-acceptance authority. Download it as a draft packet and reconcile every reference with the actual evidence store. ## What needs to be settled before production use? Reconcile the operating arrangement with commercial and technical records. Name the purchased service, permitted configuration, responsible parties, change communication and incident escalation path. Your legal and procurement owners should determine the provisions required for the actual context. This guide supplies review questions; it does not provide universal contract language or legal advice. Check that a demonstrated control remains available in the purchased edition. Establish who configures it, who can change it and how a later change is detected. A sales statement, a current contract, an administrative setting and an observed denial are different artifacts. Keep those distinctions visible in the decision record so the operating team does not inherit an assumption disguised as an accepted fact. Plan the end at the start. Identify what can be exported, which identifiers and relationships survive, who holds replacement configuration and how deletion requests are followed through. Rehearse a narrow exit with invented data before relying on a larger migration promise. The vendor-exit guide includes a private rehearsal record that can accompany this assessment. ## How do you keep the review useful after onboarding? Connect the approved use to an inventory record and an operating owner. Keep the assessment identifier in change and incident workflows so a future reviewer can find the original assumptions. A model change, added integration or observed failure should create a review task when it crosses the documented boundary. Avoid reopening everything for a cosmetic release while missing a consequential permissions change. Use public incidents to improve test questions, not to assign guilt by association. A failure elsewhere can suggest a scenario without proving the same weakness exists in your supplier. Follow the primary source, separate allegations from disclosures and retain the affected scope. GovernAtlas incident case studies preserve those distinctions and connect lessons to practical tools; they are not supplier risk scores. At renewal, revisit current service scope, data paths, permitted actions, evidence age, exceptions and exit readiness. Ask what changed since the last decision. An unchanged questionnaire can conceal an altered operating system. Preserve earlier versions so the organization can reconstruct why an earlier use was permitted and why a later one was restricted. ## What is different about AI vendor risk? AI procurement adds intended-use, model, behavior-evaluation, data-path and tool-action questions to the supplier review. Connect each answer to the exact service. Company-wide approval does not automatically cover every AI feature. ## Is a security questionnaire enough to approve an AI supplier? No single document settles the decision. Review the scope, supporting material and unresolved boundaries behind the answers, then decide which claims need an authorized demonstration for your intended use. ## What should an AI risk assessment template contain? Record the use case, service configuration, decision owner, data and action boundaries, evidence references, unresolved issues, decision conditions and review triggers. The free worksheet here exports these topics without assigning a supplier rating. ## When should an assessment be repeated? Use a scheduled review and material-change triggers. A new model, recipient, integration permission, data-use term or incident may change the original decision before the scheduled date. The accountable owner determines the necessary review. ## Does completing the checklist approve the supplier? No. Completion describes the record. Approval belongs to your accountable decision process and depends on scope, evidence and unresolved issues. The tool deliberately does not turn its completion count into a rating. ## Can paying companies change this research? No. Public research remains free. Companies can submit evidence or contrary information for review, but payment does not buy a finding, ranking, ownership approval or certification. ## Primary references and scope - [NIST AI RMF 1.0 — Core functions](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/): Lifecycle framing and the distinction between core functions and an ordered checklist. NIST notes that AI RMF 1.0 is being updated. Our procurement sequence is an editorial method. - [NIST AI 600-1 — Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf): Generative-AI risk-management context and context-dependent suggested actions. Not evidence that any directory product meets those actions. - [ICO — Contracts and third parties](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/artificial-intelligence/contracts-and-third-parties/): UK data-protection audit guidance on AI supply-chain relationships and procurement due diligence. The source states it is under review following legislative changes; it is not a worldwide compliance determination. Interactive worksheets on the canonical HTML page are user-entered tools, not observed product test results. They are not reproduced here as research findings. Suggested citation: GovernAtlas editorial. AI Vendor Risk Assessment: An Evidence-First Procurement Playbook. 2026-10-28. https://www.governatlas.com/guides/ai-vendor-risk-assessment Corrections: https://www.governatlas.com/corrections Methodology: https://www.governatlas.com/methodology