AI Procurement Evidence Packs For UK SMEs

Tools & Technical Tutorials

6 July 2026 | By Ashley Marshall

AI procurement should not be a trust exercise. Before a UK SME approves a model upgrade, a new connector or a data processing change, it needs a small evidence pack that shows what is changing, who is accountable and how the risk has been tested.

Evidence packs turn AI buying from opinion into governance

Most SME AI procurement still depends too heavily on vendor confidence. A supplier says the new model is better, the connector is secure, the data route is covered, or the upgrade will not affect behaviour. That may all be true. The problem is that none of those claims helps a director, operations lead, data protection lead or security adviser make a defensible approval decision unless the claims are converted into evidence.

An AI procurement evidence pack is deliberately small. It is not a hundred-page compliance binder. It is the minimum set of documents, answers and test results needed before approving a material change. For a model upgrade, that means the model identifier, reason for change, expected behaviour difference, regression test results, fallback route and customer impact. For a connector, it means scopes, permissions, data categories, tenant boundaries, audit logs and revocation method. For a data processing change, it means where data goes, who can access it, how long it is retained, whether it is used for training or improvement, and which subprocessors are involved.

The need is not theoretical. The DSIT Cyber Security Breaches Survey 2025 reported that 43% of UK businesses identified a cyber breach or attack in the previous 12 months, equal to about 612,000 businesses. Yet only 14% of businesses said they reviewed cyber security risks from immediate suppliers, and only 7% looked at their wider supply chain. AI vendors, plugins and automation platforms are now part of that supply chain.

What this means in practice is simple: do not approve an AI change from a slide deck alone. Ask for a short evidence pack, store it with the contract or supplier record, and make approval conditional on the answers being specific enough to test. If the vendor cannot explain the change in plain English, the business should not treat it as low risk just because the product interface looks familiar.

Model upgrades need change evidence, not just benchmark claims

Model upgrades are easy to underestimate because the user experience may barely change. A Microsoft Copilot feature, a Salesforce Einstein workflow, an Intercom Fin setup, a HubSpot AI assistant or a custom OpenAI API integration can look identical to staff while the model, routing, safety layer or prompt stack changes underneath. A newer model may be more capable, but capability is not the same as fitness for your process.

The evidence pack should start with basic identity. Ask the vendor which model version is used now, which version will replace it, whether the change is optional or mandatory, and whether your account uses a pinned model, a vendor-managed default or a routing layer. Then ask what changed in behaviour. Does the new model write longer answers, cite sources differently, refuse more often, translate better, call tools more readily or summarise with less detail? If the vendor answers only with public benchmark scores, push harder. Benchmarks do not prove that the upgrade preserves your complaint tone, finance coding rules, CRM update format or internal escalation thresholds.

The NCSC Guidelines for secure AI system development are useful because they frame AI security across secure design, secure development, secure deployment, and secure operation and maintenance. They also say the guidance applies to systems built on external APIs or hosted models. That is exactly the point for SMEs: even if you are not building the foundation model, you are still approving a system change that can affect security, privacy, availability and output quality.

What this means in practice is that every material model upgrade should come with a regression note. Ask the vendor to show the test set, the pass threshold, the failure examples and the rollback option. Keep your own small sample of real cases too. If a support assistant, invoice classifier or HR policy bot is already live, the approval evidence should include the business owner saying that the upgraded output is still acceptable for the workflow. A related control is model lifecycle planning, covered in our guide to AI model deprecation clauses.

Connectors are where useful AI becomes risky AI

The biggest AI procurement risk for many SMEs is not the chatbot. It is the connector. Once an assistant can read from Google Drive, search SharePoint, update HubSpot, draft in Outlook, query Xero, access Slack, call an API, trigger Zapier or run a Make automation, it stops being a simple question and answer tool. It becomes an actor inside the business environment. The procurement question changes from "does the model answer well?" to "what can this system see, change, export or trigger?"

A connector evidence pack should describe every requested permission in normal operational language. Read-only access to a folder is different from domain-wide access. Sending draft emails is different from sending without approval. Reading CRM notes is different from updating lifecycle stage, creating tasks or changing deal values. The pack should state the exact scopes requested, the systems connected, the data categories exposed, the authentication method, the audit logs created, the approval workflow, the revocation method and the process for reviewing dormant connections.

There is a good reason to be strict. DSIT found that adoption of stronger controls remains uneven. In the 2025 survey, two-factor authentication was used by 40% of businesses, VPNs by 31%, and user monitoring by 30%, while basic controls such as malware protection and firewalls were more common. If an AI connector is added to a business with weak identity, weak logging or informal admin rights, the connector can widen the blast radius of an ordinary account compromise.

The common misconception is that vendor marketplace approval solves this. It helps, but it does not tell you whether the connector is proportionate for your tenant, your data or your workflow. A marketplace badge does not know that one shared inbox contains HR grievances, that a finance folder includes bank details, or that your CRM has special category notes in free text fields. The evidence pack should therefore force the vendor and internal owner to justify the permission level, not just confirm that the integration works.

Data processing changes need UK GDPR answers before approval

For UK SMEs, AI data processing changes are where procurement, privacy and operations meet. A vendor may change prompt logging, retention, human review, subprocessor use, abuse monitoring, model improvement settings or hosting region. Each change can affect whether the business remains comfortable under UK GDPR, the Data Protection Act 2018 and its own customer commitments. The evidence pack should not ask for vague assurances about privacy. It should ask for a map.

