Customer prompts and AI feature logs in your product: who owns them?

Why do AI features create a new ownership question?#

AI features create a new ownership question because they generate records that older contracts never named. Before AI, customer content sat in records the customer created. Now each request also produces a prompt, the context your system retrieved, a generated output, a rating, the customer's edits, and logs of the model version, latency and cost.

Contracts drafted before the feature launched often define customer data broadly but say nothing specific about outputs or ratings. Vendors that did write it down chose different answers. Intercom's Additional Product Terms treat content submitted to its AI products and the output they generate as Customer Data. Box's Product Terms say Box AI queries and outputs are the customer's Confidential Information but are not Content, which means a clause about Content alone would not reach them. Read your own definitions with that level of care, because where nobody writes it down, the gap gets filled by argument.

Rights table: inputs, outputs, feedback and telemetry#

The rights table gives the usual starting position for each category in a B2B SaaS agreement. Your contracts may differ, and enterprise order forms often add restrictions on top.

Two categories cause most confusion. Feedback clauses were written for feature suggestions, not for ratings attached to customer content, and telemetry clauses were written for page views and error counts, not for logs that store fragments of prompts. Check whether your logging pipeline keeps text inside what you call telemetry.

Where in your contracts should you look?#

The answer sits across several documents, and the most specific one usually matters most. Read them together before forming a view.

Note the date each document took effect. Logs created before an AI addendum was signed are governed by the terms in force when they were created, which may say nothing about AI at all.

• 1Master agreement definitions of customer data, customer content, usage data and aggregated data.
• 2Any AI-specific terms, AI addendum or acceptable use policy for the feature.
• 3The data processing addendum: processing instructions, purpose limits and the sub-processor list.
• 4Order forms and negotiated riders, where enterprise customers often add no-training clauses.
• 5The feedback clause and its definition of feedback.
• 6Your privacy notice for end users and any in-product notice shown when the feature is used.

Does your role as a processor settle it?#

Your role as a processor or service provider often settles the question for personal data in prompts and outputs. Privacy laws that may apply, such as GDPR and several US state laws, generally limit a processor's use of personal data to the purposes its customer sets, and licensing that data to a third party for model training is usually outside those purposes.

De-identification can change the privacy analysis, but it does not change contract terms that restrict customer data or confidentiality obligations that cover business content. A prompt stripped of names can still reveal a customer's pricing, deal terms or plans, and that is often what the customer cares about most.

Where does your model provider fit?#

Your model provider is a third party to every AI feature log, because prompts and outputs pass through its systems. Its terms on retention, abuse monitoring and use of customer content shape what exists and where, and it should appear on the sub-processor list you give customers.

Provider terms bind you as well. If they restrict using outputs to develop competing models, that restriction applies to outputs stored in your logs, on top of whatever your customers' contracts say. A log that clears every customer contract can still fail on the provider's terms.

What does your logging pipeline actually keep?#

Your logging pipeline often keeps more customer content than your contracts assume. Engineers add tracing and observability tools to debug AI features, and those tools commonly store full prompts, retrieved context and outputs next to latency and error metrics.

That matters for two reasons. Text stored inside a telemetry system is still customer content, whatever the system is called, so the usage data clause does not cover it. And copies in debugging tools, data warehouses and evaluation notebooks are easy to forget when a customer asks for deletion at the end of a contract.

A cleaner design separates the two: metrics without text flow to telemetry, while prompts and outputs stay in a store with customer-data controls, a set retention period and access limited to people who need it. Mapping where text lands today is the first job before any rights discussion.

Illustrative: a contract management software company sets its posture#

Illustrative: a fictional contract management software company launched an AI feature that summarizes uploaded agreements and flags unusual clauses. A question about whether its logs could be licensed prompts the general counsel to map every record the feature creates.

The map shows uploaded agreements, generated summaries, thumbs ratings, user edits and latency logs. The master agreement defines customer content to include anything generated from it, and several enterprise order forms prohibit training on customer content. The feedback clause covers suggestions about the service but says nothing about ratings.

The company decides not to license prompts, outputs or edits. It keeps using latency and error telemetry internally, adds clearer definitions to its standard terms for new customers, and drafts an opt-in AI training addendum for customers who choose to take part. The logs stay where they are.

How SourceX approaches AI feature logs#

SourceX treats customer prompts and outputs as out of scope by default when it reaches Rights, the second step of the SourceX five-step transaction, unless customers have given express written authorization for the specific use. Company-owned records and properly authorized categories can proceed to Preparation and Approval.

For any included category, the SourceX Evidence Packet documents where the records came from, the licensing rights and permitted use behind them, the privacy record and who authorized release. Buyers increasingly expect that kind of metadata: the Data & Trust Alliance's Data Provenance Standards, for example, include elements for consent documentation location, license to use and intended data use.