Agents, code, data, assets: how to build a contract of trust

When an engagement combines consultants, developers, agents, third-party models, client data and reusable assets, simply asking "who owns the deliverable?" isn't enough anymore. The real question becomes: who can use what, for what purpose, for how long, with what ability to control, exit and prove, and who's accountable when the system gets it wrong or acts badly.

Intellectual property still matters. But in the age of agents, a good contract of trust is less a contract of ownership than an architecture of control.

In brief

• •Distinguishing the provider's pre-existing assets, assets created for the client, and co-developed elements is still useful, but no longer enough: third-party models, derived data, agent memories, execution logs and generated outputs all need addressing too.
• •"The client owns it" is often too thin an answer. Usage, modification, reuse, delegation to a third party, export, and deletion rights all need spelling out.
• •The model vendor's terms are now part of the engagement's economics and risk. They shouldn't stay an invisible dependency hiding behind the main contract.
• •Reversibility doesn't necessarily mean handing over all the code or all the IP. It mainly means guaranteeing a client can keep going, migrate, or have the service taken over without losing its data, its history, or its operational capability.
• •The more autonomy agents gain, the more traceability becomes a condition for accountability: without the ability to reconstruct the data used, the agents involved, the services called, and the human validations, the contract promises an accountability that will be hard to establish.

The new problem: the "deliverable" no longer has a clean boundary

In a classic IT engagement, the contractual split could seem fairly legible: the client supplied data and specs; the provider supplied work, code, documentation, or a service; the contract then assigned rights over the deliverables.

An agentic chain blurs this split.

An agent can combine a method the IT services firm developed earlier, a model supplied by a third party, open-source libraries, the client's documentation, its source code, tickets, data retrieved through augmented search, system instructions, prompts, persistent memory, and tools able to act on the IT system.

The output itself can be code, a proposed decision, a data change, or a directly executed action.

Three categories remain useful for orientation: the firm's pre-existing assets, assets co-created during the engagement, and assets belonging to the client — a logic that gradually pulls the consulting relationship closer to a SaaS model, where the vendor keeps its engine while the client keeps its data and receives defined usage rights.

Transposing this to IT services firms leads to the same conclusion: intellectual property, integration, operational accountability and trust all become structural dimensions of the AI-augmented engagement.

But this three-category grid now needs completing.

The contractual question is no longer just "who owns the asset?". It becomes "who keeps control of the system?"

What the sources actually show

The best-documented change isn't a new universal IP doctrine. It's the growing number of boundaries that need governing.

The Cigref-Numeum guide on the contractual impact of AI projects explicitly recommends addressing rights over training data, input data, generated outputs, and the system trained on the client's data. It also calls for accounting for the licences and terms attached to third-party models and components.

The same guide addresses accountability, audit, reporting and contract termination separately. It notes that an AI system combines multiple parties and components, which makes attributing a malfunction harder. It therefore recommends precisely identifying roles and anticipating result-related liabilities contractually.

This problem becomes even more tangible with agents. In a note published in July 2026, the CNIL — France's data-protection authority — observes that agents' ability to draw on multiple sources, memories, other agents and third-party services multiplies data flows and makes identifying, tracing and controlling processing harder. It proposes, in particular, being able to reconstruct, for any given task, the data used, the agents involved, the third-party services called, and their timeline.

This rise in oversight is consistent with what's observed elsewhere: across a panel of thirty organisations selected for their organisational signals, with no claim to being representative, several cases document a shift of work toward review, supervision and exception-handling. The "human on exceptions" and "agentic development" models both place the human control loop right at the centre of how things run.

The Roundtable case is especially interesting for governance: in this regulated activity, legal constraints are built into the automations upfront rather than addressed only after go-live. This is an account, not proof that this setup is a sector standard.

What these sources don't let us claim

First, they don't let us conclude there's one universally good model for sharing IP.

Co-created assets frequently fall under shared ownership, with this caveat: demanding full handover of the assets can discourage the provider's investment. This is an interesting economic framework, but it's neither a general legal rule nor an optimal solution in every situation.

For a critical system built almost entirely for one client, for a strategic component with no substitute, or when a provider's failure would create a major operational risk, a broad code transfer or escrow-like mechanisms can be perfectly rational.

Conversely, demanding ownership of a provider's generic engine, methods, and every reusable component can make pooling them across several clients economically impossible.

So both mirror-image reflexes need resisting:

"I paid, so everything's mine" isn't a sufficient sovereignty strategy.

"It's our platform, so all you need is access rights" isn't a contract of trust either.

The right balance depends on the asset's nature, how differentiating it is, how substitutable it is, and the cost of the relationship breaking down.

The conviction: ownership is one dimension of control, not a synonym for it

It's useful to reason across four separate dimensions.

Title answers the question: who legally holds the available rights?

Usage answers: who can operate, modify, share, reuse, or have the asset operated?

Exit answers: what's left for the client when it switches providers?

Accountability, finally, answers: who needs to be able to show what happened when an error occurs?

This split avoids much of the false debate in contracts.

A client can not own an agentic engine while still holding a durable usage right, the ability to export its configurations, data and history, documentation letting a third party take over, and a model-substitution mechanism.