Start with data categories. Does the tool process customer personal data, staff personal data, special category data, confidential commercial information, credentials, payment data or client documents? Then ask what happens to prompts, uploaded files, outputs, embeddings, metadata, audit logs and support tickets. Are they retained? For how long? Are they available to human reviewers? Can they be used to train or improve models? Which subprocessors are involved? Is any restricted international transfer taking place? Who is controller, processor or independent controller for each activity?

The ICO guidance on AI and data protection is explicit that AI work needs attention to accountability, transparency, lawfulness, fairness, accuracy, security, data minimisation and individual rights. The ICO also highlights DPIA considerations and Article 22 questions where solely automated decision-making is relevant. That does not mean every SME needs a full legal memo for every AI feature. It does mean the business needs enough evidence to decide whether a DPIA, contract update or customer notice is required.

What this means in practice is that procurement should require a data processing change note before approval. A useful note names the old processing route, the new processing route, the affected data categories, the purpose, the retention period, subprocessors, transfer mechanism, security controls and customer opt-out options if available. If the supplier says "no customer data is used for training", ask whether that also covers prompts, files, outputs, logs and embeddings. Precision matters because AI systems create more data exhaust than ordinary SaaS forms.

Contract and procurement questions should match the risk of the change

Not every AI change needs the same approval path. An internal writing assistant with no customer data is not the same as an agent that can update orders, email clients or process HR documents. The mistake is to have only two modes: either casual approval by the tool owner or a heavy procurement process that nobody wants to use. The better SME pattern is tiered evidence.

For low-risk changes, ask for a simple vendor statement: what changed, what data is touched, whether training use changed, and how users are told. For medium-risk changes, require a short evidence pack with test results, connector scopes, data processing details, security controls and owner approval. For high-risk changes, add legal review, DPIA screening, incident response impact, contractual change notice and a business continuity check. The key is to define the trigger. A model upgrade affecting output behaviour, a new connector, a new subprocessor, new human review access, new data retention or a change in training use should all count as reviewable events.

The UK public procurement direction is also instructive even for private SMEs. The government guidance on the Procurement Act 2023 competitive flexible procedure warns that unnecessarily complex procedures can deter SMEs and that demonstrations can reduce risk by testing deliverability. That is a useful principle for private buyers too. Keep evidence proportionate, but do not skip demonstrations, test cases or change notes when the AI tool will touch real business operations.

The counterargument is that too much process will slow useful AI adoption. That is a fair concern. The answer is not to remove evidence, but to make the evidence reusable. One supplier pack can support multiple approvals if it is kept current. A standard connector questionnaire can be completed quickly. A standing regression set can be rerun after every material model upgrade. Good governance should make repeat buying easier, not harder, because decision-makers know what evidence is expected.

The board question is who owns the decision after the demo

AI buying often starts with an impressive demonstration. The vendor shows a faster support workflow, cleaner document review, a clever CRM assistant or a new automation chain. The demo is useful, but it answers only one question: can the tool appear to work in a controlled setting? It does not answer who owns the risk after deployment, who monitors behaviour, who approves future changes or who can stop the tool if a connector or model starts behaving differently.

This matters because board and senior leadership accountability for cyber risk is not as strong as it should be. DSIT reported that 72% of businesses treat cyber security as a high priority, but only 27% have a board member with explicit responsibility for cyber security, down from 38% in 2021. AI procurement sits inside that same governance gap. A director does not need to understand transformer architecture, but somebody senior needs to be accountable for deciding which AI changes are acceptable and which need escalation.

The UK AI Opportunities Action Plan says Britain is the third largest AI market in the world and names Google DeepMind, ARM and Wayve as examples of UK strength. It also argues that government purchasing power can shape AI markets, but doing this well requires leadership and radical change, especially in procurement. That message applies neatly to SMEs. The opportunity is real, but leadership must move beyond enthusiasm into repeatable approval practice.

So the final page of the evidence pack should be an approval record. It should name the business owner, technical owner, data protection reviewer if needed, security reviewer if needed, approval date, change type, residual risks, user communication plan and next review date. That page is not bureaucracy for its own sake. It is the difference between "we bought an AI tool" and "we approved this specific AI capability with eyes open". When the vendor later changes model, connector or processing route, the business has a baseline to compare against.

Frequently Asked Questions

What is an AI procurement evidence pack?

It is a concise set of vendor answers, documents and test results used to approve an AI tool or material change. It should cover model behaviour, connector permissions, data processing, security controls, contractual notice and business ownership.

Do small UK businesses really need this?

Yes, if AI tools touch customer data, staff data, finance, CRM, documents, email, workflow automation or other business systems. The pack can be lightweight, but the decision still needs evidence.

What should we ask before approving a model upgrade?

Ask which model is changing, why it is changing, whether the change is optional, what behaviour differences are expected, what testing has been done, what failed, and how you can roll back or pause the workflow.

What should we ask before approving a new connector?

Ask for exact permission scopes, systems accessed, data categories, authentication method, audit logs, administrator controls, approval workflow, revocation steps and whether the connector can trigger actions without human approval.

What data protection questions matter most?

Ask what personal data is processed, where prompts and outputs are stored, whether logs or files are retained, whether humans can review data, whether data is used for model improvement, and which subprocessors or international transfers are involved.

Does a vendor marketplace listing remove the need for evidence?

No. Marketplace review may help, but it does not prove that the connector is appropriate for your tenant, your data, your access model or your business process.

How often should evidence packs be refreshed?

Refresh them at renewal, before any material model or connector change, after significant data processing changes, after an incident, and whenever the supplier changes subprocessors or contractual data terms.

Who should approve the evidence pack?

The business owner should approve the operational decision, with IT, security, data protection and legal input depending on risk. High-risk workflows should have a named senior accountable owner.