Notifications
Clear all
Topic starter
20/08/2026 6:09 pm
TL;DR: Enterprises are using four LLM deployment patterns, from prompt engineering and RAG to fine-tuning and training from scratch, and Fiddler frames the choice around talent, data, cost, and AI maturity. The governance challenge is not just model quality but how retrieval, data exposure, and operational control shift as deployments become more embedded in production.
NHIMG editorial — based on content published by Fiddler: Four Ways that Enterprises Deploy LLMs
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
Questions worth separating out
Q: How should security teams govern LLM applications that call tools and data sources?
A: Security teams should govern LLM applications as identity-rich systems, not as isolated models.
Q: Why does retrieval-augmented generation create new governance risk?
A: Retrieval-augmented generation creates new governance risk because the model can only be as trustworthy as the knowledge sources it retrieves from.
Q: What breaks when teams fine-tune models without dataset controls?
A: Without dataset controls, fine-tuned models can encode bad, stale, or overexposed information into the model itself, which makes later correction harder than fixing a prompt or a document source.
Practitioner guidance
- Map each LLM deployment pattern to a distinct control set Document which teams use prompt-only, RAG, fine-tuned, or trained models, then assign controls for data exposure, change approval, and access review to each pattern.
- Treat retrieval as governed access Limit which documents can be indexed, separate sensitive sources by policy, and record which retrieved passages influenced each response for audit and incident response.
- Establish model and dataset change control Require approval for training data, fine-tuning sets, and model version promotion so that governance follows the same discipline used for other production changes.
What's in the full article
Fiddler's full blog covers the operational detail this post intentionally leaves for the source:
- Implementation distinctions between prompt engineering, RAG, fine-tuning, and training from scratch
- Examples of where each deployment pattern fits different data volumes, latency needs, and cost constraints
- Technical workflow details for embeddings, retrieval, and fine-tuning that help platform teams operationalise the approach
- Observability and pre-production testing concepts that matter once an LLM moves from prototype to production
👉 Read Fiddler’s full guide to four enterprise LLM deployment patterns →
LLM deployment patterns in production: what governance teams should assess?
Explore further
20/08/2026 6:45 pm
LLM deployment strategy is now an identity governance decision, not just a model architecture choice. The article shows that each deployment pattern moves the security boundary in a different place, from prompt inputs to retrieved documents to model weights. That means enterprise AI governance has to track who can call the model, what data can be injected, and which identities are allowed to shape outputs. The practitioner conclusion is that AI controls must be designed alongside identity and data controls, not after deployment.
A question worth separating out:
Q: How do organisations know if an enterprise LLM is operating outside its intended scope?
A: The clearest signals are unexpected data exposure, retrieval from sources not linked to the user’s role, and outputs that reveal information the requesting identity should not have reached. If audit logs cannot show which data influenced the response, the system is already outside a defensible governance boundary.
👉 Read our full editorial: Four enterprise LLM deployment patterns and their governance trade-offs
