Somewhere in your organization today, someone is pasting a customer contract, a pricing sheet or a claims file into an AI tool. The tool will give a good answer. Depending on three or four sentences in terms nobody reads, it may also keep what was pasted and use it to improve a model. And the vendor keeps that improved model when your subscription ends.
AI data ownership covers more than the information you put in. It covers the outputs that come out, and the learned behavior in between. Who created the data rarely settles any of it; the contract does, and the clauses that decide it sit in the least-read parts of the agreement, under headings like "service improvement," "aggregated data" and "feedback."
This article walks through the six clauses that decide AI data ownership in practice: what each one gives away when it's written in the vendor's favor, what the enterprise-grade version looks like, and what European regulation already expects. It's written for the procurement, legal and technology teams who have to sign. It isn't legal advice, so read it alongside your own counsel.
Why is AI data ownership different from ordinary data ownership?
Because with AI, the value of your data no longer sits only in the data. It sits in what a model learns from it. A traditional SaaS vendor stores your records and gives them back. An AI vendor may also:
- Derive embeddings from your records
- Use them to fine-tune a model
- Tune the model's behavior on your users' corrections
- Sell that improved behavior to every other customer, your competitors included
None of that requires the vendor to claim ownership of your files. The files stay yours on paper while the value they created leaves through a clause you didn't read.
That's why AI data ownership has to be checked at three layers: the inputs you provide, the outputs the system produces, and the learned state that connects them. Most contracts cover inputs clearly, outputs vaguely, and the learned state not at all.
The stakes depend on the industry. For a marketing team pasting blog drafts, the exposure is small. For a bank, an insurer, a law firm or a fund, the inputs are the business. The case for on-premise AI in legal and financial services is largely about who controls what the model learns.
Clause 1: What do the training rights actually permit?
The question to ask: can the vendor use our data to train, fine-tune or improve any model, and for whose benefit?
Vendor-friendly language rarely says "we train on your data." It says the provider may use "customer content" to "improve the services." Or it grants the vendor a "perpetual, irrevocable license" to "feedback," where feedback is defined to include the corrections your users make to outputs. Both routes get the vendor the same thing: your data, or your experts' judgment, becomes part of a model the vendor owns and every customer uses.
Consumer tiers usually train by default, with an opt-out. Some enterprise tiers default to off. The word "enterprise" in a product name tells you nothing until you've read the clause.
The enterprise-grade version is unambiguous: customer data is never used to train, fine-tune or improve any third-party model, and there's no opt-out setting that an admin could flip or a product update could reset. That's the standard on Unframe's security page, and any vendor handling regulated data should be able to state it in the same plain terms. If the clause needs a lawyer to interpret it, it probably isn't saying no.
Clause 2: How long is your data kept, and who decides?
The question to ask: how long do inputs, outputs and everything derived from them persist after a request is done, and can we set that period ourselves?
The answer sets the size of your exposure in a breach, a subpoena or a vendor acquisition. Check three things:
- Is retention defined at all? Many agreements set a retention period for account data and say nothing about prompts and outputs.
- Who sets the period? Can you set it, down to zero, or does the vendor set it for "abuse monitoring" and "service quality" with no say for you?
- Does it cover derived artifacts? A vendor that deletes your uploaded document but keeps its embedding has kept the part a model can still learn from.
The enterprise-grade version keeps data only as long as it takes to deliver the result, gives you a configurable policy that goes down to immediate deletion, and applies that policy to derived artifacts as well as source files.
Retention is also where deployment becomes a contract term. Data processed inside your own perimeter, on-premises or in a private VPC, is retained on your infrastructure under your policy. The on-premise AI decision framework helps decide which workloads need that level of control.
Clause 3: Can the vendor reuse your data in aggregated or derived form?
The question to ask: what exactly counts as "aggregated" or "de-identified" data, and can any of it be used outside our account?
This is where ownership is most often lost while the customer thinks it's protected. A vendor that won't train on your raw data may still reserve the right to use it in "aggregated," "de-identified" or "statistical" form.
Those words sound harmless and cover a lot: the patterns in your contracts, the distribution of your claims, your industry's terminology, the corrections your experts made. De-identified is also a long way from anonymous. For specialized business data it's often easy to reverse, and a model that learned from a thousand of your loan files has learned your underwriting judgment, whether or not any borrower's name survived. European regulators see it the same way: the EDPB's 2024 opinion on AI models says a model trained on personal data can't be assumed to be anonymous.
The clause to look for defines derived data precisely, states whether any of it can leave your account, and treats embeddings, fine-tuned weights and learned behavior as customer data with the same rights as the source. The enterprise AI data security buyer's guide covers the procurement questions that bring this clause to the surface before the contract reaches legal.
Clause 4: Where does the data go, and through which third parties?
The question to ask: which third parties touch our data, which model providers are among them, and whose terms apply to our data while they have it?
The sub-processor clause names every third party that touches your data, and in AI that list usually includes the model providers themselves. Your contract with the platform vendor is only as strong as the vendor's contract with the model behind it.
Many AI products are assembled from someone else's models. If the vendor sends your prompts to a foundation model provider, that provider's retention and training terms apply to your data in transit, and they may differ from the terms you negotiated. So ask for the sub-processor list, ask which model providers are on it, and ask for the data terms behind each one. An LLM-agnostic platform that lets you choose the models, including ones running inside your own environment, turns this from a disclosure you have to trust into a decision you make.
Jurisdiction sits here too. Where a sub-processor runs is where your data legally sits during processing, and the provider's home country can matter as much as the region: an EU region of a US provider can still be reached by US law. This year added a sharper version of the same risk. In June, US export controls forced one of the leading frontier labs to suspend access to its top models for nearly three weeks. If that lab was a sub-processor behind your AI vendor, your workflows stopped with it. For regulated industries, the requirement is to know exactly where processing happens, and to be able to change it when a regulator, or events, require it.
Clause 5: What happens to your data, and the model, when you leave?
The question to ask: what do we get back, what gets deleted, and what does the vendor keep?
The exit clause decides whether ownership survives the end of the contract. It's the clause most likely to be missing entirely, and the one that matters most if the relationship goes wrong. Four questions settle it:
- Can you export your inputs, outputs and derived artifacts in a usable format, and by when?
- Will the vendor certify deletion of everything else, backups included, within a defined period?
- Is any model fine-tuned on your data deleted, returned or kept by the vendor?
- Does the accumulated context come with you: the entity definitions, rules and corrections that made the system useful? Or did it only ever exist in the vendor's proprietary format?
The last question turns AI data ownership into an architecture decision. If the context layer that holds your business knowledge lives in a platform you control, exit is a migration. If it lives inside a vendor's tooling, exit is a rebuild, and you'll find you owned the data all along without owning anything that made it valuable.
Clause 6: How do you verify the contract is being kept?
The question to ask: what gives us the right, and the means, to check?
A training ban you can't audit is a promise, and promises about data handling have a poor track record in this market. The enterprise-grade version has three parts:
- Independent certification of the vendor's governance, such as ISO 42001 for AI management systems alongside SOC 2 and ISO 27001.
- The right to see the evidence: detailed compliance artifacts on request, under NDA.
- Output traceability, so every result can be traced back to its source data and the steps that produced it.
Traceability is what makes the other clauses testable. If you can see what the system relied on, you can also see what it didn't. A vendor that resists verification is telling you something about the other five clauses.
The six clauses at a glance
Use this as a checklist when the next AI contract lands on your desk.
What does European regulation add to these clauses?
For European organizations, several of these clauses are less a negotiation than a legal requirement. Three frameworks matter most.
GDPR: a processor that trains on your data is no longer just your processor
When personal data is involved, your AI vendor is usually your processor under GDPR, which means it may only process that data on your documented instructions (Article 28). A vendor that uses your data to improve its own models is processing it for its own purposes, and for that processing it starts to look like a controller in its own right, with its own legal basis to find. That's a compliance problem for you as well as for them. The same article also expects your processor contract to cover sub-processor approval and the deletion or return of data at the end of the service, which maps straight onto clauses 4 and 5.
DORA: for financial services, most of these clauses are mandatory
If you're a bank, an insurer or an investment firm in the EU, DORA's Article 30 turns a good part of this checklist into required contract content. Every contract for ICT services, AI included, has to state where data is processed, cover data availability, integrity and confidentiality, and guarantee access to and return of your data in an easily accessible format if the provider fails or the contract ends. Where the service supports a critical or important function, the contract also needs unrestricted access, inspection and audit rights, and a tested exit strategy.
In other words: if your AI contract doesn't cover clauses 4, 5 and 6, it may not be DORA-compliant, whatever the product does.
The EU AI Act: you'll need the evidence, so make sure you keep it
The AI Act puts logging and documentation duties on organizations that deploy high-risk AI systems, and those obligations apply from 2 December 2027. If the logs and records that prove how your system behaved live only in a vendor's environment, under the vendor's retention policy, your compliance evidence depends on a contract you may not control. That's one more reason the verification and exit clauses should treat logs and traces as yours.
Across all three, the pattern is the same: European regulation increasingly expects you to know where your data goes, to get it back, and to prove what happened to it. The six clauses are how you make sure your AI contracts let you do that.
What does AI data ownership look like when it's built in?
The strongest data ownership doesn't rely on the contract at all, because the architecture never gives the data away in the first place. That's the design principle behind the way Unframe delivers AI.
Data is processed within the enterprise boundary, on the hyperscaler of your choice, in a private VPC or fully on-premises, so the retention and jurisdiction questions have answers you set. Customer data is never used to train, fine-tune or improve third-party models. Retention defaults to the minimum needed to deliver the result and can be set to immediate deletion.
The platform is model-agnostic, so you choose which models see your data and where they run, and you can change that choice when a provider's terms, or its access to your market, change. The business context that makes the AI useful lives in a knowledge fabric, a relational and semantic context layer you control, so it leaves with you rather than with the vendor.
The six clauses still matter, and you should still read them. But the easiest contract to enforce is one where the vendor built the system so it couldn't do what the clauses prohibit. If you'd like to see how that holds up against your own data terms, book a demo.
What else do enterprise teams ask about AI data ownership?
Do we own the outputs an AI tool generates from our data?
Usually the contract assigns output ownership to the customer, but check two things: whether the vendor keeps a license to reuse outputs for service improvement, and whether outputs are retained after delivery. Owning the outputs means little if the vendor keeps a copy and the right to learn from it.
Does an enterprise license stop a vendor training on our data?
Not automatically. Some enterprise tiers default training to off; others rely on an opt-out that an admin can change or a product update can reset. Read the training and feedback clauses rather than trusting the tier name, and look for a plain statement that customer data is never used to train or improve third-party models.
Is de-identified data safe to let a vendor reuse?
Often not, for specialized business data. Removing names doesn't remove the patterns, terminology and expert judgment a model learns from, and de-identification is often reversible. Treat embeddings, fine-tuned weights and aggregated patterns as customer data with the same rights as the source files.
Can an AI vendor train on our data under GDPR?
Only if it has its own legal basis for that processing. A processor may only process personal data on the customer's documented instructions, so a vendor that trains its own models on that data is acting for its own purposes and takes on controller-level obligations for it. The simplest position is a contract, and an architecture, in which customer data is never used for training.
What does DORA require in an AI vendor contract?
For EU financial entities, DORA Article 30 requires every ICT contract, AI services included, to state where data is processed, cover data integrity and confidentiality, and guarantee access to and return of data if the provider fails or the contract ends. Where the service supports a critical or important function, it also requires audit and inspection rights and an exit strategy.
What should happen to a fine-tuned model when we leave a vendor?
The contract should say so explicitly. The strongest position is that any model or context derived from your data is deleted or returned at exit, with certified deletion of backups within a defined period. If the clause is silent, assume the vendor keeps it.
Explore more blog posts from Unframe.
