Two milestones should have changed how companies buy AI. First: in December 2023, ISO and IEC published standard 42001 — the first international AI management system standard, auditable and certifiable by an independent third party. Second: IBM's Cost of a Data Breach 2025 report found that 63% of surveyed organizations have no AI governance policy at all, and that 97% of those that suffered an AI-related security incident admitted they lacked proper access controls.
In other words: the standard exists, the framework exists, the ready-made questionnaire exists. What's missing is the question. The person buying AI usually asks "how fast is it?" and "what's the monthly cost?" They rarely ask: "When my employee sends an important document to your system, what exactly does your contract allow you to do with it?"
The result is predictable: contracts without audit trails, data stored in a datacenter chosen by the vendor, all-or-nothing access, and no human approval before sensitive actions — the same risky architecture we already know from shadow AI, only this time it's signed.
Why technical vendor assessment matters
The NIST AI Risk Management Framework (AI RMF 1.0), published in January 2023, organizes risk management into four functions: govern, map, measure, and manage. Within "govern," one category deals exclusively with vendors: GOVERN 6 requires that "policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues."
The NIST playbook spells out what that means: subcategory GOVERN 6.1 calls for "transparency into third-party system functions, including knowledge about training data, training and inference algorithms, and assumptions and limitations." GOVERN 6.2 adds what almost nobody negotiates: a policy for when the vendor's system fails, with redundancy for vital AI systems.
These aren't brochure suggestions; they're risk controls. And the difference between a governed AI vendor and an ungoverned one isn't model intelligence. It's the answer to one question: "If we audit you today, can we know exactly who accessed what, when, and with whose authorization?" If the answer includes "maybe" or "depending on how you configure it," the risk isn't in the AI — it's in the contract.
When data negligence costs more than the subscription
IBM put a price on the absence of governance: the global average cost of a breach in 2025 was US$4.44 million, and where there was heavy AI use outside IT's control, it rose by another US$670,000 — with slower detection, precisely because nobody could say which data had gone where. It isn't the AI's fault; it's the fault of whoever failed to define, in the contract, who accesses what.
One public case makes the point. In 2023, Zoom updated its terms of service with clauses granting it the right to use customer content — audio, video, chat — to "train and tune algorithms and models." The change went unnoticed for months and only became a crisis when someone actually read the document, in August of that year; facing the backlash, the company revised the terms twice in one week, until it stated explicitly that it would not use that content to train models without consent. Nobody was hacked: the risk sat in text customers had accepted without reading.
What has to be in place
Anyone who wants a ready-made roadmap has one: in 2026 the Cloud Security Alliance published the AI Controls Matrix v1.1, with 247 control objectives across 18 security domains — and, alongside it, a questionnaire built specifically to evaluate third-party vendors, plus role-specific auditing guidelines. Below are the controls that most clearly separate a contract from a brochure.
Corporate identity, not personal accounts. Ask: "How does my employee log into your system?" The answer "with email and password" is a problem. The answer "with their corporate network login, federated with the company directory" is a control. If an employee leaves tomorrow, their access must end with them. If the answer is "we'll email you and you cancel the account," the risk lives in "you remembering."
Access role by role, not all-or-nothing. "What's the least access my support team needs?" If the answer is "our tool doesn't work that way — either they have everything or nothing," look for another vendor. Real control means a record of who accesses what, when, and why; if support needs to see one ticket, they see that ticket — not the entire dashboard.
Approval for sensitive actions. Which of these appears in the contract? (a) "Critical actions can be paused and require a person's authorization before continuing"; (b) "The platform is fully automated"; (c) "It depends on how you configure it." Only (a) is acceptable. If it's too sensitive to happen without human approval in your normal process, it should be in AI too.
Queryable audit trail. "If my internal auditor asks for a report of who accessed what in your system between January and March, how long does it take?" If the answer isn't "hours" and is instead "days" or "we don't have that," the contract wasn't read. An audit trail isn't a detail — it's the difference between explaining an incident in a week or in two months.
Data residency and training use
This is the chapter of the contract most people skip. Data residency isn't "we run on secure cloud." It's the answer to: "If my jurisdiction requires personal data to stay in the country, which specific datacenter holds my data, where is the backup, and who holds the keys?"
Training use is even more sensitive — and the Zoom episode shows why. The right question is: "Is my data used to train, refine, or tune any model, yours or a partner's?" The answer "it depends on the plan" is a warning sign; "no, and it's in the contract" is clear; "only what you mark as public" is acceptable, as long as it's written down, with an opt-out, and doesn't hinge on a unilateral terms update. Ask for the data processing addendum and read it before signing: that's where these sentences actually live, not in the sales deck.
The ten questions, listed
-
Identity: Does authentication come from my company's corporate directory or from a personal account IT has to manage manually?
-
Lifecycle: When an employee leaves, how many different tools and accounts need manual intervention to revoke access?
-
Granularity: Does your system let me limit a person's or an agent's access to certain data, functions, or models — or is it all or nothing?
-
Approval: What's the path for a sensitive action to be paused and require human confirmation before continuing? Is that the default or something that has to be enabled?
-
Audit trail: If I request an audit report for a specific period, how long does it take and what level of detail do I get (who, what, when, from where)?
-
Data residency: Which specific datacenter, which jurisdiction, and is it in the contract — or can you change it unilaterally?
-
Backup and recovery: Where are backups stored, how often, and what are the recovery time and maximum acceptable data loss in case of failure?
-
Model training: Is my data — including my customers' data — used to train, refine, or improve any model, yours or a third party's? Does that change by plan?
-
Vendor access: Who on your team can access my raw data? What documentation exists for justification and approval?
-
Independent audit: Do you undergo an annual SOC 2, ISO/IEC 42001, or equivalent audit? Can I see the report or a summary?
Closing the negotiation
These questions turn a contract of "vague security promises" into one of "verifiable rights." Skyller, for example, is built on exactly these four pillars: identity from the company directory, access according to each person's role, human approval before sensitive actions, and a queryable audit trail.
But the lesson isn't "choose Skyller." It's "whatever you choose, demand written answers to these ten questions." A vendor that's slow to respond or says "it depends on how you use it" is signaling they didn't architect for governance — they're selling a black box and hoping you adjust your expectations afterward.
