Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

Generative AI in production: what risk controls are teams missing?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 18936
Topic starter  

TL;DR: Teams need to balance model choice, data governance, real-time monitoring, and robustness testing before generative AI applications reach users, especially where prompt injection, PII leakage, and hallucinations can create operational risk, according to Fiddler. The practical shift is toward governed AI pipelines, not just better prompts and bigger models.

NHIMG editorial — based on content published by Fiddler: Building Generative AI Applications for Production

Questions worth separating out

Q: How should security teams govern generative AI once it becomes part of daily operations?

A: Treat generative AI as an access-bearing workflow, not a standalone tool.

Q: What breaks when RAG systems are not tied to identity controls?

A: RAG fails when retrieval permissions are broader than the user's entitlements.

Q: How can organisations tell whether session-level LLM monitoring is actually working?

A: Look for the ability to explain late-session failures from earlier turns.

Practitioner guidance

  • Classify model hosting and data flows before deployment Document whether prompts, embeddings, retrieval content, and outputs leave your environment, then map those flows to data classification and approval requirements.
  • Instrument real-time LLM monitoring Add controls for prompt scanning, output review, toxicity detection, and anomaly alerts so unsafe behaviour is caught during the interaction, not after the fact.
  • Lock down retrieval permissions in RAG systems Apply least privilege to document stores and retrieval endpoints, and separate user entitlements from model access so the system cannot disclose content outside a user's scope.

What's in the full article

Fiddler's full blog covers the operational detail this post intentionally leaves for the source:

  • Practical guidance on choosing between open-source and closed LLMs for specific deployment constraints
  • Additional detail on testing prompts, outputs, and model robustness before production rollout
  • More context on GPU sizing, cost trade-offs, and scaling behaviour for inference workloads
  • Further discussion of when RAG or fine-tuning is the better architectural choice

👉 Read Fiddler's guidance on building generative AI applications for production →

Generative AI in production: what risk controls are teams missing?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 18527
 

Production generative AI has become an access-control problem, not just a model-quality problem. The article correctly shifts attention from benchmark performance to data governance, observability, and runtime control. That is where enterprise risk actually concentrates, because LLMs consume data, respond to prompts, and interact with tools in ways that resemble privileged software consumers. Practitioners should treat these systems as governed access pathways rather than standalone applications.

A question worth separating out:

Q: Should organisations choose open-source or closed models for sensitive use cases?

A: They should choose based on control requirements, data sensitivity, and operational maturity, not model popularity. Closed models can reduce setup burden, while open-source models can improve hosting control and transparency. For sensitive data, the deciding factor is who can inspect, govern, and audit the full inference path, including retrieval and output handling.

👉 Read our full editorial: Production generative AI needs stronger model risk and data governance



   
ReplyQuote
Share: