Scrutineer · Vendor risk

AI vendor risk management software and AI vendor assessment

Someone in your company signed up for an AI tool this quarter, and it now reads customer records. Procurement never saw it, and your vendor questionnaire has no question that would have caught it.

Scrutineer treats an AI vendor as a vendor: same register, same tiering, same evidence, plus the handful of questions that only make sense when a model is involved.

or try it below ↓

Control-mapped findings · linked evidence · you decide what to remediate

The Scrutiny Desk

Illustrative sample · not an audit attestation

SOC 2 ISO 27001 HIPAA GDPR PCI DSS

Controls in evidence-linked report out

AI scrutinizes you decide

Why it works

What you get with AI vendor risk

The US AI vendor law every checklist cites was repealed before it ever took effect

Read almost any 2026 guide to assessing AI vendors and it points at Colorado SB 24-205, the Colorado AI Act, as the reason a deployer can demand documentation from a developer. That law is gone, and it never once applied to anybody. It was passed in 2024 with a start date that slipped to June 30, 2026. Before that date arrived, xAI sued to enjoin it in the US District Court for the District of Colorado, xAI v. Weiser, case 1:26-cv-01515, filed April 9, 2026, on First Amendment, Commerce Clause, vagueness and Equal Protection theories. The US Department of Justice intervened, and on April 27, 2026 the court granted a joint motion that suspended enforcement. Three weeks later, on May 14, 2026, Governor Polis signed SB 26-189, Automated Decision-Making Technology, which repeals and reenacts those provisions and took effect the day it was signed as chapter 131 of the session laws. So the developer duty exists, but it is a different duty with a different deadline, and if your AI vendor questionnaire still quotes the old statute you are asking vendors to attest to a law that was struck from the books.

Texas does not require an AI impact assessment, whatever the vendor checklist says

The Texas Responsible Artificial Intelligence Governance Act, HB 149, took effect January 1, 2026, and it is regularly described in vendor marketing as requiring impact assessments and high-risk AI documentation from private companies. The enacted text does not. TRAIGA was pared back heavily before it passed. What private developers and deployers owe is a clear and conspicuous plain-language disclosure that a consumer is interacting with an AI system, plus a list of prohibited conduct: intentionally inciting self-harm or crime, unlawful discrimination against a protected class, systems built to produce child sexual abuse material, and systems built to infringe constitutional rights. The discrimination hook is the part most summaries get backwards, because it is an intent standard: a violation requires developing or deploying an AI system with the intent to unlawfully discriminate, and the statute says outright that a disparate impact is not sufficient by itself to demonstrate an intent to discriminate. There is a separate healthcare disclosure duty, a biometric carve-out for training data unless the system is used to uniquely identify a specific individual, and a regulatory sandbox running up to thirty-six months. Enforcement is the Texas Attorney General only, after a sixty-day cure period. Asking a vendor for a TRAIGA impact assessment gets you a confused email, because no such filing exists.

The framework you are mapping to already warns that the vendor will not show you its math

NIST AI RMF 1.0, NIST AI 100-1, is the reference most US programs settle on, and it is unusually blunt about third parties. GOVERN 6 asks for policies and procedures to address AI risks and benefits arising from third-party software and data and other supply chain issues. GOVERN 6.1 wants policies that address AI risks associated with third-party entities, including risks of infringement of a third-party intellectual property or other rights. GOVERN 6.2 wants contingency processes in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk. MAP 4.2 wants internal risk controls for components of the AI system, including third-party AI technologies, identified and documented. MANAGE 3.2 is the one nobody implements: pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance. The framework then says the quiet part in its own text, warning that risk metrics or methodologies used by the organization developing the AI system may not align with those used by the organization deploying it, and that the developing organization may not be transparent about the risk metrics or methodologies it used. Elsewhere it notes that technologies acquired from third-party entities may be complex or opaque and that risk tolerances may not align. That is a standards body telling you, in advance, that a vendor answer is not a measurement.

What it handles

Controls in, an evidence-linked report out

Point Scrutineer at a framework or a vendor and it maps every control, pulls the evidence it can find, flags the gaps and scores the risk, returning a report with linked evidence and a prioritized remediation list. Scrutineer is decision support for readiness, an accredited auditor still issues the attestation.

Finds the AI a vendor added after you approved them, because the risky ones are almost never the vendors you bought as AI vendors
Runs AI questions as a layer on your existing questionnaire rather than a second questionnaire, so tiering, owners and due dates stay in one register
Tracks whether a vendor trains on your data, whether that setting is contractual or a toggle, and who at your company flipped it last
Keeps a live subprocessor and model-provider list per vendor, so a change of underlying model provider raises a review instead of passing silently
Records the AI artifacts a vendor has actually produced, ISO 42001 certificate, SOC 2 report, AI-CAIQ response, model card, and flags the ones that have expired
Carries the NIST AI RMF third-party subcategories, GOVERN 6.1, GOVERN 6.2, MAP 4.1, MAP 4.2, MANAGE 3.1 and MANAGE 3.2, as controls you can evidence rather than prose
Maps the same evidence to SOC 2, ISO 27001, HIPAA and ISO 42001, so AI vendor review feeds your framework work instead of duplicating it
Produces the dated, approved write-up a regulator or an enterprise customer asks for when they want to know how you vet AI in your supply chain

AI VENDOR RISK readiness_report

READINESS · 82%

ACCESS CONTROL 91

evidence · MFA enforced and access reviews evidenced.

CHANGE MGMT 78

evidence · Mostly covered; one approval log left untested.

VENDOR RISK 64

evidence · Two subprocessors missing a current review.

ENCRYPTION 86

evidence · Data encrypted in transit and at rest, evidenced.

Example report layout, not customer data

Why Scrutineer

One platform that maps controls and scores risk

Not a static questionnaire, not a pass-fail black box, and not a spreadsheet you maintain by hand. Live control mapping across SOC 2, ISO 27001, HIPAA, GDPR and PCI, automatic evidence and a prioritized gap list, returned as a report you can act on. The AI scrutinizes, you decide.

Mapped to real controls

Every framework is broken down into the controls it actually requires, each scored on a red to amber to green scale, so readiness stays transparent and consistent.

Evidence behind every finding

Each control links to the exact evidence that satisfies it, the policy, the config, the log line, so the finding is auditable and your readiness is defensible.

A prioritized gap list

Open gaps roll up into a ranked remediation list, so the highest-risk findings sit at the top and your team fixes what matters before the audit begins.

AI vendor assurance reference

What an AI vendor can actually hand you, and what each artifact fails to cover

Every published AI vendor risk checklist is a list of questions to ask. None of them tells you which artifact exists, who stands behind it, or what it deliberately leaves out. That is the part that decides whether a review is assurance or paperwork, so this table runs on the artifact rather than the question.

Artifact you can ask an AI vendor for	Who stands behind it	What it actually covers	What it does not tell you	Can you get it today
ISO/IEC 42001 certificate	An accredited certification body, after an audit	That the vendor operates an AI management system: policies, roles, risk process, impact assessment process	Nothing about how any specific model performs, what it was trained on, or whether your data is used	Yes, and the number of certified vendors is growing quickly
SOC 2 Type 2 report	A licensed CPA firm, on management assertions	Security and availability of the platform over a period, at the scope management chose to describe	Whether AI features were in scope at all, unless the description section says so in words	Yes, but read the system description before you count it
CSA AI-CAIQ response, mapped to the AI Controls Matrix	The vendor, as a self-assessment, unless it is a STAR for AI submission	A structured answer against AICM v1.1, released June 22, 2026: 247 control objectives across 18 domains	It is the vendor grading its own homework at Level 1, exactly like a CAIQ	Yes, and it is the most AI-specific questionnaire that currently exists
Model card or system card	The vendor, with no external review at all	Intended use, rough evaluation results, and the limitations the vendor chose to publish	Anything the vendor decided not to publish, which is where the interesting failures live	Usually, for model providers; rarely for the SaaS tool wrapping the model
A written statement that your data is not used for training	The vendor, contractually, if you get it into the agreement	The single control that most enterprise AI reviews actually turn on	Whether the setting is enforced in the product or is a toggle an employee can change	Yes, and this is the one to insist on in the contract, not the questionnaire
Current subprocessor and model-provider list	The vendor, usually as a web page with a change feed	Which model providers and infrastructure sit under the product you are buying	What changes between the day you read it and your next annual review	Usually, but you have to subscribe to the change notifications yourself
Colorado developer technical documentation under SB 26-189	The developer of a covered automated decision-making technology, by statute	Intended uses, categories of training data, known limitations and instructions, plus notice of material updates, with records kept three years	Nothing yet, because the duty does not start until January 1, 2027	No. This is the artifact most AI vendor checklists already assume you can demand

The last row is the one worth planning around. The statutory documentation duty most AI vendor questionnaires already reference does not begin until January 1, 2027, and it replaced a law that was enjoined and repealed before it applied to anyone. Until then every artifact above is voluntary, which means what you can actually enforce is what you wrote into the contract.

Good questions

Questions about AI vendor risk

AI vendor risk management is the practice of assessing and monitoring the AI systems your suppliers use to deliver a service to you, alongside the security review you already run on them. It adds a small number of questions a normal vendor review does not ask: what model sits underneath, whether your data trains it, which subprocessors see prompts, and what happens when the model changes.

An AI vendor is any supplier whose product uses a model to produce output you rely on. That includes the obvious model providers, but in practice most AI vendors are ordinary SaaS tools that shipped an AI feature after you approved them. The support desk that added summarization and the recruiting tool that added ranking are AI vendors now, and neither appeared on an AI procurement list.

Start from your existing vendor tier, then add the AI layer only where a model touches regulated or customer data. Establish what the model does, whether it is a substantial factor in a decision about a person, whether your data is used for training, who the subprocessors are, and what the vendor will commit to in the contract. Score it against the same scale as every other vendor so the results are comparable.

Ten to fifteen AI-specific questions on top of your standard set is usually enough. Cover the underlying model and provider, training use of customer data and whether that is contractual, data residency and retention for prompts and outputs, human review of consequential outputs, evaluation and red-team results, incident notification for model failures, subprocessor change notice, and which AI artifacts the vendor holds today.

Not today. Colorado SB 24-205 was enjoined in xAI v. Weiser and then repealed and reenacted by SB 26-189, signed May 14, 2026. Under the replacement, developers of covered automated decision-making technology must provide technical documentation covering intended uses, categories of training data, known limitations and instructions, and must notify deployers of material updates. That duty starts January 1, 2027.

No. The enacted Texas Responsible Artificial Intelligence Governance Act, effective January 1, 2026, does not require private developers or deployers to produce or file impact assessments. It requires a clear and conspicuous plain-language disclosure of AI interaction, bans a specific list of intentional conduct, and uses an intent standard under which a disparate impact alone is not enough to show intent to discriminate.

GOVERN 6 asks for policies and procedures addressing AI risks and benefits arising from third-party software, data and other supply chain issues. GOVERN 6.1 covers third-party entity risk including intellectual property infringement, GOVERN 6.2 asks for contingency processes for failures in high-risk third-party data or AI systems, MAP 4.2 covers internal risk controls for third-party AI components, and MANAGE 3.1 and 3.2 cover ongoing monitoring, including of pre-trained models.

It is meaningful and it is not sufficient. An ISO/IEC 42001 certificate says an accredited body audited the vendor management system for AI: that they have a policy, roles, a risk process and an impact assessment process. It says nothing about how a given model behaves, what it was trained on, or whether your data is used in training. Treat it as evidence of governance maturity, then still ask the data questions.

The AI Controls Matrix is the Cloud Security Alliance control framework for AI systems. Version 1.1, released June 22, 2026, carries 247 control objectives across 18 domains and maps to ISO 42001, ISO 27001, NIST AI RMF, BSI AIC4 and the EU AI Act. The AI-CAIQ is the matching questionnaire, so a vendor can self-assess or you can send it as part of a review, and it underpins the STAR for AI registry.

The register, the tiering and the evidence discipline are identical. Four things are genuinely new: the vendor may not be able to explain its own failure modes, the product changes when a model changes without any release you see, your data can end up in a training set through a default setting, and the chain of subprocessors underneath the vendor is longer and moves faster than in ordinary SaaS.

Yes, and splitting them is the most common early mistake. A separate AI vendor inventory drifts from the main one within a quarter, because the same vendor appears in both and only one gets updated. Keep one register, add an AI flag and the AI-specific fields, and let tiering decide the depth of review the way it already does for everything else.

That is where most of the concentration risk sits. Your ten AI vendors probably resolve to two or three model providers, so a single provider outage or policy change hits everything at once. Ask each vendor to name its model providers, ask what happens if one is unavailable, and keep the answer in the same place you keep the rest of your fourth-party mapping.

Read every compliance and risk question

Keep reading

Guides that go deeper on AI vendor risk

Best AI vendor risk management software

The four kinds of tool being sold for AI vendor review, what each can actually produce, and which fits a mid-market security team.

Read the guide

Best AI governance tools

The governance side of the same problem: the tools for the AI you build and run yourself, rather than the AI you buy.

Read the guide

Fourth-party risk explained

Why the model provider behind your AI vendor is the concentration risk nobody has mapped.

Read the guide

Explore more

More ways to scrutinize compliance and risk with Scrutineer

SOC 2 compliance

Map controls to the Trust Services Criteria, collect evidence, and close gaps before audit.

Learn more

SOC 2 compliance software

A platform that maps SOC 2 controls, automates evidence, and tracks readiness continuously.

Learn more

ISO 27001 compliance

Map your ISMS to Annex A, automate evidence, and stay certification-ready.

Learn more

See every use case See pricing Back to Scrutineer

Stop guessing about readiness. Scrutinize on real evidence.

Point Scrutineer at a framework or a vendor and it maps every control, gathers evidence and scores the risk, returning an evidence-linked report and a prioritized gap list. The AI scrutinizes, you decide.

See pricing

SOC 2, ISO 27001, HIPAA, GDPR & PCI · evidence-linked controls · readiness, not certification