They should treat external foundation models as third-party critical infrastructure, not as ordinary software components. That means defining data residency, audit rights, change control, monitoring and recovery expectations before deployment. If the organisation cannot inspect or constrain the model lifecycle, it does not truly govern the system, even if it can consume the API.
Organisations should govern external foundation models as third-party critical infrastructure, because the model provider becomes part of the system’s control plane even when the organisation only sees an API. Governance should therefore be contract-aware, operationally testable and lifecycle-aware, with explicit expectations for residency, auditability, change notification, monitoring and recovery. For a broader governance baseline, AI Governance Guide is the right internal starting point.
That distinction matters because the riskiest failures are usually not visible in the application code. A foundation model can change behaviour, retention posture or access conditions without a normal software release process, so the organisation needs controls that survive provider-side model updates, service degradation and policy changes. Third-Party AI Risk Guide is the clearest internal reference for that vendor-risk framing.
Good governance also requires deciding what evidence will prove the model is still operating within agreed boundaries. That includes logs, retention settings, testing results, incident notice paths and any contractual right to review operational changes that affect the deployed system. If the team cannot validate those conditions continuously, the deployment is being consumed, not governed. ISO/IEC 42001 Guide is useful where organisations want a formal management-system structure around that evidence.
What governing an external foundation model actually means
Governance here is broader than model selection or prompt testing. It means the organisation can define acceptable use, constrain data flows, observe material service changes, and make a defensible decision to continue, pause or exit the dependency. The model provider may be external, but the business impact still lands on the deploying organisation, so governance has to cover both the technical interface and the commercial and operational relationship around it.
That is why data residency, training-data usage limits, retention terms, subprocessors and audit rights are not legal boilerplate. They are operational controls that determine whether the model can be used for regulated data, whether the organisation can investigate a dispute, and whether it has enough leverage to respond when behaviour changes. Where the model is embedded into customer-facing or internal decision workflows, the governance standard should be closer to a managed service than a library dependency.
Which controls matter before deployment
Before go-live, the organisation should define the acceptable boundary conditions for the model relationship: what data may enter, where it may be processed, what telemetry must be available, what notice is required for material changes, and what exit criteria trigger suspension or migration. This is especially important when multiple teams can consume the same model through shared APIs, because informal adoption often creates shadow dependencies faster than policy can catch up.
Change control deserves special attention. If the provider can alter weights, safety behaviour, routing, context limits or content handling without a clear notification and review path, then the organisation cannot assume the deployed behaviour remains stable. A governed deployment needs a trigger for re-validation whenever the provider changes the model version, usage terms, safety layer or data handling posture.
How to keep the dependency governable after launch
After launch, governance should shift from approval to supervision. The organisation should watch for drift in outputs, latency, refusal patterns, data exposure, retrieval quality and unexpected changes in usage cost or volume. Those signals often reveal that the model has changed, that a prompt or workflow is being abused, or that the dependency is behaving differently under load or after a provider update.
The recovery plan should be written before the first production use. That means knowing how to fail over to a secondary model, a degraded workflow or a human-reviewed process when the external model becomes unavailable or untrustworthy. For many organisations, the real question is not whether the model is good enough on day one, but whether the business can continue operating if the provider changes the service or withdraws it entirely. AI Security Posture Management (AI-SPM) Guide is a strong companion for discovery, exposure tracking and control verification.
Risk and Threat Considerations
External foundation models create concentration risk, supplier risk and trust risk at the same time. If the provider changes behaviour, weakens access conditions, or loses availability, the organisation may inherit the impact immediately even though it does not control the underlying model lifecycle.
Failure mechanism: The organisation relies on a service boundary it cannot fully inspect, then discovers too late that data handling, output behaviour or availability changed outside its control.
Impact: That can produce compliance failure, broken business processes, unplanned exposure of sensitive data, or an inability to prove what happened during an incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023, EU AI Act and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | External model use depends on supplier context and lifecycle risk. |
| 8.1 — Operational planning and control | Governs controlled operation of AI systems with external model dependencies. | |
| Recommendation — Assess provider context and external model dependencies before approval. Define operational controls for change, monitoring and recovery. | ||
| NIST AI RMF | GOVERN — Govern | This subject is fundamentally about governing AI risk, accountability and oversight. |
| MANAGE — Manage | External foundation models require ongoing monitoring, mitigation and response. | |
| Recommendation — Set ownership, policies and review gates for external model use. Monitor provider changes and manage residual model dependency risk. | ||
| NIST SP 800-53 Rev 5 | SA-9 — External System Services | External foundation models are third-party services needing controls and agreements. |
| CM-8 — System Component Inventory | Governance requires inventorying which systems depend on which external models. | |
| CP-10 — System Recovery and Reconstitution | Recovery planning is essential when the model provider changes or fails. | |
| Recommendation — Specify security, audit and continuity requirements for the external model service. Inventory external model dependencies and review them continuously. Maintain tested fallback and recovery paths for model-service disruption. | ||
| EU AI Act | GPAI obligations — General-purpose AI model obligations | External foundation models commonly fall under provider/deployer governance obligations. |
| Recommendation — Track provider obligations and align deployment duties to the model class. | ||
| SOC 2 (AICPA) | CC7.2 — Security event monitoring | Ongoing monitoring of external model behaviour supports assurance over the service relationship. |
| CC8.1 — Change management | Provider-side model changes are a core governance issue for dependent systems. | |
| Recommendation — Monitor external model service changes and alert on abnormal behaviour. Require controlled notification and review for material model changes. | ||
Practitioner Guidance
What to prioritise: Put contractual and operational rights ahead of model tuning. If you cannot specify retention, audit access, change notice and recovery expectations, the deployment is not yet production-ready.
What to verify: Confirm that someone in the organisation can evidence the current model version, the current data-handling posture and the current rollback path. If those cannot be produced quickly, governance is too weak for regulated or high-impact use.
Practitioner takeaway: Treat the provider relationship as part of the system architecture, because the moment you cannot see or constrain model lifecycle changes, you no longer truly govern the AI system.
Related resources from NHI Mgmt Group
- How should organisations govern AI systems when data, models and audit evidence are spread across multiple tools?
- How should security teams govern API keys used for generative AI access?
- Should organisations prioritise external exposure or internal credential governance first?
- How should organisations govern AI systems that can make consequential decisions?