AI data licence terms for training, fine-tuning and RAG

The developer's engineering lead should describe the actual processing stages before legal teams negotiate the word “use”. Record the source material, copies created, recipients and resulting assets at each stage. A retrieval-augmented generation system, or RAG system, retrieves material to supply context to a model. Its retrieval function should have a separate permission entry even where the same product also trains or fine-tunes models.

The use schedule should distinguish:

1. Ingestion and preparation: downloading, storing, deduplicating, translating, annotating and converting content. Identify reproduction rights and any adaptation rights engaged by the particular transformation. Technical preprocessing does not automatically constitute a legally protected adaptation.
2. Indexing: creating chunks, embeddings, search indexes and associated metadata. Specify whether the index retains source text, permits reconstruction or gives access to protected database contents.
3. Retrieval: searching the collection, selecting passages and placing them in prompts or context windows. Identify who receives the passages, including any external model provider.
4. Pre-training: using the permitted material to develop the named model or model family. Specify whether successors and additional training runs are included.
5. Fine-tuning: modifying an existing model, including separate adapters or other parameter updates. Identify the base model and the intended customer or product.
6. Evaluation: using test sets, human review, benchmark prompts and generated answers. State whether examples or results may be published and whether evaluation feedback can enter training.
7. Output delivery: displaying quotations, reproducing images, distributing answers or allowing customers to export retrieved material. Agree attribution and source-display conditions separately from model development.

For EU operations, reproduction and public communication rights require separate analysis. Database copyright and the right against substantial extraction or re-utilisation can overlap with rights in individual contents. Repeated systematic extraction of small portions can also engage database protection. A short passage is not automatically free to reproduce. (Directive 2001/29/EC, Articles 2–3; Directive 96/9/EC, Articles 3(2), 5 and 7(1), (5).)

For copying in Ireland, apply the national provisions on reproduction, making available and adaptation, together with database rights. For UK copying, assess the corresponding restricted acts under the Copyright, Designs and Patents Act. For US activity, assess the relevant exclusive rights and any applicable limitation. The server, processing and disclosure locations therefore belong in the legal review. (Copyright and Related Rights Act 2000, sections 37, 39–43 and 324; Copyright, Designs and Patents Act 1988, sections 16–21; 17 U.S.C. §§ 106–107.)

The legal team should approve each operation against the rights actually available. If source passages may be indexed internally but not displayed to customers, the product must enforce that boundary before retrieval goes live. The separate AI training-data copyright and transparency analysis addresses the comparative copyright background.

The licensor should supply a provenance record at source level or for a collection sharing the same rights. The developer should connect that record to the delivered dataset version. A warranty is a contractual allocation of responsibility; the acceptance process still needs the documents supporting the grant.

Apply five checks before admitting material to a permitted use:

1. Identify the asset and rights holders. Separate the database, individual works, recordings, performances and annotations. Identify personal data and confidential customer material alongside them.
2. Trace acquisition. Obtain the relevant employee terms, contributor agreement, assignment, licence or other entitlement. Check signatures and formalities where required. Irish, UK and US law each prescribe writing requirements for specified copyright transfers or exclusive arrangements. (Copyright and Related Rights Act 2000, sections 120 and 122; Copyright, Designs and Patents Act 1988, sections 90 and 92; 17 U.S.C. § 204(a).)
3. Test the rights received. Compare permitted purposes, territories, term, adaptation, attribution and onward licensing with the proposed workflow. Identify moral rights and any consent or waiver the applicable law permits and the use requires.
4. Check restrictions and competing grants. Record confidentiality duties, customer prohibitions, exclusivity, open-licence conditions and reservations against text and data mining. A publisher or aggregator may control only part of the relevant rights.
5. Record the decision. Admit the source for specified operations, restrict it to a narrower use, obtain further permission or exclude it. Preserve the supporting agreement and its version so later challenges can be traced to affected data and models.

