An AI audit and AI due diligence are separate products, and a file that merges them will answer neither question properly. An AI audit is an evidence review of a system or an organisation's AI management against criteria fixed before the work begins. An independent reviewer reports one finding for each criterion, and a criterion that cannot be evidenced is recorded as unverified. AI due diligence is a pre-purchase check on one supplier, one subscription tier and one stated use. It ends with a recorded approval, a conditional approval or a refusal. The audit asks what a system has done or can be shown to do. Due diligence asks what the firm is about to expose and whether it can defend that decision.
Generic checklists fail at this point. A governance questionnaire can list model cards, bias metrics and human oversight, while the risk that decides the file sits in an abuse log retained for a year, a tenant setting that permits training, or a retrieval tool that returns a client document to a crafted prompt. TestMu AI's guide adopts NIST's definition of an audit as a documented, independent and systematic evidence review measured against criteria, which is a higher test than a supplier questionnaire signed by the person who bought the licence. The IIA's Artificial Intelligence Auditing Framework offers internal auditors a practitioner checklist that the institute presents as a starting point for tailoring. The EDPB-commissioned checklist summarised at aigl.blog starts with a model card and a system map because failures appear where the model meets the workflow and its permissions. Those are audit instruments. They do not tell a managing partner whether the enterprise tier of a chatbot keeps abuse logs for a year.
Solicitor News reported that the SRA's warning notice on misuse of AI, published on 17 August 2026, makes adequate contract, technical and organisational controls a condition for putting client information into AI tools. The notice ties that condition to paragraph 2.1 of the Code of Conduct for Firms, which requires effective governance, systems and controls for risk. UK GDPR Article 28(1) points the same way: a controller may use only a processor that offers sufficient guarantees. The breach can happen when the tool is selected, before any client text is entered. That is why the technical checklist has to name the plan in front of the firm and record the evidence behind each answer.
A safeguard any fee earner can switch off is a preference.
What the two exercises produce
The distinction is easiest to see against the evidence each exercise leaves behind:
- AI audit. Criteria fixed before evidence is gathered; a deployed or specified system; one finding per criterion, including one for evidence that could not be verified; a report to an audit committee, regulator or customer.
- AI due diligence. Supplier terms, data processing agreement and tenant configuration checked before first use; one recorded decision for each tool and plan; conditions attached to approval; a re-check trigger when terms or configuration change.
The failure mode is a document that answers neither. A file that starts with model cards and ends with a bias ratio cannot tell a practice manager whether client text remains in a provider log for a year. It cannot say whether the firm's plan permits training, whether a sub-processor has been added without notice, or whether a certificate covers the feature the firm intends to use. Prompt injection and data leakage are technical properties of the deployment, and they show up in those details. A retrieval tool connected to a document store can return a client file through a crafted request. A tenant setting can send conversations into a training corpus. The checklist has to ask for the setting, the log and the contract clause that govern each one.
Two rules apply across every question. Check the plan the firm is actually buying, because vendors publish different terms for individual, team and enterprise tiers and the public help page usually describes the cheapest plan. Treat a contractual commitment as different from a toggle, because a safeguard any fee earner can switch off is a preference.
The eight questions, answered from the plan
The processing contract comes first because every other answer depends on it. Establish whether the provider acts as a processor and whether a signed data processing agreement covers the exact plan. The agreement should set out documented instructions, confidentiality, security, approval of sub-processors, help with individual requests and breach reporting, support for impact assessments, return or deletion at the end of service, and audit evidence. A privacy policy on a marketing site does none of this.
Training needs a direct answer. Find out whether prompts, uploads and outputs feed the provider's models, whether that is the default, and whether the firm can turn it off at account or tenant level. The SRA notice permits training use only where the firm has expressly agreed and the purpose fits. A commitment at account level that binds every user is the evidence to keep. A default-on switch that any user can reverse is not a control.
Retention has two clocks, and most assessments read only one. A tenant settings call can return something like this:
$ curl -s https://api.vendor.example/v1/account/settings | jq
{
"plan": "enterprise",
"training_opt_out": true,
"conversation_retention_days": 30,
"abuse_log_retention_days": 365,
"processing_region": "eu-west-2"
}
The agreement usually quotes the conversation figure. The log figure keeps client text on the provider's disks for a year, and the deletion route the firm can trigger often clears conversations while leaving those logs in place. Ask for the retention period for each category, and ask which categories the deletion route covers.
Access is where the paper thins. Identify which provider employees may view client data and on what grounds. Get the current sub-processor list, the notice period for additions and any right to object. TrueFoundry's 2026 checklist reports IBM's finding that 97 per cent of organisations that reported AI-related breaches lacked proper access controls. A subcontractor absent from any list the firm has seen cannot count as approved.
Location has moved. The ICO's transfers guidance was rewritten on 15 January 2026. It now frames the test as three questions: does UK GDPR govern the processing, is the firm sending information to an organisation outside the UK, and is the recipient a distinct legal person. If each answer is yes, the transfer is restricted and needs an adequacy finding, a safeguard or an exception. Notes written before that date describe a structure that no longer exists. The regulator has promised further guidance covering transfer risk, the international data transfer agreement and the cloud services, so this is an area to recheck.
Security means reading the scope statement attached to the certificate. The badge proves nothing until the firm checks which parts of the service the certificate covers, and the scope frequently leaves out the features the firm plans to use. Ask how the provider notifies a breach and how quickly. The firm has its own reporting deadline and cannot work to a schedule it never negotiated.
A data protection impact assessment is a screening decision with a documented outcome. The ICO treats novel technology as a screening factor and names AI, machine learning and deep learning among its examples, including AI applied to an existing process. A DPIA becomes necessary when that factor sits alongside another criterion, and the ICO accepts that some uses require one on their own. If the firm decides none is needed, it should record the reasoning, so the negative decision is evidence too.
Privilege is the question with the newest authority. Solicitor News reported that in UK and R (Munir) v Secretary of State for the Home Department 2026 UKUT 00081 (IAC), at paragraph 21, a three-judge panel remarked that putting client documents into an open-source tool puts the document into public view, breaks confidentiality and gives up privilege. It named Microsoft Copilot as a closed-source option for summarising. Read the status of the passage before relying on it. Solicitor News noted that the passage opens with the phrase “we also observe”, sits in a hearing about the conduct of two representatives, and sets out no test for a safe system. A court deciding waiver would not be bound. The usable point is narrower and still serious: the panel expected the regulator to be told and the ICO to be consulted, which is enough for an internal approval file.
Record the answers on one page for each tool and plan: the provider, the tier, the answers with the terms relied on, whether a DPIA was done or why not, the decision, any conditions, the decision-maker, the date and the next review. Date-stamp the terms or keep a copy, because provider terms change without notice. Record refusals as well as approvals, because a file showing a tool was declined is stronger evidence of a working process. An IT or operations lead usually drafts the assessment, and the COLP signs it. That signature is the step most often absent.
Sources
- What Is an AI Audit? Checklist, Standards and Agents | TestMu AI
- AI Auditing Framework | Internal Audit Guidance
- AI Auditing Checklist for AI Auditing
- AI due diligence checklist for UK law firms
- AI Audit Checklist 2026: What to Review and When
Source: AI due diligence checklist for UK law firms, Solicitor News
