Read supplier terms as product decisions
What the model provider may do with what you send, what it retains, and what it will stand behind.
Technology
AI and emerging technology.
A great deal of what people would like to know about artificial intelligence is not settled, and in the United Kingdom several of the central questions are actively contested. That is the honest position, and what can be done is to separate the questions that are genuinely open from the ones you control through your own contracts and your own decisions.
What this looks like when it goes wrong
The most common problem is a feature shipped on somebody else's model, where that supplier's terms decide things the product team assumed were theirs to decide. What may be done with material sent to the model, whether it is retained, what is said about the output, and what the supplier will and will not stand behind are all in a document accepted during a prototype and never read again.
The next is ownership, asked by a customer and answered by nobody. Whether the customer owns what the feature produces, whether you do, whether anybody does, and what either side may do with it were never addressed, because it did not come up until a customer asked in writing.
Then there is material that should not have left the building. Source code, an unsigned deal, personal information, or a client's confidential documents put into a tool because it was convenient. The obligation that was breached was frequently one owed to somebody else, and it was breached by a person doing their job faster.
The version that causes commercial damage is a claim about what the system does. Marketing describes it as doing reliably what it does most of the time. When it is wrong in front of a customer, the argument is not about the technology. It is about what was promised.
What actually decides it
The starting point has to be that several of the central questions are open. Whether material produced with substantial machine involvement attracts protection at all, who would hold it if it does, and how that sits alongside contractual arrangements are argued rather than resolved, and positions differ between jurisdictions. Building on the assumption that outputs belong to you in the way handwritten code does is a risk. Where the law provides no clear answer, the answer has to be created by contract, as far as contract is able to reach.
The contract stack is what you actually control. Your supplier's terms, any conditions attaching to weights or components you use, and your own terms with your customers have to be read against each other rather than separately. You cannot grant what you were not granted, and the protection offered to you by a supplier rarely matches what your customers are asking you to give them. Where those do not line up, the gap sits with you.
Whether and how copyright works may be used to build these systems is contested in the United Kingdom, with policy having been under review and litigation running. Nothing on this page states an outcome, because there is not one to state. What is within your control is different and more practical: what you can show about the provenance of what went into anything you built, what your suppliers commit to about theirs, and whether your product is capable of changing supplier if the position moves against the one you chose.
Liability turns on description and on use. What you promised, whether a person reviews the output before it does anything consequential, how the feature is presented to the buyer, and what your terms say about accuracy all matter more than any characteristic of the underlying model. Sector rules, consumer protection and rules about how products are described can apply even where nothing written specifically for this technology does. Regulation is developing in several places at once, and the sensible assumption is that whatever is true now will be adjusted.
What we do
Ownership as far as contract reaches
Positions on inputs and outputs set out expressly, rather than left to a question nobody can currently answer.
Inputs and confidentiality
A rule about what may be put into which tool, written so that people can follow it while working.
What you can safely promise
Terms and marketing brought into line with what the feature actually does when it is not working perfectly.
Protection up and down the chain
Whether what a supplier gives you matches what your customers are asking you to give them.
Tell you when it moves
Flagging developments that change a decision you have already taken, rather than leaving you to find out late.
When to spend nothing
A prototype nobody outside the company has seen does not need documentation. What it needs is the one discipline that costs nothing and prevents the worst outcome, which is a rule about what may be put into a tool that sends material elsewhere. That rule protects obligations you owe to other people, and those are the ones that are hardest to repair afterwards.
It is equally a mistake to wait for the position to settle before deciding anything. The workable approach is to make decisions that survive more than one outcome: keep records of provenance, avoid depending on a single supplier in a way you could not unwind, describe the product accurately, and revisit the position deliberately rather than assuming that what was true when you built the feature is still true.
Before anything is sent
Positions harden the moment the other side takes advice, and the quiet routes stop being available once a demand has gone out. While nothing has been sent, everything is still open.