Check statutory limits on the durability of upstream grants. Qualifying US grants executed by authors after 1977 can be terminated despite contrary terms, subject to statutory timing and notice conditions; works made for hire are excluded. Do not assume that the protection for certain existing derivative works covers trained weights. Irish author and performer contracts can trigger remuneration, transparency and adjustment duties, and revocation of qualifying unexploited exclusive grants after the required notice process; the relevant Part excludes computer-program authors. Record the applicable obligations and termination exposure before promising continuing model use. (17 U.S.C. § 203(a)–(b); S.I. No. 567 of 2021, regulations 25–29 and 31–32.)

An exception can change the permission decision. Under the EU text and data mining rules, the general exception requires lawful access and the absence of an appropriate express rights reservation. The separate scientific-research exception has institutional and purpose conditions. Neither automatically supplies permission to publish retrieved protected content. (Directive (EU) 2019/790, Articles 2(1), 3–4 and 7.)

Preserve statutory protections against contractual override, including qualifying scientific-research mining and specified lawful-user activities for databases. Confirm the relevant national implementation before enforcing an exclusion. (Directive (EU) 2019/790, Article 7(1); Directive 96/9/EC, Articles 6(1), 8 and 15.)

Ireland's commercial mining provision specifically recognises machine-readable reservations for publicly available online content. Its contract-override provision also protects uses that qualify for the exception. The parties should distinguish a valid rights reservation from an attempt to contract out of an available mandatory protection. The wording now refers to the “rightholder” following the September 2026 amendment. (Copyright and Related Rights Act 2000, section 53B(1)–(6); S.I. No. 469 of 2026, regulation 2(b).)

The UK's section 29A exception requires computational analysis for the sole purpose of non-commercial research, lawful access and sufficient acknowledgement unless impracticable. It does not clear commercial training simply because the activity involves research. US fair use requires the statutory assessment for the particular copying and use. Where the business depends on an exception, record its conditions and the product restrictions needed to stay within it. (Copyright, Designs and Patents Act 1988, section 29A(1)–(5); 17 U.S.C. § 107.)

The grant should identify the licensor, developer and licensed dataset precisely. Attach a manifest with source identifiers, versions, delivery dates and exclusions. Include updates only through an agreed acceptance procedure. A new delivery can contain different contributors, restrictions or personal data, so permission for an earlier version should not silently expand.

Specify the approved operations, models, purposes, customer groups, commercial channels and duration. Separate internal experimentation, a customer-specific model, a shared commercial model and redistribution of data. State whether training is restricted by model family, customer, sector or deployment. Avoid a general “service improvement” permission where the parties intend a narrower use.

Map acquisition, export, storage, remote access, training and customer delivery separately. The licensor should identify source-country restrictions and upstream export conditions. The developer should identify each destination and provider location. Counsel should record the applicable legal clearance before adding that location to the schedule. A governing-law clause cannot itself supply a missing statutory permission or a third party's rights.

For personal data, the responsible controller must establish the processing purpose and lawful basis before processing. Where EU GDPR applies, special-category data needs an Article 9 condition and criminal-offence data needs the conditions in Article 10. Assess notices, data minimisation, retention and the need for a data protection impact assessment. A licence between two companies is not itself the data subject's consent. (Regulation (EU) 2016/679, Articles 3, 5–6, 9–10, 13–14 and 35.)

Where UK GDPR applies, conduct a separate purpose, lawful-basis and special-category review under its amended provisions, including Article 8A for further processing. The basis for recognised legitimate interests in Article 6(1)(ea) requires an Annex 1 condition; it does not authorise AI training generally. (UK GDPR, Articles 5, 6, 8A and 9.)

Allocate roles from the actual decisions about purposes and means. A supplier acting only on instructions requires processor terms; a developer deciding to train its own shared model may be a controller for that processing. Joint decisions may require a joint-controller arrangement. Record those roles by operation, with responsibility for rights requests, incidents and supplier oversight. (Regulation (EU) 2016/679, Articles 4(7)–(8), 26 and 28.)

