AI Model Licensing: Build a Rights Matrix Before Going On-Premise

AI model licensing for an on-premise avatar must cover the actions the customer will actually perform: install models, make operational copies, optimise them for chosen GPUs, recover them after failure, allow approved support and keep the service running when a contract changes. Permission to download a model is not enough. Nor is a supplier saying that a component is “open”.

The useful procurement artefact is a rights matrix. It maps every model, runtime, dataset and human identity in the avatar stack to the rights, restrictions, evidence and owner that apply. Architecture, legal, procurement and operations can then review the same facts before hardware is purchased or a pilot becomes dependent on an unsuitable component.

This is an architecture and procurement framework, not legal advice. Licence interpretation, copyright position and regulatory status require qualified review for the relevant deployment and jurisdiction.

Why on-premise changes the licensing question

In a managed cloud service, a customer usually buys an outcome or an API entitlement. The provider operates the models and supporting software, and the contract defines permitted use, data handling, service levels and outputs. That can be the cleaner model when workload volume is uncertain or the customer does not want to maintain the stack.

Customer-hosted deployment transfers more activity to the buyer. Model files may be copied into development, test, production and recovery environments. Engineers may quantise or compile them for local accelerators. An integrator may need access. Backups may cross sites. A fine-tuned adapter may contain customer data or intellectual property. Each action needs an explicit legal and operational basis.

An avatar also combines more than one AI model. Speech recognition, retrieval, language reasoning, safety, text-to-speech, voice, visual rendering and streaming may have different licensors and terms. Yepic’s guide to choosing an on-premise avatar stack explains the technical boundaries. The licensing review should follow the same component boundaries.

Open-weight is a delivery method, not a licence conclusion

“Open-weight” generally means that trained parameters are available to download. It does not, by itself, establish permission for commercial use, modification, redistribution or every regulated use case. The accompanying licence controls those questions, and model code, training information and datasets may have separate terms.

The Open Source AI Definition 1.0 sets a higher bar: freedom to use, study, modify and share the system, plus access to the preferred form for making modifications. A downloadable checkpoint that lacks those freedoms should not be described in a procurement record as fully open source.

Even a familiar permissive licence must be read rather than inferred from its label. The Apache License 2.0, for example, includes copyright and patent grants together with conditions on redistribution and notices. That makes it a useful illustration, not a universal approval for any model, dataset or combined system.

Build the rights matrix across five asset classes

Start with the existing AI bill of materials, then add a rights record for each dependency. At minimum, separate five asset classes:

1. Models and weights: speech recognition, language, moderation, voice, avatar rendering and any vision models.
2. Software and runtimes: orchestration code, inference servers, codecs, drivers, SDKs, container images and management tools.
3. Data and derived artefacts: training or tuning datasets, embeddings, adapters, evaluation sets, prompts, policy files and generated synthetic data.
4. Human and brand rights: actor likeness, cloned voice, performance, brand assets and any permitted translations or transformations.
5. Services and operational material: licence servers, update repositories, external APIs, support tooling, documentation and recovery packages.

SPDX provides an open standard for describing software, licensing, dataset and AI relationships. Its AI profile guidance explicitly connects models, data, software and service contracts. A team can use SPDX-compatible records where helpful, but the immediate goal is simpler: no production dependency without an accountable rights record.

Test seven rights for every dependency

1. Operate

Define who may run the component, for which purpose, legal entities, users, territories and environments. “Internal use” may not answer whether a group company, public-sector agency, managed-service provider or citizen-facing service is covered. Record prohibited sectors or uses separately from technical guardrails.

2. Copy and recover

Customer-hosted services need working copies, cached images, backups and disaster-recovery replicas. Establish whether these copies are permitted, how many may exist and where. A licence tied to one server or site can conflict with clustering, blue-green deployment or geographic recovery even when no additional user traffic is served.

3. Optimise and modify

Quantisation, pruning, graph optimisation, compilation and conversion may be necessary to meet latency and GPU constraints. Confirm whether they count as permitted modifications and whether modified files require notices or other obligations. Test the transformed artefact separately; a legal right to modify does not prove technical quality or safety.

4. Fine-tune and own derived artefacts

State who owns or may use adapters, checkpoints, embeddings, synthetic evaluation data and customer-created prompts. Define whether the supplier can access them, use them to improve a shared service or retain them after termination. Do not assume that ownership of tuning data automatically determines ownership of the resulting artefact.

5. Share operational access

List the parties that may possess or access each component: the customer, Yepic, an infrastructure provider, an implementation partner, an auditor and an emergency support engineer. Distinguish remote access from receiving a copy. Match those rights to the privileged-access and break-glass design rather than giving a broad contractual right that the architecture cannot constrain.

