Design partner agreements for AI features: data rights to settle up front

Why data rights belong in the design partner agreement itself#

Data rights belong in the design partner agreement because the early AI build is when customer records are most likely to be copied into prompts, fine-tuning sets and evaluation suites. Once those copies exist, a later amendment cannot easily pull them back.

Changing terms after the fact also carries regulatory risk. In February 2024, FTC staff warned that a company adopting more permissive data practices, such as using consumers' data for AI training, and disclosing that only through a surreptitious, retroactive change to its terms or privacy policy may be engaging in unfair or deceptive practices. Design partners are usually businesses, but the lesson carries over: settle consent up front, in plain words.

A short data rights schedule attached to the agreement does more than a long general clause. It gives engineers a list they can follow and gives the partner's counsel something concrete to approve.

Clause checklist for AI design partner agreements#

The clause checklist below covers the decisions that most often go unanswered in pilot, beta and early access agreements. Each row is a question the agreement should answer in writing, with a common starting position you can adapt with counsel.

How to define data scope#

Data scope is defined best by system and record type, not by the phrase customer data. A partner that agrees to share Zendesk tickets and help center articles has not agreed to share call recordings, Salesforce notes or Slack exports, and the agreement should say so.

Include the date range, the fields that are excluded and who performs the export. Many partners prefer to export a filtered set themselves rather than grant API access, which also leaves them with their own record of exactly what left their systems.

Model scope: the clause most teams leave vague#

Model scope states which models can learn from the partner's records, and it is the clause most often left vague. There is a real difference between using records to configure the partner's workspace, fine-tuning an adapter that only that partner uses, and improving a shared model that every customer receives.

Write each tier as a separate permission the partner can grant or refuse. Also cover the model providers in your stack: if a hosted model vendor processes the partner's records, the agreement should say whether that vendor may retain inputs or use them for its own training, and point to the terms that bind it.

Feedback, outputs and evaluation sets#

Feedback clauses are written for product ideas, and they cause trouble when they are read to cover the partner's records. A standard clause granting a broad license to use feedback should carve out customer data, prompts and uploaded documents, so nobody argues later that a batch of tickets counted as feedback.

Outputs and evaluation sets need their own lines. Evaluation sets built from a partner's real cases stay useful to the vendor long after the program, so decide whether they are deleted at exit, kept only in de-identified form, or kept with the partner's written permission.

Fill-in fields for your data rights schedule#

A data rights schedule can be added to an existing design partner or early access agreement as an exhibit. The fields below are the minimum to complete before signing; adapt the wording with counsel so it fits the main agreement's definitions.

• 1Systems in scope, for example Zendesk, Jira, Salesforce or a shared document folder.
• 2Record types in scope and record types excluded.
• 3Date range of records and who performs the export.
• 4Permitted uses: configuration, partner-only fine-tuning, shared model improvement, evaluation.
• 5Model providers that may process records, with their retention and training terms.
• 6Ownership of outputs, labels and evaluation results.
• 7Feedback license with a carve-out for customer records.
• 8Redaction rules for personal and confidential details before any training copy is made.
• 9Exit triggers, the deletion list, any retained items and the deletion certificate.
• 10Onward licensing: prohibited unless a separate written consent is signed.

Illustrative: a scheduling vendor and three design partners#

Illustrative: a fictional field scheduling software company invites three customers to test an AI dispatch assistant. Each partner shares job records, technician notes and customer messages from its own account.

The data rights schedule limits use to each partner's own instance by default. One partner opts in to shared model improvement after reviewing the redaction rules; the other two decline. The feedback clause excludes job records, and evaluation sets are kept only for the partner that consents in writing.

When one partner leaves the program, the vendor deletes its prompts, its partner-only adapter and its evaluation cases, then sends a deletion certificate. Because the schedule named each item, the exit is a checklist exercise rather than a negotiation.

How SourceX treats design partner records#

SourceX treats records that a design partner shared with a software company as customer-controlled, so they are excluded from any licensing package by default. A design partner agreement that permits product improvement does not, on its own, permit licensing those records to an AI developer.

When a software company wants to license its own operational records, such as engineering issues, code reviews and internal support workflows, the Rights step of the SourceX five-step transaction separates company-owned records from customer content. The SourceX Evidence Packet then records permitted use and release authorization for what remains.