Before You Buy Any AI Tool — An Internal Audit Checklist

The Problem With Most AI Procurement Checklists

Search "AI procurement checklist" and you will find a hundred templates that all start at the same place: vendor evaluation. Security questionnaires, SOC 2 reports, API documentation, pricing tiers. All vendor-facing. All external.

Here is what none of them ask: Are you ready to buy AI at all?

Before you send a single RFI, there is work that happens inside your own four walls. Skipping it is how organisations end up with tools they cannot deploy, data they cannot explain, and compliance gaps they did not know they had until an auditor found them.

This internal audit is grounded in two clauses of ISO 42001:2023 that most procurement guides ignore: Clause 4 (Context of the Organisation) and Clause 6 (Planning). Clause 4 requires understanding your organisation's context, the needs of interested parties, and the boundaries of your AI management system before you build or buy anything. Clause 6 requires assessing risks and setting objectives before you act. Together they demand an internal readiness assessment before any vendor conversation begins.

This article walks through that assessment: six steps, specific questions for each, and a one-page template you can take into your next procurement meeting.

The 6-Step Internal AI Audit

Work through these in order. If you cannot answer a question confidently, stop there. That is your first gap.

Step 1: Map Your Data Classification Landscape

Before you buy an AI tool, you need to know what data it will actually touch. Not what data you think it will touch.

Most organisations have a data classification policy somewhere. Few have actually mapped their data against it. ISO 42001 Clause 4.1 asks you to understand "external and internal issues that are relevant to its purpose." Your data landscape is the single biggest internal issue.

Ask yourself:

• Do we have an up-to-date data inventory that classifies every dataset by sensitivity level?
• Which business processes touch personally identifiable information (PII)?
• If an AI vendor trains on our data, what classification levels would that cross?
• Can we isolate the data the AI needs from the data it should never see?

If your answer to question one is "we have a policy but no inventory," you are not ready to buy AI. Build the inventory first. The NIST AI Risk Management Framework calls this "contextual knowledge of the AI system's operating environment." You cannot assess risk in an environment you have not mapped.

Step 2: Discover Your Shadow AI Footprint

Shadow AI is any AI tool your employees are using without IT or procurement knowing. ChatGPT free tier, Claude for document summarisation, Notion AI, Midjourney, GitHub Copilot on personal accounts. A 2024 Cyberhaven survey found that 11% of data employees paste into AI tools is confidential. This is already happening in your organisation.

ISO 42001 Clause 4.2 requires you to understand "the needs and expectations of interested parties." Your employees have already voted with their feet. Before you procure anything officially, know what is already running.

Ask yourself:

• Have we run a network-level audit of AI tool domains accessed from corporate devices?
• What AI features are already embedded in tools we licensed (Salesforce Einstein, Microsoft Copilot)?
• Are employees using personal accounts for AI tools that handle work data?
• Has anyone surveyed teams to ask what AI tools they use daily?

Step 3: Identify Which Business Processes Touch Personal Information

For every AI use case you are considering, trace the data flow from source to output. Not the idealised diagram. The actual flow, including the parts nobody documented.

ISO 42001 Clause 6.1 requires you to "determine the risks and opportunities that need to be addressed." Data touching personal information is the highest-priority risk category.

Ask yourself:

• Which specific business processes would this AI tool interact with?
• Do any of those processes handle customer data, employee data, or financial records?
• Where does the data live (on-premises, cloud, third-party SaaS)?
• Would the AI vendor's processing cross any data sovereignty boundaries?
• Can we limit the AI's access to only the data it needs?

If you are buying a customer support AI and your support tickets contain customer names and order histories, that is PII. If the vendor processes data in a different jurisdiction, that is a cross-border transfer. These are not vendor questions. These are questions about your own processes.

Step 4: Determine Who Owns the AI Procurement Decision

AI procurement sits in a weird organisational gap. IT owns the infrastructure. Legal owns the compliance risk. The business unit owns the use case. Procurement owns the contract. Nobody owns the whole decision.

ISO 42001 Clause 4.3 requires you to define the scope and boundaries of your AI management system. If nobody has defined who decides, you do not have a scope.

Ask yourself:

• Who has authority to approve an AI purchase, and is that documented?
• Does the approval chain include IT security, legal, privacy, and the business owner?
• Who owns the AI risk register for this use case?
• What is the escalation path if the AI behaves unexpectedly in production?

We have seen organisations where the marketing team bought an AI content tool on a credit card, IT discovered it six months later, and legal had no idea. The tool was fine. The process was a compliance failure. Define ownership before you define requirements.

Step 5: Audit Your Existing Policies Against Third-Party AI Tools

Most organisations have an IT acceptable use policy, a data protection policy, and a vendor risk management framework. Few have updated any of them to account for AI. An AI tool is not just another SaaS vendor. It processes data differently, introduces new failure modes, and creates outputs your existing policies may not cover.

