How to vet an AI tool before you roll it out to your team
The moment an AI tool goes from 'one person trying it out' to 'the whole team relies on it', the risk profile changes completely: more data, more people, more assumption that someone already checked it. Most teams either skip this step entirely (shadow AI) or turn it into a weeks-long process that people route around. Here is a middle path that is fast enough to actually get used.
Step 1: name the data before anything else
Before checking a single vendor policy, get specific about what will actually go through the tool: customer PII, health information, source code, financial records, or just general internal drafting. The data type determines which questions matter. PHI needs a HIPAA BAA question, EU personal data needs a GDPR DPA question, and proprietary code needs a training-and-retention question. Skipping this step is how teams end up checking the wrong things.
Step 2: check the sourced facts, not the reputation
Check the facts that actually matter, and get them from a source. Training posture: does it train on inputs, and does that depend on plan tier? HIPAA BAA: required only if PHI is in scope, but confirm either way. GDPR DPA: required if EU or UK personal data is in scope. SOC 2 or ISO 27001: a baseline security hygiene signal, not proof of the above. Data residency and subprocessors: relevant if you have jurisdiction-specific requirements. Get each answer from the vendor's own trust center, DPA or enterprise-privacy page, not from the product's general reputation or a colleague's impression of it. If a fact isn't documented anywhere public, ask the vendor directly and keep the written answer as your source. ModelCharter's AI Tool Risk Directory has already done this lookup for the most common AI tools, so check a tool's profile first before starting a manual review; it may save the whole step.
Step 3: pin the tier, not just the tool
Almost every finding from Step 2 applies to a specific plan tier, not the product as a whole. Decide and document which tier is approved ('Business or Enterprise only'), and check whether anyone already using the tool is on a different one: a free or personal account someone signed up with before the review even started.
Step 4: write the verdict down
A one-paragraph record, covering what was checked, what the source said, which tier it applies to, and the resulting verdict (approve, conditional, reject, or needs more info), is what turns a one-time conversation into something an auditor, a customer security questionnaire, or your own future self can actually rely on. Skipping documentation is the most common reason the same tool gets re-discovered and re-debated six months later.
Step 5: set a recheck trigger
Set a trigger for rechecking, whichever comes first: a fixed cadence, where six or twelve months is typical for a full re-review; any vendor terms-of-service or privacy-policy update; any publicly disclosed security incident; or a plan-tier change for your team, whether upgrading, downgrading, or adding new seats. None of this needs to take weeks. For a vendor with a public trust center and documented DPA, the whole process, from 'someone wants to use this' to a written, sourced verdict, realistically takes fifteen to thirty minutes once you know what to check. A free, structured template at /ai-vendor-risk-assessment walks through exactly these steps, and you can check whether the tool your team wants is already vetted in ModelCharter's AI Tool Risk Directory.