AI supplier due-diligence checklist for small firms

An AI supplier due-diligence checklist helps a small business look beyond an impressive demonstration and decide whether a product or provider is suitable for a real job.

The aim is not to demand a perfect system or send every supplier a hundred-question form. It is to ask proportionate questions about the result you need, the information the system will handle, the actions it can take and the support you will receive after launch.

A low-risk writing tool used with public information needs a lighter review than an agent connected to customer records and email. The questions should become more detailed as the possible consequence increases.

Use this checklist before a paid pilot or contract. Record the supplier’s answers, evidence, unresolved points and the person in your business who accepts the remaining risk.

Start with the job, not the product

Write a one-sentence problem statement before comparing suppliers:

We need to reduce the time spent preparing weekly campaign reports while keeping a marketing manager responsible for the figures and commentary.

That is more useful than “we need an AI platform”. It gives you something to test and makes it easier to reject capabilities you do not need.

The UK Government’s guidelines for AI procurement are written for the public sector, but two principles translate well to a small business: focus on the challenge rather than a predetermined solution, and treat lifecycle testing as an ongoing activity rather than a one-off buying decision.

Define these five points before speaking to a supplier:

1. the exact job and the people affected;
2. the current time, cost, error or service baseline;
3. the information the workflow genuinely needs;
4. the decisions and actions that must remain with a person;
5. the evidence that would support a scale, change or stop decision.

Our AI pilot guide provides a four-week structure for testing those assumptions without committing to a broad rollout.

1. Business fit and scope

Ask the supplier to show how the proposed system completes your defined job from input to final outcome. A generic demonstration can prove that a feature exists without proving that it fits your data, team or customer journey.

Questions to ask:

• Which part of our current process will change?
• What must our team prepare, review or maintain?
• Which cases are outside the system’s intended use?
• What happens when the input is incomplete, unusual or ambiguous?
• Which result should improve, and how will we measure it against the current baseline?
• Could a simpler rule, template or ordinary automation solve the same problem?

Write exclusions as clearly as requirements. If the system may prepare a customer reply but may not send it, that boundary should appear in the design, access settings, tests and contract rather than only in a meeting note.

2. Data use, location and retention

Draw a simple information flow from the first input to the final output. Include the supplier, model provider, integration services, storage, support access and any other subprocessors.

Ask:

• What business and personal information will enter the system?
• Where is it stored and processed?
• How long are prompts, files, outputs, logs and backups retained?
• Is our information used to train or improve any model or service?
• Can training or product-improvement use be disabled, and how is that setting enforced?
• Who can access the information for support, safety or maintenance?
• Which subprocessors receive it, and how will we be told when that list changes?
• How can we retrieve and delete our information at the end of the service?

Do not accept “we do not train on your data” as a complete data answer. It says nothing about retention, human access, other product-improvement uses, logs, backups, location or deletion.

The Information Commissioner’s Office says organisations should consider the whole AI supply chain, document the roles of controllers and processors, undertake due diligence before procurement and put relevant processing responsibilities in written contracts. Its current AI contracts and third-parties guidance is under review following the Data (Use and Access) Act, so use it as a starting point and check the latest position for your circumstances.

If the workflow handles personal or sensitive information, involve whoever is responsible for data protection in your business. This checklist is not a substitute for a data protection impact assessment or legal advice where either is needed.

3. Accounts, permissions and integrations

List every system the product can read from or write to. Check the proposed permissions against the specific job, not against everything the platform could eventually do.

Ask:

• Does the product support individual accounts, suitable sign-in controls and role-based access?
• Can we give it access to one mailbox, folder, project or record set rather than the whole account?
• Are read, create, edit, send, publish and delete permissions separate?
• Can consequential actions require approval in the system that performs the action?
• Can access be revoked quickly without relying on the supplier?
• What activity is logged, and can our business inspect or export those logs?
• How are integration credentials stored, rotated and removed?

A written instruction telling an AI not to use unnecessary access is not the same as preventing that access. Apply least privilege in the connected accounts and tools. Use the AI agent permissions checklist to record the identities, data and actions involved.

4. The complete supplier chain

