All articles
Forward Deployed

Case Study: Deploying an LLM Feature at a Regulated Enterprise Customer

FDE Coach EditorialAugust 8, 20266 min read

The 5-Week Timeline: From Demo to Production

Most enterprise LLM projects die in the pilot phase. The reason isn’t model quality—it’s the inability to navigate procurement, legal, and InfoSec while maintaining technical momentum. This case study walks through a real shipment at a top-20 US bank. The ask: an internal tool that summarizes lengthy compliance documents for relationship managers.

The hard constraints:

  • Data never leaves the bank’s virtual private cloud (VPC).
  • Personally Identifiable Information (PII) must be redacted before inference.
  • The model must run on existing CPU-only infrastructure (no GPU budget approved yet).
  • Every prompt and completion must be logged immutably for audit.

As the Forward Deployed Engineer, I owned the entire outcome. Here’s the week-by-week breakdown:

WeekFocusKey Artifact
1Discovery & compliance scopingApproved architecture diagram, risk assessment template
2On-prem model serving (llama.cpp)Dockerfile, health-check endpoint, latency benchmarks
3PII guard logic + policy engineOpen Policy Agent (OPA) rules, regex redaction module
4Integration & UATStaging environment with sanitized data
5Production cutover & runbookMonitoring dashboard, escalation path

This cadence aligns with the FDE weekly rhythm: ship a tangible artifact every Friday to keep the customer’s trust.

Architecture: The Air-Gapped RAG Pattern

We couldn’t use managed APIs. The solution was a Retrieval-Augmented Generation (RAG) pipeline where every component lived inside the bank’s boundary. The user uploads a document, we chunk it, embed it, store vectors locally, and run a local LLM for summarization.

Here is the data flow:

We used Qdrant as the vector store because of its strong filtering API—crucial when you need to enforce data residency per business unit. For a similar pattern on a smaller scale, see the Discord FAQ bot build that uses Qdrant’s free tier.

The Compliance Gauntlet: PII Redaction and Policy-as-Code

InfoSec didn’t just want a checkbox; they wanted proof that the system couldn’t leak data. We implemented a two-layer guardrail:

Layer 1: Pre-inference PII Redaction A microservice based on Microsoft Presidio. It stripped names, account numbers, and SSNs before text hit the embedding model. This was non-negotiable for the legal sign-off.

# Simplified redaction call
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

def redact(text: str) -> str:
    results = analyzer.analyze(text=text, language='en')
    return anonymizer.anonymize(text=text, analyzer_results=results).text

Layer 2: Post-inference Policy Engine We wrote Open Policy Agent (OPA) rules to validate the LLM’s output. For example, a rule blocked any response that contained a 9-digit number pattern resembling an SSN, even if the model hallucinated it.

# OPA rule: deny any completion with potential SSN
package llm.guardrails

default allow = false

allow {
    not regex.match(`\b\d{3}-\d{2}-\d{4}\b`, input.completion)
}

The audit log captured the raw completion, the OPA decision, and the sanitized response delivered to the user. Immutable storage in S3 with object lock ensured we could reconstruct any decision. This approach directly addresses the question: "What is a key challenge of deploying LLMs in customer service?"—preventing the model from generating or regurgitating sensitive data.

Model Selection: Why We Ran a 7B Model On-Prem

The bank’s infrastructure team initially pushed for a CPU-only deployment. We benchmarked several quantized models and landed on Llama-2-7B-Chat (Q4_K_M) served via llama.cpp. Key metrics:

ModelQuantizationTokens/sec (8-core CPU)RAM Usage
Llama-2-7BQ4_K_M12.45.2 GB
Mistral-7BQ4_K_M14.15.1 GB
Llama-2-13BQ4_K_M6.89.8 GB

We chose Mistral-7B for its slightly better instruction following on compliance text. The 14 tokens/sec was acceptable for a summarization use case where users expected a 5-10 second wait. The Docker container exposed an OpenAI-compatible API, making the integration trivial for the bank’s internal app teams.

# Server startup
docker run -p 8080:8080 \
  -v /data/models:/models \
  ghcr.io/ggerganov/llama.cpp:full \
  -m /models/mistral-7b-instruct-v0.1.Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080

The Career and Comp Context for This Kind of Shipment

Shipping an LLM feature inside a regulated enterprise is one of the highest-leverage moves an FDE can make. Why? It proves you can operate in the hardest environment. Anyone can build a ChatGPT wrapper. Delivering value when you can’t call an external API, must run on CPUs, and have legal reviewing every log line—that’s the signal.

From a compensation standpoint, FDEs who close these deals typically see:

  • Base: $160K–$220K
  • Variable/Commission: 20–30% of base, tied to customer go-lives and expansion ARR
  • Equity: 0.1%–0.5% at Series B/C startups

But the real value is the portable trust. After this shipment, the bank expanded the contract to three more use cases. That’s how you build a $1M+ book of business as an individual contributor. For the skills that make this possible—rapid data prep, pragmatic model selection, and prompt engineering—review the highest-leverage FDE skills.

FAQ: Deploying LLMs in Regulated Environments

What is an enterprise LLM?

An enterprise LLM is a large language model deployed within a company’s own infrastructure, with controls for access, data handling, and auditing. It’s not the model architecture that’s different; it’s the operational wrapper—authentication, PII redaction, rate limiting, and immutable logging—that makes it “enterprise-grade.”

What is a key challenge of deploying LLMs in customer service?

The primary challenge is preventing the model from exposing sensitive customer data or generating legally binding statements. This requires robust input sanitization, output filtering with policy engines, and human-in-the-loop review for high-stakes responses. Without these, a hallucinated promise can become a regulatory liability.

How to deploy LLMs in production?

Start with the smallest model that solves the problem. Containerize it with a REST API. Add a pre-processing layer for input validation and a post-processing layer for output guardrails. Ship to a staging environment with real (sanitized) data, measure latency and accuracy, and only then promote to production. Every step must produce an artifact the customer can review.

What is an enterprise deployment?

An enterprise deployment means the software runs on the customer’s controlled infrastructure—on-premises or in their private cloud—and meets their specific security, compliance, and integration requirements. It’s the opposite of a multi-tenant SaaS where data and compute are shared. The FDE’s job is to make this as seamless as a managed service, without any of the shared responsibility risks.


Building a similar internal tool? The pattern of local embedding + on-prem LLM + policy guardrails works across regulated industries. For a hands-on start with vector search, try the codebase Q&A tool with Supabase to see the retrieval side in action.

#case-study#llm#deployment#compliance

Want to build like a Forward Deployed Engineer?

FDE Coach is a cohort-based program in frontend, backend, AWS, and AI. Build real products and get referred to 200+ hiring partners.

Explore the program

More forward deployed

August 15 · 0d left
Enroll Now