H&M’s AI gateway shows how enterprise AI governance scales

At a glance

What this is: This is a case study of H&M's centralized Generative AI Gateway, which shows how governing AI traffic through one control plane reduces fragmented security, compliance, cost, and observability risks.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly have to govern AI integrations as shared enterprise access paths, not isolated experiments.

Context

Enterprise AI gateway governance is the practice of placing authentication, policy enforcement, logging, and traffic controls in front of AI integrations so every team does not reinvent them differently. In this case, the primary problem was not model performance but fragmented access, inconsistent controls, and invisible consumption across multiple LLM integrations.

H&M's example shows a familiar enterprise pattern: decentralised AI adoption creates a control gap across security, compliance, operational ownership, and cost attribution. The governance issue is cross-functional, but the control surface is identity-adjacent because the organisation is deciding who and what may call models, under what policy, and with what audit trail.

Key questions

Q: How should security teams govern direct LLM integrations at scale?

A: They should treat direct integrations as a temporary pattern and move policy, routing, and observability into a central control plane. The key is to remove provider-specific logic from application code so identity, logging, and failover are enforced consistently across services instead of being rebuilt per team.

Q: Why do ad hoc AI integrations create security and compliance risk?

A: Because they scatter credentials, logging, and data-handling decisions across many code paths. Once that happens, the organisation loses consistent visibility into who called a model, what data moved, and whether the access path followed policy. The risk is not only technical exposure, but also the inability to prove control.

Q: What breaks when AI agent traffic is not governed by a centralized control plane?

A: Without centralized governance, teams usually end up with fragmented API keys, inconsistent rate limits, and weak cost attribution. That creates blind spots in security review and makes it harder to isolate failures when an agent misuses a tool or data source. It also slows incident analysis because request history, authorization decisions, and usage patterns are spread across different systems.

Q: Why do AI gateways matter for enterprise IAM programmes?

A: AI gateways matter because they create a central point for identity, routing, and observability across model and tool traffic. Without that layer, AI systems tend to sprawl across multiple providers and integrations, making access controls inconsistent and audit evidence incomplete. For IAM teams, the gateway becomes the place where AI privilege is actually enforced.

Technical breakdown

Centralised AI traffic control planes

A centralised AI gateway sits between applications and one or more model endpoints, applying authentication, routing, rate limiting, logging, and policy enforcement before traffic reaches the LLM. That architecture matters because it turns distributed AI consumption into something observable and governable. Instead of every team embedding its own key handling and logging logic, the gateway provides one place to standardise controls, reduce duplicate implementation, and preserve an audit trail across all model calls.

Practical implication: route enterprise AI requests through a shared control plane rather than allowing direct, team-specific model integrations.

Why ad hoc LLM integrations create identity and secrets risk

When teams connect directly to LLMs, they usually scatter API keys, secrets, logging, and error handling across projects. That increases the chance of inconsistent authentication, weak secret hygiene, and data handling gaps because no single layer owns enforcement. In governance terms, the organisation loses the ability to answer basic questions about which application called which model, under what identity, and whether the access path followed policy.

Practical implication: inventory all AI integrations and bring credential handling under a single governance pattern before exposure expands further.

Cost attribution and auditability in AI operations

AI gateways do more than secure access. They also create metering points for cost allocation, rate limiting, and audit logging, which are essential when AI usage is spread across many teams. Without that layer, consumption is hard to attribute and budgets become guesswork. With it, the enterprise can connect traffic volume, team ownership, and policy events to a single operational record, which is exactly what finance and compliance teams need.

Practical implication: treat logging and metering as core governance functions for AI, not optional observability features.

NHI Mgmt Group analysis

Enterprise AI governance is now an identity control problem. Once multiple teams can call LLMs directly, the organisation is no longer managing isolated experiments. It is managing an access layer with credentials, policy, logging, and accountability requirements that look increasingly like IAM and NHI governance. The practitioner takeaway is that AI adoption without a shared control plane creates unmanaged access paths faster than governance teams can review them.

Centralisation is not a convenience, it is the governance boundary. H&M's pattern shows that security, compliance, and cost control all fail in the same place when each team implements its own AI integration. The named concept here is AI traffic governance layer: a shared enforcement point that turns model access into a managed enterprise service. The implication is that identity teams must decide whether AI calls are sanctioned enterprise access or merely application code with credentials attached.

Access review logic does not map cleanly to distributed AI integrations. Reviews assume there is a stable inventory of identities and permissions to certify, but ad hoc AI connections fragment that inventory across projects and environments. That makes least privilege difficult to prove, not just difficult to enforce. Practitioners should treat every direct model integration as a governance exception until it is folded back into a controlled platform model.

Cost visibility and security visibility are the same control surface in enterprise AI. The same gateway that enforces policy also reveals who is consuming what, at what rate, and under which workload. That makes the control plane relevant to both chargeback and risk management. The field is moving toward treating AI traffic like any other critical enterprise access path, which means identity governance has to extend into model usage, not stop at application login.

From our research library:

• Enterprise AI use rose from 55% of organisations in 2023 to 88% in 2025, according to McKinsey’s Global Surveys on the State of AI.

What this signals

AI gateway governance is converging with identity governance. The practical question is no longer whether teams use LLMs, but whether those model calls sit inside a controllable access architecture. For IAM and NHI programmes, the useful boundary is the gateway: if access, logging, and policy do not terminate there, governance fragments immediately.

AI traffic needs the same lifecycle thinking as any other enterprise access path. Credentials, routing, and audit data all have owners, and they should not be left to individual development teams to interpret differently. That is why centralisation matters: it creates an operational record that security, compliance, and finance can all use without rework.

For practitioners

• Centralise AI model access Place all LLM traffic behind one governed gateway so security, logging, and routing policies are applied consistently across teams.
• Standardise secret handling for AI integrations Remove direct, team-specific API key patterns and require shared lifecycle ownership for credentials used to reach model endpoints.
• Build auditability into model calls Capture request identity, route, policy decision, and usage volume for every model interaction so compliance and finance can trace activity.
• Treat AI cost controls as governance controls Use rate limiting, usage telemetry, and team attribution to manage spend before AI traffic becomes too dispersed to forecast.

Key takeaways

• Distributed AI integrations create the same governance problems that identity teams already know from unmanaged access paths, only faster and across more teams.
• H&M's example shows that centralised policy enforcement is the difference between AI experimentation and AI sprawl.
• The practical response is to govern model access as an enterprise service, with one control plane for credentials, logging, and accountability.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• AI Traffic: Machine-generated requests that may come from scripts, automations, or autonomous agents. In identity governance terms, AI traffic is not trusted because it is automated. It must be classified by authority, purpose, and scope before it is allowed to perform sensitive actions.
• Model Access Path: The end-to-end route an application or workflow uses to reach an LLM or other AI service. In governance terms, it must be inventoryable, attributable, and controlled, because it often carries credentials, data, and policy decisions.
• Centralized Logging: Centralized logging moves event data into a separate system for storage, search, and analysis. This reduces the chance that a compromised production system can erase its own trail, and it gives teams one place to enforce access, retention, and integrity controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.