Why LLM guardrails for financial services need evidence, not only filters
A bank or insurer assistant team preparing for model risk review will be asked a simple question: how do you know the assistant will not reveal account data or give investment advice? This page covers self-hosted guardrails built on NeMo Guardrails or Guardrails AI, enforced at an AI gateway, and the evidence that model risk and compliance teams need to accept them. The controls run inside the organization's own infrastructure, so prompts, retrieved account context and blocked events stay under its control. Financial services differs from general-purpose assistants in four ways. Account numbers, balances, transaction histories and personal identifiers are common in both prompts and outputs, so detection must cover structured financial data as well as free text. Advice boundaries are a regulatory and conduct question, not only a brand question, so topic rails must separate general product information from personalized recommendations. Outsourcing rules apply when a third party hosts or operates part of the stack, which makes where guard models run and where logs are kept part of the design. Logging expectations also differ: a guard decision that cannot be reconstructed later is weak evidence, however good the filter. For platform selection, NeMo Guardrails fits teams that want dialog, retrieval and output rails defined in Colang and served over HTTP, while Guardrails AI fits teams that want validators chained onto specific inputs and outputs and structured output checks. Both are open source and can sit behind a gateway such as LiteLLM or Apache APISIX. Confirm the exact rail, validator and logging behavior against the versions you intend to deploy. DeployOpen plans, implements and documents these controls and prepares the evidence for assessment, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and assessors.
Which financial rules shape guardrail requirements
This table maps each financial rule to the guardrail build decision it drives, such as log retention, policy change control or hosting location for guard services. Read it as a checklist for the requirements phase, and confirm with your compliance and legal teams which rules apply to your entity and assistant.
| Source rule | What it asks for | What it means for the guardrail build |
|---|---|---|
| PCI DSS v4.0.1 | Cardholder data and sensitive authentication data must be protected wherever they are stored, processed or transmitted, including inside the cardholder data environment scope. | Scope prompts, retrieved chunks, guard logs and tracing data. Mask card numbers before they reach guard models, observability tools or blocked-request stores, and confirm with your QSA whether guard components fall in scope. |
| DORA Article 28(3) and 28(8) | A register of information covers all ICT contractual arrangements, and critical functions need documented, tested exit strategies. | Record every hosted guard API, classifier model source and validator package in the register. Keep policies and rail configurations in a format you can move to another runtime if a provider exits. |
| DORA Article 30(2) | ICT contracts state where services are provided and data processed, give advance notice of changes, and cover data return on termination. | If a hosted moderation or guard service receives prompts, the contract must name processing locations. Self-hosted guard models avoid this transfer question but shift patching and model updates to your team. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Multi-factor authentication is required for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing. | Require MFA for administrative access to guard consoles, policy repositories, gateway admin screens and log viewers. Record any written exception approved by the Qualified Individual. |
| SEC ICFR guidance, Release 33-8810 | IT general control areas include program changes and access to programs and data, relevant to SOX Section 404 assessments. | Treat rail definitions, Colang files, validator versions and thresholds as controlled code. Require change approval, peer review and a record of who deployed each policy version. |
| EU AI Act Articles 12(1) and 19(1) | High-risk AI systems must technically allow automatic event logging over their lifetime, and providers keep logs for at least six months unless other law provides otherwise. | Where a credit or insurance assistant is classed as high-risk, retain blocked-request and guard-decision logs for the required period. Confirm the classification and retention period with legal counsel before setting retention. |
| NIST and assessor evidence (not a financial rule) | Auditors and model risk teams ask for evidence that controls work as described, not only that they exist. | Keep versioned policy files, test results against known injection and leakage cases, and a log of guard decisions so model risk reviewers can trace each change. |
Which account data and personal information reach the model
Account data reaches the model through four routes, and each needs its own guard. The first is the user prompt, where customers and staff paste account numbers, card numbers, IBANs or claim references. The second is retrieved content: policy wording, claims narratives and call transcripts indexed for a RAG assistant often carry names, dates of birth and balances inside the text. The third is tool results, where a balance or transaction lookup returns a full record to the model context. The fourth is the model output, which can repeat or reassemble any of these. Input rails can mask identifiers before inference, retrieval rails can filter or redact chunks before they enter the prompt, execution rails can limit which fields a tool may return, and output rails can scan the final answer for card numbers, account identifiers and personal data before the user sees it.
Logs and traces are the leak point most teams underestimate. Prompts, retrieved chunks, tool payloads and blocked requests are often written to the gateway log, the observability tool or the application database, so a redaction step that only protects the user screen leaves the same data in storage. Confirm whether your gateway, tracing platform and application logs capture raw prompts and tool responses, and whether redaction runs before those writes. Where payment card data is in scope, PCI DSS applies to any system that stores, processes or transmits cardholder data, so the logging path may fall inside the cardholder data environment. Ask your QSA or internal assessor to classify the assistant early.
Guard decisions are themselves sensitive records. A blocked prompt often contains the exact account number or personal detail the guard was meant to protect, so the block log needs the same retention and access rules as the source data. Decide which fields a guard event stores (for example, a rule identifier and a masked hash rather than the raw match), who may read full payloads, how long they are kept, and how deletion works for data-subject requests under GDPR where customers are in the EU. Restrict access to guard logs through named roles, and record who reviewed a blocked request. Confirm these rules with compliance before the first production release, because they determine what the audit trail can show and what it must not expose.
How deployment constraints change the guardrail design
When the assistant sits close to core banking systems, the guard service is part of the same trust boundary as account data, so its placement is a security decision. Input rails can block requests that try to pull other customers' records or that smuggle instructions into account lookups, and output rails can mask account numbers before a response leaves the segment. Detection models should run on hosts inside the banking network, not on an external endpoint, because every prompt and response passing the guard is itself regulated data.
- Model placement: Run classifiers for PII, topic and injection checks on hosts in the same segment as the assistant, with no outbound calls at inference time.
- Policy updates: Changes to Colang or
config.ymlfiles should move through the bank's change process with a reviewed, signed package, not a direct edit on the guard server. - Action rails: If the assistant calls banking APIs, place execution rails in front of each call and keep the allowlist of permitted operations under change control.
- Third-party components: Any vendor-supplied validator or model file should be treated as an ICT service, with its location and update channel recorded in the DORA register of information.
- Logging: Write blocked-request events to a store the core banking security team already monitors.
Confirm with your architecture and security teams which segment the guard may reach, and whether any component needs approval before it is deployed next to production systems.
In a private cloud account holding regulated data, the guard runs as a service that the AI gateway calls before and after each model request. The main design question is which account, subnet and key boundary hold the guard, its models and its logs. Keeping these in the same account as the regulated data simplifies evidence, but it also widens the set of administrators who can change policy. Separating policy authorship from runtime operation is a common way to keep that set small.
- Model placement: Host guard models on compute in the regulated account or a dedicated sub-account, and avoid calling hosted moderation endpoints from inside the trust boundary.
- Policy updates: Store policy files in version control with peer review, deploy them to the guard service through a pipeline, and record which version handled each request.
- Key management: Keep keys used by the guard service, the gateway and the logging store in the account's own key service, with access limited to named roles.
- Third-party components: Confirm for each cloud provider or managed service where data is stored and processed, and that the contract covers advance notice of changes and data return on termination, as DORA Article 30(2) requires for ICT services.
- Exit planning: Document how the guard configuration and logs could move to another platform, supporting the exit strategy expectations in DORA Article 28(8).
Ask your cloud provider and any guard vendor to state in writing the regions and sub-processors that touch prompts, logs and model files.
In restricted networks where hosted moderation APIs are not allowed, the guard cannot depend on an external classifier or live policy feed. Every detection model, validator package and rule set must be imported across a controlled transfer process and verified before use. Updates become scheduled releases rather than continuous changes, which affects how quickly a new jailbreak pattern can be countered. Teams should plan for this lag and test the guard against known attack sets after each import.
- Model placement: Deploy self-hosted classifier models and the guard runtime entirely inside the restricted zone, with no fallback to external services.
- Policy updates: Bundle policy and model changes into signed packages, import them through the approved transfer channel, and keep a record of the hash of each version in service.
- Validator packages: Import Guardrails AI validators or NeMo Guardrails dependencies as reviewed artifacts, since the guard may not be able to fetch them at runtime.
- Third-party components: Where a vendor provides updates only through an external channel, record that dependency in the DORA register and agree a contractual path for offline delivery and data return.
- Failure behavior: Define whether the gateway fails closed or fails open when a guard component is unavailable, and document the decision for risk owners.
Confirm with the vendor how offline installation and model updates are delivered, and how often the team can run regression tests after an import.
Which open-source guardrail platforms fit a financial assistant
A financial assistant usually needs a rail or validator layer that inspects content, a gateway that enforces the checks on every model call, and a trace store that proves what was blocked. The options below sit at different points in that chain, so most teams combine one guard framework, one gateway and one evidence tool rather than choosing a single product.
NeMo Guardrails for dialog policy
NeMo Guardrails configures input, dialog, retrieval, execution and output rails in Colang, which suits a bank assistant that must stay on approved topics and refuse investment recommendations. Its guardrails server exposes an HTTP API, so the policy can run as a separate service in your own cluster. Check that your Python version falls within the supported 3.10 to 3.13 range and that your team can review Colang rules. Colang 1.0 to 2.x conversions need manual review before a policy change reaches production.
Guardrails AI for output validation
Guardrails AI builds guards from validators installed from Guardrails Hub, such as regex matching for account numbers or card-like strings, and can chain several of them. It also produces structured output that matches a Pydantic model, which helps when a response must carry fields such as a disclaimer flag or a product code. Confirm which validators you need, whether each one runs fully offline in your environment, and whether anonymous metrics reporting is disabled during setup.
LiteLLM as the enforcement gateway
LiteLLM sits between applications and model providers, so input and output guards apply to every call regardless of which assistant sends it. It also records logs and tracks cost, which supports the audit trail a model risk team will ask for. Its license is MIT except for the enterprise directory, so confirm which features your deployment uses before relying on them. Verify that routing and logging keep prompts within the approved hosting region.
APISIX or Kong as an edge alternative
Apache APISIX and Kong, both Apache-2.0 licensed, can enforce authentication, rate limits and request inspection at the network edge before traffic reaches the AI gateway. This suits institutions that already run one of them for API management and want a single control point for customer-facing channels. Check whether their AI-specific plugins cover the guard types you need, since an edge proxy will not inspect model output on its own. Confirm version support with your vendor or community before upgrading.
Langfuse for trace evidence
Langfuse records prompts, retrieved context, guard decisions and outputs so that a model risk or compliance team can reconstruct why a response was allowed or blocked. Its license is MIT except for the ee directories, which need separate review if you use them. Decide in advance what gets stored, how long it is retained, and who can read traces that may contain customer data. Arize Phoenix is an alternative, but it is under the Elastic License 2.0, which prohibits offering the software to third parties as a hosted or managed service, so confirm those terms with counsel before hosting it for other teams.
How a bank or insurer rolls out guardrails in phases
The sequence moves guardrails from a documented risk decision to a monitored production control, with each phase producing evidence that model risk and compliance teams can review before the next phase begins. Each phase has a named output, so the rollout can be paused or reversed at any gate.
Inventory risks and agree scope with model risk
The bank or insurer lists the assistant's use cases, the data it can see (account data, personal information, product terms), the users who reach it and the actions it can take. Model risk, compliance, information security and the business owner agree which risks the guardrails must address, such as account data exposure, investment advice and off-topic use. Output: a signed risk inventory and scope statement that names what is out of scope and who owns each risk.
Design the policy baseline in Colang or validators
The implementation team translates the agreed risks into rules. With NeMo Guardrails, this means input, dialog and output rails written in Colang and a config.yml file. With Guardrails AI, it means selecting validators from Guardrails Hub or writing custom ones. Policies should be reviewed by compliance for wording on advice, disclaimers and refusal messages. Output: an approved policy baseline in version control, with a named owner for each rule and a record of which framework and version it uses.
Test on a labeled set from the bank's data
The team builds a labeled set of prompts and responses from the institution's own product catalog, call-center themes and sanctioned test accounts, including adversarial prompts for prompt injection and attempts to extract account numbers. Results are measured for missed detections and false positives, and the team agrees acceptance thresholds with the business owner before testing starts. Output: a test evidence pack that records the dataset, the results, the known gaps and the decisions taken on each gap.
Run shadow mode behind the AI gateway
The guardrails are deployed at the self-hosted AI gateway, but they log their decisions without blocking traffic to users. Reviewers compare what would have been blocked or redacted against what the assistant actually answered, and they flag misclassifications to the policy owners. Output: a shadow-mode review log with classified false positives and false negatives, and a documented decision on whether each rule moves to enforcement.
Release in controlled stages with monitoring
Enforcement is turned on for a limited group of users, with dashboards and alerts on blocked requests, redactions, refusal rates and escalations to human agents. Operations staff define who can disable a rule during an incident and how that change is approved and recorded. Output: a release record that shows the scope, the monitoring thresholds, the incident contacts and the criteria for widening access.
Manage policy changes under change control
Every change to a rail, validator, threshold or underlying model goes through the same path as other production changes: a request, a test run against the labeled set, approval by the policy owner and model risk, and deployment through the normal pipeline. Periodic red-team exercises feed new cases into the labeled set. Output: a change record for each release and an updated evidence pack, so an examiner can trace any guard decision to the policy version in force at that time.
What model risk and compliance teams ask to see
This table maps each evidence item a model risk or compliance team typically requests to the component that produces it and the framework that explains why it matters. Read it as a checklist to agree before go-live, since DeployOpen prepares this evidence while independent auditors and certification bodies decide whether it meets their standard.
| Evidence item | Produced by | Why reviewers ask for it |
|---|---|---|
| Versioned policy files and change approvals | Guardrail config in Git (config.yml, Colang or validator settings) | Shows which topic and output rules were live on a given date and who approved each change, mirroring ITGC change control areas in SEC Release 33-8810 |
| Guard test results on bank data | Test suite run against synthetic or masked account and advice prompts | Demonstrates that investment advice, account data and personal information rails block what they should and record false positives, before and after each policy change |
| Blocked-request and output-decision logs | Guardrail server logs forwarded to the bank's own log store | Supports EU AI Act Article 12 event recording and Article 19 retention where the system is high-risk, with retention period set by the bank's own policy and other law |
| Gateway configuration and access records | AI gateway (for example LiteLLM or APISIX) config and admin audit trail | Shows who can change routing, keys and guard settings, and where multi-factor authentication applies under the FTC Safeguards Rule for non-bank institutions |
| Supplier register and contract data-location terms | Register of ICT arrangements covering each guardrail, model and gateway component | Maps each open-source component and any hosted model or classifier to its contract terms, data location and exit plan under DORA Articles 28 and 30 |
| Statement on PCI DSS scope | Written scope note from the architecture review | States whether cardholder data enters prompts, logs or retrieved content, and whether the assistant changes the cardholder data environment; the bank and its assessor decide the final scope |
How to keep answers away from investment advice and product recommendations
Topic restriction starts with a written line between advice and general information. Before any rail is configured, the firm's compliance and product teams should agree which questions the assistant may answer (how an account works, where a branch is, what a term means in the public product sheet) and which it must decline (whether to buy, hold or sell a security, which insurance product suits a named person, or how a policy compares with a competitor's). Those definitions become the policy text that NeMo Guardrails enforces through dialog rails written in Colang, with example user utterances for each category. Guardrails AI can add a complementary check on the output side through validators from Guardrails Hub, for example a classifier-based topic validator on each response, but the topic list itself must come from the firm, not from the tool defaults. Confirm with the library's current documentation which topic and safety models are supported in your deployment before you rely on them.
Borderline questions need a designed response, not a silent failure. A question such as whether an index fund is a good place for savings should get a short refusal that explains the assistant cannot give personal recommendations, offers approved general material, and hands the customer to a named channel such as a licensed adviser or a contact form. The handoff text, the escalation route and the logging of each declined turn should be specified in the same ticket as the rail, so that the refusal is consistent across channels. Test false positives as carefully as misses. Build a test set from real questions taken from call-center notes, chat transcripts and complaint logs under the firm's own data handling rules, label each item with the expected category, and measure how many legitimate product or fee questions are wrongly refused. Repeat the test after every policy change.
The guard supports the firm's policy but does not replace suitability assessment, product disclosure or the approval processes the firm already owns. Those obligations sit with licensed staff and the compliance function, and the assistant's refusal text should not be presented as a substitute for them. Ask the implementation partner to document which rules are policy controls, who approves each change to the topic list, and how that approval is evidenced in version control. Also confirm with your legal and compliance team which disclosures must appear alongside any generic product information, since those wording decisions are theirs to make and should be reviewed before go-live.
What to ask an implementation partner before hiring
How do you test whether account data and personal information leak through outputs on our own data?
The partner should test with a labeled sample drawn from your own systems, under a data handling agreement, rather than with generic demo prompts. Ask how they build the test set (account numbers, names, card-like strings, policy numbers, free text in complaints), how they measure missed detections and false positives separately, and where the test data is stored. Ask whether the test runs in your environment or theirs. A credible answer names the output rails and the redaction or blocking behavior they will verify, and records each result so it can be repeated after every policy change. Confirm that the tests cover both the model's direct answers and retrieved content, since leakage often comes from documents the assistant reads.
Where do classifier models run, and how are they updated without internet access?
The answer should be that every classifier and validator model runs inside your infrastructure, with no runtime call to a hosted moderation API unless you have approved that component. Ask for the exact list of models, their licenses, where the weights are stored, and the procedure for importing new versions through your change process. Ask how they handle Guardrails Hub validators or NeMo Guardrails models in a network that cannot reach the internet, and who signs off on each import. Ask what happens to detection quality when a model is out of date, and how that gap is measured and disclosed to your model risk team.
How are policy changes reviewed, versioned and rolled back?
Policies such as topic restrictions, investment advice boundaries and blocked terms should live in version control with the same review as application code. Ask who approves a change, how the diff is recorded, and how a release is tied to a specific configuration version for audit. NeMo Guardrails configurations use config.yml and Colang files, and Colang 1.0 and 2.x need manual review after conversion, so ask how they check converted rules. Ask for a documented rollback path and whether a change can be tested in a staging environment against the same regression set before it reaches customers.
What evidence pack do you deliver for model risk and compliance reviews?
Ask for a written list of artifacts, not a general promise of documentation. A typical pack for this purpose includes the risk-to-control mapping, the policy configuration at each version, the test plan and results, logs of blocked and allowed requests, change records and open findings with owners. Ask how logs are retained, who can read them, and how they support record-keeping duties if your assistant falls under the EU AI Act, where Article 12 and Article 19 describe automatic event logs and a minimum six-month retention unless other law provides otherwise. Confirm that DeployOpen prepares this evidence for your assessors; it does not issue audit reports or certifications, and independent auditors decide what is sufficient.
How do you handle DORA contract terms for any hosted component in the guardrail stack?
Under DORA, Article 30(2) requires every ICT services contract to state where services are provided and data processed, give advance notice of changes, and cover data return on termination or insolvency. Ask the partner to list every component that is hosted or externally operated, and to flag any that touches prompts or outputs. Ask whether they will map those components into your register of information under Article 28(3) and draft an exit plan under Article 28(8) for any service supporting a critical or important function. The best answer keeps the guard path self-hosted so that fewer third-party terms apply, and says clearly where that is not possible.
How do you test guards after release, and how often?
Ask for a regression suite that runs on every policy or model change and on a recurring schedule, plus adversarial testing that covers prompt injection, jailbreaks and attempts to extract account data. Ask how the partner's security testing team separates guard testing from application testing, and whether results feed back into policy changes. Ask what happens when a new bypass is found: who triages it, how fast a fix is released, and whether the regression suite is updated. Ongoing testing and support are available as retainers, so ask for the scope of recurring work in writing before you compare quotes.
What does a fixed-scope engagement cover, and what do we still have to run ourselves?
Most DeployOpen engagements are fixed-scope, so the written scope should list the risks covered, the rails and validators deployed, the integration points with your AI gateway, the test cycles and the handover items before work starts. Ask which costs are one-time, such as design, policy build and initial testing, and which recur, such as model updates, policy reviews, logging storage, compute for classifiers and retained testing. Ask what your own team must provide, including staff who approve policy changes and owners for blocked-request reviews. Request a quote that separates these items so you can see what drives the total.
How DeployOpen scopes guardrails for regulated assistants
Every engagement starts with a written, fixed scope that names the assistant, the data it can see, the guard points and the evidence the bank or insurer will need. For a financial services assistant, that means listing the account and personal data fields that must never appear in an output, the investment and product topics the assistant must refuse, and the gateway or application layer where checks run. DeployOpen implements the agreed design with either NeMo Guardrails or Guardrails AI, depending on whether the team wants Colang-based dialog and topic rails or validator-based input and output guards, and integrates them with the AI gateway inside the client's own cloud accounts, data centers or private networks. Deliverables, environments and timelines are set out in that scope before work begins, and DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move it, such as the number of assistants, the number of rails and the volume of integrations, should be fixed on paper first.
Security testing sits alongside the build, not after it. DeployOpen tests the assistant and its agents against prompt injection, attempts to extract account or personal data, and attempts to elicit investment advice, then records which guard decisions held and which did not. Model risk and compliance teams usually ask for this as repeatable evidence, so the test scope should be agreed in advance with the second line of defense. DeployOpen prepares that evidence, including configuration versions, test results and guard logs, for the assessments your auditors, examiners and certification bodies run. It does not issue audit reports, attestations or certifications, and those conclusions remain with the independent assessor you choose. Ongoing work, such as re-testing after a model or policy change and upgrading guard components, can be covered by a retainer agreed separately from the initial scope.
