AI Procurement Agreements for UK Small Businesses

Buying an AI tool can feel like a normal software purchase until something goes wrong: customer data is used to train a model, the output is inaccurate, or the supplier cannot explain where the results came from. Small businesses often sign AI supplier terms without checking data use, ownership of outputs, liability for mistakes or what happens when the tool is withdrawn.

An AI procurement agreement should turn those risks into practical contract protections. A clear contract helps you decide what data the supplier can access, whether outputs can be relied on, who owns new material, how errors are handled, and what audit or exit rights you need before the tool becomes part of daily operations.

What Your AI Procurement Agreement Should Cover

An AI procurement agreement should define the AI service, the business purpose, the data flows, the output rules, and the supplier responsibilities in enough detail for both sides to manage risk.

Many AI products are sold through standard SaaS terms, but AI services often need extra clauses because the tool may learn from data, generate new content, automate decisions, or rely on third-party models. The legal issues are not only about whether the software works. They are also about how the supplier uses your information, how outputs are created, whether the system can be checked, and who carries the cost if the technology causes a business problem.

For a small business, the starting point is to separate what you are buying. The contract protections for a chatbot trained on your internal knowledge base will not be the same as those for an AI sales forecasting tool, a document review platform, a recruitment screening product, or a marketing content generator.

A practical AI procurement checklist usually includes:

• Purpose and scope: what the AI tool is meant to do, which teams can use it, and which use cases are excluded.
• Service description: whether the supplier is providing software access, managed AI services, IT support services, custom model development, implementation support, or ongoing consultancy.
• Data inputs: what business, customer, employee or confidential information will be uploaded or integrated.
• Training and improvement rights: whether the supplier can use your inputs, prompts, files, feedback or outputs to train or improve AI systems.
• Outputs: who can use generated content, how it should be reviewed, and what the supplier promises about accuracy, originality or suitability.
• Security: minimum technical and organisational measures, access controls, incident notification and vulnerability management.
• Subcontractors and model providers: whether the supplier relies on external AI models, cloud providers or offshore support teams.
• Audit and evidence: what logs, reports, testing results or security documents the supplier must provide.
• Liability: responsibility for data breaches, IP infringement, service failure, inaccurate outputs and regulatory problems.
• Exit: data return, deletion, transition assistance and continued access to your records.

The agreement should also identify the contract documents and their order of priority. AI procurement often involves a proposal, order form, statement of work, online terms of use, data processing agreement, acceptable use policy, service level agreement and security schedule. If these documents conflict, your order form should not quietly lose to a supplier's broad online terms.

A founder might sign a pilot for an AI customer support tool after a demo, then discover that the full terms allow the supplier to use chat transcripts for product development. A better structure is to use the pilot as a controlled test: limited users, limited data, no live sensitive information unless approved, clear success measures and an obligation to negotiate full production terms before wider rollout.

The strongest AI services agreement in the UK is often not the longest document. It is the one that matches the real business use. If the tool will only draft internal meeting summaries, the key risks may be confidentiality and data deletion. If it will recommend lending decisions, triage healthcare enquiries, rank job applicants or answer consumer complaints, the contract needs a much higher level of governance, testing and accountability.

Data Use, UK GDPR and Security Clauses

Your AI supplier contract should say exactly what the supplier can do with your data, and the safest position is usually to prohibit training, reuse or disclosure unless you have expressly agreed to it.

Data is the main reason AI procurement needs closer contract review. Your staff may upload customer lists, call recordings, source code, financial information, employee records, designs, legal documents, marketing plans or commercially sensitive prompts. Once that data enters an AI system, you need to know whether it is stored, retained, copied, used to train models, passed to another provider, or transferred outside the UK.

If personal data is involved, the UK GDPR and the Data Protection Act 2018 are central. Your business may be the controller if it decides why and how personal data is used, while the AI supplier may be a processor if it acts on your instructions. In some products, the supplier may also be an independent controller for certain purposes, such as service analytics, fraud prevention or model improvement. The contract needs to reflect the real arrangement, not just use labels.

Where the supplier processes personal data for you, you will usually need a data processing agreement covering instructions, confidentiality, security, sub-processors, assistance with individual rights, breach notification, deletion or return of data, and audit information. The Information Commissioner's Office expects organisations to assess data protection risks, especially where new technologies, profiling, monitoring or sensitive data are involved.

For higher risk AI use, a data protection impact assessment may be needed before rollout. This is particularly relevant where AI is used for recruitment, staff monitoring, customer profiling, automated recommendations, financial eligibility checks, children, health data or large-scale analysis. The supplier should help with the information you need for that assessment, including model logic at an appropriate level, categories of data, security controls and residual risks.

Useful AI procurement clauses for data use include:

• No training without consent: the supplier must not use your inputs, outputs, files, prompts or user behaviour to train general models unless you expressly opt in.
• Purpose limitation: data may only be used to provide the agreed services and support, not for unrelated analytics, resale, benchmarking or product development.
• Data minimisation: the supplier should only collect and process the data needed for the service.
• Retention limits: prompts, files, logs and outputs should be deleted or anonymised after an agreed period unless retention is required for security, audit or support.
• Sub-processor controls: the supplier must disclose key sub-processors and give notice of changes.
• International transfers: transfers of personal data outside the UK should use a lawful transfer mechanism and be documented.
• Security standards: the supplier should maintain access controls, encryption where appropriate, logging, backups, vulnerability management and staff confidentiality obligations.
• Incident notification: the supplier should notify you promptly if there is a security incident, data breach or unauthorised access involving your data.

Confidential business data deserves attention even when it is not personal data. A dataset of pricing, margins, supplier lists or product strategy can be commercially valuable without falling under the UK GDPR. Your confidentiality clauses should cover prompts and outputs, not only documents marked confidential. Many AI interactions happen through informal text boxes, plugins and integrations, so the contract should treat information entered into the system as protected information.

A common mistake is relying on a supplier's public privacy notice to control data use. A privacy notice is not always a negotiated contract promise to your business. If data use matters, put it in the agreement, the data processing schedule or the order form.

Another common mistake is letting staff test AI tools with real customer or employee data before procurement has reviewed the terms. Your internal AI policy should tell employees what they can upload, which tools are approved, and when legal or data protection approval is needed. The supplier agreement and the internal policy should work together.

Outputs, Accuracy and Liability for Mistakes

AI output clauses should make clear that the supplier is responsible for the service it provides, while your business keeps control over how outputs are reviewed and used.

AI tools can generate persuasive but inaccurate answers. They can also omit context, produce biased recommendations, reuse patterns from training data, or present guesses as facts. If your business relies on those outputs, the contract should not simply say the supplier accepts no responsibility for anything produced by the system.

Start with the service standard. For ordinary software, you might ask for availability, support response times and conformity with documentation. For AI, you may also need performance criteria linked to the use case. A document extraction tool might need agreed accuracy levels for particular fields. A fraud detection tool might need reporting on false positives and false negatives. A chatbot might need escalation rules when it cannot answer confidently.

The supplier may resist broad accuracy warranties because AI systems are probabilistic. That does not mean you must accept no protection. A balanced AI supplier contract in the UK can include narrower and more practical promises, such as:

• the service will materially perform in line with agreed documentation and the statement of work;
• the supplier will not knowingly provide a model that has been trained or configured in breach of law or third-party rights;
• the supplier will use reasonable skill and care in implementation, configuration and support;
• the supplier will disclose material limitations, known risks and recommended human review steps;
• the supplier will maintain testing, monitoring and quality assurance processes appropriate to the service;
• the supplier will correct defects or performance issues within agreed timeframes where the issue is within its control.

Your own responsibilities should also be clear. Many AI systems need a human-in-the-loop process. If your team uses AI to draft product descriptions, someone should check claims before publication. If AI summarises customer complaints, a staff member should review sensitive or escalated cases. If AI supports recruitment shortlisting, the employer should keep human oversight and avoid decisions that could create discrimination risks under the Equality Act 2010 or unfair process concerns in an employment context.

Liability clauses are where many buying AI software legal issues become commercial. Suppliers often try to exclude liability for outputs, data loss, indirect loss, loss of profits, loss of goodwill and regulatory penalties. Some exclusions may be normal in software contracts, but the cap and carve-outs should reflect the risk.

For example, if an AI marketing tool produces a misleading advertising claim, your business may face complaints, customer refunds or regulatory attention. If an AI coding assistant introduces infringing code or a security vulnerability, you may incur investigation and remediation costs. If a customer support bot gives incorrect refund information, the Consumer Rights Act 2015 may become relevant to how you deal with consumers, even though the supplier contract is business-to-business.

You may want higher or uncapped liability for specific risks, depending on bargaining power and the value of the contract. Common carve-outs include confidentiality breaches, data protection breaches, IP infringement indemnities, deliberate misconduct, payment obligations, and misuse of data. Where the supplier will handle sensitive personal data or business-critical functions, a low liability cap based only on a few months of fees may not be enough.

Indemnities can be useful, but they need to be specific. A general promise to indemnify you for all AI-related harm may be unrealistic and heavily negotiated. More targeted indemnities often work better, such as an indemnity for third-party IP infringement claims arising from the supplier's technology, or costs caused by the supplier using your data outside the agreed purpose.

You should also check whether the supplier's terms push responsibility back to you through acceptable use policies. These policies often ban illegal, harmful, discriminatory or high-risk use. That may be reasonable, but the definitions should not be so broad that the supplier can avoid responsibility for ordinary business use that it knew about during procurement.

IP, Confidentiality, Audit Rights and Exit

Your agreement should say who owns inputs, outputs, custom work and improvements, and it should give you enough evidence and exit rights to manage the tool over time.

Intellectual property can be tricky in AI procurement because several layers may be involved. Your business may provide data, prompts, documents, brand assets or source material. The supplier may provide software, models, workflows and templates. The AI system may generate new text, images, code, summaries, classifications or recommendations. A consultant may also create custom prompts, fine-tuning materials, integrations or reports.

