The degree of control an organisation has over a trained model, including where it can run, whether the raw weights are accessible, and how easily it can be moved. Strong custody reduces dependency, while weak custody increases platform lock-in and exit risk.
What Model Custody Means in Practice
Model custody is really about control boundaries. A model can be technically useful, but if it can only run on a vendor platform, cannot be exported cleanly, or depends on proprietary serving constraints, the organisation’s actual custody is weaker than the model’s apparent capability.
That distinction matters because custody is not the same as model quality. A highly capable model with poor custody can still create strategic dependency, especially when deployment rights, runtime location, or exportability sit outside the organisation’s control.
Custody as a Control Over Portability and Dependency
Strong custody usually means the organisation can decide where the model runs, how it is packaged, and whether it can be shifted to another environment without losing essential functionality. That makes custody a practical part of vendor independence, not just an asset-management concern.
Weak custody shows up when the model is tightly coupled to a specific platform, inference service, or managed runtime. In that case, the organisation may own the model in name, but not in operational reality, because moving it becomes slow, expensive, or technically incomplete.
Raw Weights, Execution Rights, and Operational Control
Custody also covers whether the raw weights are accessible and governable. If the weights are opaque, inaccessible, or only usable through a vendor-controlled interface, the organisation has limited ability to inspect, relocate, or independently operate the model.
Execution rights are part of the same control problem. A model that can be run only in one environment, under one provider’s policy, has weaker custody than a model that can be hosted, tested, and re-deployed under organisational control.
Why Custody Matters for Exit Planning
Model custody becomes most visible during change events, such as contract renewal, platform failure, regulatory review, or a need to move workloads. If the model cannot be moved without major re-engineering, the organisation inherits exit friction and negotiation leverage shifts toward the platform owner.
Strong custody supports resilience because it reduces the chance that a single provider becomes the unavoidable path for continued model use. It also makes internal governance simpler, because the organisation can align model operation with its own security, data, and lifecycle requirements.
Risk and Threat Considerations
Weak custody creates concentration risk, because a single platform, runtime, or access path can become the effective owner of the model’s future use. The security issue is not only loss of flexibility, but also loss of control over where the model runs, what can be inspected, and how quickly it can be moved if trust breaks down.
Failure mechanism: Custody fails when deployment and portability are constrained by proprietary formats, inaccessible weights, platform-bound execution, or contractual limits that make migration slow or incomplete.
Impact: The organisation can face lock-in, delayed exit, reduced negotiating power, and higher exposure if the provider changes terms, suffers disruption, or no longer meets governance expectations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management | Model custody reflects dependence on third-party hosting and portability constraints. |
| GV.RM-01 — Risk Management Strategy | Custody affects lock-in, portability, and exit risk, which are governance-level risk decisions. | |
| Recommendation — Map model custody dependencies and exit assumptions to supply-chain risk management. Treat model custody as a strategic risk decision and document acceptable dependency thresholds. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | Custody often depends on whether an external provider controls model hosting and operation. |
| CP-10 — System Recovery and Reconstitution | Weak custody can hinder relocation or restoration of model capability after disruption. | |
| Recommendation — Define provider responsibilities and exit conditions for externally hosted model services. Ensure model recovery plans preserve a path to reconstitute or redeploy the model elsewhere. | ||
| ISO/IEC 27001:2022 | A.5.22 — Monitoring, review and change management of supplier services | Custody risk increases when a supplier controls runtime, access, or portability changes. |
| Recommendation — Review supplier changes that could reduce model portability or increase lock-in. | ||
Practitioner Guidance
Why practitioners should care: Model custody is a governance question, not just a technical one. Teams should be explicit about who can move the model, where it may run, and what conditions would prevent an orderly exit or re-hosting decision.
Common misunderstanding: Owning a trained model does not automatically mean owning its custody. If export, execution, or inspection depend on a vendor-controlled environment, the organisation should treat custody as partial rather than complete.
Practitioner takeaway: The strongest custody is the one that remains practical under stress, when the organisation needs to relocate the model without depending on the current provider’s continued cooperation.