New AI contract guidelines emphasise protecting data and output rights

As artificial intelligence becomes embedded across software development, customer service, marketing and product design, organisations are discovering that the technology itself is only part of the story. The real commercial value often sits in the data, know-how, prompts, outputs and other material that flow into and out of these systems. Yet many deals are still being negotiated on the basis of familiar SaaS-style templates, leaving important gaps in protection.

That mismatch...

matters. Several recent legal commentaries have stressed that AI contracts need to do more than allocate access to a platform. They must deal expressly with who owns the results, what may be fed into the system, how supplier models may learn from customer material, and what happens if the system changes or the relationship ends. Without that detail, the party buying the service may find that it has paid for tools while leaving behind the most valuable rights.

Ownership of AI-generated output is one of the most obvious pressure points. Buyers often assume that if they commission a system and provide the prompts, the result must belong to them. In practice, that will depend entirely on the contract. Some suppliers grant broad ownership or control, while others reserve significant rights or offer only a licence to use the output. As several legal guides note, traditional software clauses are often too blunt for AI because they were drafted for a world in which the supplier owned the programme and the customer merely used it.

The position can become more complicated still when a business wants to commercialise the output as part of a wider product or intellectual property strategy. Rights over revisions, derivative works and later developments may matter as much as the initial result. If those are not clearly allocated at the start, the customer may struggle to exploit the value it thought it had created.

Inputs deserve equal attention. Much of what gives an AI deployment its edge is not the prompt itself, but the proprietary material behind it: internal documents, datasets, customer records, technical specifications, processes and accumulated commercial insight. Those assets can embody years of investment and may confer an advantage that is more valuable than the output. Contracts should therefore make clear that the customer retains ownership of its inputs, while the supplier receives only the limited rights needed to deliver the service.

That protection should be matched by discipline around what is uploaded into the system. Customers cannot assume that every piece of information they hold may lawfully be passed to an AI provider. Material gathered from third parties, or from public sources, may come with reuse restrictions. Personal data raises a further layer of risk, requiring a proper legal basis, appropriate disclosures and a clear audit trail. In many cases, the supplier’s role may also be more complex than the standard controller-to-processor model used in conventional software contracts, so the relationship needs to be assessed on its actual facts.

Training rights are another area where the commercial stakes are high. Suppliers often want permission to use customer material to improve general models, but many customers will regard that as a transfer of value they do not wish to make. An AI system can reveal pricing strategies, product plans, operational methods and sector intelligence, all of which could be highly sensitive if they were absorbed into a broader model. The contract should therefore say precisely whether such use is allowed, whether the material will be anonymised or aggregated, how long it will be retained and whether the customer can opt out or use a dedicated environment.

Confidentiality and data protection cannot be treated as box-ticking exercises. AI systems may process some of the most sensitive information an organisation holds, including trade secrets and personal data. Standard confidentiality wording may not be enough if prompts, uploaded files or datasets are retained for analytics or model improvement. Customers should look closely at retention periods, access controls, deletion obligations and security standards, and should not assume that generic data-processing language will fit every AI arrangement.

Because AI systems evolve, change management also matters. Unlike static software, these tools are often updated frequently, and those changes can alter performance, compliance risk and operational behaviour. Contracts should therefore address notice of material changes, testing, implementation procedures and, where necessary, the possibility of rolling back to a previous version.

Exit planning is another area that is often left too late. If the relationship ends, the customer may need the ability to retrieve data and outputs, manage retention and deletion, and secure transition support. Building those provisions into the contract early helps preserve continuity and reduces the chance of disputes at the point when commercial co-operation is weakest.

The message from the legal commentary is consistent: AI contracting is no longer just procurement of technology. It is about protecting the value generated around the technology. For organisations investing heavily in AI, that broader discipline may prove as important as the system itself.

Source: Noah Wire Services