The contract should usually confirm that your business retains ownership of its pre-existing materials. That includes your data, documents, trade marks, branding, confidential information and proprietary materials. The supplier should receive only the limited licence needed to provide the services.

Outputs need more careful drafting. Some suppliers say you own outputs, subject to their underlying technology and third-party rights. Others grant a data licence or output licence to use outputs but avoid giving ownership. You should check whether the licence is broad enough for your business use, including internal operations, customer communications, marketing, resale, sublicensing to clients, or incorporation into products.

For creative outputs, UK copyright law may not protect every AI-generated item in the way a business expects. The UK IPO has considered AI and copyright issues over recent years, and the area can be complex. From a procurement perspective, the key is not to assume exclusivity. If your brand needs unique campaign assets, product names, code or designs, the contract should address originality, infringement risk, human contribution and whether the supplier can provide similar outputs to others.

For software development or technical services, check whether any AI-generated code can be used commercially and whether it may be affected by open source licence obligations. A supplier should not deliver code or materials that create unexpected disclosure, attribution or licensing requirements unless you have agreed to them.

Confidentiality clauses should be updated for AI workflows. They should cover:

• information entered into prompts, integrations, training datasets and support tickets;
• outputs that reveal or summarise confidential information;
• model configuration, custom prompts and workflow rules developed for your business;
• security documents, audit reports and testing results shared during procurement;
• employee, customer and supplier information processed through the tool.

Audit rights are not only for large enterprises. Small businesses can ask for practical evidence without demanding full access to the supplier's systems. The agreement might require security summaries, penetration test confirmations, independent certification reports, sub-processor lists, data flow diagrams, model cards, testing records or incident reports. If your sector is regulated, or if your clients audit you, you may need rights to pass on reasonable information.

For AI services that affect customers, employees or regulated workflows, explainability matters. The supplier may not be able to reveal proprietary model weights or confidential training data, but it can often provide information about input factors, system limitations, confidence scores, escalation pathways and testing methodology. Your contract should require enough information for you to respond to customer queries, complaints, internal reviews and regulator questions.

Change control is another practical protection. AI products can change quickly. A supplier may update models, alter features, change sub-processors, remove functionality or modify safety filters. Your agreement should require notice of material changes, especially if they affect data use, security, output quality, integrations, compliance obligations or pricing. For business-critical tools, you may want a right to reject material changes or terminate with data export if the service changes in a way that no longer suits your business.

Exit clauses are often overlooked until renewal time. You should know how to retrieve data, outputs, logs and configuration settings in a usable format. The supplier should delete or return data at the end of the contract, subject to agreed retention for legal, security or backup reasons. If the AI tool is embedded in customer service, operations or reporting, ask for transition assistance and a reasonable period to migrate.

Consider a business that uses an AI tool to analyse customer calls and identify complaints. After a year, it wants to switch supplier. Without export rights, it may lose tags, summaries, audit trails and training feedback that staff rely on. With a better exit clause, it can export recordings, metadata, summaries and configuration notes, then require deletion from the old platform.

FAQs

Do I Need a Separate AI Procurement Agreement or Can I Use the Supplier's Standard Terms?

You can start with the supplier's standard terms, but AI-specific risks often need extra clauses in an order form, data processing agreement, statement of work or negotiated addendum. The higher the data, IP or customer impact, the more likely you need tailored terms.

Can an AI Supplier Use My Business Data to Train Its Model?

Only if the contract allows it or you otherwise agree. Your agreement should say whether training, fine-tuning, benchmarking or product improvement is permitted, and whether data must be anonymised, aggregated or excluded entirely.

Who Owns AI-Generated Outputs?

Ownership depends on the contract and the nature of the output. Your agreement should state whether you own outputs or receive a licence to use them, and whether the supplier gives any protection against third-party IP claims.

What Should I Check Before Using AI With Customer or Employee Data?

Check the data protection roles, the lawful basis for processing, the supplier's security measures, sub-processors, international transfers, retention periods and whether a data protection impact assessment is needed under UK GDPR practice.

Should Small Businesses Ask for Audit Rights?

Yes, but they can be proportionate. Many small businesses ask for security reports, sub-processor information, incident records and evidence of testing rather than physical audits or unrestricted system access.

Key Takeaways

• An AI procurement agreement should cover data use, training rights, outputs, accuracy, liability, IP, confidentiality, audit rights and exit arrangements.
• Do not assume standard SaaS terms are enough. AI tools may process sensitive data, generate risky outputs or rely on third-party models that need extra contract controls.
• UK GDPR and the Data Protection Act 2018 matter whenever personal data is processed, especially for profiling, monitoring, recruitment, customer support or automated recommendations.
• Output clauses should balance supplier responsibility with your own human review process, particularly where customers, employees or regulated decisions are affected.
• IP and confidentiality clauses should protect prompts, datasets, generated materials, custom workflows and business information entered into the AI system.
• Exit rights should let you retrieve data, logs and useful records so your business is not locked into a tool that no longer works for you.

If your business is buying or rolling out an AI tool, Sprintlaw can help with your supplier terms, data processing agreement, IP clauses and internal AI use policy. Contact us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.