Transfers require their own route. EU GDPR Chapter V applies to qualifying transfers outside the EEA. UK transfers must be checked under the amended UK GDPR, including Article 44A and the applicable safeguard provisions. Identify the actual recipient and onward access, then establish the applicable adequacy or safeguard route, or a qualifying derogation for a specific situation, before transfer. In the US, also check the state, sector and sensitive-data rules triggered by the people, data and transaction. The Data Protection and GDPR for AI guide develops the privacy workstream. (Regulation (EU) 2016/679, Articles 44–46 and 49; UK GDPR, Articles 44A, 45A, 46 and 49.)

Confidentiality and customer restrictions can prevent reuse even where copyright permission exists. Obtain the customer's amendment or consent where its contract requires it, or remove that material. Keep customer prompts, retrieved passages and feedback outside shared training unless that use has passed the agreed rights and privacy checks. Where information qualifies as a trade secret, unauthorised acquisition, use or disclosure can create separate liability. (Directive (EU) 2016/943, Articles 2 and 4; S.I. No. 188 of 2018, regulations 2–6; Trade Secrets (Enforcement, etc.) Regulations 2018, regulations 2–3; 18 U.S.C. §§ 1836(b)(1) and 1839(3), (5)–(6).)

List cloud hosts, annotation providers, embedding services and model providers by function. Distinguish a provider performing the developer's authorised work from a recipient obtaining its own exploitation rights. Approval to host a dataset should not become permission to improve an unrelated model or resell the data.

The developer should obtain terms covering purpose restrictions, confidentiality, security, permitted locations, onward providers and deletion. Check those terms against the actual service configuration and logging settings. If a necessary supplier insists on reuse outside the grant, obtain the missing permission or change the supplier or architecture before sending data. For EU processors, Article 28 separately governs authorisation, contractual terms and the initial processor's responsibility for subprocessor performance. (Regulation (EU) 2016/679, Article 28(2)–(4).)

Define derived assets individually: cleaned datasets, annotations, embeddings, indexes, adapters, checkpoints, weights and generated outputs. Allocate contractual ownership or use rights only to the extent the relevant rights exist and the allocating party holds them. Describe permitted exploitation separately. Calling an asset “derived data” does not decide whether it contains protected expression, personal data or confidential information.

The product team should document what can be extracted or reproduced from each asset. Anonymity needs evidence about the particular model and reasonably likely means of identification or extraction. The EDPB's AI-model opinion treats anonymity as a case-specific assessment; it does not assume training removes personal data. That opinion is regulatory guidance. The underlying GDPR obligations remain statutory. (EDPB Opinion 28/2024, paragraphs 29–40 and 54–57; Regulation (EU) 2016/679, Article 4(1) and recital 26.)

For outputs, agree who can display, redistribute or commercialise them and which source-use restrictions survive. Attribution does not replace a required permission. Put controls around protected passages and restricted customer content, including source-level takedown and correction procedures. Any ownership allocation between the parties should preserve third-party rights. (Directive 2001/29/EC, Articles 2–3; 17 U.S.C. § 106.)

Where the developer places a general-purpose AI model on the EU market, the licence must accommodate applicable AI Act duties. Article 53 requires a copyright-compliance policy and a public summary of training content. Obtain the source categories, provenance and reservation information needed for those obligations. Confidentiality terms should permit required disclosures while protecting information beyond what must be disclosed. A RAG implementation is not automatically a general-purpose model provider; classify the actual activity. (Regulation (EU) 2024/1689, Articles 2(1)(a), 3(3), (63), and 53(1)(c)–(d).)

The general-purpose model obligations began applying on 2 August 2025. Providers of models placed on the market before that date have until 2 August 2027 to comply. The July 2026 amendment did not replace those dates with the later high-risk-system timetable. Record the relevant model's first market date and any modification requiring a fresh classification. (Regulation (EU) 2024/1689, Articles 111(3) and 113, as amended by Regulation (EU) 2026/1744.)

