The MHCLG AI Gateway, detailed by technical architect Sam Harrison in the department’s Digital blog and reported by Think Digital Partners, is already in use by multiple teams and exposes approximately 20 AI models. Its most significant feature is not the model count. It is the decision to make AI access a centrally operated service with common onboarding, role-based access, monitoring, auditability and cost visibility—an approach enterprise IT teams will recognize as a response to the growing sprawl of direct model API integrations.
For Windows and enterprise administrators, the useful lesson is concrete: the department is treating AI models as governed production dependencies, not employee tools procured one team at a time. That is a more durable pattern than distributing provider API keys into individual applications and hoping security reviews, data-handling rules and spending controls remain consistent afterward.
A shared route replaces per-project AI integrations
MHCLG says product teams, data scientists and services hosted in both Azure and AWS can use the Gateway to access approved AI capabilities. Instead of every project separately choosing a model provider, arranging credentials, implementing logging and seeking its own approvals, the Gateway provides a standard API route and support process.
The architecture is designed to be provider-agnostic. That claim is important in practical terms: a department can retain an application’s integration pattern while changing, adding or retiring a model backend centrally. Microsoft’s Azure API Management documentation confirms that its AI gateway capabilities can front models from Microsoft Foundry and Azure OpenAI as well as non-Microsoft services including Amazon Bedrock, Google Vertex AI, OpenAI, Anthropic and compatible custom endpoints.
That abstraction does not mean every model behaves alike. Model-specific prompt formats, safety behavior, token limits, output quality, regional availability and commercial terms still differ. But a common front door can prevent those differences from becoming 20 separate implementations of authentication, observability and budget controls.
MHCLG has not published the names of the roughly 20 models, the vendors supplying them, or the individual services using them. Nor has it disclosed whether applications use a single OpenAI-compatible interface, provider-native APIs, or a mixture of both. Those omissions make it impossible to judge how portable existing departmental applications actually are between providers.
The public developer portal independently confirms that a live MHCLG-branded Azure API Management portal exists and presents “MHCLG-approved AI models and APIs” through a single secure gateway. That moves the project beyond a conceptual architecture post: there is at least a discoverable developer-facing access layer, although its catalogue is not publicly exposed.
Governance is the actual product
The department’s announcement emphasizes that the Gateway passed its internal AI approval process, technical and data-protection approvals, and penetration testing. It uses existing authentication and role-based access controls, then connects to departmental logging, monitoring and audit systems. Governance documentation covers acceptable use, accountability, operations and data handling, while the platform connects to MHCLG’s AI Register and approval process.
That is a credible baseline, but it should be read for what it says rather than as a blanket assurance that all AI use behind the gateway is safe. Centralizing access makes controls possible to enforce consistently; it does not decide whether a particular service should send a particular category of public data to a particular model.
For an IT organization, the harder operational questions are usually these:
- A model allow-list must be paired with rules for what each application is permitted to submit to that model.
- Role-based access needs to distinguish administrators who can alter gateway policies from application identities that can only invoke approved endpoints.
- Logging must balance incident investigation and cost reporting against the risk of retaining prompts, completions or personal data unnecessarily.
- A central approval path needs an exception and offboarding process, or teams will retain direct vendor connections when the gateway cannot meet an urgent requirement.
Microsoft’s documentation highlights why the access-control design deserves particular scrutiny. Azure API Management can use managed identities to avoid placing backend secrets in applications, and it can apply controls such as token quotas, request throttling, content-safety policies and IP filtering. Yet Microsoft also cautions that people able to edit API Management policies may be able to act through an assigned managed identity. In other words, a gateway reduces credential distribution, but it raises the importance of tightly restricting policy-authoring privileges, change control and audit review.
MHCLG has not described its policy set, identity model, private-network configuration, prompt-retention settings or separation of development and production environments. Those are sensible details to withhold from a public post, but they are the implementation evidence administrators should demand before copying the model.
Cost visibility is useful, but savings remain unproven
MHCLG says the platform allows it to view AI consumption, adoption patterns, costs and resource use across services. Azure API Management supports that claim at the product level: Microsoft documents token metrics, logging of prompts and completions, per-consumer monitoring and quotas across applications.
This is the operational advantage many early AI deployments lack. With direct integrations, a procurement or FinOps team can see vendor invoices but struggle to map consumption back to a service, feature, user group or release. A gateway can attach a consistent identity and telemetry trail to requests, making it possible to find expensive workloads, set allocation rules and detect sudden consumption spikes.
But MHCLG’s blog provides no baseline, savings figure, request volume, token volume, latency data, or indication of whether central routing has reduced model bills. Its statement that the Gateway reduces cost and implementation time should therefore be treated as an expected benefit, not a demonstrated result.
There is also a centralization trade-off. A gateway becomes a shared dependency. If its policy configuration blocks legitimate traffic, if a logging change adds latency, or if a gateway incident occurs, it can affect multiple services at once. Microsoft’s API Management capabilities include load balancing, circuit breakers and multiregion deployment options, but MHCLG has not said how it handles availability, failover or backend-provider outages.
The department should eventually publish anonymized operational measures: onboarding time before and after the gateway, number of direct integrations retired, model usage by service class, blocked or remediated policy violations, and the cost effect after gateway overhead. Those measures would establish whether it has solved the duplication problem it identifies.
Azure API Management, not necessarily Microsoft’s new AI Gateway tier
MHCLG’s naming overlaps with Microsoft’s newer “AI Gateway tier” for Azure API Management, but the two should not be conflated. MHCLG says it built its departmental platform using Azure API Management as the core platform. Microsoft describes its AI Gateway tier as a separate, managed AI-focused offering that entered public preview in July 2026.
Microsoft says that preview tier currently has no service-level agreement, may change before general availability, and is available only in East US 2 and Sweden Central. That would make it an awkward fit for a UK public-sector deployment with UK data-residency or production-assurance requirements if those preview constraints applied.
However, Microsoft also documents AI gateway capabilities across existing API Management tiers, including multi-provider routing, observability, rate limits, managed identities and content-safety controls. MHCLG has not identified the API Management tier, Azure region, or whether it uses Microsoft’s new preview tier at all. The safer reading is that the department has built an AI-gateway pattern on Azure API Management, rather than that it has adopted Microsoft’s newly branded preview product.
That distinction matters for organizations looking to reproduce the work. They should begin by assessing the API Management service tier they already operate, their data-residency requirements, model contracts, network controls and identity architecture—not assume a newly announced preview service is required.
The next expansion needs stronger disclosure
MHCLG plans to add more AI capabilities and support services hosted by additional cloud providers. Extending access across clouds is consistent with the stated provider-neutral goal, and it could reduce the risk of tying every public service to one model vendor or one cloud platform.
Cross-cloud access also increases the governance burden. Data residency is determined by the full request path—application, gateway, model backend, monitoring destination and any connected tools—not merely by where the gateway itself runs. Microsoft makes the same point in its Azure documentation, and it is especially material for public-sector systems processing citizen information.
MHCLG has made a credible architectural move: centralize access first, then let teams build services on top of it. The test now is whether the department can show that its controls work under real demand, provide enough transparency about model and data boundaries, and keep the gateway from becoming another opaque platform team bottleneck.