This is the second of a three-post issue-spotter about contracts related to artificial intelligence. Click here for the first of the series.

B. Ownership and Control of Outputs

6. General Problems with “Ownership” of Outputs: AI systems produce data as outputs, and ownership of data is problematic, as bullet 1 explains (in the last post). The same goes for ownership of the more “creative” outputs from generative AI, but for different reasons. The law will not grant a copyright or patent for works created by an AI or any other non-human. The law does offer copyright and patent protection to humans who use AI to supplement their own creativity. But as of today, no one knows how much the AI can contribute. Ownership of outputs, then, could have some value for copyrights and patents, but it’s hard to say how much. It could also contribute to trade secret and trademark rights, which don’t need human creators. So contract terms about ownership might be worthwhile. But the would-be owner might get more protection by restricting the other party’s use of outputs, discussed below in bullet 11.
7. Customer Ownership of Outputs: Usually, it’s the customer who wants ownership. “Provider recognizes and agrees that Customer owns and will own Outputs, including without limitation any intellectual property rights therein, except as set forth ___.” (See bullet 9 below for the “except” language.) And the customer might want more: an assignment of any provider IP in outputs. But what’s to assign? The customer or its staff might have patent rights or copyrights in outputs, assuming an adequate human contribution, as discussed in the last bullet. But the provider’s contribution almost certainly won’t involve human work. So the provider could not own patents or copyrights related to outputs. And unless the AI processes the provider’s confidential data – as discussed below in bullet 16 – the provider wouldn’t own trade secret rights. Nor would it own trademarks it hasn’t registered or used in commerce. Any assignment terms, then, would result from a serious abundance of caution on the customer’s part. Still, you never know. “Provider hereby assigns to Customer all its right, title, and interest in and to Outputs, including without limitation intellectual property rights, except as set forth ___.“[mfn]For a discussion of assignment and for more detailed terms, see Chapter 1.F of The Tech Contracts Handbook. And see the book’s assignment terms reproduced here on TechContracts.com: 1.F.1. limited ownership transfer and 1.F.2. broad ownership transfer.[/mfn]
8. Provider Concerns – Refusing Output Ownership: In most cases, the AI provider should resist customers ownership of outputs. In many systems (not just generative AI), outputs could include data or content owned or claimed by third parties or by the AI provider itself. The safest route for the provider, then, may be to say nothing about IP, leaving ownership to the underlying laws. Those laws might give the customer ownership, but not of anything that already has an owner. The provider should also consider disclaimers related to IP. “PROVIDER OFFERS NO REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, RELATED TO INTELLECTUAL PROPERTY OR OTHER RIGHTS IN OUTPUTS, AND CUSTOMER USES OUTPUTS AT ITS OWN RISK WITH REGARD TO ALL SUCH RIGHTS.“
9. Provider Concerns – Limiting Output Ownership and Retaining Rights: In some deal-types, the customer can and does insist on owning outputs. But the provider should still try to limit ownership terms to an acknowledgement, like the first example above in bullet 7 – with no assignment. And with or without an assignment, the provider should add carve-outs. “The Customer ownership rights and the assignment in Section __ (Ownership and Assignment of Outputs) do not apply to Independent Assets.“[mfn]If there’s no assignment, delete “and the assignment.”[/mfn] With some systems, the provider can offer a clear list of the data or content included in these “Independent Assets.” The provider knows the input data or training data the AI processes, so it knows what could appear in outputs. But the provider can’t offer much certainty about Independent Assets if the AI draws on very broad or hard-to-define data, like the Internet-wide training data used by some generative AI. “‘Independent Asset’ means any data or content created before or independent of the prompt that led the System to generate the Output in question.” Unfortunately, the customer almost certainly won’t know what parts of outputs were created “before or independent of” its prompt. So the example above doesn’t tell it what components of the outputs it owns. The customer might have to accept that as the price of complex AI. Or maybe creative attorneys can come up with better IP terms – nuanced terms tuned to the system in question.
10. License to Outputs: The customer probably doesn’t need a license to outputs, even if it doesn’t own them. The provider probably has no IP to license, as explained above in bullets 6 and 8. And if the provider did have IP, a license would probably be implied. But the abundance of caution that demands an assignment could demand a license too, particularly if the provider refuses ownership terms. “Provider hereby grants Customer a nonexclusive, perpetual, worldwide license to reproduce, distribute, modify, publicly perform, publicly display, and use Outputs, with the right to sublicense each and every such right. Provider grants the license in the preceding sentence under such copyrights as it may have, if any.” (Those terms could also apply to the Independent Assets discussed above in bullet 9.) Finally, the provider/licensor should consider disclaiming IP warranties related to outputs, using the language in bullet 8.
11. Use of Outputs – Restrictions and Rights for Each Party: As we’ve seen, IP ownership might not give the customer much protection related to outputs, even if it works. So if the provider has access to outputs, the customer should consider restricting provider use of outputs. “Provider shall not: (a) publicize or distribute Outputs; or (b) access or use Outputs other than to maintain or improve the System or to support Customer’s use of the System. The preceding sentence does not restrict Provider’s rights to information from independent sources that also appears in Outputs.” Of course, if the provider uses outputs to train the system for other customers’ benefit (which isn’t likely), it probably can’t accept these or other use restrictions. Finally, the customer should consider protecting outputs through nondisclosure terms.

