Building an AI Vendor Risk Management Program That Is Not Just a Spreadsheet

Direct answer: Four parts: find every AI tool actually in use, tier them by what data and permissions they hold, assess proportionally to the tier, and re-review on a schedule. The hard part is discovery, because most AI adoption happens without procurement and most inventories are wrong on day one.

Discovery, and why your list is incomplete

Start from what you pay for, then widen. Expense reports catch corporate cards. Your identity provider's application list catches anything using SSO. Browser extensions and personal accounts catch nothing, which is why an anonymous amnesty question to the team usually surfaces more than any tool does.

Then add the category everyone forgets: AI features switched on inside software you already buy. Your CRM, support desk and note-taker all shipped AI capability recently, and none of it went through procurement because you already owned the product.

Tiering

Tier 1, high: processes customer personal information, or holds write access to your systems. Full assessment, contractual commitments, named owner, annual review.

Tier 2, medium: processes internal but non-personal data. Lighter assessment, subprocessor and training questions answered, reviewed on renewal.

Tier 3, low: public data only, no integration. Record it and move on.

Tiering is what makes the programme survivable. Assessing everything to Tier 1 depth means assessing nothing well, and the first time it feels like theatre is the last time anyone updates it.

The assessment

Reuse your existing vendor process and add the AI questions: training on inputs, retention and location, model providers as subprocessors, and change notification. For anything agentic, add permissions, approval gates and logging. Record answers with a date and a source, so that when a buyer asks you can show the evidence rather than the conclusion.

The cadence

Quarterly discovery, because adoption moves faster than procurement. Annual reassessment for Tier 1. Reassess on trigger for everything: a new integration, a permission change, a security incident at the vendor, or a material change in what data flows.

Tie it to a control you already run. If you do quarterly access reviews, do AI discovery in the same sitting.

Where it connects to compliance

This is not a separate regime. SOC 2 and ISO 27001 already require vendor management, and AI vendors are vendors. ISO 42001 formalises the AI-specific layer if you need certification. The EU AI Act adds obligations based on what the system does. Building one register that serves all of them is far cheaper than three parallel efforts.

Our AI Vendor Risk Assessment stands this up end to end, the vendor questionnaire builder and shadow AI risk checker are free, and third-party risk management covers the wider programme this sits inside.

Reading the answers, not just collecting them

The most common answer you will get is "we do not train on customer data," and on its own it means very little. It is usually true of the enterprise or API tier and untrue of the consumer tier of the same product, and your staff signed up for the consumer tier. Ask which plan the commitment attaches to, then check what plan your organisation is actually on. A surprising number of registers record an enterprise data commitment against an account that is being paid for on somebody's personal card.

The second thing to pull apart is training versus retention. A vendor can honestly say inputs are not used for training while still holding them for thirty days for abuse monitoring, and that retained copy sits somewhere with staff access controls you have not looked at. Ask for the retention period in days, ask whether a zero-retention configuration exists, and ask what it costs, because it is often available only on a higher tier or by request. If the answer is a marketing page rather than a number, record it as unanswered rather than as a pass. A register full of "yes" with no source is worse than a short register, because it manufactures confidence you have not earned.

The third is the model provider chain. Plenty of AI products are a thin layer over somebody else's model, and your data reaches a company you have never assessed and whose name may not appear in the vendor's subprocessor list. Ask which model providers are used, whether the vendor can switch providers without telling you, and whether inference happens in a region you can name. For anything in Tier 1 that answer needs to be in the contract, because a silent provider switch is a change in where your customers' data goes.

What to get in writing for a Tier 1 vendor

Assessment answers age badly. Contract terms do not. For any AI vendor touching customer personal information, the terms worth insisting on are narrow and achievable even with a smaller supplier. A written commitment that inputs and outputs are not used to train or improve models, stated as a term rather than a policy the vendor can revise. A defined retention period with deletion on termination and a mechanism to request deletion earlier. A subprocessor list with advance notification of changes, ideally thirty days, and a right to object. Notification of security incidents within a defined window, expressed in hours. Data residency, if your own customer contracts promise it, because you cannot promise downstream what your vendor has not promised you.