The parties should decide what happens on expiry, breach, loss of upstream rights and a source-specific challenge. The developer should maintain enough lineage to identify affected datasets, indexes and model versions. The agreed response should distinguish stopping a new training run, disabling retrieval, withdrawing outputs and restricting an affected model.

For ordinary expiry, choose expressly whether previously trained models may continue operating. If continued use is permitted, identify the model versions, purposes, customers and duration. Address separately whether further training, refreshing an index or creating another model is allowed. Any survival depends on the rights actually secured and continuing compliance with applicable law.

Set deletion rules by asset. Raw data, cleaned copies, retrieved chunks, embeddings, caches, logs and backups require an identified owner and process. Specify operational deadlines, backup isolation, restoration controls and evidence of completion. Retain material for legal claims or mandatory records only on an applicable legal basis and under restricted access. For EU processor services, Article 28(3)(g) requires deletion or return at the controller's choice and deletion of existing copies, unless law requires storage.

Do not equate deleting source files with removing their influence from model weights. Require the developer to explain the proposed unlearning or remediation method, affected versions, test conditions and residual limitations. Agree the alternative if that method cannot achieve the required result: retraining, replacing an affected component or withdrawing the affected model. Contractual exit arrangements must also accommodate applicable erasure grounds and exceptions. (Regulation (EU) 2016/679, Article 17; EDPB Opinion 28/2024, paragraphs 38–40 and 54–57.)

The licensor should warrant its authority to grant the specified rights and the accuracy of agreed provenance disclosures. The developer should commit to the agreed use limits and supplier controls. Avoid replacing these commitments with a broad promise that every future model output will be free of every third-party claim.

Negotiate evidence access proportionate to the proposed use and the identified gaps. Permit inspection of relevant upstream rights, source logs and supplier terms, with confidentiality protections and an independent auditor where appropriate. Define notification and cooperation duties when a right is disputed or an upstream licence ends. Material changes should trigger a review of the affected source before further use.

Allocate claim handling and costs expressly. Address defence control, settlement consent, interim suspension, securing replacement rights, removing data, rebuilding indexes, retraining and refunds. Connect each indemnity to the breach or rights failure it covers. Allocate the developer's unauthorised expansion separately from defects in the licensor's grant. Review exclusions and caps under the selected governing law; the label “data licence” does not settle their enforceability.

Where the EU Data Act applies, Article 13 can make unfair terms on data access, use and related liability or remedies non-binding on the enterprise on which they were unilaterally imposed. Chapter IV reaches private-sector data contracts beyond connected-product data and applies to contracts concluded after 12 September 2025. Identify the data holder and any recipient in the Union. Retain the negotiation record: unilateral imposition requires that the other enterprise could not influence the supplied term despite trying to negotiate. Review liability exclusions, sole control of conformity decisions, restrictions on data use and exit terms against the relevant statutory tests. The rule excludes main-subject-matter terms and price adequacy; covered parties cannot contract out of it. (Regulation (EU) 2023/2854, Articles 1(2)(c), 1(3)(c)–(d), 13 and 50.)

A payment remedy cannot authorise continued infringement. Preserve the ability to stop the affected activity while the parties assess permission, replacement or withdrawal. Third-party injunctions and statutory personal-data rights remain separate from the parties' allocation of losses. (Copyright and Related Rights Act 2000, section 127; Copyright, Designs and Patents Act 1988, section 96; 17 U.S.C. § 502; Regulation (EU) 2016/679, Article 17.)

Before signing, the legal, engineering and procurement owners should confirm the accepted dataset, approved operations, source evidence, provider terms and exit procedure. Release the relevant operation only when its agreed acceptance conditions are satisfied. An unresolved source can be excluded while the cleared portion proceeds within its own permissions.

Review a training-data licence. Bring the draft licence, provenance records and proposed uses and locations. Licentium can scope a review of the permission chain, supplier restrictions and exit terms, with the amendments and local-law checks needed for the intended deployment.