Two tools, two different jobs
An AI gateway and a governance registry are often shelved under the same heading, yet they do opposite things. A registry is a system of record: it catalogues your AI models and systems, holds their policies and documentation, and tracks assessments. A gateway is a system of control: it sits in the path of every AI request and acts on it as it runs. The registry answers what AI do we have and what are we supposed to do with it. The gateway answers what is this request allowed to do right now. Conflating them is how teams end up with thorough documentation and ungoverned traffic.
What a governance registry does well
A registry is the backbone of programme management. It gives you an inventory, owners, model cards, and a place to attach the policies and risk assessments that frameworks such as ISO 42001 and the NIST AI Risk Management Framework expect you to maintain. For organising a governance effort and reporting to stakeholders, it is the right tool. Its boundary is structural: a registry describes systems, it does not sit in the request path, so any policy it records is enforced elsewhere or not at all.
What an AI gateway does well
A gateway is where governance becomes action. Every AI request passes through it, and it intercepts the request, redacts personal data in transit, enforces the policy for that user and use case, routes to approved models, and records the decision. Because it sits at runtime, it can stop a violation before it happens rather than note it afterward. For agentic AI, where actions are generated on the fly, the gateway is the point at which a tool call can be evaluated and blocked. It enforces; it does not merely observe.
Observe versus stop
The sharpest way to tell the two apart is to ask what happens when policy is about to be broken. A registry, having no presence in the request path, can at best record that a breach occurred once a log reaches it. A gateway, sitting in the path, can prevent the breach. This is the difference between observing risk and stopping it, and it maps directly to what regulators increasingly ask for: evidence that a control operated, not just that a policy existed. Observation produces a report; enforcement produces prevention plus the evidence.
How they fit together
These tools are complements, not rivals. A mature programme keeps a registry for inventory and management and runs a gateway for enforcement and evidence, with the gateway feeding live records back into the registry's documentation. The mistake is buying one and assuming it does the other's job: a registry will not stop a request, and a gateway is not a substitute for programme governance. Decide which gap is more urgent, close it first, and connect the two so documentation and control reinforce each other.
Frequently asked questions
Can a governance registry enforce policy?
Not on live requests. A registry catalogues systems and stores policy, but it does not sit in the request path, so enforcement of any policy it holds has to happen at a runtime layer such as a gateway.
Do I need both a gateway and a registry?
Many teams do. The registry manages the programme and inventory; the gateway enforces policy and produces evidence at runtime. Together they cover documentation and control, which are different halves of governance.