AI Vendor Risk Management

Your AI vendor list is wrong, and the problem is not the assessments you did badly.

It is the vendors you never assessed, because nobody knew you had engaged them.

Third party risk management assumes a relationship exists. A contract was signed. A questionnaire was completed. Someone in procurement owns the file. That assumption held for decades because software arrived through the front door.

AI does not. It arrives four different ways, and only one of them passes your vendor risk process.

The four vendors you have

The ones you assessed. A model provider your bank contracted deliberately, with an enterprise agreement, negotiated terms and a completed questionnaire. This is the category your TPRM programme was built for, and it handles it well. It is also the smallest of the four.

The ones that arrived inside something else. Your case management platform shipped an AI assistant in its last release. Your CRM added summarisation. Your developer tooling embedded a coding model. Nobody signed a new contract, because there was no new contract. A vendor you already approved quietly became a vendor with a very different risk profile, and your assessment file still describes the product you bought in 2023.

The ones behind your vendors. The AI feature in your approved SaaS tool is not built by that vendor. It calls a model provider underneath. Your data reaches a company you have never assessed, under terms in a subprocessor list that changes without your involvement. You have a contractual relationship with the front door and no visibility into the back one.

The ones a team provisioned themselves. An API key on a corporate card. A team lead who needed a capability this quarter, not after a six week vendor review. Fast, well intentioned and entirely outside the process.

Categories two, three and four share one property. They generate no procurement event, so they generate no assessment, so they do not exist in your register.

Why the questionnaire cannot fix this

Even where a vendor is known, the standard instrument struggles.

It is a snapshot of a moving thing. You assess a vendor once at onboarding and again at annual review. In between, the model version changes, capabilities are added, the terms of service are updated and the subprocessor list shifts. Traditional software changed on a release cycle you could track. AI vendors change faster than your review calendar.

It describes intent, not behaviour. A questionnaire tells you what a vendor says it does. It does not tell you what your employees actually send them, how often, from which departments, or containing what. Those are different questions, and only the second set carries regulatory weight.

It stops at the first party. Ask a SaaS vendor about their AI feature and you will get a confident answer about their controls. The model provider underneath may be handled in a paragraph, or a link to a page that changes.

It cannot see consumer accounts. Your enterprise agreement excludes training use. The free tier your analyst signed up for on Tuesday does not. Same vendor, same logo, completely different terms, and your assessment file only knows about one of them.

That last point deserves emphasis. Most banks assessing a major AI provider are assessing the enterprise product. A meaningful share of the traffic reaching that provider from inside the institution is not going through the enterprise product.

Assessment is not the same as observation

Here is the reframe that matters. Vendor risk for AI has two halves, and most programmes only run one.

The first half is diligence. Contracts, security posture, certifications, data residency, retention terms, subprocessor lists, financial stability. This work is necessary, it is well understood, and Sayaa does not replace it.

The second half is observation. Which AI vendors are actually receiving data from your institution, how much, from whom, containing what categories, and under which account type. Almost nobody runs this half, and it is where the real exposure lives.

Diligence tells you what a vendor promised. Observation tells you what you gave them.

How Sayaa handles it

Sayaa builds the vendor picture from traffic rather than from paperwork.

Because it sits in the network path between your people, applications and agents and the AI platforms they reach, it can identify which platforms are receiving traffic, whether they are in your approved inventory, and what is being sent.

That produces a few things a questionnaire cannot.

A vendor list that reflects reality. Every AI platform receiving traffic appears, registered or not. The ones nobody assessed surface as shadow AI, with the department, user and data category attached.

Vendor as a governed attribute. Each AI system in the inventory carries its vendor, owner, lifecycle stage, control status, approval state and risk score. Risk rolls up by vendor across the portfolio, so you can see concentration rather than inferring it from a spreadsheet.

Policy that binds to the vendor. Enforcement is configured per AI platform, not as a blanket rule. Regulated customer data can be tokenised on the vendor you assessed and contracted, blocked outright on the one you did not, and passed untouched to an internal model inside your own perimeter. Where several policies match, the most restrictive applies.

Evidence per vendor. Every enforcement decision records which platform was involved, what was detected, which policy applied and what action followed. When someone asks what data reached a specific vendor last quarter, that is a query rather than an investigation.

Lifecycle you can act on. Systems move through proposed, approved, active, restricted, retired and decommissioned. When a vendor relationship changes, or an assessment expires, or terms shift in a direction you dislike, restricting the system changes enforcement behaviour immediately rather than generating an email asking people to stop.

What this does not do

Three limits worth stating plainly.

Sayaa does not audit a vendor's internal controls. It cannot tell you whether their data centre is well run, whether their staff are vetted or whether their SOC 2 is meaningful. That is diligence work, and you still need to do it.

It does not read contracts or interpret terms. It tells you what data reached which platform. Whether that was permitted under your agreement is a judgement someone in your institution has to make, though at least they will be making it with facts.

And on our own position, Sayaa is early stage and working with its first banking design partners. We are formalising independent security attestations alongside them, and we would rather say that than imply certifications we do not yet hold. If you are assessing us, ask the same questions you would ask any vendor in this article.

Three questions worth asking this week

Take these to your next vendor risk or technology committee.

How many AI vendors are we sending data to right now? Not how many we contracted. How many are receiving traffic. If those two numbers are the same, the answer is probably wrong.

For our largest AI vendor, what proportion of our traffic goes through the enterprise agreement we negotiated? If nobody can answer, consumer accounts are in play, and the terms you negotiated do not apply to that traffic.

When a vendor we already approved adds an AI feature, what triggers a reassessment? For most institutions the honest answer is that nothing does, until someone notices.

None of these are difficult questions. They are just difficult to answer with a register, which is the point.

Vendor risk was designed for a world where engaging a vendor was an event. AI made it a default. The programmes that hold up will be the ones that stopped asking vendors what they do and started observing what we send them.

Sayaa is a runtime assurance platform for regulated financial institutions, combining AI governance, real time data protection and audit ready evidence in one control layer.