AI DLP is a system that controls AI services to prevent sensitive data from being sent to inappropriate destinations. DLP stands for Data Loss Prevention. Customer information pasted into chatbots, internal documents retrieved by search, and AI-generated responses can all be subject to protection.
Tools that frequently appear together when building such services are Presidio and NVIDIA NeMo Guardrails. Presidio is responsible for finding and masking sensitive information, while NeMo Guardrails connects inspections and policies to conversation and processing flows. A configuration that combines these two tools with the application’s actual blocking capabilities can be described as an AI DLP pipeline.
This article will examine the roles of these two tools separately and, using an AI service that summarizes customer consultations as an example, clarify where data should be inspected and where it should be stopped. The scope of explanation primarily covers LLM applications that process text.
At the Heart of AI DLP: Data and Destination
The basic question of DLP is simple: “Can this person send this data to this destination?” Even for the same document, policies may differ between storing it in an internally approved repository and uploading it to an external service.
Enterprise DLP applies this question to various channels such as email, file sharing, endpoints, and cloud apps. For example, Microsoft Purview DLP evaluates sensitive information and user activities against policy conditions and provides features to restrict sharing or leave warning/audit records based on those conditions. The scope of protection and application methods vary depending on the product and deployment configuration. Microsoft’s DLP Overview
In services using LLMs (Large Language Models), data movement paths increase. User input is sent to the model provider, internal documents are searched and fed as reference material to the model, and tools are invoked to retrieve data from business systems. Generated responses can be delivered to users and also remain in operational logs.
Here, we refer to a configuration that connects sensitive information identification, destination-specific policies, masking or blocking, and verification records to these paths as AI DLP. Since “AI DLP” can also mean DLP utilizing AI depending on the context, clarifying that the protected scope includes LLM’s input, search, and output paths in documents or lectures makes the scope clear.
| Component | Primary Role | Functions to Connect |
| — | — | — |
| Presidio | Detection and transformation of configured sensitive information types, such as personal data | Definition of information to protect, language-specific recognizers, subsequent policies |
| NeMo Guardrails | Inspection and flow control for input, search, conversation, tools, and output | Inspection models/actions, business policies, application integration |
| Application/Gateway | Actual allowance or stoppage of request delivery, response return, and tool execution | Authentication/authorization, transmission destination, error handling, audit logs |
| Enterprise DLP | Control of data movement across various business channels | Connection of supported channels by the product and organizational policies |
This table summarizes the primary responsibilities of each component. There are overlapping functionalities. Presidio can be called within NeMo, and a gateway might offer its own inspection features. The key is not the number of tools, but whether controls are connected to the actual data paths.
Presidio: Finding Sensitive Parts and Transforming Them as Needed
Presidio’s text processing structure is easy to understand in two stages. The Analyzer finds “where and what sensitive information exists,” and the Anonymizer processes “how to transform the found parts.”
The Analyzer uses detection units called recognizers. Recognizers can leverage regular expressions, rules, context, named entity recognition models, and more. Named entity recognition is the task of finding specific types of expressions, such as person names or locations, within a sentence. Detection results include information type, start/end positions, and score. Presidio Analyzer Documentation
The Anonymizer receives this location information and performs operations such as deleting strings, replacing them with other values, masking some characters, or encrypting them. For example, when summarizing consultation content with an external model, if the customer’s contact information is not needed for the summary, only that part can be removed from the sentence before sending. Presidio Anonymizer Documentation
The following is an example illustrating the processing concept. Values in curly braces are explanatory notations used instead of actual personal information and are not detection results obtained by running Presidio.
처리 전
고객 {고객 이름}의 연락처는 {고객 이메일}이다.
배송 지연에 대한 문의를 한 문장으로 요약해 줘.
필요한 항목을 탐지·치환한 뒤
고객 [PERSON]의 연락처는 [EMAIL_ADDRESS]이다.
배송 지연에 대한 문의를 한 문장으로 요약해 줘.This configuration retains “delivery delay inquiry” which is necessary for the summary, while reducing the exposure of names and contact information. Conversely, if the purpose is identity verification or contact information modification, the required data and permitted processing environment will differ. The masking scope is determined according to business objectives and the recipient’s authority.
Figure 1. Role relationship of detection/transformation, policy connection, and actual enforcement. Reconstructed based on official documentation for Presidio Analyzer, Anonymizer, and NeMo Guardrail Types. The application enforcement area is a design example from this article.
Here, the term “anonymization” should be read in conjunction with the processing method. Presidio’s Anonymizer also includes reversible operations like encryption. Even if a name is masked, if it can be re-identified by combining it with other information, the possibility of re-identification remains. Therefore, when describing processing results, it is more accurate to use the actual actions performed, such as “masked contact information” or “replaced identifiers.”
How to Handle Korean and Internal Information?
As of September 15, 2026, the official support list includes Korean-related types such as KR_RRN (Korean Resident Registration Number) and KR_DRIVER_LICENSE (Korean Driver’s License Number). In actual services, it is necessary to verify whether the corresponding recognizer is included in the package version being used, and if it is loaded in the settings and selected as a target for inspection. Presidio Supported Entities
Korean names, addresses, and sentence context are separate issues. Presidio’s multilingual documentation explains that the default configuration includes English models and recognizers, and for additional languages, it requires matching NLP engines and recognizers/contextual words. This is why support for Korean-related number types and the detection quality of entire Korean sentences are verified separately. Presidio Multilingual Support
Beyond personal information, there is much data to protect. Internal project codes, confidential contract terms, and design documents may not be sufficiently classified by personal information detection alone. For such information, business-specific recognizers, document security classifications, and classification rules can be applied together. Presidio allows for the addition of custom recognizers, but the meaning and policies for the information to be protected must be specifically defined by the service.
Note that the project known as “Microsoft Presidio” is currently transitioning to an independent community project under Data Privacy Stack, as announced. The Presidio links in this article are based on the current official documentation. Project Transition Announcement
NeMo Guardrails: Connecting Inspections at Necessary Points
In NeMo Guardrails, a “rail” refers to an inspection and control flow that applies policies during request processing. Inspection points can be placed not only at input and output but also in retrieved documents, tool calls, and multi-turn conversations.
A configuration using both tools together is also officially provided. NeMo’s Presidio integration includes flows for detecting or masking sensitive information in input, output, and retrieved document snippets. Therefore, instead of a fixed arrangement where “NeMo is followed by a separate Presidio server,” it can also be implemented with a structure where the relevant NeMo rail calls Presidio for inspection. NeMo PII Detection
At this point, detection and masking are different policy actions. “Reject the request if sensitive information is present” and “Continue the request after replacing sensitive information” also result in different user experiences. What types to inspect, at which stage to apply them, and what actions to choose must be included in the configuration. NeMo Presidio Integration Guide
For example, a policy can be created to restrict requests like “Show me all customer information.” This requires rules or models to interpret the meaning of the request and actions to stop processing based on the outcome. Simply installing NeMo does not automatically define internal business policies or customer data access permissions.
Following a Single Request Reveals the Scope of AI DLP
Let’s assume a service that summarizes customer consultations. The user inputs consultation content, and the service searches for necessary business documents before requesting a summary from the LLM. RAG stands for Retrieval-Augmented Generation, a method of generating responses by incorporating retrieved information into the model’s reference context.
The following diagram is a design example for this service. It does not depict the actual internal call sequence of NeMo but focuses on the conditions that must be met before data moves to the next destination.
Figure 2. Data movement and inspection points in an LLM service. This is a design example reconstructed based on official documentation for NeMo PII Detection, Guardrail Types, and Microsoft DLP Overview. Permission checks and transmission/response enforcement are indicated as application responsibilities.
First, the application verifies the user’s identity and permitted scope of work. The server restricts which documents can be searched, which customer records can be viewed, and which tools can be executed. Defining this scope is crucial for subsequent data inspections to lead to meaningful policies.
Second, complete necessary inspections before sending user input to the next recipient. If the goal is to avoid sending raw personal information to external models, detection and masking must be completed before crossing that boundary. Here, external models include not only the primary model generating responses but also auxiliary models classifying requests.
This order is a design condition. For example, if the raw text is sent first to an external LLM that determines input policy and then masked by Presidio, the raw text has already been transmitted to that auxiliary model. Therefore, it should be configured to either inspect within an environment approved for personal information processing first, or use an approved inspection service and data processing path.
Settings that execute inspection and generation in parallel are judged by the same criteria. NeMo has a method to start generation during input inspection, so for paths where inspection completion is mandatory before transmission, the actual settings and call order must be verified. Subsequent rails that need to inspect masked content are executed sequentially after masking. NeMo Runtime Security FAQ
Third, newly incoming data from search and tools is also inspected. Even if user input contains no personal information, retrieved consultation records might contain contact details. Restrict search targets to only documents permitted by authorization, and before feeding to the model, mask necessary items according to destination policies. Tool results entering the model’s context are handled with the same perspective.
Fourth, inspect the generated response and then return the actual response. The application receives the rail’s result and either sends an approved response, a modified response, or terminates the request. Even if the library returns “block,” if a separate code path sends the original response as is, controls will not apply to that path.
By connecting Presidio inspections for input and output, NeMo’s policy flow, and application enforcement, data protection actions can be explained end-to-end. In security architecture documents, adding “what is inspected, and what is stopped if it fails” next to each stage’s name clarifies the scope of implementation.
Masking and Access Permissions Answer Different Questions
Sensitive information detection determines “Does this content contain information to be protected?” Access permission checks determine “Can this user access this information?” Both determinations are necessary together.
For example, suppose a customer service agent has permission to summarize the record of one assigned customer. While contact information to be passed to an external model can be masked, that fact does not grant permission to search records of customers from other departments. Conversely, even if a request comes from an employee with access permissions, it must be verified whether the external service to which the data will be transmitted is an approved destination.
Therefore, in this design, document search and business API permissions are enforced by the server, and the appropriateness of requests and results is further inspected via guardrails. Business information such as data owner, user role, document classification, and transmission destination must be linked to policy decisions. This section describes application design principles extended from the functional descriptions of the two libraries.
In Operations, Verify Inspection Order and Logging Paths
When verifying the effectiveness of AI DLP, both detection results and actual transmission results are considered. The following three points are particularly good to decide during the design phase.
Streaming: Exporting Only the Inspected Scope
Streaming is a method of sending responses generated by the model to the user incrementally. Content already transmitted cannot be recalled by a belated output block. If the goal is to prevent sensitive information exposure, configure buffers and output policies to inspect the entire response or transmit only the inspected scope.
NeMo provides streaming and output rail settings. The official FAQ advises inspecting segments first with stream_first: False if inspection is required before exposure. When applying, verify inspection units, buffer processing, and interruption behavior in the actual integrated environment. Full response inspection and segment-by-segment inspection have different characteristics in terms of latency and context acquisition. NeMo Streaming Settings, Runtime Security FAQ
Errors: Deciding How to Handle Inspection Failures
Detectors or policy services may time out. At this point, it must be decided whether to abort the request, restrict functionality, or send it to another approved processing path. For example, if a path prohibits the external transmission of raw personal information, requests that fail to complete essential inspections can be designed not to be forwarded externally.
This does not mean applying the same interruption rules to all services. The key is to differentiate between “inspection not performed” and “inspection passed” in records, while segmenting policies based on the data to be protected and business impact.
Logs: Observing Protection Results While Minimizing Raw Data Storage
Even if the response returned to the user is masked, the original input might first be stored in tracking systems. NeMo’s official documentation also states that PII rails do not automatically sanitize all application logs and external observation systems. Logs, caches, error reports, and retry records should also be treated as separate data destinations, applying pre-storage processing and access/retention policies. NeMo Runtime Security FAQ
Operational metrics can largely be collected without the full raw text. This involves linking request identifiers to information such as which policy version was applied, what information types were detected, what actions were performed, and how long processing took. Limited investigation paths requiring raw text verification should have separate permissions and retention periods defined. The items in this section are design examples extending the previously defined data movement scope to operational paths.
Evaluate Implementation Effectiveness by Detection Quality and Business Outcomes
Presidio’s official documentation states that automatic detection does not guarantee finding all sensitive information and requires evaluation tailored to the use case. Evaluation measures both cases where legitimate data is incorrectly blocked and where sensitive information is missed. Presidio Project Guide, PII Detection Evaluation Document
First, precision and recall can be verified using controlled evaluation data such as synthetic data. Precision is the ratio of actual sensitive information among what was detected as sensitive information, and recall is the ratio of detected sensitive information among all actual sensitive information. Separating by type, such as names, contact information, and identification numbers, and distinguishing between mixed Korean and English data, reveals areas for improvement.
Next, verify the results for the entire application. The following items are evaluation examples for the consultation summary service discussed in this article.
- Delivery Results: Do the values transmitted to the external model and returned to the user comply with the relevant policy?
- Business Quality: Does the service correctly summarize the cause of delivery delays and customer requests even after masking?
- Normal Processing: Does it avoid unnecessarily rejecting consultations that do not contain sensitive information?
- Failure Handling: Are the defined interruption/restriction actions executed if essential inspections fail?
- Operational Costs: Do the latency and costs incurred by additional inspections fall within the service objectives?
Especially after masking, information relationships can change. If two different people are replaced with the same notation, “who requested what from whom” becomes unclear. For tasks requiring distinction, consider designs that use different substitute identifiers, and if a mapping table between original and substitute values is kept, that table should also be managed as a protected asset.
Summary: The Two Tools Can Be Described as AI DLP Components
The process of protecting sensitive information in LLM services using Presidio and NeMo Guardrails can be explained under the theme of AI DLP implementation. Clearly stating the role and protection scope of each tool clarifies its technical meaning.
- Presidio: A data protection engine that detects and masks/replaces sensitive information.
- NeMo Guardrails: A guardrail engine that configures inspection and processing flows, including AI DLP policies.
- Application/Gateway: An enforcement layer that actually allows or stops data transmission and task execution based on permissions and destination policies.
Lectures or design documents introducing this configuration can use the title “Implementing AI DLP in LLM Environments: Presidio and NeMo Guardrails.” By including the processing scope and verification criteria for input, search, tool results, output, and logs, readers can connect the tools’ functionalities with the protection provided by the system.
The actual scope of AI DLP protection is determined not only by which tools are installed but also by what data moves to which destination and what inspections and enforcements it undergoes before that.
Leave a Reply