The vendor has a trust portal. You checked it during procurement. You noted the SOC 2 Type II report, the ISO 27001 certificate, possibly an ISO 42001 AI management system certification or an EU AI Act conformity declaration. You noted the data processing agreement and the subprocessor list. You felt covered. You may not be.
The vendor's review covers the vendor. The system you built on their AI — your prompts, your integrations, your data flows, your exposed capabilities, your output handling — is not the vendor. Their certification does not reach it.
What the vendor's review actually covers
A vendor's security posture documentation is real and relevant. SOC 2 verifies that their infrastructure meets defined trust service criteria: logical access controls, change management, availability, and confidentiality of customer data in transit and at rest. ISO 27001 adds a management system layer: risk treatment, supplier relationships, incident response, business continuity. ISO 42001, where present, covers their AI development and deployment practices — how they test their model, how they monitor it, how they handle data used for training.
These are genuine assurances. They tell you that the vendor is not negligent. They tell you the vendor's infrastructure is audited. They tell you the vendor has thought about the risks of running their service.
They do not tell you anything about your system. They do not speak to what you send into the model, what permissions the model's output has in your environment, or whether the controls you have built around the integration are adequate for the risk level of your use case.
The vendor's certification covers the pipe. You own what flows through it.
A vendor SOC 2 tells you the vendor's systems are audited. It says nothing about your system.
The three layers the certification doesn't reach
There are three layers of your AI deployment that exist entirely on your side of the API boundary, and that no vendor certification can speak to.
The first is how you use the model. Your system prompt defines what the model believes about itself — its role, its permissions, its constraints. Your tool definitions tell it what actions it can take and on what resources. Your RAG retrieval pipeline determines what data enters its context window. These are design decisions you made, not the vendor. A compromised or poorly designed system prompt is your attack surface, not the vendor's.
The second is what you expose to the model. Which data sources does your integration pull from? What is the sensitivity classification of that data? Can a carefully constructed user input manipulate the retrieval to surface data the user is not supposed to see? Is PII injected into context in ways that persist across sessions? These questions are about your data architecture, not the vendor's.
The third is what happens to the output. What systems receive and act on the model's response? Does a downstream system execute code the model generates? Can the model's output trigger writes to a database, send emails, or modify access controls? What validation, if any, sits between model output and consequential action? The answer to each of these depends on how you designed your system.
The vendor's model is one component. The system you built around it is the system you are responsible for.
Why this gap is governance-load-bearing
The EU AI Act makes the accountability structure explicit. Article 16 lists the obligations of providers — the companies building AI models and products. Article 26 lists the obligations of deployers — the organisations putting those models and products into use in a specific context. The two sets of obligations are distinct. A provider's conformity assessment does not transfer to the deployer; it satisfies the provider's obligations, not the deployer's.
If you are deploying an AI system that falls into a high-risk category under Annex III — making decisions about credit, employment, education, or safety of persons — you are required to conduct your own due diligence on the system you are deploying, maintain a technical documentation record of your use, implement human oversight, and log incidents. The vendor cannot do this for you. Their certification addresses their system, not yours.
ISO 42001 follows the same logic. The standard requires each organisation to maintain an AI management system — its own, specific to its context, its risk appetite, and its use cases. A supplier's 42001 certification demonstrates that they have such a system. It does not demonstrate that you do.
An auditor reviewing your AI governance posture will not stop at the vendor's SOC 2. They will ask: what is your documented understanding of how this system works, what risks it carries in your specific use case, and who in your organisation has reviewed and accepted those risks? If the answer is “the vendor has a trust portal,” that is not an answer that holds.
What your review needs that the vendor can't provide
Reviewing your system requires documentation of the integration, not the underlying model. The relevant artifact describes how your system is constructed: which components touch the model, what data each component exposes to it, what actions the model can take downstream, and what controls — rate limits, output validation, human review gates, permission boundaries — you have implemented to constrain those actions.
On top of the architecture description, the review requires a threat analysis specific to your deployment. An agentic system with write access to a procurement system has a different attack surface than a summarisation tool operating over archived documents. Generic threat lists are a starting point, not a substitute for reasoning about the specific capabilities and exposures of the system you have actually built.
Finally, the review requires a documented decision. Someone with the authority and the understanding of the analysis has to look at the threat model, the stated controls, the residual risk, and make a determination: this system is cleared to operate, conditionally cleared, or not cleared, for these reasons, with these conditions, subject to re-review when these triggers occur. That determination is the governance artifact. It is what an auditor, a regulator, or an internal AI committee can examine, question, and rely on.
The review is not an overhead. It is the record of the decision that justifies deploying the system.
Vendor due diligence and your review are not substitutes for each other
Nothing here argues that vendor due diligence is unnecessary. It is necessary. Knowing how your AI vendor operates, what they do with your data, and how they maintain their model is a prerequisite for responsible deployment. The vendor's trust portal is a legitimate input to your review.
The point is that it is an input, not the output. The output is an organisation-specific, use-case-specific assessment of the system you are deploying — including the vendor's model as one component in that system, alongside your architecture, your data handling decisions, and your control implementation.
The vendor has reviewed what they built. You are the only one who can review what you built on top of it.