Why runtime matters for AI
Written AI policies are common. Enforced ones are rarer. A policy that says confidential data must not be sent to external models has no effect until something in the request path can detect the data and stop the call. Runtime policy enforcement is the set of checks applied while an AI system is actually operating, as opposed to review at design time or audit after the fact.
AI systems make this harder than conventional software because behavior depends on inputs the designers did not write. A prompt, a retrieved document or a tool result can change what the system does. Controls therefore need to sit at the boundaries where information and actions cross.
The enforcement points in an AI stack
- Identity and access: who or what is calling, and which models, tools and data they may use.
- Input checks: inspection of prompts and attachments for sensitive data, disallowed content or injection attempts.
- Retrieval controls: filtering of documents returned from a knowledge base according to the caller's entitlements.
- Tool and action limits: restrictions on which external systems an AI application may call and with what parameters.
- Output checks: inspection of responses before they reach a user or downstream system.
- Rate and cost limits: ceilings on usage per user, team or application.
Gateways as a common choke point
Many organizations route model traffic through a gateway that applies shared rules in one place. A gateway makes authentication, logging, redaction and routing consistent across applications. Its limit is coverage: a team that calls a model directly bypasses it. Pair the gateway with network egress rules and credential management so that the sanctioned path is also the only path.
Be honest about what checks can do
Content filters and classifiers are probabilistic. They reduce risk but do not eliminate it, and attackers adapt. Prefer deterministic controls wherever the decision allows: an entitlement check on a document is exact, while a classifier guessing whether a prompt is malicious is not. Use probabilistic checks as an additional layer, and measure their false positive and false negative rates on your own traffic.
Separate the decision from the model. Do not rely on the model to police itself, because the same inputs that cause the problem may also defeat the check.
Proving enforcement
For each rule, keep a test that attempts the forbidden behavior and confirms it is blocked. Log every decision with the rule that fired. Review blocked and allowed samples regularly, and track how long a rule change takes to reach every application. Without that evidence, an AI policy is a statement of intent rather than a control.
A starting set of rules
Teams that are unsure where to begin can start with five rules: only registered applications may call approved models, prompts containing secrets or regulated identifiers are blocked or redacted, retrieval honors the caller's document permissions, tools are denied unless allow-listed and every request is logged with the decision. Each can be tested with a simple forbidden example.
Add rules as incidents and reviews reveal real gaps, and retire those that never fire and no longer map to a risk. A small, enforced rule set beats a long policy document that nothing applies.
