Migrate from Lakera Guard to NeMo Guardrails: what the move involves
Moving from Lakera Guard to NeMo Guardrails replaces calls to a hosted guardrail API with a self-hosted rails server that your application calls instead, and it replaces a managed policy console with configuration files your team owns. Usually the internal platform team runs the change, often with an implementation partner for the policy mapping and red-team work. The effort sits in three places: translating Lakera's detection policies into NeMo input and output rails, tuning detection until false positives are acceptable, and proving that verdicts match before enforcement moves. Before scoping, ask Lakera in writing what policy, log and configuration exports are available to you, because the answer decides how much of the mapping you can do from existing records rather than from interviews with the people who set the policies.
NeMo Guardrails is configured with a config.yml file, optional Python actions and Colang files, and it can run as a guardrails server that loads configurations from a folder and exposes an HTTP API. Your team will need to decide which rail types cover each Lakera check, which detection models run where and how much compute they need, and how the application's error handling behaves when the rails server is slow or unavailable. If your configurations use Colang 1.0, which is the default, and you later move to Colang 2.x, NVIDIA's migration tooling converts files but says the output still needs manual review, so plan that review as part of the project. The NeMo Guardrails microservice is a separate commercial offering from the open-source library, and the choice between them affects who supports the running system.
The safest path runs both systems side by side on recorded traffic. Replay a representative sample of prompts and responses through Lakera and NeMo, store both verdicts with the policy version that produced them, and review every disagreement with the security owner who signed the original policy. Set an exit criterion for each category before any traffic is switched, and keep Lakera active in enforcement until the disagreements in the sample are explained and accepted. Record traffic is sensitive data in its own right, so decide where it is stored, who can read it and how long it is kept before you copy any prompts into a test environment. The result is evidence you can show to a security review, and it tells you whether your remaining Lakera spend or license renewal still has a job to do.
Which Lakera Guard capabilities map to NeMo Guardrails, and where rework or gaps remain
This table maps each Lakera Guard screening area to its closest NeMo Guardrails equivalent and labels it clean, needs rework or gap. Read it as a starting inventory for your migration plan, since the labels describe fit with the NeMo Guardrails model, not detection quality, which you must measure on your own traffic.
| Lakera Guard area | NeMo Guardrails equivalent | Status and what to confirm |
|---|---|---|
| Prompt attack screening | Input rails with jailbreak and injection detection | Needs rework. Confirm detection coverage against your own attack corpus before retiring Lakera verdicts. |
| Harmful content moderation | Input and output rails with self-check moderation or NVIDIA content safety models | Needs rework. Choose and host the detection model, then tune thresholds for your user base and languages. |
| Data leakage checks on outputs | Output rails with custom Python actions for pattern and PII checks | Gap. NeMo Guardrails does not ship a managed data leakage policy, so your team writes and tests the checks. |
| Policy configuration in a managed console | config.yml, Colang files and optional Python actions in version control | Needs rework. Policies become code, reviewed and deployed like other configuration rather than edited in a web console. |
| Per-request verdicts and API response | Guardrails server HTTP API returning blocked or allowed responses | Needs rework. Map Lakera response fields to your application's handling logic and update error paths. |
| Shadow comparison on live traffic | Run NeMo Guardrails alongside Lakera on recorded requests and compare verdicts | Clean. Use your own logging to replay traffic, then review disagreements manually before any switch. |
| Topic and off-policy restrictions | Dialog rails and topic safety models in Colang | Needs rework. Colang flows must be written and reviewed, and Colang 2 migration needs manual review if you convert older files. |
| Latency and hardware sizing | Detection models run on CPU or GPU in your own cluster | Gap to confirm. Measure latency and capacity under your load, since model hosting is your responsibility. |
How input and output rails replace the Lakera Guard API call
Today an application that uses Lakera Guard typically calls the Lakera API twice per request: once on the user prompt before it reaches the model, and once on the model response before it reaches the user. In NeMo Guardrails, the direct equivalent of those two calls is the input rails and output rails. Both are declared in the config.yml file of a guardrails configuration, so the team maps each existing Lakera check to a named rail, then decides which detection model or custom action backs it. The other three rail types (dialog, retrieval and execution rails) have no Lakera counterpart, so they are scope to plan for separately rather than assumptions to carry over from the current integration.
The first integration decision is how the application calls NeMo Guardrails. The *Python API* embeds the library in the same process as the application, which suits a single Python service that already runs the model call. The *guardrails server* loads configurations from a folder and exposes an HTTP API, which fits a Lakera-style setup where the application sends text to a separate service and reads a verdict. The server is the closer match for teams that have only an HTTP client today. NVIDIA also provides a Dockerfile to build a server image. Python 3.10, 3.11, 3.12 and 3.13 are supported, so confirm your runtime version before choosing the embedded route.
If the application uses LangChain, the integration is opt-in. Set the environment variable NEMOGUARDRAILS_LLM_FRAMEWORK=langchain to enable it, and test that the model calls still pass through the rails after the change. Colang 1.0 is the default configuration language, so confirm which Colang version your team will write before copying any example from older material. Keep the Lakera call in place until the rails produce verdicts you can compare, which the side-by-side step later in this guide covers.
What data, policies and integrations move, and what must be rebuilt
A Lakera Guard migration moves less than most teams expect. Recorded traffic and verdicts carry over as test material, while policies, thresholds and call sites must be redefined for NeMo Guardrails. The cards below separate what you can export from what you need to write again.
Recorded requests and verdicts
Logs captured from the existing Lakera integration are the most valuable input you have. Keep the raw prompts, model responses, flagged categories and scores for a representative window, then strip or tokenize personal data before using them in a shared test environment. These records become the replay set for comparing verdicts side by side. Confirm with Lakera which fields and formats your account can export, because the export options depend on your plan and deployment.
Policy definitions and category settings
Lakera policies are set in its console or API, and their categories do not map one to one onto NeMo Guardrails rails. Write down each enabled category, its action (block, flag or log) and the surface it applies to, such as user input or model output. Treat this list as a requirements document rather than a config to copy. Ask Lakera whether policy definitions can be exported in a machine-readable form.
Allowlists, denylists and thresholds
Exceptions are where false positives get resolved in production, so they carry real operational knowledge. Record every allowlisted phrase, user group, project or tenant, and the score cutoffs your team tuned. Each one needs a reason and an owner before you rebuild it, since a rule copied without its reason can silently reopen a gap. Expect threshold values to change, because detection models in NeMo Guardrails are not the same models Lakera runs.
Colang configurations are written fresh
NeMo Guardrails uses a config.yml file, optional Python actions and Colang files. Colang 1.0 is the default and Colang 2.0 is also supported, so a configuration written for one version will not be assumed to work with the other. NVIDIA provides a migration path between Colang versions with a convert tool, but its output still needs manual review. Plan to write and test rails for your policies rather than porting anything from Lakera, since Lakera's API has no equivalent config format.
Application call sites and the guardrails server
Every place your application calls the Lakera API must change to call the NeMo Guardrails server instead, including chat endpoints, agent tool calls and retrieval paths. Map each call site to the input, retrieval, execution or output rail it should trigger. Note how Lakera's response fields are read today, because the response shape from the NeMo server will differ and your code needs an adapter. Keep the server behind your network boundary.
Evidence and change records
Security reviews and compliance assessments will ask how the control changed, when, and who approved it. Keep the old Lakera policy inventory, the new rail definitions, the replay comparison results and the sign-off for each threshold change in version control. DeployOpen prepares this evidence for assessments, but independent auditors decide whether it is sufficient. Confirm the retention period for your Lakera logs before you decommission the account.
Migration sequence: inventory, pilot, parallel run, cutover and decommission
This sequence moves Lakera Guard checks to a self-hosted NeMo Guardrails server in controlled stages, so each verdict change is measured before enforcement moves and the application keeps the same call boundary throughout. Each phase ends with a named output that the next phase depends on.
Inventory Lakera Guard call sites and policies
Your engineers list every place the application calls Lakera Guard, including gateways, batch jobs, retrieval pipelines and output checks, and record which Lakera policy categories and thresholds each call uses. The owner of each application signs off on the list and on which calls block traffic and which only log. The output is a call-site register that maps each Lakera category to the NeMo Guardrails input, output or retrieval rail that will replace it, with gaps flagged for the security team to decide.
Build a pilot rails configuration
Engineers create a NeMo Guardrails configuration with a config.yml file, any Python actions and Colang files, and run it in a non-production environment using the open-source library or the server. They choose detection models for jailbreak, injection and content categories, and confirm which Python version and deployment target the team will use. Colang 1.0 is the default, and NVIDIA's convert tool can help move Colang 1.0 to 2.x, but its output needs manual review before anyone relies on it. The output is a versioned configuration that passes a smoke test against a fixed set of known prompts.
Replay recorded traffic in parallel
Captured production requests, with personal data removed under your own policy, are sent to both Lakera Guard and the NeMo Guardrails server, and the verdicts are stored side by side. Reviewers sort every disagreement into true positives, false positives and missed attacks, and the team tunes thresholds, flows and actions until false positives fall to a level the business owners accept. Ask the security lead to confirm the sample size and retention rules for recorded traffic before the run starts. The output is a disagreement report with an agreed tuning log and sign-off on the remaining gaps.
Stage the cutover behind the same call boundary
The application keeps calling one internal guard function, and a feature flag or routing setting decides whether that function calls Lakera Guard or NeMo Guardrails. Traffic moves in stages, starting with logging-only mode on the new path, then enforcement for a limited set of applications, with alerts on block rates and latency watched at each stage. Rollback is a configuration change, not a code change, and the team tests it before each stage. The output is an enforced NeMo Guardrails path with a documented rollback procedure and monitoring dashboards.
Decommission the Lakera integration and keys
After the new path has run in enforcement for the agreed period, the team removes Lakera Guard calls from the code, revokes the Lakera API keys or license credentials, and removes any secrets from CI/CD and runtime configuration. Your procurement or legal team confirms the contract end date and any data processing terms with Lakera or Check Point. The team also archives the parallel-run evidence, configurations and tuning decisions for future security reviews. The output is a closed integration record, revoked credentials and an archive of the migration evidence.
Running both guardrails side by side and tuning false positives
Run both guardrails in shadow mode before any enforcement moves. Keep Lakera Guard as the enforcing check, and send a copy of each recorded prompt and model response to a NeMo Guardrails server with its input and output rails configured but not blocking. Store both verdicts against one request ID so every disagreement can be traced to the same text. Sort disagreements into three buckets: Lakera blocks and NeMo passes (a coverage gap to investigate), NeMo blocks and Lakera passes (a possible new false positive or a rail that is stricter than intended), and both block but with different categories or reasons. Ask Lakera for the policy and category settings your account uses, and read the NeMo rails that produced each verdict, since a config.yml rail and a Colang flow fail in different ways. Your own engineers and security reviewers should label a sample of each bucket, because agreement between the two tools does not prove either is correct.
Tune in a fixed order: first adjust thresholds and the detection models used by the input and output rails, then change Colang flows for the cases that remain. Each change should be replayed against the same labeled set so you can see which legitimate prompts it unblocks and which attacks it lets through. Build a red-team set from your own threat model, covering the prompt injection, jailbreak, data leakage and harmful output cases your application actually faces, and run it against both tools with the same harness. Then move enforcement in stages: route a small share of traffic through NeMo as the enforcing rail while Lakera keeps screening the rest, and keep the existing check in front of the model until NeMo's results hold across both sets. Changes to a rail should go through version control and re-run the full test set, because the NeMo library and its configuration can change between releases.
What drives cost and duration in a Lakera Guard to NeMo Guardrails move
This table lists the main drivers that change the effort of moving from Lakera Guard to a self-hosted NeMo Guardrails server, why each one moves cost, and how to keep it contained. No price or duration is supplied for this move, so request a fixed-scope written quote built from your own call sites, traffic volume and policies.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of applications and call sites | Each application that calls Lakera Guard needs its input and output checks rewired to a NeMo Guardrails endpoint, and each one needs its own testing. | Inventory every call site first, then group applications that share a prompt or response pattern so one rail configuration covers several of them. |
| Policy complexity | Lakera policies map to input rails, output rails and sometimes dialog rails. Custom categories, per-user thresholds and exceptions add rule logic that has to be rebuilt and checked. | Export and document current policies before design starts, and drop rules nobody uses or can justify. |
| Colang expertise | NeMo Guardrails configures behavior in Colang and config.yml. Teams without Colang experience need time to learn it, and existing Colang 1.0 configurations may need conversion and manual review. | Decide early whether you use Colang 1.0 (the default) or Colang 2.0, and confirm the in-house skills before committing to a schedule. |
| Detection model choice and hosting | Self-check moderation, jailbreak and injection detection, and content safety models run on your own capacity. GPU or CPU sizing depends on the models chosen and the request rate, and those capacity costs recur. | Benchmark a small set of candidate models on your own traffic, then size hardware for the smallest set that meets your latency and accuracy targets. |
| Volume of recorded traffic to compare | Running Lakera and NeMo side by side on recorded requests means storing, sampling and labeling traffic, and reviewing disagreements between verdicts. | Sample by risk category and by verdict disagreement rather than replaying everything, and set a fixed review sample size in the quote. |
| False-positive tuning effort | Each tuning cycle needs reviewers to judge blocked legitimate prompts and adjust thresholds, flows or examples. Effort repeats until false-positive rates are acceptable to the business owner. | Agree on acceptance criteria and a maximum number of tuning rounds in writing, and assign a named owner for verdict review. |
| Red-team testing scope | Rails need adversarial testing for prompt attacks, harmful content and data leakage. The depth of testing, the number of attack categories and the retest cycles set the effort. | Limit the first release to the risk categories your policies cover, use a repeatable test suite, and ask the vendor to confirm which test scope is included. |
What usually goes wrong and how to prevent it
Most failed guardrail migrations fail on assumptions made before any traffic is switched. The cards below cover the risks that tend to appear between the first NeMo Guardrails config and full enforcement, each paired with a check to run before cutover.
Assuming Colang configs port automatically
Lakera policies are managed in a console, while NeMo Guardrails rails are written in Colang and config.yml. NVIDIA provides a conversion tool for Colang 1.0 to 2.x, but it states converted configurations still need manual review. Prevention: treat conversion as a starting draft, review every rail against the original policy intent, and test each rail with recorded prompts before relying on it.
False positives that appear only after enforcement
A rail that blocks nothing in shadow mode can still block legitimate customers once it is enforced, because the traffic mix and the thresholds differ. Prevention: run NeMo Guardrails in parallel with Lakera on recorded traffic, record every disagreement, and set an agreed false positive review before any user-facing switch. Label a sample of blocked prompts with the business owner, not only the security team.
Detection quality with no owner
Detection models, jailbreak patterns and topic rules age. Lakera's detection updates come from its vendor, but a self-hosted stack keeps that work with your team, including model versions, rule changes and re-testing after each NeMo Guardrails release. Prevention: name an owner for detection quality, schedule regular red-team runs, and record which model and config version produced each verdict.
Latency and GPU capacity underestimated
Each input and output rail adds a call, and some rails run detection models that need GPU or substantial CPU capacity. A guardrail on the hot path can add visible delay to every request. Prevention: benchmark the full rail chain at expected peak concurrency on the hardware you will run, and confirm the hardware requirements of each chosen detection model with its documentation before sizing.
Incomplete inventory of call sites
Lakera is often wired into several services, batch jobs, retrieval pipelines and internal tools, and not all of them appear in the main application repository. Any call site missed during migration keeps running unprotected or against a retired endpoint. Prevention: search code, gateway logs and secrets stores for the Lakera endpoint and API key, map each call to its input or output position, and sign off the list with each owning team.
Enforcement switch that exposes the application
Changing the guardrail endpoint in one step can break clients that expect Lakera's response format or fail closed when NeMo Guardrails is unavailable. Prevention: put the NeMo Guardrails server behind a feature flag or gateway route, keep the Lakera path available for rollback, define the failure behavior (fail open or fail closed) per application, and test the rollback before enforcement.
How the move differs by starting point and environment
If your application calls the hosted Lakera Guard API, the move changes where inspection runs. Each prompt and response currently leaves your network for a vendor endpoint, and policy decisions are maintained in a managed console. With NeMo Guardrails, the rails run in a process you operate, so your team takes on the detection models, hosting and policy definitions.
- Traffic path: Application calls move from an external HTTPS endpoint to an internal guardrails service, so egress rules and firewall changes need to be planned with the security team.
- Policy translation: Console-managed rules have no direct file equivalent, so each policy becomes a rail in
config.ymlwith Colang flows, and the mapping needs written review. - Detection models: You choose which classifiers cover prompt attacks, harmful content and data leakage, and you confirm where their weights come from and who approves updates.
- Capacity: Inspection now consumes your own CPU or GPU and memory, so load testing at expected peak traffic is part of the work.
Before cutover, list which Lakera policies your team edits in the console today, and confirm with the vendor what data the hosted service retains.
Lakera's self-hosted option is typically delivered under an Enterprise agreement, so the first question is contractual: what the license covers, how long it runs and what happens to running containers when it ends. The engineering work resembles the hosted case, but the operating model shifts. Your team pulls, scans and runs the images, and the vendor is no longer the only source of update delivery. NeMo Guardrails is licensed under Apache 2.0, and NVIDIA also offers a microservice deployed on Kubernetes with Helm.
- License exit: Renewal dates, notice periods and post-expiry terms should be read before the migration plan is fixed.
- Packaging: The open-source library runs as a guardrails server built from the provided Dockerfile, while the NeMo Guardrails microservice is a production image on Kubernetes with Helm.
- Image supply chain: Your platform team takes over pulling, scanning and signing images from the vendor registry.
- Configuration portability: Rules documented by your team must be rebuilt as Colang and
config.yml, so confirm with the vendor whether any policy export exists before assuming one.
Ask the vendor to confirm the container delivery method and update cadence, and review the NeMo Guardrails documentation to match the packaging to your Kubernetes standards.
One application with one guardrail call path is the simplest case for a side-by-side comparison. A single configuration folder, one server and one logging stream are enough to answer whether the two systems agree on recorded traffic. The main risks are usually organizational. A small team often owns both prompts and rails, so changes can reach production without a second review.
- Narrow scope: One set of input and output rails can be mapped and reviewed in a small number of working sessions, which keeps the Lakera mapping manageable.
- Shadow mode first: Run NeMo Guardrails beside Lakera on copied traffic, log both verdicts and review the disagreements before any enforcement change.
- Failure behavior: Decide whether the application blocks or passes traffic when the guardrails server is unavailable, then test that path under failure.
- Single owner risk: One engineer often holds the Colang knowledge, so document the flows and assign a second reviewer.
- Latency budget: Measure the added round trip inside the request path before enforcement is switched on.
Check whether the application streams responses, because output rails then need a different test plan from buffered replies.
When several applications, business units or agents call Lakera, the migration becomes a platform decision. Shared rails, shared model hosting and shared logging reduce duplication, but a change to a shared rail affects every consumer. Teams need a way to version configurations per application while keeping a common security baseline that applies everywhere.
- Shared baseline: Core rails for prompt attacks and data leakage can live in a common configuration, with application-specific topic rails layered on top.
- Per-application rollout: Separate configuration folders or deployments let a high-risk application move on a different schedule from the rest.
- Ownership split: Security owns the baseline rails, application owners own topic and dialog rails, and each change has a named approver.
- Call-site inventory: Find every Lakera call, including scripts, batch jobs and internal tools, before setting a cutover order.
- Shared model updates: A detection model used by many applications is a single point of change, so test it against recorded traffic from each consumer before rollout.
Build the call-site inventory first and ask which applications already log Lakera verdicts, since that history drives the comparison.
On a connected network, packages and models can be retrieved when needed, but those retrievals still need change control. On an air-gapped network, every dependency, container image, Python package and detection model must be imported through an approved path. Model updates become scheduled transfers with recorded evidence rather than background downloads. The full offline design is covered on the sibling air-gapped page, so this tab focuses on what changes in the migration itself.
- Dependency import: Python packages, container images and model artifacts need a documented transfer path with checksums.
- Model update cadence: Plan who requests a model refresh, how the candidate is tested against recorded traffic and who approves it.
- Egress verification: Confirm in tests that the server makes no outbound calls it should not make, including during model loading.
- Evidence trail: Keep records of which rail configuration and model versions were in force for each period, for security reviews.
- Release pinning: Pin the NeMo Guardrails release you test, since v0.24.1 was released on 16 September 2026, and route later releases through the same review.
Confirm with NVIDIA and each detection model provider how the models are delivered and whether offline use is covered by their terms.
Questions teams ask before moving from Lakera Guard to NeMo Guardrails
How much effort and cost does moving from Lakera Guard to NeMo Guardrails involve?
The cost has two parts: the engineering work to port policies and wire the application, and the compute and tuning that run afterward. NeMo Guardrails is licensed under Apache 2.0, so the library itself carries no license fee. Your recurring costs are the infrastructure to run the server, the CPU or GPU capacity for any detection models you choose, and the engineers who maintain Colang configurations and tune false positives. Lakera's costs depend on whether you use its hosted API or the Enterprise self-hosted option, so ask Lakera for the license and support terms in writing. Drivers that raise effort include the number of applications calling Lakera, the number of policies in use, and how much custom logic your rails need. Request a fixed-scope quote from DeployOpen based on a written scope, since we do not publish prices.
How long does a Lakera Guard to NeMo Guardrails migration take?
The timeline is set by how many applications call Lakera, how many policies you map, and how much parallel testing your risk owners require. A migration typically moves through policy inventory, rail mapping, detection model selection, side-by-side traffic comparison, false positive tuning and a controlled switch. Each stage depends on access to recorded traffic and on the time your reviewers need to agree on verdicts. Your own environment will set the duration, so confirm it during scoping rather than planning around a generic figure. DeployOpen agrees timelines and deliverables in writing before work starts.
What does the migration need from our internal engineering and security teams?
Three internal groups carry most of the load. Application engineers must identify every call site, the request and response shape, and the fallback behavior when a check fails. Security or risk owners must approve the policy mapping and the acceptable false positive and false negative rates. Platform engineers must provide the Kubernetes or VM environment, secrets handling, logging and network controls. Expect these teams to review converted configurations, because NVIDIA states that Colang 1.0 to 2.x conversions still need manual review. Agree on named owners and review slots before the project starts.
Can our own team do the migration without an implementation partner?
A capable team can do it in-house if it has Python experience, operates containers and Kubernetes, and can build a labeled evaluation set. NeMo Guardrails runs as a Python library or as a server that loads configurations from a folder, and a Dockerfile is provided for the server image. The harder parts are Colang rule design, red-team testing of the rails, and the ongoing tuning that keeps detection quality stable. Teams without that capacity usually bring in outside help for the rail design and testing, then keep the operations in-house. DeployOpen can plan, implement, harden, document and support the deployment, and can run security testing of the rails, as a fixed-scope engagement or a retainer.
What should we ask Lakera for before we scope a migration?
Ask Lakera for the written terms that determine your exit cost and your timeline. Confirm whether you use the hosted API or the Enterprise self-hosted option, because the self-hosted route requires an Enterprise license. Request the export or policy format for your current rules, the list of detection categories you rely on, and the API version history so you can map each call. Ask about data retention and log access, since you will need recorded traffic for the side-by-side comparison. Also ask about the notice period and any contract terms that affect running both systems in parallel.
How do we confirm that NeMo Guardrails detects threats as well as Lakera Guard?
Run both systems on the same recorded traffic and compare verdicts category by category. Lakera's verdicts are the baseline only for the categories you care about, so label a sample by hand and measure where each system disagrees. NeMo Guardrails includes jailbreak and injection detection, self-check input and output moderation, and content safety and topic safety models, but you choose which of these to enable and which model backs each one. Track false positives and false negatives separately, tune thresholds and Colang flows, and then repeat the test with a red-team tool such as promptfoo before enforcing the new rails. Keep the results as dated evidence for your security review.
Which NeMo Guardrails version and Python runtime should we plan for?
Plan around the current NeMo Guardrails release line and confirm the exact version at scoping. NeMo Guardrails v0.24.1 was released on 16 September 2026, and the library supports Python 3.10, 3.11, 3.12 and 3.13. Pin the version in your build so verdicts do not change silently between test and production. Check the release notes before each upgrade, because detection behavior and Colang handling can change between releases. If you consider the NeMo Guardrails microservice instead of the open-source server, confirm its deployment model and support terms with NVIDIA, since it is deployed on Kubernetes with Helm.
Does the switch to NeMo Guardrails keep our applications and data inside our own infrastructure?
Yes, when you run the NeMo Guardrails server and the detection models in your own cloud account, data center or network. Prompts, responses and logs stay in your environment, and no third-party guardrail API is required for enforcement. Confirm each model you enable and its source, and confirm that no component calls an external service at runtime if your policy requires offline operation. Decide where traffic logs are stored and how long they are kept, because the side-by-side comparison will generate sensitive records that need the same controls as production data. Document these choices for your compliance assessment, and note that DeployOpen prepares controls and evidence, while independent auditors issue any audit report.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company. We plan, implement, harden, document and support self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Lakera Guard migration, the work starts with a written scope that names the applications whose traffic will pass through the rails, the NeMo Guardrails deployment model (library inside the application or the guardrails server behind an HTTP API), the detection models to be served locally, and the team that owns each Colang or config.yml change. Most engagements are fixed-scope, so deliverables, acceptance criteria and timelines are agreed in writing before work begins. We do not publish a price list, and a quote follows from that scope.
Red-team testing of the rails is one of the deliverables we can scope. The question to settle early is who runs the attack corpus: DeployOpen, your security team, or both. Testing covers the input and output rails against prompt injection, jailbreak attempts, sensitive data leakage and harmful content, and the results feed back into the side-by-side verdict comparison described above. Ask any provider to show how findings are recorded, retested and closed, and whether the test evidence can go to your assessors. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation.
After cutover, the work does not end. Detection quality drifts as attack patterns change and as your application's prompts and tools evolve, so false-positive review, rail updates, NeMo Guardrails version upgrades and model refreshes need an owner. Ongoing tuning, upgrades and continuous testing are available as retainers, which is often the practical choice when your own engineers must also keep the application running. Before signing, confirm what the retainer includes, how quickly changes to rails reach production, and how a rollback to Lakera Guard would be handled if the self-hosted path needed to be reversed.
