Your Vendor Risk Team Can't Assess an AI Vendor. That's a Staffing Gap, Not a Tooling Gap
November 10, 2026
Randy Hall, CEO— AI-assisted and reviewed prior to publication.
Most vendor risk teams were built to evaluate uptime guarantees, encryption standards, and SOC 2 reports. They were not built to ask a vendor how its model behaves after a silent weight update, or whether its AI system has a bias-testing record. That gap is now a procurement bottleneck, and the fix is training the people who sit in that seat, not buying another assessment tool.
Why Is AI Vendor Risk Suddenly a Board-Level Problem?
Regulators moved faster than most vendor risk programs could staff up. Three separate regimes now expect documented evidence of third-party AI oversight: DORA's third-party risk pillar, which applies to EU financial entities and carries the highest rate of supervisory findings in 2025-2026 assessments according to EBA data, the EU AI Act's deployer obligations, and the NIST AI Risk Management Framework, which treats third-party dependencies as a core measurement function for trustworthiness.
In the United States, banking regulators have joined the pressure. The OCC, Federal Reserve, FDIC, and NCUA proposed updated interagency guidance on managing third-party relationship risk on September 11, 2026, explicitly in response to AI-driven vendor exposure that existing guidance never anticipated. Insurance regulators have moved too. State insurance departments now expect documented pre-acquisition due diligence on third-party AI under the NAIC Model Bulletin, and New York's DFS circular letter requires written standards for acquiring third-party AI.
None of this is abstract policy. It shows up as a line item in a board deck, because the people who answer for a failed audit are named executives, not an anonymous risk function.
Who Actually Owns This Inside a Typical Organization, and Can They Do the Job?
Right now, almost nobody. Third-party risk most commonly reports into risk management or a risk committee, not procurement, and procurement itself owns the function at only 6 percent of organizations surveyed by Venminder and Ncontracts in 2025. That split matters because the people closest to the buying decision are frequently the ones least equipped to evaluate what an AI vendor's claims actually mean.
The technical bar has also moved. Evaluating an AI vendor properly means reading a model card the way a risk analyst once read a SOC 2 report, understanding what an AI Bill of Materials should contain, and knowing the difference between a vendor that has genuinely mapped its AI system inventory to specific controls and one that has simply pasted an ISO 42001 badge into a sales deck. Annex A.10 of ISO 42001 requires organizations to identify AI suppliers, allocate responsibilities, and manage AI-specific considerations across the supplier lifecycle, and auditors test those controls directly against vendor evidence, not against policy language. A generalist vendor risk analyst with a standard GRC background was not trained to do that work, and most have not been asked to learn it yet.
This is where the business decision actually sits. You can keep routing AI vendor reviews through staff who learned third-party risk before generative AI existed, and accept the rework, the delayed deployments, and the audit findings that follow. Or you can treat this the way you treat any other specialized control gap: as a role that needs a named, credentialed owner.
What a Properly Trained Reviewer Actually Checks
A vendor risk analyst who understands AI governance is looking for specific, checkable evidence rather than a vendor's marketing language. NIST AI RMF's GOVERN function, ISO 42001 Clause 8.4, and sector-specific frameworks like the FS-ISAC Generative AI Vendor Risk Assessment Guide are the frameworks most directly applicable to this work, and Clause 8.4 specifically requires AI system impact assessments comparable to a GDPR data protection impact assessment before a third-party AI system gets integrated.
In practice, a trained reviewer is checking for things a standard vendor questionnaire never asks:
- Whether the vendor maintains a current inventory mapping each AI system to the controls that apply to it, not just a general security policy statement
- Whether the vendor can produce a completed risk assessment performed at onboarding, not retrofitted after the contract was signed
- Whether contract language addresses model change notification, since AI vendors ship continuously and most existing vendor contracts assume fixed release cycles
That last point is where generalist vendor risk processes break down fastest. A point-in-time questionnaire assumes a vendor's product is stable between review cycles. An AI vendor's model behavior can shift without a version number changing at all, which means the review itself has to become a continuous practice rather than an annual form.
Making the Training Investment Case to Leadership
The argument for building this capability internally is not abstract risk avoidance. It is a direct cost comparison between training existing staff and absorbing the cost of deployment delays, failed audits, or a declined insurance claim tied to an unvetted AI vendor. Insurance underwriters already treat third-party oversight as a binding condition, and the same documentation gaps that stall a vendor approval can stall a renewal.
| Capability gap | Business consequence | What closes it |
|---|---|---|
| Staff can't read an AI vendor's model documentation | Deployment delayed pending manual legal review | Role-specific AI governance training |
| No standard for AI-specific contract clauses | Model changes go unnoticed until an incident | Trained reviewers who know what to require |
| Vendor risk reports to IT or compliance with no AI background | Audit findings against Annex A.10 or DORA Pillar 4 | A named, credentialed vendor risk owner |
Building this capability does not require hiring a new team. It requires identifying who already owns vendor relationships and giving them a structured path to the specific competencies this work demands, from AI governance frameworks to the contract language that actually holds up under audit. Forge University's curriculum overview and FAQ in the resources section lays out how that training maps to the frameworks regulators are actually citing.
For organizations building this out, ISACA's AAISM credential is built specifically around the governance, risk, and vendor oversight skills this role now requires, and it is the closest match on the market to what AI vendor risk actually demands day to day. If you are deciding where to put your next training dollar, the AAISM certification page is the place to start, and if you want a study plan built around this specific use case, you can start training whenever you're ready.
The Cost of Waiting
Every quarter a vendor risk team operates without this capability, the backlog of unreviewed AI vendor relationships grows, and the organization's actual exposure outpaces what anyone on staff can accurately describe to an auditor or a board. That gap does not stay hidden. It surfaces at the worst possible moment, during a regulatory exam, an insurance renewal, or a post-incident review where the first question is who approved this vendor and what did they check.
The organizations handling this well are not the ones with the most expensive assessment platform. They are the ones who recognized early that AI vendor risk is a staffing decision before it is a tooling decision, and who moved to close that gap with people qualified to make the call.