LLM guardrails for GDPR: redacting personal data in prompts

Expect a record of processing activities that describes the assistant as a processing activity, covering its purposes, categories of personal data, recipients, retention and security measures, in the form Article 30 of the GDPR describes. The redaction layer is part of that description, because it is the measure that limits which identifiers reach the model. Who maintains the record depends on your role: as controller you own it, and a partner can draft the technical sections from the deployed architecture. The record should name each self-hosted component, including the gateway, the guardrail service and the model server, and state where each one stores data. Keep the record current whenever the model, the policy set or the logging destination changes.

The policy is the set of detection rules, entity types, masking or pseudonymization actions and exceptions that the guardrail layer applies, and it should be kept in version control. Each version should record what changed, who approved it, the date it took effect and the reason, such as a new identifier type or a false positive fix. In a NeMo Guardrails deployment, the policy lives in configuration files such as config.yml and any Colang files, and in Guardrails AI it lives in the guard definitions and the validators they chain. Tie every production deployment to a specific policy version so you can show which rules were active for any given request. Confirm with your partner how the repository, approval workflow and release tags will be set up before work begins.

Auditors will want measured detection and miss rates on data that resembles your production traffic, not only vendor claims. Build a labeled test set that includes the identifiers you handle, such as names, national identifiers, account numbers, contact details and free-text references, then record how many were detected, masked and missed for each policy version. The guardrail service produces the raw decisions, but the labeling and the metrics come from your test harness, and they should be rerun after every policy change. Report false positives too, because over-masking affects answer quality and is a documented trade-off. Confirm with your partner how the test set is built and whether it can be kept inside your environment.

Keep logs that show what was detected, which rule fired, what action was taken and which policy version applied, without storing the raw personal data itself where a hash, token or category label is enough. The gateway, typically LiteLLM or Apache APISIX, and the guardrail service both produce these events, and an observability platform such as Langfuse or Phoenix can store them if they are self-hosted. Retention should be set in your own storage, with a documented period that matches your legal basis and internal policy. If the assistant is a high-risk AI system under the EU AI Act, Article 12(1) requires automatic event logging over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Confirm with counsel whether that duty applies to your system.

Maintain a change log that records each modification to guard configuration, validator versions, model files, gateway routes and access rights, with the author, reviewer, timestamp and rollback point. The strongest evidence comes from infrastructure as code and pipeline logs, where every production change passes through a reviewed merge and a deployment record. Include upgrades of the guardrail library itself, since NeMo Guardrails and Guardrails AI release new versions regularly, and record the version in use. Where the platform uses Colang 1.0 and migrates to 2.x, keep the converted configuration and the manual review record, because NVIDIA states that converted configurations still need manual review. Ask your partner to deliver the change procedure alongside the platform.

A DPIA, required under Article 35 of the GDPR when processing is likely to result in high risk, needs a description of the processing, an assessment of necessity and proportionality, the risks to individuals and the measures that address them. The guardrail layer supplies evidence for the measures section: the identifier types covered, the masking method, the test results on miss rates and the residual risks you accepted. It also documents where detection runs, which matters for transfers under Chapter V, since self-hosted detection models keep prompts inside your infrastructure. The DPIA remains the controller's document, and the assessment should be reviewed when the assistant's scope or data sources change. Your data protection officer should own the final text.

Even when every component runs in your own infrastructure, a contract should state the roles, the scope of any access a partner or vendor has, the security measures and the conditions for support and remote access. Under Article 28, when a third party processes personal data on your behalf, the controller and processor need a written agreement that sets these terms. Cover the implementation partner, any managed support you purchase, and any hosted service you still use, such as a model API or an external observability tool. Also confirm licensing terms of each component, since some open-source projects restrict hosted or managed use. Check the processor agreement with your legal team, and ask the partner to list every system that touches data during deployment and support.

The total depends on scope, and no price is published here. The cost has four main parts: compute for the detection models that find identifiers, engineering time to write and tune redaction policies, testing against the organization's own sample prompts and documents, and the logging design that records what was masked without storing the personal data itself. Compute is usually recurring because detectors run on every request, while policy design, integration and initial testing are one-time work. Costs rise with the number of languages, document types, applications calling the gateway and the volume of traffic. Ask any partner to split the quote into one-time and recurring items, and to state which environment, models and log retention periods each line assumes.

No duration is fixed in advance, so confirm the timeline in writing before work starts. Engagements are usually fixed-scope, and the schedule follows from the agreed deliverables: which applications and gateways are covered, how many identifier types are in scope, whether responses must be restored, and how much testing on the organization's own data is required. A narrow scope with one application and a short list of identifiers will take far less time than a multi-application rollout that also needs approval workflows and log review. Ask for milestones tied to deliverables, including the test results that will be accepted as the basis for going live.

Yes, many teams can build a first version with open-source components, and the NeMo Guardrails and Guardrails AI libraries both provide mechanisms for input checks and custom validators. The harder work is operational: writing policies for your identifier types, tuning them against false positives and misses on your own data, placing them at an AI gateway, and keeping logs free of the personal data they are meant to protect. Internal teams should estimate whether they have the time, skills and on-call capacity to maintain detection rules as models, applications and languages change. A partner can take on the build, and your team keeps ownership of policies and decisions.

Each group has a distinct role. The data protection officer should define which categories of personal data must be masked, the lawful basis for any restoration of identifiers in responses, and the retention rules for logs. Security should review where detection models run, how the gateway enforces policies, how access to logs and mapping tables is controlled, and how the controls are tested. Business owners should identify the assistants and workflows in scope, the expected use cases and the acceptable cost of a false positive, such as a legitimate name being masked. Agree these decisions before the build starts, because they shape the policy configuration and the test plan.

No. The GDPR does not require an audit, attestation or certificate for redaction or any other control. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask your legal and DPO teams which evidence they need to demonstrate data minimization and security of processing under Article 32.

Ask for a written scope that lists the applications, gateways and models covered, the identifier types and languages in scope, and the sample data used for testing. The quote should separate one-time work (design, integration, initial tuning, documentation) from recurring costs (detector compute, log storage, policy updates, retesting after model changes). Request the acceptance criteria for detection and masking tests, how false positives and misses will be reported, and who owns the policies after handover. Confirm the hosting location of every component, the log retention period and the support terms after go-live. DeployOpen works from a written scope and provides a quote from it, and does not publish a price list.