C. Trade Secrets and other Confidential Information Related to AI

12. 

    Typical Prompts and Customer Training Data & Input Data – Nondisclosure Protecting Customer: If prompts or customer data could include sensitive information, the customer should consider nondisclosure provisions. The “Confidential Information” definition in standard NDA terms would include prompts, customer input data, and customer training data. See Chapter 1.F of The Tech Contracts Handbook and the confidentiality terms on this site at II-H: Nondisclosure/Confidentiality. The provider can probably accept those terms if its AI makes no future use of prompts or customer training data (like most AI), or if it uses them only to train the customer’s copy (like many machine learning systems). But the provider needs the typical exceptions to nondisclosure, which protect the recipient’s rights to information received from a third party or generated independently. See Confidential Information Defined, on this site.

13. Prompts and Customer Training Data Used to Train Provider Products – No Confidentiality, No Trade Secrets: If the system uses prompts or customer training data to train the AI for all customers’ use, the provider should not accept confidentiality terms protecting that information. In fact, it should consider disclaimers and warnings. “CUSTOMER RECOGNIZES AND AGREES THAT: (a) PROMPTS AND CUSTOMER TRAINING DATA ARE NOT CONFIDENTIAL AND MAY BE USED TO TRAIN THE SYSTEM FOR THE BENEFIT OF PROVIDER’S OTHER USERS AND CUSTOMERS; AND (b) INFORMATION GIVEN TO PROVIDER’S OTHER USERS AND CUSTOMERS MAY INCLUDE INFORMATION FROM CUSTOMER’S PROMPTS AND CUSTOMER TRAINING DATA UPLOADED PURSUANT TO THIS AGREEMENT.” In that case, the customer should keep sensitive information out of prompts and training data. (These concerns probably don’t apply to customer input data, since it’s not used to train the system at all, much less for the benefit of other customers.)
14. Typical Outputs – Nondisclosure Protecting Customer + Trade Secret Precautions: If the provider can accept nondisclosure terms protecting prompts and customer training data, it can probably accept them for outputs. The usual caveats about information developed independently should protect the provider, as discussed in bullet 12. Among other things, those caveats should protect provider rights to its own information that winds up in outputs, like information from its training data. For the customer, nondisclosure terms offer the chance to establish trade secret rights in new information generated by the AI. And of course, those terms should protect existing customer secrets that find their way into outputs through prompts and training data. But the customer should take an additional precaution, outside the contract, if outputs could include sensitive information. The customer should treat outputs like trade secrets. It should make sure its staff keeps outputs confidential, at least until it can establish which outputs include potential trade secrets.
15. Outputs from Systems that Reuse Prompts and Customer Training Data – Options for Provider: The fact that AI reuses prompts or customer training data doesn’t necessarily rule out nondisclosure terms protecting outputs. The provider still might not use or even see outputs. So nondisclosure could work, again with the usual independent development caveats discussed in bullet 12. But some providers can’t promise nondisclosure. Their systems use outputs as training data. Or they run open-door AI systems (maybe B2C): software that shares incoming and outgoing information.
16. Provider’s Training Data and Other Inputs – Nondisclosure Protecting Provider: Some software processes sensitive information supplied by its vendor/provider, and AI is no exception. If the system involves machine learning, outputs could include sensitive information from provider-supplied training data or input data. In that case, the provider needs nondisclosure promises from the customer. The usual caveats about independent development should protect the customer’s rights to preexisting and third party information, including information it includes in prompts. Again, see bullet 12 above. But nondisclosure still greatly limits the customer’s use of outputs. For some deals, the customer might need detailed terms on permitted use of confidential information. The following, for instance, could work for AI that helps set prices. “Customer may: (a) use Confidential Information in Outputs to set prices for its own purchase or sale of Priced Assets (“Internal Use Transactions”) but not for any transaction that does not directly involve Customer as a buyer or seller; and (b) disclose Confidential Information in Outputs to its contractor assisting Customer with Internal use Transactions, subject to Section __ (Contractor NDAs).” Of course, customer nondisclosure obligations would complicate customer ownership or exercise of IP rights in outputs (the subject of bullets 6, 9, and 10).
17. Provider’s Sensitive Information in Models and Other Tech – Nondisclosure Protecting Provider: Use of software and computer systems can give the customer access to the provider’s sensitive information. Again, AI is no exception. If so, the provider needs nondisclosure terms protecting its technology. See Chapter 1.F of The Tech Contracts Handbook and the confidentiality terms on this site at II-H: Nondisclosure/Confidentiality. The provider’s “Confidential Information” might then include AI software, models, documentation, user interfaces, and just about any information available when the customer logs in.

The third and final post in this series addresses liability related to outputs and training data, including liability for errors in outputs and for IP infringement, misuse of private information, and defamation. It also addresses special issues, like data security and responsible use of artificial intelligence. Click here.

© 2023 by Tech Contracts Academy, LLC. All rights reserved.

Illustrations created by the author using generative AI from NightCafe.