You will not win all of these with every supplier, and that is fine. What matters is that the ones you did not win are recorded as accepted risk with a named owner, not quietly dropped. When a buyer or an auditor asks why a vendor has no subprocessor notification clause, "we asked, they refused, we accepted it for these reasons on this date" is a legitimate answer. Silence is not.

Agentic tools change the question entirely

A summariser that receives text is a data flow problem. A tool that holds an OAuth token and can act inside your systems is an access control problem, and it belongs in the same conversation as employee access rather than in a vendor spreadsheet. The practical work is to look at the scopes actually granted rather than the ones the vendor asks for in its documentation. A meeting assistant frequently ends up with read access to the whole calendar, the whole drive, and historic mail, because the consent screen bundled them and somebody clicked through in twenty seconds.

For anything agentic, record three things beyond the standard assessment. What it can write or delete, not just read. Whether actions run under a shared service account or under an individual user's identity, because the former destroys your ability to attribute anything afterwards. Whether its actions appear in a log you retain, since a tool acting under a user token often produces audit entries indistinguishable from the human, which turns an incident investigation into guesswork. Where an approval gate is available for destructive actions, turn it on and record that you did.

Failure modes we see repeatedly

The blanket ban. An organisation prohibits AI tools, does nothing to make an approved path available, and drives the whole thing onto personal accounts and phones. Usage does not fall, visibility does. If you are going to restrict, publish an approved list on the same day and make getting something added take under two weeks, otherwise the policy is a discovery problem you created yourself.

The register that ages out. Somebody builds a beautiful inventory during a compliance push, and nobody touches it for eleven months. The fix is not discipline, it is attaching the review to an event that already happens, which is why quarterly access reviews are the natural host. If the AI discovery step has no owner in a calendar invite, assume it will not run.

Security as the sole gate. If every AI request routes through one reviewer who also has a day job, the queue becomes the reason people stop asking. Tier 3 should be self-service with a form and a logged record. Reserve human review for the tiers where it changes the outcome.

Assessing the tool and ignoring the use. The same vendor can be Tier 3 for a marketing team drafting copy and Tier 1 for a support team pasting in customer tickets. Tier the use case, not just the logo, and note the intended use in the register entry so a later reviewer can see when reality has drifted from it.

What buyers and auditors actually ask

Buyer questionnaires have moved quickly on this, and the questions are now specific. Whether AI or machine learning processes their data, and if so which vendors. Whether their data trains any model. Whether AI subprocessors appear on your published subprocessor page, and whether you will notify them before adding one. Whether outputs affecting their end users are reviewed by a human. Whether you can disable AI processing for their tenant, which is the question that catches teams out most often, because the honest answer is frequently no and nobody has told sales.

Auditors approach it through controls you already have. Under SOC 2 the vendor management control is where AI suppliers land, and the evidence expected is the same as for any other vendor: a current inventory, evidence of review at the stated frequency, and evidence that risk-ranked suppliers were assessed. Under ISO 27001 the relevant Annex A controls on supplier relationships and information transfer do the same job. Nobody needs a separate AI compliance regime for this, and building one usually means maintaining two registers that disagree. Our compliance work treats it as one register with AI-specific questions attached to the entries that need them.

When you should not buy this from us

If you are under about thirty people and you can name every tool in use from memory, do not hire anyone. Spend an afternoon pulling the identity provider's application list and the last two quarters of card statements, write the result in a spreadsheet with four columns, set a calendar reminder for the next quarter, and you are done. That spreadsheet is a real programme. Paying a consultancy to produce a better-formatted version of a list you could have written yourself buys you nothing an auditor will value more highly.

If you have no AI vendor holding customer personal information and nothing agentic with write access, this is a low-priority item and the money is better spent elsewhere. The genuine trigger for outside help is one of a few situations: a buyer questionnaire you cannot answer honestly, an ISO 42001 or EU AI Act obligation you have to evidence rather than assert, agentic tooling with production write access, or an inventory you already know is wrong and no internal owner with time to fix it.

If what you actually need is somebody to own the whole third-party programme rather than stand it up once, that is a retainer question rather than a project one, and how we work on retainer sets out what that looks like. If the pressure is coming from a specific customer review rather than an internal goal, send us the questionnaire and we will tell you whether this is a two-week fix or a programme.