ISO 42001 Clause 6.2 requires you to establish "AI objectives at relevant functions and levels." Your policies are the operational expression of those objectives. If your policies do not mention AI, you have not set objectives.

Ask yourself:

• Does our acceptable use policy mention AI tools specifically, or only "software" generically?
• Does our vendor risk management process include AI-specific assessment criteria?
• Do our data processing agreements cover sub-processing by AI models?
• Do we have a policy on AI-generated content and how it is identified?
• Does our incident response plan cover AI-specific failures (hallucination, bias, model drift)?

If you answered no to more than two of these, your existing policies do not cover what you are about to buy. Update the policies before you sign the contract. A vendor will not point out that your internal policies are not ready.

Step 6: Assess Organisational Readiness and Capability

The final step asks whether your organisation can actually operationalise the AI tool. Can you deploy it securely, monitor it effectively, and respond when it goes wrong?

ISO 42001 Clause 7 covers competence, awareness, and communication. It is not enough to have a policy. You need people who understand it and can act on it.

Ask yourself:

• Do we have staff with the skills to evaluate AI vendor claims critically?
• Can we integrate the tool into our existing identity and access management framework?
• Do we have monitoring capability for AI outputs, or will it run unsupervised?
• Who will own ongoing compliance monitoring after deployment?
• Do we have budget for ongoing AI governance, not just the initial purchase?

Organisational readiness is a spectrum, not a checkbox. Match the tool to your actual capability, not your aspirational one.

How to Discover Shadow AI in Practice

Shadow AI discovery deserves attention because it is the step most organisations skip.

Network-level discovery. Your firewall or secure web gateway already has the data. Generate a report of all domains accessed by corporate devices in the last 90 days and cross-reference against known AI tool domains.

Browser extension audit. Many AI tools ship as browser extensions with access to everything the user sees. Your endpoint management tool should report installed extensions across your fleet.

Expense audit. Check corporate credit card statements and SaaS management platforms for AI subscriptions. Many fly under procurement thresholds but still process company data.

Once you have the list, do not ban everything immediately. That drives usage underground. Publish the list internally: approved, under review, and blocked, with a clear reason for each.

Common Gaps We See

After running internal audits with organisations preparing for AI procurement, a few patterns repeat:

• The data inventory gap. Organisations know they have sensitive data but cannot tell you where it lives or whether an AI tool would touch it.
• The ownership vacuum. IT thinks legal owns AI risk. Legal thinks IT owns AI risk. Meanwhile, a business unit manager is three clicks from deploying AI to production.
• The policy lag. Acceptable use policies from 2019 do not mention AI. Vendor risk assessments do not ask about model training data. DPAs do not cover sub-processing by foundation models.
• The capability mismatch. Organisations buy tools requiring ML ops expertise when their most technical staff member writes SQL queries.
• The shadow AI blind spot. One organisation we worked with discovered 14 different AI tools in active use across 200 employees. IT had approved two of them.

A Template for Your Internal Audit

Bring this one-page template to your next AI procurement discussion. Do not talk to a single vendor until every box has a confident answer.

Internal AI Readiness Assessment

1. Data Classification — Do we have a current data inventory mapped against our classification policy? Can we isolate what the AI needs from what it must never see?
2. Shadow AI — Have we run network, browser, and expense audits? Do we have a published list of approved, under-review, and blocked tools?
3. PII Touchpoints — Which in-scope business processes touch personal information? Where does that data live? Would processing cross jurisdictional boundaries?
4. Decision Ownership — Who approves AI purchases? Is the approval chain documented? Does it include IT, legal, privacy, and the business owner?
5. Policy Gaps — Do our existing policies cover AI? What updates are needed before procurement begins?
6. Organisational Readiness — Do we have the skills, infrastructure, and budget to operate this tool safely? Who owns ongoing compliance monitoring?

This template is a starting point, not a replacement for a full ISO 42001 readiness assessment. But if you work through these six steps honestly, you will be further ahead than most organisations that jump straight to vendor demos.

Why This Matters Now

Gartner predicts that by 2027, more than 50% of organisations will have formal AI procurement policies, up from less than 10% in 2024. The organisations that build internal readiness now will have leverage in vendor negotiations. They will know what data to protect and what questions to ask. Everyone else will be evaluating vendors against criteria they have not yet defined.

The ISO 42001 framework gives you the structure. Clause 4 (Context) ensures you understand your starting point. Clause 6 (Planning) ensures you have objectives and risk treatments before you commit. Together they form the internal readiness assessment that every AI procurement checklist should start with, and almost none do.

Do the internal work first. The vendor conversations will be shorter when you know exactly what you need and why.

Written by David Swan, reviewed and fact-checked against primary regulatory sources including ISO 42001:2023 and the NIST AI Risk Management Framework. AI-assisted but human-directed.