Purpose
Most AI tools are adopted faster than they are assessed. This checklist gives you a structured, pre-adoption review covering the areas that actually create privacy risk: what data goes in, what the vendor does with it, whether access controls carry over from connected systems, and whether a human remains accountable for consequential outputs. Each check below states its priority, the role best placed to own it, and the evidence that proves the control is real — not just claimed.
How to use this checklist
- Run it before any AI tool (a standalone product, a plugin, or a feature added to an existing platform) is approved for use with organisational data.
- Assign one accountable reviewer per tool — usually the privacy lead working with IT/security and the business sponsor requesting the tool.
- Do not accept "the vendor says it's fine" as evidence. Require the specific artefact listed in the Evidence column.
- Where a check cannot be satisfied, record it as an open gap with an owner and a target date — do not silently skip it.
- File the completed checklist with your vendor assessment (see the Vendor Privacy Assessment Template) and your approved-tool register.
Checklist
| # | Check | Priority | Owner role | Evidence that demonstrates the control |
|---|---|---|---|---|
| 1 | Identify what data users will realistically enter into the tool, not just what the intended use case describes | High | Privacy Lead | Sample prompts/inputs reviewed from a pilot group; documented realistic-use assessment |
| 2 | Confirm whether special category or highly sensitive data is plausible as an input | High | Privacy Lead | Data classification note referencing the actual use case |
| 3 | Confirm whether a redaction, masking or minimisation step exists before data reaches the model | Medium | Engineering/IT Lead | Technical documentation of the pre-processing pipeline, or confirmation none exists |
| 4 | Confirm whether user inputs or outputs are used to train or improve the vendor's models, and whether this can be disabled | High | Privacy Lead | Vendor DPA clause or written confirmation of the training opt-out setting, screenshotted or filed |
| 5 | Confirm the retention period for prompts, uploaded files, and generated outputs | High | Privacy Lead | Vendor retention policy or contractual retention clause |
| 6 | Identify the vendor's sub-processors and where processing takes place | High | Privacy Lead | Current sub-processor list published or provided by the vendor |
| 7 | Confirm deletion commitments on contract termination or account closure | Medium | Privacy Lead | Termination/deletion clause in the contract or DPA |
| 8 | Confirm whether the tool inherits existing user permissions from connected systems (e.g. email, file storage, chat) | Critical | IT/Security Lead | Access model documentation; test result showing what the tool can see for a sample account |
| 9 | Review and remediate over-broad sharing in connected systems before granting the tool access | Critical | IT/Security Lead | Sharing/permissions audit report and remediation log, e.g. from the Microsoft 365 Sensitive Data Checklist |
| 10 | Define which decisions may be informed by the tool's output versus which require documented independent human judgement | High | Business Sponsor | Written usage policy naming permitted and prohibited decision types |
| 11 | Establish a process for users to report errors, bias, or inappropriate outputs | Medium | Business Sponsor | Reporting channel documented in the usage policy; sample of at least one logged report and its resolution |
| 12 | Confirm the tool is listed on the approved-tool register with a named owner and review date | High | Privacy Lead | Entry in the approved-tool register |
| 13 | Confirm a data processing agreement is in place if the vendor processes personal data on your behalf | Critical | Legal/Privacy Lead | Signed DPA referencing the AI feature specifically |
| 14 | Confirm cross-border transfer safeguards for any data sent to model providers outside your jurisdiction | High | Legal/Privacy Lead | Named transfer mechanism (e.g. standard contractual clauses) in the contract |
| 15 | Retain this completed assessment as evidence of due diligence prior to go-live | Medium | Privacy Lead | Filed, dated copy of the completed checklist in the assessment/vendor record |
Decision criteria: should this tool be approved?
- Approve: all Critical and High checks are satisfied, or open items have a documented, time-bound remediation plan accepted by the approver.
- Approve with conditions: Critical checks are satisfied, but one or more High/Medium checks are open — approve for a limited pilot group with a fixed re-review date.
- Do not approve: any Critical check fails with no remediation path (e.g. the tool inherits broad, unremediated permissions, or no DPA can be put in place despite personal data being processed).
Worked example (illustrative only)
A 40-person SaaS company evaluates an AI meeting-notes assistant connected to its calendar and video conferencing tool. Check 8 fails initially: the integration requests access to all historical recordings, not just future meetings, and is classified Critical, blocking approval. IT rescopes the integration to future meetings only, confirmed in writing by the vendor, and it is re-tested and passed. Check 4 passes: the vendor's DPA confirms customer data is not used for model training by default, evidenced by the DPA clause and a screenshot of the disabled setting. Outcome: approved with conditions, for a 30-day pilot with the People team, with the reporting channel (Check 11) established before wider rollout. This example is illustrative only, not a benchmark for any real vendor's actual controls.
Ownership and maintenance
- Checklist owner: the privacy lead maintains the master checklist template and ensures a completed copy exists for every AI tool in use.
- Per-tool reviewer: a named individual (often from IT/security, with privacy sign-off) is accountable for each specific tool's completed checklist and for tracking open remediation items.
- Review cadence: re-run the full checklist at least annually for any approved tool, and immediately upon a vendor policy change, a new integration or connector, a reported incident, or a material change in how the tool is used.
- Register: keep the approved-tool register as the single source of truth for what is in use, who owns it, and when it was last reviewed — this feeds into your broader data inventory.
Where this fits in your program
This checklist is the practical companion to the AI Privacy and Data Readiness course, which covers the underlying concepts of automated decision-making, training-data risk and oversight obligations in more depth. For the foundational lawful-basis and data-minimisation concepts referenced throughout, see Global Data Privacy Fundamentals. To embed this checklist into a repeatable intake process, see Practical Privacy Program Implementation. To see how AI tool governance fits into your overall program maturity, take the free assessment.
AI regulation is moving quickly and varies by jurisdiction and sector; treat this checklist as an operational baseline and confirm current, jurisdiction-specific obligations before relying on it for a compliance decision.
Download formats
- CSV worksheet (.csv) — every check with priority, owner role, assigned owner, evidence requested, evidence received, finding, status, action and due date, plus one clearly labelled example row.
- Guidance (Markdown .md) — this page.
- Print / Save as PDF — a clean print view for review meetings.
Nothing here is emailed — each option downloads or prints directly from your browser.