A practical AI risk management framework for engineering teams. Map production AI risks to NIST AI RMF functions and enforce controls at the gateway level.
Production AI systems fail in ways that traditional software does not. A misrouted API call can send customer medical records to a third-party model provider. A poorly tuned agent loop can burn through thousands of dollars in tokens before anyone notices. A model can hallucinate a compliance citation that your legal team publishes to a regulator.
These are not edge cases. They are the four core risk categories that every engineering team running LLMs in production needs to manage: data leakage, cost runaway, compliance gaps, and model hallucination. This article maps each category to specific controls, aligns them with the NIST AI Risk Management Framework, and shows where gateway-level enforcement makes the difference between a policy document and an operational safeguard.
The OWASP Top 10 for Large Language Model Applications (2025 edition) lists prompt injection as LLM01 and sensitive information disclosure as LLM02. These are ranked by real-world severity, not theoretical concern. But OWASP covers vulnerability classes. Engineering teams need a risk taxonomy that maps to operational controls they can actually implement.
The four categories below organize production AI risks by what goes wrong and where you can intercept it.
Every API call to an LLM provider transmits your prompt content to an external server. When that prompt contains personally identifiable information (PII), financial details, health records, or proprietary business data, you have created a data exposure event.
OWASP's LLM02:2025 (Sensitive Information Disclosure) describes this directly: "Sensitive information can affect both the LLM and its application context. This includes personal identifiable information (PII), financial details, health records, confidential business data, security credentials, and legal documents."
The risk compounds in three ways:
Providers may store prompts for up to 30 days. Customer data sits on third-party servers outside your control during that window.
Without enterprise agreements, prompt data could be used to train future models, potentially surfacing sensitive information to other users.
Transferring EU citizen data to US-based AI providers without proper safeguards violates GDPR Article 44. Fines can reach 4% of global revenue or 20 million euros, whichever is higher.
Controls that work:
LLM API pricing is token-based, and tokens accumulate fast in agentic workflows. A recursive agent loop, a retry storm against a rate-limited endpoint, or a poorly configured batch job can generate thousands of API calls in minutes. Unlike traditional compute costs that scale with provisioned resources, LLM costs scale with usage, and usage can spike without any infrastructure change.
Controls that work:
AI regulations are multiplying. The NIST AI Risk Management Framework (AI RMF 1.0, published in 2023) was developed in collaboration with more than 240 contributing organizations and is currently being revised. Turkey's KVKK amendments introduced a five-day notification window for Standard Contractual Clauses, and banking regulators like BDDK mandate domestic data residency for financial institutions.
The gap is not awareness. Most engineering teams know regulations exist. The gap is enforcement. Compliance policies written in a wiki do not prevent a developer from sending a prompt containing customer IDs to an uncertified provider endpoint.
Controls that work:
LLMs generate plausible text, not verified text. When a model fabricates a statistic, invents a legal citation, or produces a product specification that does not exist, the output looks identical to accurate content. Engineering teams cannot eliminate hallucination, but they can contain its blast radius.
Controls that work:
The NIST AI RMF Core is composed of four functions: Govern, Map, Measure, and Manage. Each function breaks down into categories and subcategories with specific actions and outcomes. The framework is voluntary, and organizations can select the categories that match their needs and capacity.
| NIST AI RMF Function | Purpose | Data Leakage | Cost Runaway | Compliance Gaps | Hallucination |
|---|---|---|---|---|---|
| Govern | Cultivate risk management culture, define policies | PII handling policy, data classification | Budget ownership, spend authority | Regulatory mapping, provider approval process | Output review policy, acceptable use definitions |
| Map | Identify risks in your specific deployment | Inventory which prompts contain PII, map data flows to providers | Identify which workflows have unbounded token consumption | Map applicable regulations per jurisdiction and provider | Identify which outputs reach end users without review |
| Measure | Quantify and track risks | PII detection rates, false negative rates on redaction | Token spend by project, cache hit ratios, cost per request | Audit log coverage, time-to-compliance for new regulations | Hallucination rates by model and prompt type |
| Manage | Prioritize and act on risks | Deploy gateway-level redaction, enforce key rotation | Set spend caps, enable caching, alert on anomalies | Enforce provider allowlists, automate audit trails | Implement output validation, flag uncertain responses |
NIST describes Governance as "a cross-cutting function to inform and be infused throughout the other three functions." In practice, this means your AI risk management policies need to exist as enforceable rules, not just documentation. A governance policy that says "all prompts must be scanned for PII" is only effective if the scanning actually runs on every request.
The distinction between policy and enforcement is where most AI risk management programs stall. The NIST AI RMF includes both organizational governance (policies, roles, culture) and technical actions (testing, evaluation, verification, validation). But the framework does not prescribe specific technical architectures.
For engineering teams running LLMs through API calls, the natural enforcement point is the API gateway. Every request passes through it. Every response returns through it. That makes it the single location where you can apply controls to all four risk categories simultaneously.
SHIM implements a managed gateway boundary for supported providers. Production provider keys live in a managed secret backend; Fernet is limited to the local development backend. Requests and secrets are tenant-scoped.
A risk register turns the taxonomy above into a living document your team maintains. For each risk, capture five fields:
Data leakage, cost runaway, compliance gap, or hallucination.
E.g., "Customer support agent sends unredacted email addresses to GPT-4o."
Based on how many code paths trigger this scenario.
Regulatory fine amount, maximum cost exposure, reputational damage scope.
The specific technical or procedural mitigation, and whether it is enforced automatically or depends on human compliance.
The value of a risk register is not the document itself. It is the process of identifying specific scenarios, assigning ownership, and verifying that controls are actually operational. Review it quarterly, or whenever you add a new model provider, deploy a new agent workflow, or enter a new regulatory jurisdiction.
The NIST AI RMF was developed as a consensus resource with input from private industry, academia, civil society, and government over an 18-month period. It provides the vocabulary and structure for thinking about AI risk. But frameworks do not block API calls. They do not redact PII. They do not cap spend.
Engineering teams need both: a governance framework that defines what "managed risk" means for their organization, and technical enforcement that makes those definitions operational on every request. The framework tells you what to measure. The gateway gives you the instrumentation to measure it and the controls to act on what you find.
For a broader view of the AI governance tools market and how platforms fit together, see our full platform comparison. For the security threat landscape that motivates these controls, see our guide to AI security in 2026.
Start with the four risk categories. Map your current exposure in each. Identify which controls you enforce today and which exist only as policy. Then close the gaps, starting with whichever category has the highest likelihood and impact in your specific environment.