To send customer messages to an LLM for classification, first extract the needed text, find sensitive fragments, and replace them according to the task rules. Presidio helps detect and transform such fragments, but it does not guarantee that all personal data will be detected. Replacing just a name with [PERSON] is not enough to consider the message anonymous. This limitation is stated directly in the project documentation.
This FAQ is for support leaders and integration developers. It explains how to prepare complaint text: what to hide, how to preserve customer distinctiveness, and why the detector misses data. This is a technical review, not a legal opinion on whether transmission to a specific provider is allowed. Documentation was checked on November 4, 2026. Presidio was not run here; the transformations shown are suggested training examples, not results of a library test.
Contents
- What exactly does Presidio do before sending text to AI?
- What data should be removed before running the detector?
- What should names, phone numbers, and addresses be replaced with?
- How do you preserve the connection between messages from the same customer?
- Is it enough to specify Russian?
- Why does Presidio miss internal numbers and unusual contact details?
- Why does useful complaint context disappear after cleaning?
- How can you tell whether the cleanup quality is good enough for the task?
- Can the same processing be used to clean PDFs and screenshots?
- Where should Presidio be deployed, and what should you do if processing fails?
- Can you consider the data transfer allowed after replacements?
What exactly does Presidio do before sending text to AI?
Presidio separates detection from transformation. The Analyzer finds text segments, and the Anonymizer applies the selected operations to them. Finding a last name and deciding what to replace it with are two different tasks. That is why detector setup alone does not yet determine the content of the request sent to the LLM. The architecture is described in the text handling section.
For a case-reason classifier, you usually need the meaning: "the payment was charged twice," "the item arrived damaged," "cannot log in." A name, contact detail, and order ID can often be excluded. For preparing a personalized response, the requirements are different: linking the reply back to the customer record is better done inside your own system after generation.
Start by defining the outcome: for example, get the complaint category and a short problem summary. Then define the allowed input fields. This approach helps avoid sending an entire CRM record just because it is convenient to export.
What data should be removed before running the detector?
Exclude fields that are clearly unnecessary for analysis. There is no need to search for a phone number in text if the integration already adds a separate phone field. Suggested structure for complaint classification:
| Source record field | Suggested action | What remains useful |
|---|---|---|
| Contact phone and email | Do not include in the request | Reason for the inquiry |
| Employee full name and signature | Delete or replace with a local pseudonym | Participant role |
| Complaint text | Process with the detector and rules | Problem description |
| Order number | Keep in the internal system | Link to the order after the reply |
| Attachment | Do not send together with the text automatically | Separate file-processing solution |
This is an example of a project decision, not a built-in Presidio policy. The set of fields depends on the task and company requirements. For table data, the project has Presidio Structured: processing cells and columns differs from passing the entire row as arbitrary text.
What should names, phone numbers, and addresses be replaced with?
Choose the operation based on what needs to remain after processing. Anonymizer includes, among others, replace, redact, mask and encrypt: replacement, removal, partial hiding, and encryption. Parameters and behavior should be checked against the operator documentation.
To identify the complaint topic, it is suggested to replace contact details with clear labels: [EMAIL], [PHONE]. Removal is appropriate when the mere presence of the fragment is not needed. Partial masking leaves part of the original value: it cannot automatically be considered sufficient for sending to an external service.
Training example: "I am Customer A. For order ORDER-A, the payment was charged twice, reply to EMAIL-A" can be transformed into "I am [CLIENT_1]. For order [ORDER_1], the payment was charged twice, reply to [EMAIL]". The reason for the complaint is preserved, but the exact values are not used in classification. What transformation your configuration will actually perform must be checked separately.
How do you preserve the connection between messages from the same customer?
Use consistent pseudonyms within the needed scope. If one participant received the label [CLIENT_1], their later messages in the same conversation should keep that label. Another participant needs a different one. Replacing all names with [PERSON] can mix up roles and distort conversation analysis.
The suggested scope is a single conversation, unless analytics need to link the customer across cases. Keep the mapping table inside a trusted system and do not add it to the prompt. Do not extend the retention period or scope just for developer convenience.
This is a project recommendation. The official Presidio FAQ includes a link to a pseudonymization example that can be adapted. Having reversible matching does not prove irreversible anonymization: the ability to restore the link must be considered separately.
Is it enough to specify Russian?
No. For Russian text, the NLP model, language configuration, and recognizers for the needed entities must all be aligned. A language code by itself does not give the model knowledge of Russian surnames, inflections, and addresses. The project describes the adaptation in the multilingual processing guide.
Practical question for the developer: which model recognizes names, which rules look for contact details, and which entities are included for Russian specifically? The answer “the library supports multiple languages” does not replace a list of the exact components.
To test it, prepare different forms: a name in a signature, a surname in an oblique case, an address inside a quote, mixed Russian and English text. This is the suggested set of examples. The results and accuracy for Russian were not measured in this article.
Why does Presidio miss internal extensions and unusual contact details?
A general-purpose detector is not required to know your CRM format. A contract number, customer code, or internal login may look like ordinary words. For such values, you need a separate recognizer or removal of the corresponding field before analysis.
In Presidio, you can add recognizers based on regular expressions, value lists, and custom logic. The extension architecture is described in the recognizer guide. You should not treat any sequence of digits as a personal identifier: the same pattern may match a product SKU.
Suggested example: if an internal identifier always has the prefix CLIENT-, the rule should account for that format and the surrounding context. Then you need negative examples—similar SKUs that must not be removed. That scenario was not run here and is not offered as a ready-made universal rule.
Why does useful complaint context disappear after cleanup?
The detector may mistake ordinary text for a sensitive entity. That is a false positive. For example, a broad numeric pattern can affect a product feature; the exact outcome depends on the configuration. The official FAQ discusses threshold tuning, recognizer selection, and the tradeoff between false negatives and false positives. Source: detection errors.
Analyze the cause on specific examples: which recognizer fired, which span it marked, and why it cannot be removed. Raising the overall threshold just to make the text look cleaner is risky: along with extra replacements, you can also lose the findings you actually need.
Permission to keep individual words should be narrow and justified. For example, a product line name can be preserved for defect classification, but that is not a reason to allow all similar names. After changing the rule, check both the useful text and the sensitive fragments that were previously detected.
How do you know whether the cleanup quality is good enough for the task?
Evaluate misses and extra removals separately. Recall shows the share of sensitive entities detected out of all annotated ones. Precision shows the share of correct findings out of all detector findings. These definitions and formulas are provided in the Presidio evaluation guide.
Suggested process: manually label an approved sample, separate examples for tuning from the control set, and compare extracted spans with the labels. Count errors separately by entity type: one overall metric can hide address misses even when email detection is strong. Check full value boundaries, not just whether part of a value was found.
At the same time, compare complaint classification before and after transformation in an approved test environment. The category “duplicate charge” must remain distinguishable. The readiness threshold is set by the process owner together with the data owners; there is no universal percentage that permits any transfer.
Can the same processing be used to clean PDFs and screenshots?
A text detector does not clean an image automatically. For images, Presidio has a separate Image Redactor that uses OCR and sensitive entity detection. So text recognition quality affects downstream replacements. Image Redactor documentation.
If a request contains a screenshot, processing only the text field leaves the attachment as a separate data channel. The suggested rule for the first scenario is to exclude attachments from submission until a dedicated processing path is defined for them.
For PDFs, also distinguish between extracted text and the file itself. Cleaning a text copy does not mean the original document has been stripped of data. Text preparation is covered in the PDF parsing tools comparison; it addresses extraction, not anonymization confirmation.
Where should Presidio be deployed, and what should you do if processing fails?
The suggested placement is inside trusted infrastructure before an external request is formed. On output, create a new object using only allowed fields. If the detector fails or returns an unclear result, route the record to manual review; automatically sending the original text should be a separate prohibited bypass.
Check not only the prompt, but also logs, traces, and error messages: in the proposed architecture, the original request should not reach them without an approved storage and access policy. The mere presence of a local service does not implement that policy.
The official FAQ warns: the Presidio API does not include built-in authentication; access protection should be provided by a separate infrastructure layer. Do not expose the service directly to an untrusted network. Source: Presidio deployment.
Can you consider the data transfer permitted after replacements?
You cannot draw that conclusion from the detector result. The project itself warns that automatic detection can miss sensitive information. Beyond direct identifiers, company specialists should assess the remaining context: a unique event, job title, location, or a combination of details may still be identifying. This is a risk that must be assessed for a specific dataset, not a property of any label [PERSON].
The legal permissibility of transfer, contractual terms, and requirements for a specific system are assessed separately. This article does not confirm regulatory compliance and does not present Presidio cleanup as such confirmation. If you cannot justify external transfer, consider performing the task within approved infrastructure.
How does Vladimir Lomtev’s AI studio help prepare requests for AI?
Vladimir Lomtev’s AI studio focuses on data preparation, AI integration with business systems, and testing. In complaint analysis, this makes it possible to connect the work to three concrete outcomes: define the input field set, design the transformation before the model call, and verify that the meaning is preserved on control examples.
The first step is to choose one complaint classification process, describe its current output, data sources, constraints, and readiness criterion. Such a description helps keep the integration discussion specific. It does not guarantee anonymization, error-free processing, or the legal permissibility of transfer.
Bottom line: what text should be sent to the classifier?
Pass only the fields needed for the task after the agreed transformation and validation. Distinguish between detecting a sensitive fragment, replacing it, and preserving the connection between messages. To get started, it’s often easiest to choose a complaint-reason classification use case: it has a clear output, and there’s usually no need to return the customer’s contact details to the model. The success of this kind of workflow depends on both the quality of the redaction and preserving the meaning of the original message.