An AI product may combine a user interface, a hosted model, external search, document storage, automation software and several APIs. A change or incident in any important dependency can affect the service you receive.

Ask the supplier to identify:

• the main models, hosting services and external components used for your workflow;
• which parts it controls directly and which depend on another provider;
• how third-party components are assessed before use;
• how material dependency or model changes are tested and communicated;
• what happens if a provider removes a feature, changes a limit or becomes unavailable;
• whether a manual process or alternative service can keep critical work moving.

The National Cyber Security Centre’s guidelines for secure AI system development recommend assessing and monitoring the AI supply chain across the system lifecycle. They also frame security across design, development, deployment, operation and maintenance, rather than as a check performed only at launch.

You do not need every low-level technical detail. You do need enough transparency to understand your important dependencies and the business consequence if one fails.

5. Performance, limitations and evidence

Agree what acceptable performance means for your use case before the pilot begins. “High accuracy” is not a usable acceptance criterion.

Ask:

• What evidence supports the supplier’s performance claims?
• Does the evidence resemble our users, information and operating conditions?
• What types of error are known or expected?
• How does the system show uncertainty or the source of an answer?
• Which languages, formats or edge cases perform less reliably?
• Can we test the product with representative and deliberately awkward cases?
• How will we detect a drop in quality after a model, prompt or data change?

For generated content, sample quality, factual support, tone and prohibited claims separately. For extraction or classification, define a labelled test set and measure the mistakes that matter. For an agent, assess both its answer and any tool or action it proposes.

NIST’s Generative AI Profile treats risk management as a cycle of governing, mapping, measuring and managing. That is a useful buying discipline: understand the context, test the system, act on the findings and repeat when the system changes.

6. Security and misuse

Ask the supplier for a clear description of its security responsibilities and yours. Look for practical controls, testing and incident handling rather than a broad claim that the AI is safe.

Questions should cover:

• how customer accounts and stored information are protected;
• how vulnerabilities can be reported and how updates are handled;
• how the system is tested against malicious or misleading inputs;
• which controls restrict data access and important actions outside the model;
• how uploaded documents, retrieved webpages and tool outputs are treated;
• how abuse, unusual access and unexpected tool use are detected;
• how quickly the supplier will notify you about a relevant incident.

If the system reads emails, documents, websites or customer submissions, include indirect prompt injection in the discussion. Our prompt-injection guide explains why untrusted content should not be allowed to reach powerful actions without separate controls.

Request evidence proportionate to the risk. That might include security documentation, current independent assurance, a summary of relevant test results, incident-response commitments or a technical review by somebody qualified to assess the proposed setup. A certificate alone does not prove that your particular workflow is safe.

7. Human review and accountability

Define who makes the decision when the AI system prepares, recommends or acts. “Human in the loop” is too vague unless the person has the right information, authority and time to intervene.

Ask:

• Which outputs and actions require review?
• What will the reviewer see: source material, proposed action, recipient, changed fields and uncertainty?
• Can the reviewer edit, reject, escalate or request more evidence?
• Which actions are never allowed to run automatically?
• Who investigates a complaint or harmful result?
• Who in our business owns the workflow after handover?
• What manual route remains available when the system is paused?

Check that the interface makes review meaningful. A confirmation button shown after the important information has been hidden or reduced to a vague summary transfers the click, not the judgement.

8. Testing, change and ongoing operation

The system you buy will not remain fixed. Models, integrations, prices, limits, data and business processes change.

Ask the supplier:

• What will be tested before launch, and can we see the acceptance results?
• Which changes trigger regression testing or renewed approval?
• How much notice will we receive about material changes?
• Can we delay or opt out of a change when it affects our controls?
• What quality, security, cost and usage signals are monitored?
• What support response applies when the workflow fails?
• How can we pause it, roll it back and recover?

Agree a review schedule and name the owner on each side. Use the AI agent testing checklist before launch and the AI agent monitoring checklist once the workflow is live.

9. Commercial terms, ownership and exit

Price the complete operating model, not only the subscription shown in the demonstration.

Clarify:

