Embeddings, indexes, transformed datasets, evaluation corpora, and interaction logs are created during an engagement. They are the artifacts a receiving team most needs and the ones the governing contract is least likely to mention.
The question has four parts that get collapsed into one. Who holds the data. Who owns rights in it. Who is licensed to use it, for what. And who can practically export or rebuild it. Those have different answers, and a project can hold an asset it cannot use and cannot reproduce.
No general ownership rule
Rights in derived data do not follow from having created it.
US copyright practice distinguishes original compilation authorship, and potentially protected database contents, from plain facts and purely mechanical arrangement. Putting information into a database does not establish copyright in each fact within it.
EU law separates copyright in a qualifying selection or arrangement from rights in the contents, and adds a distinct database right resting on substantial investment, with its own conditions and limits. Article 13 of that directive expressly preserves other regimes, including contract, confidentiality, and data protection.
Neither framework classifies an embedding as a derivative work, as anonymous information, or as a freely transferable asset simply because a transformation occurred. So the operative instruments are the contract and the source licences, and the analysis has to be done rather than assumed.
The manifest
The workable artifact is a derived-asset manifest that maps each index, embedding set, transformed dataset, and log to its sources, the transformations applied, the rights asserted, the permitted purposes, the recipients, and the export dependencies.
Its value is in exposing the gaps. A team that owns its indexing code outright but built vectors from a licensed third-party corpus hands over the code cleanly, and leaves two questions unanswered: whether the source-derived assets can be copied to the recipient, and whether the recipient can rebuild an equivalent index. Neither follows from code ownership, and both determine whether the system works after transfer.
Purposes are not one purpose
Vendor retention is the second half of the question, and it fragments the same way.
Separate the purposes: delivering the contracted service, operational and security telemetry, model training or product improvement, support and human review, end-of-service preservation, and return or deletion. Each needs its own record of data classes, recipients, duration, authority, configuration settings, and evidence.
A vendor that agrees not to train on customer content and retains support transcripts under a service purpose has made a true statement that answers one row. The handover review records that purpose and its duration, then checks the applicable return and deletion terms against it.
Two legal anchors set the end-of-engagement position. Under GDPR, the controller chooses deletion or return after processing services end, including deletion of existing copies, unless Union or Member State law requires storage; the standard contractual clauses add termination detail and continued compliance until deletion or return occurs. Under HIPAA cloud guidance, the business associate agreement must provide for return or destruction of protected health information at termination where feasible, and where infeasible the protections continue with further uses and disclosures limited to the purposes that make return or destruction infeasible.
Continued protected storage is not permission for unrelated reuse. The two are frequently conflated in vendor responses.
The agreement is not the practice
A data processing instrument has to be binding, define the processing and safeguards, document instructions, and set subprocessor conditions. Where a processor improperly determines the purposes and means of processing, it is treated as a controller for that processing — the label in the contract does not settle the role.
Two further distinctions get lost. Controller-to-processor clauses are expressly distinguished from clauses satisfying international transfer requirements; substituting one for the other leaves a gap. And accountability stays with the transferring organisation under Canadian guidance, which also states plainly that a contract cannot override foreign law.
The practical method is to follow the actual data flows through experiment, operation, and handover, and link each purpose and recipient to a signed authority and to evidence that the safeguard is implemented. An agreement permitting evaluation of support queries in a specified environment does not extend to retaining them for vendor-wide training, nor to copying an index to a new operator. Both are new activities needing their own authority.
The rule
What stays fixed is that possession, rights, permitted use, and portability are answered separately for every derived artifact. What changes is which of the four is missing, and the missing one is discovered at handover unless the manifest was maintained during the build.
Where this fails
Code ownership is read as asset ownership. The repository transfers, the index does not, and nobody checks until a rebuild is attempted.
Copies outside direct control are unrecorded. Provider and subprocessor copies, support systems, and backups sit outside the receiving team’s reach. Deletion evidence has to cover the stores that actually exist.
Not to be confused with
A determination. Which rights subsist in a particular index is a legal question about specific sources, transformations, and jurisdictions. The manifest identifies what needs deciding; it does not decide it.
Anonymity. Transformation is not de-identification, and an embedding is not established as anonymous information by the fact that it no longer looks like text.