How UK AI Software Companies Should Draft Confidentiality Clauses

AI software founders usually know they need a confidentiality clause, but the real problem is getting the clause to fit how the business actually works. A short NDA copied from a template often misses the biggest risks. It may fail to cover training data, model weights, prompts, evaluation results, customer datasets, or information created during a pilot. It may also say the recipient can use confidential information for vague “business purposes”, which is far too wide if you are sharing sensitive technical material before you sign a contract.

Another common mistake is treating all information the same. In an AI business, code, datasets, product roadmaps, security processes, and client data create different risks and often need different rules. The right clause should also line up with privacy obligations, IP ownership terms, and the practical reality of how your team, contractors, cloud providers, and customers handle information.

This guide explains how confidentiality clauses for AI software company arrangements should be drafted for the UK market, what to check before you sign, and where founders most often get caught out.

Overview

A good confidentiality clause should tell both sides exactly what information is protected, how it can be used, who can access it, how long the obligations last, and what happens when the relationship ends. For AI software companies, the wording also needs to deal properly with training materials, derived outputs, customer data, and information shared during testing, procurement and integration.

Small drafting choices can make a big difference to whether the clause protects your commercial position or leaves gaps.

• Define confidential information broadly enough to capture code, models, prompts, datasets, outputs, product plans, commercial terms and security material.
• Limit use of the information to a narrow permitted purpose, not a general business purpose.
• Set clear rules on who may access the information, including employees, contractors, group companies and subprocessors.
• Deal separately with personal data, because confidentiality wording does not replace UK GDPR obligations.
• Address ownership and permitted use of derivative work, feedback, model improvements and evaluation results.
• Include practical return, deletion and certification obligations when discussions or services end.
• Check whether the duration of confidentiality is realistic for trade secrets and long-life technical information.
• Make sure the clause works alongside the wider contract, especially IP, security, liability clauses and dispute terms.

What Confidentiality Clauses for AI Software Company Means For UK Businesses

For a UK AI software business, a confidentiality clause is the part of the contract that controls what the other side can do with sensitive information you disclose. The point is not just secrecy. The point is to stop misuse, over-sharing, unauthorised retention, and unapproved secondary use of information that gives your business value.

That matters at several founder moments. You may be speaking to an enterprise customer before a pilot, hiring a developer, sharing model documentation with a reseller, or reviewing a vendor’s standard terms for a data labelling service. In each case, the clause should reflect the real information flow, not just a generic promise to keep things confidential.

What counts as confidential information in an AI business?

In a standard software deal, confidential information might mean source code, pricing and customer lists. In an AI business, the scope is usually wider because valuable information sits in technical processes and data relationships as much as in the product itself.

Your definition may need to cover:

• source code, object code, scripts and APIs
• model architecture, weights, fine-tuning methods and system prompts
• training data, labelled data, synthetic data and evaluation datasets
• benchmarking, testing, hallucination reports and performance results
• security measures, red team findings and vulnerability information
• product roadmap, pricing, investor materials and commercial strategy
• customer data, usage patterns and implementation details
• documentation, playbooks and internal operating processes

If the definition is too narrow, a recipient may argue that only documents marked “confidential” are protected. That can be risky during fast-moving sales or procurement discussions where information is shared in meetings, demos and collaborative tools rather than formal attachments.

Why purpose limits matter

The most valuable sentence in many confidentiality clauses is the one that limits use. A recipient should usually be allowed to use your confidential information only for a defined purpose, such as evaluating a proposed integration, performing services under the agreement, or receiving support under the contract.

Founders often accept wording that allows use for “internal business purposes” or “the parties’ commercial relationship”. That language can be far too broad. It may leave room for benchmarking your tool, training internal systems, improving a competing product, or sharing learnings more widely than you intended.

Before you accept the provider’s standard terms, check whether the purpose clause is narrow enough to stop side uses that undermine your business.

Confidentiality is not the same as privacy

A confidentiality clause protects information as between the contracting parties. It does not replace a proper data protection framework where personal data is involved. If your AI product processes names, contact details, HR records, health data, customer support logs, or any other personal data, you may also need a data processing clause or separate data processing agreement.

This is a common gap in AI contracts. One clause says information is confidential, but the contract says nothing useful about controller and processor roles, lawful instructions, subprocessor use, cross-border transfers, security measures, retention, or data subject rights.

Where personal data sits inside a training or testing dataset, both confidentiality and privacy issues may apply at once.

Trade secrets and long-term value

