Managing third-party model risk and AI dependencies

For many UK SMEs, the fastest route to using AI is not to train a model in-house. It is to consume a hosted model through an API, add a wrapper around a large language model, or embed an AI feature from a supplier into an existing product. That is often a sensible delivery choice. It reduces time to value and avoids the cost of building everything from scratch.

The trade-off is that your security posture now depends on a model provider and a chain of supporting services you do not fully control. That dependency can affect confidentiality, integrity, availability, and operational resilience. It can also create a gap between what your team believes the AI is doing and what the provider is actually delivering at runtime.

Managing third-party model risk and AI dependencies is therefore less about abstract AI governance and more about practical control. You need to know what is in use, what data is being sent, what the provider can change, and how your systems behave when the model is wrong, unavailable, or manipulated.

What third-party model risk means in practice

Third-party model risk is the risk created when your product, service, or internal workflow relies on a model you do not operate. That includes hosted foundation models, model APIs, managed copilots, retrieval-augmented generation platforms, and AI features embedded in SaaS tools.

In practice, the risk sits in several places:

• Hosted models and APIs, where your application sends prompts or context to an external service and receives completions back.
• Wrappers and orchestration layers, where your code adds business logic, prompt templates, routing, or guardrails around a model.
• Plugins and agent frameworks, where the model can call tools, query systems, or trigger actions on behalf of a user.
• Embedded AI features, where a supplier has added model-driven functionality into a product you already use.

This is different from traditional software supplier risk. With ordinary software, the supplier usually ships a defined build and you assess the package, patching, and support model. With AI dependencies, the behaviour can vary by prompt, context, model version, temperature settings, retrieval sources, and provider-side changes. A model can be technically available but still behave in a way that breaks your controls or business expectations.

Build a model inventory and dependency map

You cannot manage what you cannot see. The first practical step is to create an inventory of every third-party model and AI dependency in use across the organisation. This should include production systems, internal tools, proof-of-concept work, and any shadow AI usage that has crept in through browser extensions or SaaS features.

For each dependency, record at least:

• Model or service name
• Provider and contract owner
• Version or model family in use
• Endpoint or integration method
• Region or hosting location, where known
• Business purpose and system owner
• Data types sent to the model
• Whether prompts, outputs, embeddings, or logs are retained
• Fallback behaviour if the service is unavailable

It is also worth mapping transitive dependencies. A single AI feature may rely on an orchestration layer, a vector database, a content moderation service, a secrets manager, and a cloud function platform. If one of those components changes, your overall risk profile changes too.

A simple way to structure this is to treat the AI feature like any other service dependency in your architecture diagrams. Show the user, application, model provider, retrieval layer, and downstream systems. Mark where data leaves your environment and where decisions are made automatically.

For SMEs using infrastructure-as-code or platform engineering, it helps to keep the inventory close to the deployment artefacts. For example, maintain a YAML or JSON manifest for each AI-enabled service with fields for provider, model, allowed tools, data classes, and approved environments. That makes review easier during change management and release approval.

Assess vendor and model assurance signals

Once you know what is in use, assess whether the supplier gives you enough assurance to use the service safely. You do not need a heavyweight procurement process for every experiment, but you do need a repeatable set of questions for anything that reaches production.

Review the supplier’s security documentation and terms for:

• Data retention and deletion terms
• Whether prompts or outputs are used for training or service improvement
• Incident notification commitments
• Subprocessor or hosting disclosures
• Access control and administrative security measures
• Encryption in transit and at rest
• Support for tenant isolation and regional hosting

For model-specific assurance, look for artefacts that help you understand behaviour and limitations. These may include model cards, system cards, safety notes, release notes, and change logs. They are not a guarantee, but they are useful evidence of how the provider thinks about intended use, limitations, and known failure modes.

Where available, ask for SBOM-style artefacts for the wider AI stack, not just the model itself. In AI contexts, that may mean a list of model components, orchestration libraries, embedding services, retrievers, and external tools. The point is to understand what you are actually depending on, including transitive components that are easy to miss in procurement.

Also check how the supplier handles change notification. If the provider can swap a model version, alter safety filters, or change retention settings without notice, you need to know how much warning you will get and whether you can pin a version. Version pinning is often essential for production workflows that depend on stable output quality or policy behaviour.

Define technical controls for AI dependencies

Assurance is only part of the picture. You also need technical controls around how the model is used.

Start with least privilege. API keys should be scoped to the minimum required capability, stored in a secrets manager, and rotated on a defined schedule. Do not reuse developer keys in production. If the provider supports separate keys for environments, use them. If it supports per-feature or per-project keys, use those too.

Network egress controls matter as well. If your architecture allows it, restrict outbound traffic so only approved services can reach the model endpoint. In cloud environments, that may mean private connectivity, firewall rules, or proxy-based allow lists. The aim is to prevent an application from silently calling unapproved AI services.

Environment separation should be treated as a baseline control. Development, test, and production should not share the same model credentials, retrieval indexes, or prompt logs. If you are experimenting with a new model, keep it isolated from production data until it has passed acceptance checks.

At runtime, apply controls to prompts, outputs, and retrieval sources:

• Prompt filtering to block obvious secrets, credentials, and disallowed content before data is sent out.
• Output filtering to catch unsafe or policy-breaking responses before they reach users or downstream systems.
• Retrieval filtering to ensure the model only sees approved documents and data sources.
• Rate limiting to reduce abuse, cost spikes, and automated probing.
• Abuse monitoring to detect repeated jailbreak attempts, prompt injection patterns, or unusual tool calls.

If the model can trigger actions, add explicit approval gates for high-impact operations. For example, a model should not be able to send emails, update records, or create tickets without a deterministic policy check or human confirmation where the action is sensitive.

Manage data exposure and prompt handling risks

One of the most common mistakes is treating prompts as harmless text. In reality, prompts often contain customer data, internal instructions, source code, incident details, or commercially sensitive information. Once that data leaves your boundary, you need to know exactly how it is handled.

Create a simple data classification rule for AI use. Define what can be sent to third-party models, what can be sent only after redaction, and what must remain local. For example, you may allow generic support queries to use external AI, but prohibit the use of customer personal data, authentication material, or confidential source code unless a specific exception has been approved.

Logging deserves special attention. Many teams log prompts and completions for troubleshooting, but that can create a second copy of sensitive data in application logs, observability platforms, or analytics tools. Decide what must be logged, what should be redacted, and how long logs are retained. Apply the same discipline to embeddings, because they can still expose sensitive context even when they are not human-readable.

If you use retrieval-augmented generation, review the content of the knowledge base carefully. A model that can retrieve from unrestricted internal documents may surface material that should never have been exposed to that workflow. Index only approved content, and separate public, internal, and restricted sources.

For SMEs handling regulated or sensitive data, it is sensible to treat AI prompts and outputs as part of your information asset register. That makes ownership, retention, and deletion easier to manage within existing security and privacy processes.

Plan for model drift, version changes, and service failure

AI dependencies are not static. A provider may update a model, change a safety layer, alter latency characteristics, or deprecate an endpoint. Even when the API contract stays the same, the behaviour may not.

Before promoting a model into production, define acceptance tests that cover quality, safety, and security. These should be specific to the use case. For a customer service assistant, you might test factual accuracy, refusal behaviour, and handling of sensitive requests. For a code assistant, you might test whether it introduces insecure patterns or leaks secrets from context.

Use a release gate that compares the new model or configuration against the current baseline. If the output quality drops, the refusal rate changes materially, or the model starts calling tools in unexpected ways, do not promote it until the issue is understood.

Rollback criteria should be written down in advance. If a model update causes unacceptable behaviour, you need a clear path back to the previous version or a safe fallback mode. That fallback might be a rules-based workflow, a human review queue, or a simpler model with narrower capability.

Graceful degradation is especially important for customer-facing services. If the AI feature fails, the rest of the product should continue to work where possible. A failed model call should not take down authentication, order processing, or support case creation.

Monitor, detect, and respond to AI dependency issues

Once the service is live, monitoring should focus on both security and operational signals. Feed AI-related events into your SIEM or logging platform alongside the rest of your application telemetry.

Useful detections include:

• Unusual spikes in prompt volume or token usage
• Repeated requests that try to bypass policy or safety controls
• Unexpected tool invocation patterns
• Large numbers of retrieval queries against restricted content
• Changes in refusal rate, latency, or output length after a provider update
• Authentication failures or API key misuse

