All insights
EN · AI Strategy & Transformation

Who owns the code, data, and prompts in an AI services engagement?

Negotiate ownership, licenses, access and reuse for each AI asset—not one generic IP clause for the entire engagement.

Eight AI project assets connect to a contract boundary that distinguishes ownership, licenses, access and third-party dependencies.
AI Rights & Reuse Proof-8 turns intellectual property into verifiable operating rights for each asset. · Generated with OpenAI

Do not resolve an AI engagement with “the client owns all IP.” Separate every asset and define four things: who owns any legally recognized right, which license each party receives, which uses are prohibited, and which access must survive termination. Buyers should generally retain control of their data, requirements and strategic assets; receive broad rights to project-specific deliverables; and secure sufficient licenses, portability and documentation for provider background material and third-party components.

The answer changes by jurisdiction, asset type, human contribution, model terms, data provenance and supplier chain. WIPO emphasizes that AI and IP analysis is jurisdiction-specific; the U.S. Copyright Office separately addresses copyrightability of generative outputs. Use this framework for diligence, then have local counsel validate the final rights register and drafting.

The AI Rights & Reuse Proof-8

Score each asset class from zero to four: zero is unidentified; one is a generic promise; two is a partial list; three is documented rights plus evidence; four is tested access, export and exit. Require at least 24 of 32, no zero and passage of five mandatory gates.

  • Background assets — methods, libraries, templates and know-how each party had before the engagement.
  • Project-created deliverables — code, interfaces, schemas, automations, documentation and infrastructure produced for the work.
  • Data and source materials — buyer data, licensed datasets, content, labels, embeddings and derived sets.
  • Models and third-party components — foundation models, APIs, open source, connectors, plugins and their licenses.
  • Prompts and configuration — system prompts, policies, tools, workflows, memory, parameters and guardrails.
  • Outputs and human contribution — generated material, selection, editing, approval and evidence of human authorship.
  • Evaluations and operating signals — test sets, rubrics, feedback, logs, traces, incidents and operational learning.
  • Access and exit — repositories, accounts, keys, formats, documentation, transition support and post-termination rights.

Build a rights register before the SOW

For every asset, record source, creator, stated owner, license, territory, term, sublicensing, restrictions, data used, storage, accountable party, evidence and exit treatment. Add a “rights needed” field: own, modify, operate, train, evaluate, audit, sublicense, publish or internal use only. Ownership is not required for every component, but every critical component needs sufficient operating rights.

The UK Mid-Tier IPR schedule is useful because it treats rights as configurable contract choices. A firm can retain its general framework without taking buyer data, configuration or customer-specific implementation. A buyer may not own the foundation model but should understand its terms, receive the configuration and retain a credible substitution path.

Five mandatory gates

  • The provider cannot produce an inventory of material components and licenses.
  • Buyer data, prompts, feedback or outputs may train provider products without separate explicit authorization.
  • The buyer lacks repository, configuration, evaluation and documentation access needed to operate or migrate.
  • A third-party license blocks intended commercial use, modification, scale or geography.
  • The provider promises exclusivity or copyright in outputs without qualifying law, human contribution and model terms.

Buyer data is not the same as derived data

Separate raw data, corrected records, labels, embeddings, indexes, features, feedback and logs. State who may create each derivative, for what purpose, for how long and whether it can be aggregated across customers. Prohibit reidentification and incompatible use. Define return, deletion and evidence at termination, plus applicable privacy obligations.

Prompts and evaluations may be more strategic than code

With managed models, differentiation often lives in instructions, tools, policies, test sets, acceptance rubrics and feedback. If those assets exist only in a provider account, the buyer can own code and still be unable to operate. Require versioning, export, documentation and rights to modify and reuse them within the agreed field.

Treat third parties as a supply chain

NIST's SSDF covers secure-development and supply-chain practices. Ask for an inventory connecting component, version, source, license, data sent, region, subcontractor, update process and replacement plan. Assign responsibility for monitoring term changes and for remediation when a dependency becomes unusable.

Outputs need a use policy, not an absolute promise

Define permitted uses, human review, prohibited brands and content, evidence retention, third-party claims and responsibility for materials supplied by each party. In the United States, the Copyright Office distinguishes human contribution from purely AI-generated material. Other markets differ. Do not contract for legal protection the law may not provide.

Turn the register into acceptance evidence

  • Before first payment: background and third-party asset inventory.
  • Before validation: terms for data, models, prompts, evaluations and feedback.
  • Before production: repositories, accounts, documentation, licenses and incident process.
  • Before final acceptance: tested export, dependency list, operating materials and deletion evidence where required.
  • At exit: continuity, transfer assistance, access revocation and the rights that remain in force.

The EU AI model clauses are useful for system-specific obligations, but the official resource makes clear that IP, acceptance, payment and liability must be addressed in the main agreement. AI compliance does not itself create the operating rights a buyer needs.

Connect rights, contract, evaluation and exit

Use https://makinai.co/insights/en/what-to-include-ai-services-contract-sow for the main agreement, https://makinai.co/insights/en/how-to-choose-ai-evaluation-testing-company to protect evaluation assets and https://makinai.co/insights/en/how-to-assess-ai-vendor-lock-in-exit-plan to test portability. Explore https://makinai.co/services/en/ai-strategy-transformation-consulting.

When to involve MAKINAI

MAKINAI can map assets, dependencies and operating needs before negotiation, convert the register into proposal requirements and test whether purchased rights support operation, evaluation and migration. Qualified counsel should approve the final legal drafting in each applicable jurisdiction.

Sources and references

  1. WIPO — Learning Machines · WIPO

    Explains how AI, data, models, outputs and different forms of intellectual property interact, while emphasizing jurisdiction-specific analysis.

    2026-09-01
  2. U.S. Copyright Office — Copyright and AI · U.S. Copyright Office

    Collects the official reports on output copyrightability, digital replicas and generative-AI training.

    2026-09-01
  3. UK Mid-Tier Contract — Schedule 6 IPR · UK Government

    Provides a modular reference for intellectual-property terms in services and technology contracts.

    2026-09-01
  4. NIST — Secure Software Development Framework · NIST

    Covers secure-development and supply-chain practices relevant to AI models, components and software.

    2026-09-01
  5. EU — AI Model Contractual Clauses · European Commission Public Buyers Community

    Provides AI-specific clauses while making clear that IP, acceptance, payment and liability belong in the main agreement.

    2026-09-01
Making connections

Continue exploring

AI Strategy & Transformation

How to define AI provider governance and performance management before hiring

Read insight
AI Strategy & Transformation

How to evaluate an AI consulting ROI business case before hiring

Read insight
AI Strategy & Transformation

Boutique AI firm, global consultancy, or systems integrator: how to choose

Read insight
Related capability

AI strategy & transformation

An AI transformation consultancy should answer four questions before recommending technology: where business value exists, which capabilities and data are required, how risk will be controlled, and who will operate the change. MAKINAI connects those answers in an executable plan with priorities, owners, metrics and scale decisions.

Explore this capability