LLM guardrails RFP questions

Which questions to ask about risks, accuracy, deployment, change control and testing

Red flags in guardrail vendor and partner answers

Vendor and partner answers reveal more than their feature lists. The cards below cover evasive answers on accuracy, data location, change control, testing, compliance scope and licensing, each of which tends to surface late in a rollout if it is not pressed during the RFP.

How the guardrail options differ when you ask vendors to deploy them

How to run a guardrail proof of concept on your own data

This sequence gives you a fair, repeatable comparison of guardrail options on traffic that resembles your own, so you can see detection quality, latency and policy handling side by side before you sign anything. The output is a scored record of each vendor's decisions that your reviewers have checked against agreed expectations.

1. Set thresholds and pass criteria first

   Before any vendor sees data, the security, compliance and product owners agree in writing on the risks in scope, the categories that must be blocked, the categories that must pass, the acceptable false positive and false negative rates, and the latency budget per request. Write down who decides ties and who can overrule the scoring. The step is done when the signed criteria document is version-controlled and the vendors have received only the requirement, not the test set.

2. Build a labeled test set from anonymized traffic

   Your data owner exports a sample of real prompts, retrieved chunks and model outputs from a controlled environment, then removes or masks identifiers under your privacy procedure. Reviewers label each item with the expected decision: allow, block, redact or escalate, and the risk it represents. Include ordinary business requests as well as attacks, multilingual inputs and documents with embedded instructions. The step is done when the set is frozen, labels are double-checked on a sample, and the set is stored where vendors cannot reach it.

3. Define expected blocks for each risk

   Map each labeled category to the control it should trigger, such as prompt injection detection on inputs, personal data redaction on outputs or topic restriction on out-of-scope questions. Add adversarial variants of the same request so that wording changes are tested, not only exact matches. The security engineer signs off on the mapping. The step is done when every test item has one expected outcome and every risk in scope has at least one pass case and one fail case.

4. Run each option on identical inputs

   The same frozen test set goes through each candidate in the same environment, with the same model behind it, the same request sizes and the same concurrency. Record the raw decision, the category, any rewritten text and the time each check took. Keep each vendor's configuration as delivered, and note every change that the team makes during the run. The step is done when every candidate has a complete output file for the full set and the run logs show identical inputs.

5. Score false positives and negatives with reviewers

   Reviewers who did not write the labels compare each decision with the expected outcome, without knowing which vendor produced it. Count false positives, which block legitimate work, and false negatives, which let risky content through, separately for each risk. Look at a sample of disagreements to find label errors. The step is done when the scoring sheet shows results per risk and per vendor, the disputed items are resolved and the latency figures are recorded against your budget.

6. Test policy changes during the trial

   Ask each vendor to make a planned policy change, such as adding a new blocked topic or tightening a redaction rule, using the process they would use in production. Your engineer then reruns the frozen set and checks that only the intended items changed and that the previous version can be restored. Ask who approves changes and how they are reviewed. The step is done when you have a before and after diff for each change and a note on the approval and rollback path.

7. Review logging and evidence output

   Confirm that each blocked or modified request produces a record with a timestamp, the policy version, the decision and the reason, and that the record can be exported to your own log store. Check how long records are kept, how personal data inside logs is handled and whether an auditor could trace a decision back to the policy in force at that time. The step is done when your compliance lead has inspected sample records and confirmed what each vendor provides and what you would need to build.

8. Decide from the signed scorecard

   The evaluation panel reviews the completed scorecard against the criteria set in step one, including results, latency, policy change handling and logging. Record any unresolved gaps as contract or build items rather than trial results. The outcome is a written decision with the evidence attached, which can be shared with procurement and retained for the file.

How to score vendor responses

This table lists the criteria to score each vendor answer against, what a strong answer looks like and the written evidence to request. Buyers set the weighting for their own risk profile, and a score without supporting evidence should count as zero until the vendor produces it.

What logs and evidence the guardrails must produce

How DeployOpen scopes, delivers and supports guardrail evaluations

This sequence turns an RFP question list into a written, tested scope for self-hosted guardrails, so the buyer can compare vendors and partners on the same evidence. Each step closes with a named output the buyer can keep.

1. Agree the risk register and in-scope assistants

   DeployOpen starts with a workshop led by the engagement lead, with the CISO or security architect, the application owner and, where applicable, the compliance lead. The group lists each assistant, the data it can see, the users it serves and the risks to cover, such as prompt injection, sensitive information disclosure and unsafe output. The closing output is a written risk register that maps each risk to an input rail, an output rail, or a control outside the guardrails layer, so no risk is assumed to be covered by default.

2. Confirm the target architecture in the client's environment

   The team documents where guardrail components will run: the NeMo Guardrails or Guardrails AI runtime, any classifier models, the AI gateway, and the logging store. It checks this against the client's cloud accounts, data centers or air-gapped network, including model file transfer and package import paths where updates must cross a boundary. The output is an architecture decision record that names each component, its host, its data flows and the owner of each dependency, which the client approves before build begins.

3. Write the scope, deliverables and acceptance criteria

   DeployOpen issues a written scope that lists the in-scope assistants, rail types, validators or Colang policies, integration points with the gateway, logging requirements and exclusions. Acceptance criteria state how each deliverable is checked. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any work starts. The closing output is a signed scope document, and any change after signing goes through a written change request.

4. Build and version the guardrail policies

   The team implements input, output and, where needed, retrieval or execution rails in the agreed framework, with policies held in version control and deployed through the client's change process. It sets up the configuration, custom actions, and any Colang migration review needed when a configuration moves between language versions. The closing output is a tagged policy release with a changelog and a rollback path that the client can run without DeployOpen.

5. Measure false positives and misses on client data

   DeployOpen runs the guards against a test set drawn from the client's own use cases, including benign requests that resemble attacks and real business content that must pass. The team records block rates, false positives, false negatives and added latency per request, then reviews results with the client to adjust thresholds or rules. The closing output is an evaluation report that shows measured results on the client's data, not vendor benchmarks, with known gaps listed.

6. Test guard effectiveness with adversarial cases

   The security testing practice runs prompt injection, jailbreak, data leakage and unsafe output tests against the deployed guardrails, including indirect injection through retrieved documents where a RAG assistant is in scope. Findings are classified, reproduced and retested after each fix. The closing output is a test report with reproducible cases, the guard decision logged for each attempt, and a retest result for every finding. DeployOpen tests and documents; it does not issue audit reports or certifications.

7. Hand over runbooks and evidence for assessors

   DeployOpen documents how the guardrails run, how policies are changed and approved, how blocked requests are logged and reviewed, and how the team responds when a guard fails. The package is delivered to the client's own staff, and training is included where the scope says so. The closing output is a runbook set and an evidence pack that maps controls to the client's compliance programme, which the client's independent auditors or certification bodies then assess.

8. Continue testing and updates under a retainer

   Where the client wants ongoing support, DeployOpen offers retainers that cover upgrades, periodic re-evaluation on new data, scheduled red-team rounds and policy changes after model or assistant updates. Retainer scope, reporting cadence and response expectations are written into the agreement, and the client confirms each one before signing. The closing output is a recurring evaluation report and a change log that the client can review alongside its own monitoring data.