A completed supplier review can give a compliance team a lovely false sense of closure.
The questionnaire is done. Someone has saved the ISO 27001 certificate, the SOC 2 report and the data processing agreement into the supplier folder. The procurement team is happy enough, and while legal initially raised a few questions, they were resolved, and sign off given. The supplier register is updated, the risk rating is recorded, and the business starts using the tool.
For a lot of software, that process is a reasonable control. It gives the organisation a view of the supplier’s security posture and creates evidence that the decision was considered. With AI, the supplier review remains useful, but it is nowhere near the whole story.
The reason is not especially complicated. Supplier reviews give you detailed information about your suppliers, but tell you no where near enough about your own operations. It’s the gap between these two facts that seems to be causing AI governance conversations (and audits) to become unstuck.
A vendor can have good security controls and still be used badly. The contract might say the right things, the hosting location might be acceptable, and the access controls might be perfectly sensible. None of that proves staff are using the tool in a controlled way. It does not show what information they are entering, which outputs they are relying on, whether the use case has changed, or whether the tool has quietly become part of a business process nobody has properly assessed. This is the gap auditors, customers and boards are starting to notice.
AI tools don’t behave like traditional software from a governance point of view. Their risk depends heavily on what people feed into them and how the outputs are used. The same tool might be low risk in one part of the business and completely inappropriate in another. A general approval rarely deals with that properly.
Take an AI note-taking tool. Used for internal project meetings, it might be manageable with the right settings and guidance. Used in a sensitive customer complaint meeting, a legal discussion or an HR matter, the risk profile changes quickly. The supplier may be the same, but the data, context and consequences are very different.
The same applies to document summarisation, code assistants, CRM features, customer service tools and AI search functions embedded inside platforms the business already uses. The supplier review might tell you whether the vendor encrypts data and has an incident response process. It will not tell you whether a staff member has uploaded a client contract, pasted in source code, summarised a board paper or relied on an AI-generated answer without checking the source.
AI supplier governance needs to be tied to use cases and data, not handled as a one-off procurement task.
This does not mean every AI tool needs a huge approval process. That would be a fast way to push people back into unofficial use. The process needs to be practical enough that the business will actually follow it. So, it should record:
Before approving an AI supplier, the organisation should understand what information will be shared with the tool and what happens to that information. Is it stored? Is it retained in prompts or logs? Can the supplier use it to improve models? Are subprocessors involved? Can administrators access the content? Does the data leave Australia or another approved jurisdiction? Are there settings that reduce the risk, and has anyone actually configured them?
Those questions sound like supplier review questions, but they cannot be answered by the supplier alone. They need input from the people who understand the business process.
This is where your AI supplier register needs to connect with the data register, the risk register and the control set. If those records all sit in separate spreadsheets, the organisation is relying on people to mentally join the dots. That works until someone leaves, the tool changes or the auditor asks for evidence three months later.
AI also creates an integrity problem that ordinary supplier reviews tend to underplay.
Security documentation can tell you how the vendor protects the platform. It does not tell you whether the output can be trusted. If AI is used to generate code, draft customer responses, classify issues, assess risks or summarise important documents, the business needs a clear view of review and approval.
That does not need to be dramatic. It simply means the existing management system has to absorb AI use. Code still needs review and testing. Customer communications still need appropriate approval. Risk decisions still need an accountable owner. Reports still need to be checked before they are treated as fact.
A sensible AI compliance program does not pretend every output is dangerous. It recognises where an error would matter.
Availability deserves the same practical treatment. If a team uses an AI tool every day, there may be an operational dependency even if the supplier has never been classified as critical. That dependency may not appear in a business continuity plan, because nobody thought of the tool in those terms. Then the supplier changes the licence, removes a feature, suffers an outage or changes how the model behaves, and the business suddenly realises the process was more fragile than expected.
This is especially common when AI is embedded into products already in use. A new feature appears, teams adopt it, work practices change, and the formal supplier review remains exactly where it was months ago.
That is the problem with treating supplier review as the finish line.
For AI, approval needs to stay connected to actual use. The organisation should be able to show which AI tools are approved, which use cases are allowed, what data is involved, what controls apply and what evidence proves the arrangement is still current. The evidence does not need to be overworked, but it does need to exist outside someone’s inbox.
This is where de.iterate’s view of compliance becomes important. AI risk is easier to manage when suppliers, data, risks, controls, tasks, evidence and policies are connected in one place. The organisation can see the relationship between the tool, the information it touches and the controls that are supposed to keep the use safe.
That is much harder when the supplier assessment sits in one folder, the data register in another, the policy in a PDF, and the actual business use somewhere in a team chat.
AI supplier review still matters. It should not be dismissed or replaced. But it should be treated as one part of a broader assurance process.
You need to be able to explain how the supplier is being used in practice, what information is being shared, and how the business knows the controls are still working. This is the evidence auditors are looking for, and the evidence that customers will increasingly expect.
Book a demo to see how de.iterate can help.