6. Present the output and identity

Check rights in generated speech, frames and recordings separately from rights in the underlying model. For a recognisable avatar, document the permitted persona, channels, languages, duration and approval process. A model licence cannot substitute for an actor’s informed consent or a brand owner’s permission. Yepic’s consent and provenance register provides the companion control for human identity.

7. Continue, exit and delete

Specify what happens at expiry, breach, supplier failure, product withdrawal or acquisition. Can the customer keep running the last approved release? For how long can backups remain? Which materials must be returned or destroyed? Is a transition licence available? What happens to customer-owned adapters if the base model can no longer be used?

This is where a seemingly private deployment can remain operationally dependent on an external licence server, signing service or update repository. The AI vendor exit-plan framework helps turn those questions into a tested transition rather than a contractual aspiration.

Use a decision record procurement can challenge

Give each dependency a compact record containing:

• supplier, exact component and version;
• asset class and location in the runtime architecture;
• licence identifier, contract reference and authoritative copy of the terms;
• the seven rights above, marked permitted, restricted, absent or unresolved;
• use restrictions, notice requirements, fees and usage metrics;
• territory, legal entity, environment and subcontractor scope;
• ownership and permitted use of inputs, outputs and derived artefacts;
• term, renewal, termination, transition and deletion rules;
• technical enforcement such as licence checks or remote dependencies;
• evidence date, reviewer, business owner and next review trigger.

Do not reduce unresolved rights to a green tick because a pilot is small. Mark the gap, name its owner and prevent production promotion until it is closed or the component is replaced.

Check when modification changes regulatory responsibility

Licensing and regulation are related but not interchangeable. A contract may permit extensive modification while regulation assigns new responsibilities to the organisation making or placing the modified system on the market.

The European Commission’s current guidance on general-purpose AI provider obligations describes documentation for downstream providers and copyright-compliance duties for model providers. Whether fine-tuning, integration or redistribution makes a particular organisation a provider is fact-specific. Record the deployment and modification facts, then obtain legal analysis; do not infer regulatory status from the words “open source” or “on-premise”.

Choose the deployment model with the clearest responsibility

Customer-hosted deployment is attractive when data control, latency, infrastructure policy or predictable utilisation justify it. It also requires the buyer to govern more artefacts and rights. A managed cloud service can reduce licence-handling work and give one supplier clearer accountability, but may offer less portability or control. Private cloud sits between those models and still needs an explicit boundary.

A hybrid architecture can also be rational: proprietary Yepic real-time avatar technology within a scoped private deployment, customer-approved models for sensitive tasks, and managed services for lower-risk capabilities. The answer depends on rights, performance, language quality, security, operations and cost—not ideology about open versus closed models.

Twelve questions for the architecture and procurement review

1. Can every production model be used commercially for the intended sector, users and territory?
2. Are development, test, production, scale-out and disaster-recovery copies explicitly covered?
3. May the team quantise, compile, convert and otherwise optimise each component?
4. Who owns and may access adapters, prompts, embeddings and other derived artefacts?
5. Do use restrictions flow into policies that operations can actually enforce?
6. May approved affiliates, integrators and support engineers access or receive the component?
7. Are licence, attribution and modification notices present in deployed packages?
8. Are model, runtime, dataset, voice and likeness rights recorded independently?
9. Does any supposedly local component require an external licence or signing service?
10. Can the last approved release operate during a supplier outage or contract transition?
11. Are termination, deletion and backup-retention rules technically achievable?
12. Will a version, supplier, fine-tune, new language or new use case automatically trigger review?

How this applies to a Yepic deployment

Yepic has spent years developing proprietary talking-photo and real-time avatar technology and can scope cloud, private-cloud, sovereign and customer-hosted architectures around approved components. That does not mean every dependency is open source or that one licence pattern fits every customer. The rights boundary must be designed alongside the data, GPU and operational boundary.

Yepic’s Chicago Transit Authority work included enterprise access, more than 140 presenters, 120 languages, templates, assets, administration, onboarding and continuing support. It illustrates how the usable enterprise package extends beyond a single model. It is not presented as a customer-hosted deployment or evidence of any particular model-licensing arrangement.

For a regulated buyer, the practical next step is to add a rights workstream to the architecture discovery. Build the component ledger, apply the seven-right test, identify remote licence dependencies and agree the exit state before benchmarking hardware. A private AI avatar is sustainable only when the organisation has both the technical capacity and the documented authority to operate it.