• setup, integration, usage, storage, support and model charges;
• limits, overage rates and the factors that could make costs change;
• who owns prompts, workflow logic, connected accounts, documentation and custom work;
• which data and configuration can be exported in a usable format;
• what assistance is available during handover or termination;
• how long deletion takes after the contract ends;
• what happens to service and data if the supplier stops trading;
• liability, insurance and service commitments appropriate to the possible harm.

Avoid creating dependence by accident. Keep important accounts in the business’s name, maintain current documentation and test that exports contain what you would actually need to continue elsewhere.

10. References and verification

Ask for references that match the proposed job and risk where that is proportionate. Treat a logo wall or anonymous success story as marketing, not verification.

Useful evidence can include:

• a live demonstration using representative, non-sensitive test data;
• documentation for security, data handling, administration and exit;
• sample logs, reports and approval screens;
• test results with limitations explained;
• customer references for a comparable implementation;
• a small paid discovery or pilot with clear acceptance criteria.

Never ask a supplier to reveal another customer’s confidential information. A credible provider should still be able to explain its method, boundaries, responsibilities and evidence without inventing certainty.

A simple decision record

Summarise the review on one page. Give each area the same five fields: evidence reviewed, unresolved point, owner and decision. For example:

• Business fit: workflow and pilot plan reviewed; two edge cases remain untested; marketing lead owns the point; clarify before the pilot.
• Data: data flow and retention terms reviewed; backup deletion period remains unclear; data owner is responsible; clarify in writing.
• Access: permission list and approval screen reviewed; no open point; system owner accepts the proposed setup.
• Performance: representative test results reviewed; a monthly drift check is missing; supplier owns the action; add it to the contract.
• Security: controls and incident process reviewed; notification time remains unclear; director owns the decision; agree a contract term.
• Exit: export demonstration reviewed; custom prompt format remains untested; system owner owns the action; test before signing.

Use three outcomes:

• Proceed: the evidence is sufficient and remaining risk has a named owner.
• Clarify or pilot: an answer could materially change the decision and needs evidence.
• Stop or redesign: the supplier cannot support a necessary boundary, the use case is disproportionate, or the remaining consequence is unacceptable.

Silence is not evidence. Record “unknown” rather than turning an unanswered question into an assumption.

Frequently asked questions

How much due diligence does a small business need?

Make it proportionate to the workflow. A tool that rewrites public website copy can receive a short review. A system that handles personal information, advises customers, changes records, sends messages or controls money needs deeper data, security, performance, contract and incident checks.

Is a free trial enough?

No. A trial can help assess usability and basic performance, but it may not show contractual terms, data flows, administrative controls, supplier dependencies, support, change management or exit. Use only approved non-sensitive test information until those questions are settled.

Does an enterprise plan make an AI product safe?

It may add useful controls, support and contractual commitments, but the plan name is not evidence that the product fits your workflow. Verify the exact settings, responsibilities and terms included in the proposed agreement.

Who should be involved in the review?

Include the person who owns the business outcome, somebody who understands the day-to-day work and the people responsible for relevant data, systems, security, finance or legal obligations. A small business may combine several of those roles, but the questions still need named owners.

Should we ask every supplier the same questions?

Use the same core outcome and risk questions so comparisons are fair, then follow the evidence. A hosted writing tool, a custom agent and an AI feature inside existing software have different supply chains and consequences.

Buy the operating relationship, not the demo

The supplier’s model matters, but so do the data route, permissions, integrations, testing, support, contract and exit. Those parts determine whether a promising feature can become a dependable business process.

Define the job first. Ask for evidence in proportion to the possible consequence. Pilot with acceptance criteria. Record unresolved points and keep ownership inside the business.

An AI marketing audit can help you define the workflow, baseline, data and controls before choosing a product. If the job needs a designed process rather than another subscription, Drop Jaw Studio’s AI agent build service starts with scope, permissions, review and handover.

---

Comparing an AI product or provider for a real business workflow? Talk to Drop Jaw Studio about an AI marketing audit before the demonstration becomes a long-term dependency.

Sources checked on 9 October 2026: NCSC guidelines for secure AI system development, ICO AI contracts and third-parties guidance, UK Government guidelines for AI procurement and NIST’s Generative AI Profile. This is practical business guidance, not legal, procurement, data-protection or cyber-security advice.