It is also worth capturing model version, prompt template version, and policy version in your logs. Without that context, it is difficult to tell whether a bad response came from the model, the prompt, the retrieval layer, or a recent deployment.

When something goes wrong, treat it as both an application issue and a supplier issue. Your incident response process should include steps for disabling the feature, rotating credentials, preserving logs, and notifying the supplier through the agreed channel. If the issue affects customers or internal operations, your service desk and supplier management workflows should already know who owns the response.

For organisations that already use MITRE ATT&CK in detection engineering, it can be useful to map AI abuse scenarios to relevant techniques such as credential access, command and control, or data exfiltration, depending on how the model is integrated. That helps analysts understand whether the AI issue is isolated or part of a broader attack path.

Practical governance for SMEs using third-party AI

Good governance does not need to be bureaucratic. For most SMEs, a lightweight approval process is enough if it is applied consistently.

Assign clear ownership across product, security, procurement, and legal or compliance functions where needed. Product should own the use case and business value. Security should define the control baseline. Procurement should capture supplier commitments. Legal or compliance should review any contractual or regulatory concerns that arise. The key is to avoid a situation where everyone assumes someone else has checked the risk.

A practical review checklist for new AI use cases might include:

• What business problem is the model solving?
• What data will be sent to the provider?
• Can the model be pinned to a version?
• What happens if the provider changes behaviour?
• What is the fallback if the service is unavailable?
• Are prompts, outputs, or embeddings logged?
• Who approves tool use and high-impact actions?
• How will the feature be monitored after release?

Use the same checklist for major version changes and for any new supplier that enters the AI stack. That keeps the process simple while still giving you a defensible control point.

For UK SMEs, the aim is not to eliminate AI dependency risk entirely. That is unrealistic. The aim is to make the dependency visible, constrain it technically, and ensure the service can fail safely. If you can do that, you can use third-party AI with far more confidence and far less surprise.

Conclusion

Third-party AI can be valuable, but it should be treated as a managed dependency rather than a black box. Start with inventory, add supplier assurance, then enforce technical controls around data, access, and runtime behaviour. Finally, make sure monitoring and incident response cover AI-specific failure modes as well as ordinary application issues.

If you are building or buying AI-enabled services and want a pragmatic view of the controls that matter most, it can help to talk it through with someone who works on secure software and supplier risk every day.

Speak to a consultant

Frequently asked questions

What is third-party model risk in AI systems?

Third-party model risk is the risk that comes from relying on a model you do not operate yourself. In practice, that includes hosted models, model APIs, managed copilots, retrieval platforms, and AI features built into other software. The main concern is that your confidentiality, integrity, availability, and operational resilience can all be affected by a provider or supporting service you do not fully control.

What should I include in an AI dependency inventory?

A useful inventory should cover every third-party model and AI feature in use, including production systems, internal tools, proof-of-concepts, and any shadow AI use through browser extensions or SaaS features. For each one, record the provider, version or model family, integration method, hosting region if known, business purpose, data types sent, retention of prompts or outputs, and what happens if the service is unavailable. It is also sensible to map any supporting services the AI feature depends on, such as orchestration layers or vector databases.

How do I assess a supplier’s AI security and assurance?

Start with the supplier’s security documentation and terms, then look for clear information on data retention, deletion, training use, incident notification, subprocessors, access controls, encryption, and regional hosting. For model-specific assurance, review any model cards, system cards, safety notes, release notes, or change logs that explain limitations and known failure modes. These do not remove risk, but they help you understand what the provider is actually delivering.

Why does version pinning matter for AI models?

Version pinning helps keep production behaviour more stable when a provider can change a model, safety filter, or retention setting. Without it, the same prompt can produce different results after a provider-side change, which can affect business workflows and controls. If your use case depends on consistent output quality or policy behaviour, it is worth checking whether the provider supports pinning or gives advance notice of changes.

What technical controls should I put around third-party AI use?

The article starts with least privilege, so API keys and related access should only allow the minimum needed for the task. It also recommends treating the AI feature like any other service dependency, with clear visibility of where data leaves your environment and how decisions are made. For production use, it is sensible to define fallback behaviour if the service is unavailable or the model behaves unexpectedly.