AI security
AI gateway, DLP, or enterprise AI licences: three controls, three different failures
Organisations tend to pick one of these and consider AI data risk handled. Each closes a genuine gap and leaves the others open. Knowing which failure you are accepting is more useful than knowing which product you bought.
There are two distinct AI data problems in most organisations, and conflating them produces bad procurement. The first is staff using assistants directly. The second is your own applications calling model APIs. The controls that address these are different, and no single product addresses both well.
What each control actually is
Enterprise AI licences
A contractual and administrative control. You buy a business tier from a model provider, which typically brings a data processing agreement, a commitment not to train on your content, tenant administration, SSO, and audit logging. It addresses the staff-usage problem for people who use the sanctioned tool.
DLP applied to AI traffic
A network or endpoint control. Existing DLP or secure web gateway tooling inspects traffic to AI services and blocks or alerts on policy violations. It addresses visibility and prevention for managed devices and networks.
An AI gateway
An architectural control. A proxy sitting between your applications and model providers, exposing a compatible API so applications point at it instead. It can inspect, pseudonymise, apply policy, route by sensitivity, and produce an audit record. It addresses the application-integration problem.
Where each one fails
| Scenario | Enterprise licence | DLP | AI gateway |
|---|---|---|---|
| Staff use the sanctioned tool | Covered | Adds content control | Not applicable |
| Staff use a personal account on a personal phone | Not covered | Not covered | Not covered |
| Staff use a different AI service entirely | Not covered | Blocked or alerted | Not covered |
| Your application sends prompts to a model API | Not covered | Usually not covered | Covered |
| Secrets pasted into a prompt | Not prevented | Detected if patterns are tuned | Detected and blocked |
| AI feature inside another SaaS product | Not covered | Rarely covered | Not covered |
| Need an audit trail for a regulator | Provider-side logs only | Traffic-level only | Full request-level record |
| Need to route sensitive work to a private model | Not possible | Not possible | Core capability |
The application problem is the one most people are not solving
Staff usage gets the attention because it is visible and easy to write a policy about. Meanwhile engineering teams ship features that call model APIs directly, with credentials in environment variables, prompts assembled from database queries, and no inspection of what actually leaves.
That path is higher volume, more automated, and far more likely to include structured personal data than anything a human pastes. It is also the path a supervisory authority will ask about, because it is a systematic processing activity rather than an individual's behaviour. A gateway is the control that addresses it, and its value is as much about visibility and auditability as about blocking.
Deployment questions that matter more than feature lists
- Does the gateway receive raw prompts? A hosted gateway must, in order to inspect them. That adds a party to your data flow. Whether that is acceptable depends on the operator's terms and jurisdiction — and whether a self-hosted data plane is available for the flows where it is not.
- How does an application adopt it? The realistic answer for most teams is a base URL change against an API-compatible endpoint. If adoption requires an SDK rewrite, it will not happen.
- What happens when the gateway is unavailable? Fail closed stops your product working; fail open silently removes the control. Both are defensible, neither should be a surprise, and the behaviour should differ by policy tier.
- What is logged, where is it stored, and for how long? The log is now a sensitive store containing exactly the data you were trying to protect.
- Can it route by sensitivity — external model for general work, private or self-hosted model for regulated data? This is often the strongest argument for the architecture, because it lets you say yes to AI adoption in places you would otherwise have to refuse.
- What is the latency cost, measured on your traffic rather than a datasheet?
A layered arrangement that works
- Provide a sanctioned assistant with an enterprise agreement, and make it the path of least resistance. This addresses the largest share of the problem.
- Publish a short, specific policy with a no-blame route for reporting mistakes.
- Use existing web filtering to see which AI services are being used, and allowlist browser extensions.
- Put a gateway in front of application-to-model traffic, with pseudonymization on the flows where it is appropriate and logging on all of them.
- Audit AI features in the SaaS you already licence, and disable what has not been assessed.
- Include every AI data flow in your record of processing activities.
Steps one and two do most of the work and cost the least. Step four is where the regulated risk actually lives. Steps three, five and six are the ones that get skipped and then appear in an audit finding.
Preview and maturity
The AI gateway category is young. Products in it — including our own, which is currently an invite-only developer preview and not yet approved for production or regulated workloads — vary widely in maturity, and vendor claims outpace capability more than in most security categories. Ask specifically what happens to raw prompts, whether a self-hosted data plane exists, what the detection failure modes are, and what the product is not yet suitable for. A vendor who cannot answer the last question clearly is not one to build a compliance position on.
Frequently asked questions
Do I need an AI gateway if I already have enterprise ChatGPT?
They address different problems. An enterprise licence covers staff using the sanctioned assistant, with contractual protections and tenant administration. A gateway covers your own applications calling model APIs, which is usually higher volume, more likely to carry structured personal data, and the path a supervisory authority is more likely to ask about.
Can DLP stop data leaking to AI services?
Partially. DLP and secure web gateways can detect and block sensitive content in traffic to AI services from managed devices and networks, which gives useful visibility. They do not cover personal devices, personal accounts, AI features embedded inside other SaaS products, or application-to-API traffic that does not traverse the inspection point.
What is an AI gateway?
A proxy between your applications and model providers, usually exposing an API compatible with the provider's own so that adoption is a base URL change. It can inspect and pseudonymise prompts, apply policy, route requests to different models based on sensitivity, and produce an auditable record of what was sent where.
Talk to the team
Need this tested rather than described?
QuietHours is a European cybersecurity practice operated by the securIT team. Send us the system, service, or control you are concerned about and we will help turn it into a workable scope.
Discuss your scope