Most data-rich companies are sitting on assets they don't realise they can monetise. Transaction logs, operational records, customer interaction histories, supply chain telemetry — individually, these look like operational byproducts. Together, they're the highest-quality training signal available to AI systems. And right now, the market for that signal is hungry.
The problem isn't demand. It's that the people who own this data — CFOs, general counsel, data governance leads — don't have a clear framework for answering the first three questions any licensing deal depends on: Is this actually legal? What's my exposure? What does a compliant agreement look like?
This article answers those questions. It's written for UK companies with proprietary datasets they haven't licensed — and for the advisors helping them work out whether and how to do it.
Why Most Proprietary Data Goes Unlicensed
The most common reason data stays locked down isn't legal prohibition — it's risk uncertainty. GDPR compliance feels abstract when you're trying to work out whether your customer transaction logs contain personal data, and if so, whether anonymisation is sufficient to allow licensing. CDPA (the Creative and Design Patents Act, often conflated with broader IP protections) is rarely a direct barrier but creates indirect complexity through employee and contractor assignment clauses. TUPE — the Transfer of Undertakings (Protection of Employment) Regulations — catches a surprising number of datasets built from HR, workforce planning, or operational staffing data.
The result is a default position of: don't license. Even when the data is genuinely compliant, the cost of legal uncertainty outweighs the potential revenue. That's an irrational equilibrium — and it's one a growing number of companies are beginning to challenge, partly because AI training data buyers are now offering standardised frameworks that shift compliance burden back onto themselves.
Increasingly, AI training data buyers are accepting contractual responsibility for downstream use compliance — meaning the supplier's exposure is often limited to the point of transfer. Know what your contract says before assuming you own all the liability.
The UK Legal Landscape for Data Licensing
Three frameworks interact when you're licensing proprietary data for AI training purposes in the UK: GDPR (and the UK GDPR that sits alongside it post-Brexit), the UK DSIT (Department for Science, Innovation and Technology) data sharing guidance, and the contractual terms between licensor and licensee. Understanding which obligations sit where is the first practical step.
UK GDPR — lawful basis is the starting point
Before you can license personal data — or data that derives from personal data — you need a lawful basis for processing it in the first place. The most common bases for commercial data collections are:
- Legitimate interests — valid for internal operational data and B2B datasets where the data subject's interests don't override yours. Requires a documented balancing test (LIA — Legitimate Interests Assessment).
- Contract — where processing is necessary to perform a contract with the data subject. Tends to be narrow; customer service records may qualify, but broad operational datasets usually don't.
- Consent — increasingly difficult to rely on for AI training purposes given the ICO's position that consent must be specific and freely given. Consent to "data use in accordance with our privacy policy" does not cover AI training licensing.
Where you hold data under legitimate interests, licensing it to a third-party AI developer for training purposes is a "further processing" scenario under UK GDPR Article 6(4). You need to assess compatibility with the original purpose — and if you can't establish that, you either need to re-obtain consent or remove the personal data entirely before licensing.
Anonymisation changes everything
The critical distinction is between personal data and anonymised data. Anonymised data — meaning data from which no natural person can be identified, and where re-identification is not reasonably possible given the available means — falls outside UK GDPR scope entirely. You can licence anonymised data without needing a lawful basis for the AI training purpose, because the law simply doesn't apply to it.
Getting anonymisation right is therefore the key to unlocking licensing. But "anonymisation" in this context isn't a binary state — it's a risk assessment. The ICO's guidance on anonymisation (last updated 2024) is clear: pseudonymisation (replacing names with IDs, masking some fields) is not anonymisation. True anonymisation requires removal or generalisation of quasi-identifiers, aggregation where necessary, and a documented re-identification risk assessment that takes into account the data the buyer will combine with your dataset.
CDPA and IP ownership of datasets
The Copyright, Designs and Patents Act 1988 matters for datasets in two ways. First, databases enjoy copyright protection under Part III of the CDPA — the structure and arrangement of a database is protected, not the data itself. Second, work created by employees in the course of employment is automatically assigned to the employer, which means datasets compiled by internal staff in the course of their normal duties are owned by the company — not by individual employees.
The practical implication: if your data team has been building datasets as part of their work, you own the database rights. If you've contracted external consultants or agencies to build datasets, check the assignment clause — many standard agency contracts don't automatically assign database rights, and the CDPA's default position (unlike copyright) is that database rights remain with the creator unless explicitly assigned.
The Transfer of Undertakings (Protection of Employment) Regulations 2006 can affect datasets derived from workforce or staffing data. If a dataset is built from HR records, performance data, or workforce planning outputs, it may contain information that TUPE regulations treat as originating from employment relationships. Get specialist advice before licensing HR-derived datasets — the liability sits upstream of the data.
The 7-Step Licensing Framework
Here's a practical step-by-step process for assessing and executing a compliant data licensing arrangement for AI training:
-
Classify your data by personal data content
Sort your candidate datasets into three categories: clearly non-personal (operational metrics with no natural person reference), clearly personal (any field linked to an identifiable individual), and ambiguous (aggregated data, pseudonymised data, data with quasi-identifiers). Only the first category is straightforward to licence. Everything else needs anonymisation assessment.
-
Run a re-identification risk assessment on personal data
For datasets in categories two and three, document what quasi-identifiers are present — age brackets, job titles, location data, transaction patterns, timestamps — and what external data sources a buyer might combine with yours. If re-identification is reasonably possible (with reasonable compute, for reasonable cost), the data must be anonymised before licensing. If it can't be anonymised to that standard, the dataset is not currently licenceable for AI training.
-
Confirm your lawful basis for any residual personal data
If your anonymisation pipeline can't fully remove all personal data (some datasets genuinely can't be fully anonymised without destroying utility), document your original lawful basis and assess whether AI training represents a compatible further processing purpose. If it doesn't, you need to either restrict the dataset to only the anonymised portion or re-establish a new basis (typically consent, for external third-party licensing).
-
Review IP ownership and assignment chains
Confirm that your company owns the database rights in the dataset — check employment contracts for staff-created datasets and agency agreements for externally created datasets. If rights aren't clearly assigned, negotiate an assignment now (before a buyer asks). An unlicensed dataset with ambiguous ownership is harder to licence than one with a clean chain of title.
-
Draft data licensing terms covering AI-specific obligations
Standard commercial licences don't cover AI training use cases. Your agreement needs to include: permitted AI training uses (training, fine-tuning, evaluation — or subsets thereof), restrictions on re-identification and reverse engineering, data deletion obligations upon licence termination, downstream compliance responsibility allocation (who is liable if the buyer's use creates a UK GDPR breach), anonymisation standard warranty (that the data meets your documented anonymisation threshold), and audit rights (ability to verify the buyer's compliance with agreed use restrictions).
-
Build a provenance record for the dataset
AI buyers — particularly those operating under DUAA 2025 obligations — will ask for provenance documentation. Your record should show: original data source and collection date, lawful basis for the original processing, anonymisation steps applied (what technique, what fields, what tools), date of anonymisation, and who performed the processing. This is what regulators and downstream AI developers will ask for; having it ready in advance is a competitive advantage in licensing negotiations.
-
Structure the commercial agreement
Data licensing for AI training typically runs on one of three structures: one-time licence fee for a specific dataset version, recurring subscription with updated dataset refreshes on a quarterly or annual cycle, or revenue sharing where the licensor receives a percentage of downstream model revenue or training cost savings. The structure matters because it affects your IP exposure and audit obligations. Revenue-share models in particular require careful contract drafting around what constitutes "use" of the licensed data.
What Your Licensing Agreement Must Include
Beyond standard commercial terms, AI training data licences need specific provisions that most off-the-shelf template agreements won't cover:
| Clause | Why it matters | Status |
|---|---|---|
| Permitted use definition | AI training is broader than "processing". Must explicitly name training, fine-tuning, evaluation, and benchmark testing as permitted uses. Model deployment is usually a separate right requiring separate negotiation. | Required |
| Re-identification prohibition | Explicitly prohibits the licensee from attempting to re-identify individuals from the dataset, combining it with external data for re-identification, or sharing it in a form that enables third-party re-identification. | Required |
| Audit rights | Your right to audit the buyer's use of the data — at minimum, the right to request evidence of deletion upon termination and to inspect their data handling records on reasonable notice. | Required |
| Downstream liability allocation | Specifies which party bears liability for a UK GDPR breach caused by the buyer's downstream use. Generally, if you have anonymised to the standard you warrant, the liability sits with the buyer — but this must be contractually explicit. | Required |
| Data deletion on termination | Obligation to delete all copies of the dataset (including any model weights derived from it) within a specified period (typically 30–90 days) of licence termination. Include derivative works. | Required |
| Warranty of anonymisation standard | Your warranty that the data has been anonymised to a stated re-identification risk threshold (e.g., "re-identification is not reasonably possible given available means"). Document the threshold in the schedule. | Required |
| Provenance schedule | A schedule attached to the licence documenting the data's origin, collection basis, anonymisation steps, and any prior licensing history. Required by DUAA-aware buyers; good practice for all. | Recommended |
| Revenue-sharing model terms | If running a revenue-share structure, define what constitutes "use" of the data, how model performance improvements attributable to the data are measured, and audit mechanisms for the buyer's reported revenue figures. | Recommended |
The Risk Matrix: Licensing vs. Leaving Data Unused
The decision to licence proprietary data sits at the intersection of commercial opportunity and compliance risk. Here's a structured view of the trade-offs:
| Scenario | Revenue potential | Compliance risk | Recommendation |
|---|---|---|---|
| Fully anonymised operational data (logs, metrics, aggregated behavioural) | High — high utility for AI training | Low — outside UK GDPR scope | Proceed |
| Customer data, anonymised to re-id threshold, with consent for further processing | High — rich feature set | Medium — depends on quality of anonymisation | Proceed with documented anonymisation record |
| Customer data, pseudonymised only (not truly anonymised) | Medium — licensing is limited | High — still personal data, buyer liability risk | Do not licence without full anonymisation |
| HR / workforce data | Medium — workforce behaviour signals | High — TUPE overlap, employee expectation of privacy | Specialist legal advice required |
| Data with no IP ownership chain (agency-created, no assignment) | Variable — depends on category | Medium — ownership dispute risk | Resolve IP assignment before licensing |
| Leave data completely dormant | Zero — no revenue | None — but asset remains unmonetised | Not optimal if data is licenceable |
The dominant failure mode is not licensing when you could have — it's licensing without getting the anonymisation and provenance documentation right upfront. Getting those two things right covers the vast majority of your compliance exposure and, increasingly, determines whether sophisticated AI buyers will engage with you at all, given their own DUAA 2025 obligations.
Getting the Anonymisation and Provenance Right
Provenance and anonymisation documentation is the practical heart of a compliant licensing operation. It requires two things: automated PII detection and anonymisation that can be documented at the dataset level, and a provenance tracking system that records every transformation step applied to the data from collection to the point of licensing.
For most companies, this isn't a one-time exercise — it's an operational capability. Datasets get updated, new fields get added, processing pipelines evolve. The provenance record has to keep pace. Platforms that handle this infrastructure for you — automating the anonymisation, maintaining the transformation log, and generating the provenance schedule on demand — are increasingly the practical route for companies that don't want to build this function in-house.