Some confidential information loses value quickly, such as a short-term pricing proposal. Other information, such as proprietary model design, data cleaning methods or unreleased features, may remain valuable for years. A one or two year confidentiality period can be too short if the clause is meant to protect genuine trade secrets.

UK businesses often solve this by using different durations for different categories of information, or by stating that trade secrets remain protected for as long as they retain that legal status. The wording still needs to be reasonable and clear, but a blanket short expiry date can create avoidable risk.

Who receives the information?

Most recipients need to share confidential information internally to use it. The contract should say who can receive it and on what basis. If the wording simply allows disclosure to “representatives”, that may be too loose unless the term is defined properly.

You may want disclosure limited to people who:

• need the information for the permitted purpose
• are under written confidentiality obligations
• receive only the minimum necessary information
• follow stated security and access controls

That matters even more where the recipient relies on outsourced developers, cloud vendors, consultants or offshore support teams. If your clause ignores that chain, enforcement becomes harder in practice.

Legal Issues To Check Before You Sign

Before you sign a contract with a confidentiality clause, make sure it actually matches the technical, commercial and regulatory reality of the deal. The main risk is not having no clause at all. The main risk is having a clause that sounds fine but leaves key questions unanswered.

1. Definition and carve-outs

The definition of confidential information should be broad enough to capture what you are really sharing, but the exclusions also need attention. Most clauses exclude information that is already public, already known to the recipient, independently developed, or lawfully obtained from a third party.

Those carve-outs are normal, but they should not be drafted so widely that they gut the clause. For example, “independently developed” should usually require evidence. Otherwise, a recipient may later claim your idea was developed separately without showing much detail.

2. Permitted purpose and prohibited uses

The contract should say exactly why the information is being shared and what uses are not allowed. In AI deals, prohibited uses often deserve express wording.

Depending on the deal, consider whether the clause should stop the recipient from:

• using your material to train, fine-tune or evaluate another model
• building a competing feature or service
• benchmarking your product for external publication
• reverse engineering non-public aspects of the system, where legally appropriate
• using customer information outside agreed service delivery
• retaining datasets or outputs after the project ends

If these points matter commercially, put them in the contract. Do not rely on assumptions or a verbal promise from the sales or procurement team.

3. Data protection overlap

If personal data is involved, the confidentiality clause should sit beside clear privacy terms. This may include controller or processor roles, instructions, security, assistance, international transfers, breach reporting, retention and deletion.

Founders sometimes assume a broad confidentiality clause covers customer data handling. It does not. You can keep information secret and still breach data protection law if the processing rules are wrong.

4. Ownership of outputs, feedback and improvements

AI contracts often create uncertainty around information generated during the relationship. That may include outputs, evaluation reports, prompt libraries, product feedback, model improvement suggestions and implementation learnings.

Here is where founders often get caught. The confidentiality clause may protect disclosures, but the IP clause or feedback clause may then allow the other party to use what was learned to improve its own services. Sometimes that is acceptable. Sometimes it undermines the whole deal.

Before you sign, check how the contract treats:

• customer inputs and customer data
• system outputs and who can reuse them
• feedback, suggestions and feature requests
• aggregate or anonymised usage data
• model improvements developed during the relationship
• evaluation results and proof of concept learnings

The confidentiality clause should not conflict with these provisions.

5. Return, deletion and retention rules

When negotiations end or the contract terminates, the recipient should not keep more than it needs. The clause should say whether confidential information must be returned, deleted, or both, and whether the recipient must certify that this has happened.

There may be practical exceptions for backup systems, automatic archiving, legal retention obligations or security logging. Those exceptions should be narrow and should not become a licence to keep live usable copies indefinitely.

6. Security standards and incident handling

A confidentiality clause is stronger when it connects to practical security expectations. If you are disclosing sensitive AI materials, you may need minimum security obligations, access restrictions, encryption expectations, or incident notification timelines elsewhere in the contract.

Without that support, a recipient might technically promise confidentiality but still use poor operational controls.

7. Remedies and enforcement

A confidentiality breach can be hard to reverse, especially where code, datasets or strategic information have already been copied or circulated. Contracts often state that damages may be inadequate and that injunctive relief may be sought. That can help signal the seriousness of the obligation, but outcomes still depend on the facts and the law.

You should also check limits of liability. Sometimes a contract contains a confidentiality clause with one hand and takes away meaningful remedies with the other by capping liability too low or excluding key losses.

Common Mistakes With Confidentiality Clauses for AI Software Company

The most common mistakes come from treating an AI contract like a plain software licence or a basic NDA. AI products depend on data, iteration and technical testing, so the confidentiality drafting needs more precision.

Using a one-line template

