Nullgen AI BlockerBlogEnterprise
How to evaluate an AI tool before you approve it: a vendor review checklist for security and IT teams
Requiring IT approval is the most common AI governance control there is. Here is a review that scales with the data at stake: five areas, fifteen questions, the red flags that end a review, and how to turn the verdict into something enforced.
The Nullgen team
14 min read
Every organization that has thought about AI for more than a week has an approval queue. A sales lead wants a meeting-notes tool, engineering wants a coding assistant, marketing has already signed up for three things. Someone in IT or security is supposed to say yes or no — and usually has no written criteria for either.
This guide is that criteria. It is for the people who hold the queue: CISOs, IT directors, procurement, and the legal and privacy partners they pull in. It assumes you already have, or are writing, a policy with an Approved tier — the one described in our acceptable use policy guide — and it answers the question that guide leaves open: what does a tool have to show you to earn that tier?
Approval is the control you already rely on
In the 2026 Cost of a Data Breach study from IBM and the Ponemon Institute, the most common AI governance control among organizations that had any was requiring IT approval before an AI tool is deployed — 38% of them, down from 45% the year before. Most had nothing: 68% of breached organizations lacked AI governance altogether, and shadow AI showed up in 43% of the breaches studied. Approval, in other words, is the control organizations reach for first, and it is slipping.
38%
rely on IT approval as their main AI governance control
IBM, 2026
68%
of breached organizations had no AI governance at all
IBM, 2026
43%
of breaches involved shadow AI
IBM, 2026
It slips for a predictable reason. An approval process without criteria fails in one of two directions. Either it becomes a rubber stamp — the reviewer has nothing to check against, so the answer is whatever the requester argued — or it becomes a six-week bottleneck, and people route around it. Cyberhaven puts roughly a third of workplace AI use on personal accounts already; every week a request sits unanswered adds to that number. Criteria fix both failures at once: the reviewer knows what to ask, the requester knows what to bring, and the answer arrives in days. (If you are still mapping how much unsanctioned use you have, start with our shadow AI guide.)
Decide what data the tool would touch first
Before you read a single security page, settle one question with the requester: which of your data classes would go into this tool? The acceptable use policy guide uses four — Public, Internal, Confidential, Regulated. The answer sets the review, because a tool that will only ever rephrase published marketing copy does not need the same scrutiny as one that will read customer contracts.
Review effort
- Public data only
- About fifteen minutes. Read the privacy and terms pages; confirm the tool is who it says it is.
- Internal data
- An hour or two. The data-handling and identity questions below, in writing from the vendor.
- Confidential data
- The full checklist, a signed data-processing agreement, and the vendor’s own security evidence.
Must have
- Public data only
- Published data terms; a legitimate company behind the product.
- Internal data
- No training on your data, written retention terms, single sign-on or at least company-managed accounts.
- Confidential data
- Everything in Internal, plus a DPA, deletion on request, a sub-processor list, audit logs, and admin controls.
Can skip
- Public data only
- Contract negotiation, security questionnaires, legal review.
- Internal data
- Pen-test evidence and residency questions, unless your industry requires them.
- Confidential data
- Nothing. If a question cannot be answered, the tool does not reach this tier.
Likely outcome
- Public data only
- Limited tier: usable for Public data by anyone.
- Internal data
- Approved for Internal data, usually the paid or team edition rather than the free one.
- Confidential data
- Approved for named teams under the enterprise edition, or Blocked.
| Public data only | Internal data | Confidential data | |
|---|---|---|---|
| Review effort | About fifteen minutes. Read the privacy and terms pages; confirm the tool is who it says it is. | An hour or two. The data-handling and identity questions below, in writing from the vendor. | The full checklist, a signed data-processing agreement, and the vendor’s own security evidence. |
| Must have | Published data terms; a legitimate company behind the product. | No training on your data, written retention terms, single sign-on or at least company-managed accounts. | Everything in Internal, plus a DPA, deletion on request, a sub-processor list, audit logs, and admin controls. |
| Can skip | Contract negotiation, security questionnaires, legal review. | Pen-test evidence and residency questions, unless your industry requires them. | Nothing. If a question cannot be answered, the tool does not reach this tier. |
| Likely outcome | Limited tier: usable for Public data by anyone. | Approved for Internal data, usually the paid or team edition rather than the free one. | Approved for named teams under the enterprise edition, or Blocked. |
Two practical effects follow. Most requests become fast, because most requests are for Public or Internal work — a quick review that ends in “Limited, Public data only” is a yes people can live with. And the expensive review is reserved for tools that will actually hold something you cannot afford to lose, which is where your reviewers’ time belongs.
The review in five areas
The full review covers five areas. For each, the question to answer is not “does the vendor sound responsible?” but “is this written down somewhere I can hold them to?” A marketing page is a claim; a terms document, a data-processing agreement, or a signed order form is a commitment.
Data handling
Where your prompts, files, and outputs go, how long they stay, whether they train anything, and whether you can make them disappear.
Identity and access
Whether your people reach the tool through your identity provider, whether admins can see and remove them, and what stops a personal account from doing the same work.
Security
The vendor’s own evidence — an independent audit report, recent penetration testing, a sub-processor list, and where the data physically lives.
Legal
The paper that makes the rest enforceable: a data-processing agreement, who owns outputs, what the vendor indemnifies, and how you learn when terms change.
Operations
What you can see and do after approval: audit logs, export, incident notification, and a clean way to leave.
The fifteen questions below are the review. Send them to the vendor in writing before the call; a good vendor answers most of them with links to documents they already publish, and the ones that need a meeting tell you something too.
Training — Is any of our data (prompts, uploads, outputs, feedback) used to train or improve your models, or any third party’s? Is that a contractual commitment or a setting we have to switch off?
Retention — How long do you keep prompts and outputs, where, and is there a zero- or short-retention option? Does retention differ for abuse monitoring?
Deletion — Can we delete a user’s history, a workspace, or everything, on demand? How long until it is gone from backups, and will you confirm in writing?
Single sign-on — Do you support SAML or OIDC with our identity provider, and SCIM or equivalent so accounts are created and removed automatically?
Admin controls — Can our administrators see every user, every connected integration, and every sharing setting, and turn off the ones we have not approved (public share links, third-party plugins, connectors to our file stores)?
Personal accounts — Can you force every login from our domain into the managed workspace, so a personal free-tier account with a work email is not possible?
Audit evidence — Do you have a current independent security audit report you can share under NDA, and recent third-party penetration test results? What were the open findings?
Sub-processors — Which companies process our data on your behalf (including the model providers behind the product), and how do you notify us when the list changes?
Residency — Where is our data stored and processed? Can we choose a region, and which laws govern access requests to it?
Data-processing agreement — Will you sign a DPA (and, where relevant, standard contractual clauses) that reflects the answers above, including the training and retention commitments?
Outputs — Who owns the outputs our people generate, and do you indemnify us if an output infringes a third party’s rights?
Changes — How much notice do we get before terms, privacy practices, or the sub-processor list change, and can we exit without penalty if we object?
Audit logs — Can our administrators see who used the tool, when, and with which integrations, and export that record?
Incidents — How quickly do you notify us of a security incident affecting our data, and is that in the contract rather than a policy page?
Offboarding — When we leave, can we export our data in a usable format, and how do you confirm the rest has been destroyed?
If your compliance function wants the review tied to a recognized framework, NIST’s AI Risk Management Framework gives you the govern-map-measure-manage vocabulary to file it under, and the OWASP Top 10 for LLM Applications is a good source for the technical questions — sensitive information disclosure and supply-chain risk map directly onto the data-handling and sub-processor rows above. Neither replaces the fifteen questions; they give you somewhere to hang the answers.
Same product, different tier
The most common surprise in a first round of reviews is that the same brand lands in two tiers. The consumer edition of a chatbot and its enterprise edition are different products on paper: different terms, different retention, different training defaults, different admin controls. OpenAI, for example, publishes separate enterprise privacy commitments — business data not used for training by default, admin-controlled retention, SSO — that simply do not apply to a free account someone opened with a work email. Most major vendors follow the same pattern. Review the edition, not the logo.
That is also why the Approved tier is usually a paid tier. The free edition of almost any AI tool is the one with consumer terms, and the consumer terms are the ones that put your data at risk — our guide to ChatGPT data leaks walks through where pasted company data actually goes under them. Approving the enterprise edition and blocking the consumer edition of the same product is not inconsistent. It is the whole point.
Review the edition, not the logo. The contract is what protects your data, and the free tier does not come with one.
Red flags that end the review
Most reviews end in a tier, not a rejection. A few answers, though, should stop the review on the spot — not because the vendor is necessarily careless, but because without them nothing else you learn can be enforced.
No written retention terms. If the vendor cannot tell you, in a document, how long prompts and outputs are kept, you cannot tell your own customers or regulators either.
Training opt-out is a setting, not a commitment. A toggle each user has to find is a default of yes. For anything above Public data, training exclusion needs to be contractual and workspace-wide.
No data-processing agreement at any price. A vendor that will not sign a DPA is telling you they do not intend to be your processor. Take them at their word and keep Confidential data out.
No admin visibility. If you cannot see who is using the tool or remove them, you cannot offboard a leaver, investigate an incident, or prove anything in an audit.
A red flag is not a permanent verdict. Vendors fix these things, often quickly when a customer asks. Park the tool in Blocked, tell the requester why, and offer to re-review when the vendor can answer.
Turn the verdict into enforcement
A review only matters if the outcome changes what happens on the device. Approved tools should be reachable by the people who need them, through the managed edition you reviewed; everything else — including the consumer edition of the tool you just approved — should be blocked where the data would actually leave: the prompt box. A spreadsheet of verdicts enforces nothing.
Nullgen is built for exactly this shape of policy. On managed browsers it recognizes AI prompt fields on any site, including the ones you have never reviewed, and stops typing and pasting into them while the rest of the page keeps working. Your approved tools are allowed by policy, per tool and per group; on managed phones the same tools are allowed and everything else is blocked at the network level. When someone hits a block they can ask for access, and the request reaches a named approver with the site and the duration — never what they were about to type.
Nullgen Pro Enterprise maps onto the review outcome directly:
Allow and deny policies per AI tool, chosen from a maintained catalog of known AI products, for specific users or everyone — the Approved list, made operational.
Zero-touch force-install through Intune, Jamf, Google Workspace, or Group Policy, pinned so the person at the keyboard cannot remove it — the Blocked tier, delivered through the tools you already run.
Access requests routed to named approvers with temporary or permanent grants — the exception path, with a record of every decision.
One dashboard of users, devices, requests, and policies — the evidence your next review cycle and your auditors will ask for.
One detail matters for the privacy review of Nullgen itself: detection runs on the device and prompt text is never collected. The control that enforces your approvals does not read what your people type, which is the first question your own reviewers should ask of it.
Re-review on a cadence
An approval is a snapshot. Vendors change terms, add integrations, swap model providers, and get acquired; the tool you approved in March is not necessarily the tool your people are using in September. Build the re-review into the process rather than waiting for a reason.
Quarterly for Approved tools. Re-read the terms and the sub-processor list, confirm SSO and admin controls still work the way they did, and check that the training commitment is still in the contract you hold.
Watch for change notices. Make one person responsible for the vendor emails nobody reads. A change to retention or training defaults is a re-review trigger, not a footnote.
Read the access requests. A steady stream of requests for one tool means your Approved list is missing something people need. Review it properly and the requests stop; ignore it and the workarounds start.
Retire what nobody uses. Every Approved tool is a standing data flow. If the audit logs show no one has used one in a quarter, remove the allow rule and the integration before it becomes the account nobody remembers.
Key takeaways
Requiring approval is already your main AI control. Without written criteria it becomes a rubber stamp or a bottleneck — and both push people to personal accounts.
Scope the review by the data class the tool would touch. Public-only tools get fifteen minutes; Confidential ones get the full checklist and a DPA.
Review the edition, not the logo. The enterprise edition and the free edition of the same product belong in different tiers because only one comes with a contract.
Four answers end a review: no written retention terms, training opt-out as a user setting, no DPA, no admin visibility.
Enforce the verdict at the prompt: approved tools allowed by policy, everything else blocked on managed browsers and devices, with a fast exception path — then re-review quarterly.
Frequently asked questions
Do we need a data-processing agreement for a tool that only touches Public data?
Usually not. If nothing that identifies a person or belongs to a customer goes in, there is little for a DPA to govern, and demanding one slows down the yes that keeps people inside the policy. The moment the tool is approved for Internal or Confidential data, that changes — the DPA is what makes the training and retention answers enforceable.
Should we require an independent audit report from every AI vendor?
Require it for the Confidential tier and ask for it everywhere else. A current audit report and a recent penetration test are the fastest way to check that a vendor’s security claims have been examined by someone other than their marketing team. For a Public-data tool, the absence of one is not disqualifying; for a tool that will hold customer contracts, it is.
How long should an AI tool review take?
Fifteen minutes for a Public-data tool, a day or two for Internal, and one to three weeks for Confidential — most of which is waiting on the vendor and your legal team, not reviewing. Publish those targets to requesters. A review with a known end date is one people wait for; an open-ended one is one they route around.
Do AI features inside tools we already license count as new tools?
Yes, as a review of the contract that covers them. If a copilot feature inherits the enterprise agreement you already hold — same training exclusion, same retention, same admin controls — it can inherit the Approved tier. If it was switched on by the vendor with its own terms, treat it as a new tool until someone has read them. Browser-built-in assistants are the same question in a different place.
What about tools people are already using without approval?
Review them first — they are the ones with your data in them. Run the fast review, land each one in a tier, and move people from personal accounts to the managed edition where there is one. Then block the prompt on everything that did not make the list, so the inventory stops growing while you work through it.
Sources
Enforce the approvals you just made
Install the free extension on your own laptop to see the block. Nullgen Pro Enterprise allows the tools you have approved, blocks the rest at the prompt across managed browsers and devices, and routes every exception to a named approver.