What is the difference between security responsibilities for managed AI platforms and self-hosted models?

With managed AI platforms, the provider secures the underlying service, while the customer remains responsible for identities, data, prompts, access policies, and usage controls. With self-hosted models, the organisation also owns the model infrastructure, patching, network isolation, logging, and runtime hardening. The self-hosted model gives more control but far more operational burden.

Managed AI platforms versus self-hosted models: where responsibility shifts

The core difference is control versus delegation. A managed AI platform reduces the amount of infrastructure you must operate, but it does not remove your obligation to govern how people and systems use the service. A self-hosted model gives you more direct control over the environment, but the organisation must secure the full stack that makes inference possible, from hosting to runtime operations.

That split matters because security ownership changes by layer. With a managed platform, the provider typically absorbs platform availability, patching, and core service hardening, while you still own the AI Security Posture Management (AI-SPM) Guide concerns that sit around the service, such as identities, data exposure, configuration choices, and misuse controls. With self-hosted models, those same concerns remain, but they expand into host, network, storage, and workload security responsibilities.

In practical terms, managed platforms narrow the operational surface you administer, while self-hosted deployments widen it. The managed model usually fits teams that want faster adoption with clearer vendor boundaries, but it demands tight control over tenant configuration, access policy, and approved use. The self-hosted model fits teams that need deeper isolation, custom controls, or stricter residency and logging, but it also requires the organisation to operate those controls reliably.

What you still own in either model

Even when the provider runs the platform, your team remains responsible for the business use of the model. That includes account and role governance, prompt handling, data classification, output review, and deciding which users or applications may call the service. The ownership question is not only about where the model runs, it is about who can make it act on sensitive information or influence downstream systems.

That is why managed services still need guardrails around secrets, credentials, and connectors. If the model can reach internal tools or external APIs, the exposure often comes from how access is granted rather than from the model itself. The same applies to self-hosted deployments, but the blast radius is usually larger because the organisation also controls the surrounding infrastructure and its trust boundaries.

For teams building their own environment, the security burden extends to patch management, network segmentation, logging, capacity planning, runtime hardening, and recovery. Those tasks become part of the security responsibility rather than an external service commitment. A well-run self-hosted deployment can offer stronger isolation than a shared platform, but only if the organisation can sustain that operating discipline over time.

How to choose the boundary that fits your risk profile

The right boundary depends on what you need to protect most. If the main concern is speed and reduced operational overhead, a managed platform can be the better fit, provided you can enforce least privilege, data minimisation, and usage monitoring. If the main concern is control over infrastructure, locality, and deep technical tuning, self-hosted may be preferable, but only when you can staff the additional engineering and security work.

The best decision rule is to ask whether your security requirement is mainly about service consumption or platform ownership. If the risk is dominated by who can access the model and what data they can send, managed and self-hosted both require strong governance. If the risk is dominated by host compromise, network exposure, or patching failure, self-hosting makes those responsibilities more explicit and therefore more demanding.

Where model access is tied to other internal systems, the difference becomes even sharper. Managed AI platforms may simplify operations, but they still depend on the quality of your Third-Party AI Risk Guide decisions around vendor scope, contract terms, monitoring, and deployer duties. Self-hosted models reduce vendor dependence for the runtime itself, but they increase the organisation’s responsibility for resilience and secure administration.

Risk and Threat Considerations

Managed AI platforms can create a false sense of safety if teams assume the provider has absorbed all security obligations. In reality, sensitive data can still leak through prompts, retrieval sources, overbroad connectors, or excessive user privileges, while self-hosted deployments add more ways for compromise to occur through misconfiguration, weak isolation, or unpatched infrastructure.

Failure mechanism: The organisation treats the platform boundary as the security boundary, then leaves identity, access, data handling, or runtime controls under-governed, allowing misuse or exposure through a trusted service path.

Impact: Sensitive data, model outputs, or downstream systems can be exposed or manipulated, and the organisation may inherit incidents that look like application misuse, infrastructure failure, or vendor failure depending on the deployment model.

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.OC-01 — Organizational Context	Managed vs self-hosted AI depends on who owns each security boundary.
Recommendation — Define provider and customer responsibilities for the AI service boundary.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Both models require tight access limits on users, admins, and connectors.
	AU-2 — Audit Events	Logging and review are central when deciding who can use or operate the model.
Recommendation — Restrict AI access paths to the minimum privileges required. Log model access, prompts, and administrative actions for review.
ISO/IEC 27001:2022	A.5.15 — Access control	The question turns on access ownership and control boundaries for AI services.
	A.8.9 — Configuration management	Self-hosted models place configuration and hardening squarely on the organisation.
Recommendation — Define and enforce access rules for AI platforms and self-hosted systems. Control and review AI platform and host configurations before production use.

Practitioner Guidance

What to verify: For managed services, confirm exactly which controls sit with the provider and which remain with your team, especially around identities, data retention, logging, and connector permissions. For self-hosted deployments, verify that the team can actually operate patching, isolation, and recovery at the required standard before treating the deployment as more secure.

Decision rule: If your organisation cannot sustain secure operations for the surrounding infrastructure, choose the managed path and invest in governance, policy, and access control. If your organisation needs tighter technical control and can support the full operational load, self-hosting can be justified, but only with clear ownership for the extra security work.

Practitioner takeaway: The security trade-off is not “safe versus unsafe”, it is “shared responsibility versus full operational ownership”, and the winning choice is the one your team can govern consistently at the layer where failure would actually occur.