A short generic clause may be fine for low-risk early talks. It is usually not enough for pilots, enterprise procurement, supplier arrangements or partnerships where sensitive technical material is exchanged. If the clause does not mention derived information, data handling, access rights or end-of-term deletion, you may have little practical protection when something goes wrong.

Protecting disclosure but not use

Some clauses focus only on non-disclosure. That means the recipient promises not to reveal the information, but says little about what it can do with it internally. For an AI business, internal misuse can be the real issue. A partner does not need to publish your model evaluation data publicly to cause damage. It may simply use it to improve its own product or procurement position.

Missing derived and adjacent materials

Founders often define confidential information as information “disclosed by” one party. That can leave arguments about whether notes, summaries, reports, prompts, derived metrics and internal testing records are protected.

If you care about those materials, say so clearly. The clause can cover information derived from, reflecting, or based on the confidential information, not only the original item shared.

Ignoring customer and third-party restrictions

Your own contract may not be the only source of confidentiality obligations. If you process a customer’s dataset under customer terms, or use licensed third-party material, you may already owe restrictions that need to flow down into supplier and contractor contracts.

This is especially relevant for AI companies using subcontractors for annotation, moderation, testing or support. If your downstream contracts are weaker than your upstream obligations, you can end up carrying liability without enough protection.

Assuming marking requirements will be followed perfectly

Some contracts protect only information marked confidential in writing. In real business use, that is often unrealistic. Sensitive information gets shared in workshops, demos, code repositories, Slack-style channels and calls.

A better approach is often to cover information that is identified as confidential or that a reasonable person would understand to be confidential in the circumstances. You can still keep a marking process for clarity, but do not rely on it exclusively if the relationship is fast-moving.

Setting the confidentiality period too short

A fixed one year or two year period may suit simple commercial proposals. It may not suit proprietary datasets, model design, unreleased features or sensitive security material. If the value lasts longer, the clause should reflect that.

Letting the wider contract undermine the clause

Even where the confidentiality wording looks sensible, other terms can create loopholes. A broad analytics right, feedback licence, publicity permission, or affiliate-sharing clause may undercut the practical protection you thought you had.

Before you sign, read the confidentiality clause together with the provisions on IP, data use, subcontracting, publicity, liability and termination rights.

Not matching the clause to the deal stage

The right drafting for an investor intro, a proof of concept, a vendor due diligence exercise and a full customer agreement will differ. A pre-contract NDA may need stronger restrictions on use and short access rights. A services agreement may need more detailed operational provisions on personnel, security and deletion.

One document is not always enough for every stage of the relationship.

FAQs

Do AI software companies in the UK need a separate NDA every time?

Not always. A standalone NDA can work for early discussions, but once the commercial contract is signed, confidentiality is often built into that main agreement. The key point is that the final contract should cover the real information flows properly.

Can a confidentiality clause stop the other party training its AI on our data?

It can help, but only if the wording is clear. If you want to stop training, fine-tuning, testing or reuse of your data or materials, say so expressly rather than assuming confidentiality language alone will cover it.

Is confidential information the same as personal data?

No. Personal data may also be confidential, but privacy law adds separate legal obligations. If personal data is involved, the contract should deal with UK GDPR-related issues as well as confidentiality.

How long should confidentiality obligations last?

That depends on the information. Shorter periods may work for routine commercial discussions. Trade secrets, proprietary technical know-how and security-sensitive information often need longer protection, sometimes for as long as they remain trade secrets.

Can we rely on the other side saying they will keep things private?

No. Before you rely on a verbal promise, get the terms into a written contract. You need clear wording on scope, permitted use, access, deletion, liability and any restrictions on training or derivative use.

Key Takeaways

• Confidentiality clauses for AI software company contracts should do more than impose secrecy. They should tightly control use, access, retention and deletion of sensitive technical and commercial information.
• AI businesses often need drafting that expressly covers datasets, prompts, model information, outputs, evaluation results and derived materials.
• A confidentiality clause does not replace proper data protection terms where personal data is involved.
• The clause should line up with IP ownership, feedback rights, analytics rights, subcontracting and liability provisions in the wider contract.
• Founders should check the permitted purpose carefully before they accept the provider’s standard terms, especially where training, benchmarking or competing use is a risk.
• Longer-lasting know-how and trade secrets may need longer confidentiality periods than standard commercial information.
• Written contracts matter most before you sign, before you accept the provider’s standard terms, and before you rely on a verbal promise.

If you want help with contract drafting, NDAs, negotiating customer or supplier contracts, data protection terms, and IP ownership provisions, you can reach us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.