Conversely, it can legally own a specific piece of custom development while being unable to make it work, because it depends on a model, a platform, an index, or an orchestration layer it doesn't control.

Owning without being able to exit is theoretical sovereignty.

Separate pre-existing assets from what's genuinely created for the client

The first discipline is establishing the asset inventory before the engagement.

An IT services firm should be able to declare what it already brings: a framework, an agent, a connector, a library, an architecture, a licensed dataset, an eval suite, a method, a rules engine, or a software component.

The client can then clearly distinguish what it's paying for a usage right versus what it's genuinely funding as custom development.

This distinction protects both parties. It stops the provider from discovering, at the end of the project, that the client is claiming its generic base. And it stops the client from discovering that something presented as "its" new system actually depends on an asset it can't access after the contract ends.

This matters especially for AI-generated code: its automatic origin doesn't magically turn every component into new, exclusive property. Third-party component licences, open-source dependencies, and pre-existing elements still need analysing.

A good IP appendix should look less like a generic clause and more like an architecture bill of materials.

Don't confuse a co-created asset with automatic co-ownership

The notion of a "co-created" asset is intellectually useful: an agent or an automation can genuinely result from a vendor method, development done during the contract, and data or business rules the client brought.

But legal co-ownership isn't necessarily the best way to translate this situation. It can, on the contrary, make future reuse difficult.

The contract benefits from breaking the asset down. The provider can, for example, keep its generic building blocks; the client can receive rights over the purely specific development; each can hold precisely defined rights over the adaptation layer.

In other situations, a broad, perpetual, or transferable licence can protect the client better than a poorly defined co-ownership.

A client can, in fact, negotiate a licence over customised elements, exclusive or not, knowing a full transfer's usefulness can be limited if the other components needed to run the system stay outside its control.

The debate, then, isn't "ownership or licence?".

It's: what operational rights will we need in three years?

Treat client data as a flow, not a contract line

Writing "data remains the client's property" is barely enough anymore.

An agentic system can handle the original data, but also extracts, indexes, embeddings, caches, conversation histories, memories, tool traces, or corpora created during operation.

The CNIL specifically points out that multiple memories and data flowing between agents and third-party services make locating, correcting and deleting personal data more complex.

The full cycle needs documenting, then: source, purpose, destinations, retention, access, subcontractors, deletion, and any reuse to improve the service.

For personal data, the legal status of each party can't be decided by a single commercial sentence. A provider can be a data processor for certain processing activities while being a data controller for others, depending on how it determines the purposes and means.

The contract of trust, then, has to answer a very concrete question: which data can leave which perimeter, to go where, and why?

Put third-party models inside the contract, not behind it

An engagement can be sold by an IT services firm while depending deeply on OpenAI, Anthropic, Google, Microsoft, or another vendor.

The risk, then, is having an extremely precise main contract while the decisive dependency is, in practice, left to third-party terms that nobody actually built into the contractual architecture.

It's advisable to account for the terms applicable to third-party models, software and components, and to adapt the contract's structure depending on whether the client contracts directly with the model vendor or the integrator takes on overall accountability.

Commitments need to be checked at the level of the specific service actually used, not just the brand. OpenAI, for instance, states it doesn't train its models on business data by default and attributes inputs and outputs to the client "to the extent permitted by law"; for the API, the retention policy also depends on the endpoints and configurations, with up to thirty days in some cases and zero-retention options for certain eligible uses.

This isn't a recommendation for or against this particular vendor.

This is exactly the problem: "we use such-and-such model" isn't sufficient contractual information.

You need to know the service version, the applicable terms, where processing happens, the retention policy, possible changes, the rights granted, the guarantees, the usage limits, and the replacement terms.

Don't promise rights over outputs that nobody is certain they hold

AI-generated outputs create a particular trap.

It's relatively simple to write, contractually, that the result must be delivered to the client, stay confidential, or not be reused by the provider.

It's far trickier to claim every output is necessarily protected by an exclusive, transferable copyright.

Protection for generated outputs remains an unsettled question: given this uncertainty, it's advisable to define their attribution contractually and, where needed, use confidentiality or exclusivity mechanisms. The EUIPO likewise describes the protection of generated content as an area still evolving, notably around originality and human contribution.

The operational consequence matters: the contract can organise the relationship between the parties; it can't create an intellectual-property right the law doesn't recognise.

For a strategic asset, it's better to reason simultaneously in terms of available rights, confidentiality, trade secrets, control over reuse, and documented human contribution.

Make reversibility a property of the architecture

In a classic system, a reversibility clause could come down to handing over data and documentation.

In an agentic system, exiting can require more: configurations, history, eval sets, business rules, connectors, schemas, a permissions map, agent documentation, a model inventory, operating procedures, and knowledge of third-party dependencies.

It's advisable to anticipate, from the contract stage, what happens to the system and the data when the relationship ends: continued use, takeover by a third party, handover, deletion, and rights over the modified elements.

The EU Data Act, applicable since 12 September 2025, also strengthens the ability to switch between data-processing service providers, notably in the cloud. It sets out a framework that eases switching, while still keeping distinctions with elements protected by the provider's intellectual property or trade secrets.

