By Sapumal Herath · Owner & Blogger, AI Buzz · Last updated: January 25, 2026 · Difficulty: Beginner
AI tools are getting adopted fast—often faster than policies, approvals, and security reviews can keep up.
That creates a common failure pattern: a team starts using a chatbot, “AI assistant,” agent, or AI-powered SaaS tool for productivity… and only later discovers uncomfortable details about data retention, training usage, logging, permissions, or how the tool behaves when it sees untrusted content.
This guide gives you a practical, copy-paste checklist for AI vendor due diligence. It is designed for schools, small businesses, and teams that want to move quickly without taking unnecessary risks.
Note: This article is for educational purposes only. It is not legal, security, or compliance advice. Always follow your organization’s policies and applicable laws—especially when personal, sensitive, or regulated data is involved.
🎯 What “AI vendor due diligence” means (plain English)
AI vendor due diligence means checking whether an AI product is safe and appropriate before you use it with real data, real users, and real workflows.
It is not about “trusting” a vendor or “not trusting” them. It is about making sure you understand the tool’s behavior and controls well enough to answer:
- What data will we share with this tool?
- What does it store, for how long, and who can access it?
- Can it take actions (send emails, update records, trigger tickets, call APIs)?
- What guardrails exist to prevent data leaks and unsafe behavior?
- What happens during an incident—and who is accountable?
⚡ Why AI tools need extra scrutiny vs normal SaaS
Many AI tools behave differently than traditional software. Common differences include:
- Inputs may be logged by default (prompts, files, chat history, tool calls).
- Outputs can be wrong in confident, persuasive ways (hallucinations).
- Untrusted content can influence behavior (for example, instructions hidden in documents or webpages).
- “Agent” features can take actions that have real-world impact if permissions are too broad.
- Model and system behavior can change over time (updates, new policies, new models, new retrieval sources).
Due diligence helps you adopt AI in a way that is fast and responsible.
🧭 Step 1: Classify your use case (quick risk triage)
You can move much faster if you classify the use case first. Here is a simple triage approach:
| Risk Level | Typical Data | Typical Output Impact | Recommended Approach |
|---|---|---|---|
| Low | Public info, non-sensitive drafts | Low impact if wrong | Lightweight checklist + basic controls |
| Medium | Internal docs, customer emails (non-regulated) | Could harm trust or operations | Full checklist + human review + monitoring |
| High | PII, health/financial/student data, legal docs, credentials | High-stakes decisions or irreversible actions | Formal review + strict controls + approvals + auditability |
If you are unsure, treat the use case as one level higher than your first guess.
🗂️ Step 2: Collect the minimum vendor documents
Before you evaluate details, collect the basics. Most serious vendors can provide some combination of:
- Security overview (or security whitepaper)
- Privacy policy and/or data processing terms
- Data retention and deletion details
- Sub-processor list (if applicable)
- Access controls overview (SSO/MFA/RBAC, admin features)
- Audit logging capabilities
- Incident response commitments
- Compliance attestations (if relevant to your context)
If a vendor cannot answer basic questions about data handling and controls, that is your first signal to slow down.
🧱 Step 3: Evaluate the vendor in 4 risk buckets
Most AI vendor evaluations can be organized into four buckets:
- Privacy & data handling: what data is collected, stored, used, and deleted
- Security: how access is controlled, logged, and protected
- AI-specific risks: prompt injection, data leakage, unsafe tool use, overreliance
- Operations & accountability: monitoring, incidents, changes, support, SLAs
The checklist below follows this structure.
✅ AI Vendor Due Diligence Checklist (copy/paste)
Use this as a questionnaire for vendors, or as an internal review form for tools you already use.
🔐 A) Data, privacy, and retention
- What data is collected? Prompts, files, chat history, tool outputs, metadata, user IDs?
- Where is data stored and processed? (Region/locations, high level)
- How long is data retained by default? Can we configure retention?
- Is customer data used to train models? If yes, under what conditions? If no, is that guaranteed contractually?
- Can we delete data? What is the deletion timeline and process?
- Can we export conversation logs? If yes, what format and how granular?
- Does the vendor support data minimization? (Redaction, masking, or safe input handling guidance)
- Does the tool ever show other customers’ data? (Cross-tenant leakage risk question)
- Sub-processors: Who else may process our data?
- Special populations: Are there restrictions or special handling for children/students, patients, or other protected groups (if relevant)?
🛡️ B) Security and access control
- Authentication: Does it support MFA? SSO/SAML? Password policies?
- Authorization: Is there role-based access control (RBAC)? Admin controls?
- Separation: Is customer data logically separated by tenant?
- Encryption: Is data encrypted in transit and at rest (high level)?
- Audit logs: Are admin actions and user actions logged? Can logs be exported?
- Vulnerability handling: How do they patch security issues and notify customers?
- Account lifecycle: Can we disable users quickly? Can we enforce session timeouts?
- Secure defaults: Are risky features off by default?
🧠 C) AI-specific controls (the “AI behavior” questions)
- Hallucinations: What features reduce incorrect answers (citations, retrieval controls, confidence cues, “I don’t know” behavior)?
- Prompt injection exposure: If the system reads documents/webpages, how does it handle untrusted instructions?
- Data leakage controls: Does it prevent returning secrets, personal data, or confidential internal content?
- Tool permissions: If the AI can call tools/APIs, can we enforce least privilege?
- Human approvals: Can we require confirmation before sending messages, updating records, or triggering workflows?
- Policy enforcement: Can we configure allowed/disallowed topics or actions (high level)?
- Logging safety: Are prompts and outputs logged? Can sensitive fields be redacted?
- Isolation: Can the tool separate different projects/teams/contexts to avoid accidental cross-contamination?
- RAG controls: If it uses retrieval, can we control what content is indexed and searchable?
- Explainability for actions: If the AI takes actions, can it show “why” it chose them (at least at a high level)?
🏢 D) Operations, reliability, and accountability
- SLAs/uptime: Is availability documented? What support channels exist?
- Incident response: How are incidents reported? What are notification timelines?
- Change management: How are model updates, feature changes, and policy changes communicated?
- Monitoring: What monitoring or admin dashboards exist for usage, safety, and unusual activity?
- Rate limits/cost controls: Can you cap usage to prevent surprise bills?
- Data ownership: Who owns outputs? Are there restrictions on reuse?
- Exit plan: Can you export data and leave cleanly?
- Internal accountability: Who approves high-risk use cases in your organization?
🚩 Red flags that should slow you down
- The vendor cannot clearly explain retention, deletion, or training usage.
- There is no meaningful admin control, RBAC, or audit logging.
- The tool can take actions (send/update/trigger) with broad permissions and no approval gates.
- The tool encourages users to paste secrets, credentials, or regulated data.
- There is no documented incident process or customer notification practice.
- Security answers are vague (“we take security seriously”) without specifics.
One red flag does not always mean “never use it,” but it often means “limit scope,” “pilot with non-sensitive data,” or “require additional controls.”
🧮 Simple scoring rubric (Green / Yellow / Red)
If you need a quick decision method, score each category from 0–2 and sum it.
- 2 (Green): Clear answers + configurable controls + good defaults
- 1 (Yellow): Partial controls or unclear details; workable with restrictions
- 0 (Red): No clear answers or missing controls; high likelihood of avoidable risk
| Category | Score (0–2) | Notes |
|---|---|---|
| Data & privacy | __ | ________________________________________ |
| Security & access control | __ | ________________________________________ |
| AI-specific controls | __ | ________________________________________ |
| Operations & accountability | __ | ________________________________________ |
Interpretation:
- 7–8: Approve (with standard safeguards)
- 5–6: Approve with restrictions (no sensitive data, limited users, human approvals)
- 0–4: Do not approve for organizational use (or require formal review)
🧩 What “good controls” look like in practice
When teams say “we evaluated the vendor,” what they often mean is: the tool has practical controls that match real workflows. For many organizations, the biggest wins come from these fundamentals:
🔒 Least privilege for tools and data
Start with the smallest possible permissions. Do not give broad access “just in case.” Expand only after you confirm safe behavior and monitoring.
🧑⚖️ Human approval for high-impact actions
If the AI can send messages, change records, issue refunds, or trigger irreversible steps, require a confirmation step for those actions.
🧾 Logging that is useful (and safe)
You need logs to debug and investigate issues. But logs should not become a secondary database of secrets. Aim for configurable retention and redaction where possible.
🧪 Testing before trusting
Before rollout, test common workflows and failure cases. Keep a small regression set so updates do not silently break behavior.
🔁 A clear update and incident routine
Make sure you know who to contact and what to do if the tool produces harmful output, leaks data, or takes unintended actions.
📝 Copy/paste: “AI Tool Approval” decision statement
If you need a simple internal record, here is a short approval statement you can reuse:
Tool name: __________________________
Approved scope: __________________________
Allowed data: public / internal / restricted (circle one)
Prohibited data: credentials, regulated data, sensitive personal data (and other: ____________)
Allowed actions: draft-only / read-only / tool actions with approval (circle one)
Required controls: MFA/SSO, RBAC, audit logs, retention limit, human approval, monitoring
Review cadence: quarterly / semiannual / annual
Owner: __________________________
📚 Further reading (optional reference frameworks)
🏁 Conclusion
AI tools can create real productivity gains, but adoption without due diligence often turns into avoidable privacy, security, and operational risk.
Use the checklist in this guide to make decisions faster and more consistently. Start small, limit sensitive data, require approvals for high-impact actions, and treat AI adoption as an ongoing process—not a one-time purchase.
Leave a Reply