Reversibility doesn't necessarily require the client to own all of the provider's technology. It requires that the client not become a prisoner of what it doesn't own.

Replace abstract "auditability" with a list of available evidence

"The system is auditable" is a far too vague promise.

Auditable of what? The data used? The model selected? The system instruction? The tool calls? The human decisions? The configuration changes? The incidents? Compliance with autonomy thresholds?

It's advisable to keep documentation and logs throughout the lifecycle, and to let the client obtain audit evidence on how the system runs, is operated, is maintained, and how its risk is managed.

The CNIL goes further for agents: it envisions traceability that identifies the data, the agents, the third-party services, and the timeline of actions. It also recommends limiting access, siloing memories, and keeping human intervention for critical actions.

That doesn't mean the provider needs to systematically reveal all its proprietary prompts or internal code, though.

A compromise is possible: execution logs, versions, configuration fingerprints, a model and service registry, change history, metrics, incidents, and validations can make an engagement verifiable without giving away every trade secret.

Auditability shouldn't be measured by the volume of information accessible, but by the ability to reconstruct a significant event.

Make accountability follow real control

This is probably the most important rule.

A provider shouldn't be held unlimited accountable for a result it doesn't control. But a client shouldn't, either, bear sole responsibility for behaviour determined by an architecture, a configuration, or guardrails it doesn't control.

The contract, then, needs to distinguish several layers. The model vendor controls part of the model's behaviour. The IT services firm or integrator controls orchestration, context, certain safeguards, and the interfaces. The client controls certain data, permissions, business rules, and final decisions. A third-party vendor can control the application the agent acts within.

The allocation of accountability needs to reflect this operational reality, with liability for results, error thresholds, and verification obligations addressed explicitly.

The AI Act reinforces this need to think in terms of roles: obligations depend on the position occupied in the value chain and the system's category, not just on whatever the parties chose to write at the top of their contract. Certain transparency obligations under Article 50 have applied since 2 August 2026.

The CNIL raises the same problem for data: even in a system made up of multiple agents, a data controller has to remain identifiable.

Significant accountability should never be assigned without, at the same time, assigning the power to control the corresponding risk.

The counter-argument: why not just give the client everything?

This approach has an apparent simplicity.

The client pays. It gets the data, the code, the prompts, the adapted models, the automations, and every right. No more dependency question.

This can be rational for certain very specific scopes.

But applied systematically, it raises three difficulties.

The first is economic: a provider can't industrialise an asset across several clients if it hands over all of it on the first project.

The second is technical: having the source code doesn't guarantee the client can reproduce the platform, models, or third-party services the system needs to run.

The third is strategic: the provider can end up treating every engagement as disposable development instead of investing in maintained assets.

The reverse mistake, though, would be turning this argument into a justification for lock-in.

The right contract, then, aims less at maximising one party's ownership than at making dependencies explicit and substitutable.

This is where trust gets built: the provider protects what it needs to be able to reuse; the client protects what it needs to be able to keep operating.

A question matrix for negotiating the contract

The Dryve test: three scenarios to simulate before signing

A contract of trust should be able to survive three simple questions.

The model vendor doubles its price or discontinues the model used. Can you migrate? Who funds the operation? What tests confirm the replacement model stays acceptable?

The IT services firm disappears, or the client wants to switch providers. Can the new operator retrieve the essential data, configurations, operating knowledge, and history without rebuilding the system from scratch?

An agent takes a high-impact wrong action. Can you reconstruct the context, identify the data and systems used, know the model and agent version, retrieve the human validations, and determine the error's likely origin?

If the contract can't clearly answer these scenarios, its weakness probably isn't in one isolated legal clause. It's in the very architecture of the relationship.

Self-diagnostic: is your contract genuinely ready for agents?

Take your current contract or spec sheet and award one point every time you can answer, precisely and with no interpretation, each of the ten rows in the matrix above.

8 to 10 clear answers: your contractual architecture is starting to reflect the technical reality.

5 to 7: the setup is probably workable, but several dependencies remain implicit.

0 to 4: the contract probably still treats AI as a tool the provider uses, when it's become a component of the production chain.

The score matters less than the empty boxes. They're what show where to start the discussion between leadership, legal, procurement, security and delivery.

This grid is a governance and decision-making tool; it doesn't replace legal analysis tailored to a project and its regulatory context.

The conviction

Agentic AI doesn't make contracts impossible. It instead reveals a long-standing weakness: for a long time, we used the word "ownership" to address problems that were really about control, dependency, and accountability.

The answer isn't bolting a twenty-page "AI" appendix onto a classic contract.

It's making three architectures line up.

The technical architecture describes the models, agents, data, software and flows.

The contractual architecture assigns rights, obligations, accountability, and exit options.

The managerial architecture determines who decides, who checks, and who's accountable.

When these three architectures contradict each other, trust rests on people's good will.

When they line up, a client can grant its partners and its agents more autonomy precisely because it knows what will remain under its control.

This is probably where the real contract of trust plays out in the age of AI: not trying to eliminate every dependency, but making each one visible, governable, and reversible.