The task: keep unnecessary data out of AI

A company wants to search contracts, support email and internal instructions with RAG. Connecting documents is often the easy part. The harder decision is what may enter the index, model prompt, query logs and backups at all. One message can combine a useful problem description with a customer's name, phone number, order ID and payment details. Indexing everything indiscriminately makes the retrieval layer copy data that the task does not need.

A local deployment reduces the risk of sending data to an external model provider, but it does not replace access control or data minimisation. An employee with broad permissions, an incorrectly filtered search result or verbose telemetry can expose information inside the company. Before a RAG pilot, therefore, ask which fields are essential to answer the question and which should be detected, removed or replaced with a consistent pseudonym before indexing.

What Presidio actually provides

The open-source Presidio project includes an Analyzer for detecting sensitive entities and an Anonymizer for transforming them. Detection can combine regular expressions, checksums, contextual cues, built-in recognisers and custom models. Transformations include replacement, masking, redaction and hashing. There are also components for images and structured data. The repository and its documentation are under the MIT licence. This is a library and a set of components, not a ready-made guarantee of privacy compliance.

The developers themselves give an important warning: automated detection cannot identify every sensitive item. The default configuration focuses on English; the documentation explains how to add languages and custom recognisers. For Russian contracts, merely installing the package is not a validation exercise. You need an appropriate language model, rules for local formats and a test set drawn from your own documents. Company names, job titles, contract numbers and internal codes often need domain-specific rules.

The official Presidio diagram illustrates just one stage: transforming entities that have already been detected. A high-quality masking operation cannot compensate for a missed detection. If the recogniser misses an account number or a surname, the Anonymizer leaves that fragment in the original text.

Where the control belongs in the architecture

A practical sequence for a small business is: document source → text and metadata extraction → access classification → sensitive-entity detection → transformation decision → RAG index → permission-filtered retrieval → cited answer. In parallel, limit what enters logs and backups. This is an engineering validation sequence, not a universal legal-compliance design.

Define the purpose of each collection before indexing it. To answer recurring support questions, the fault description, product model and resolution may be enough. The customer's name and phone number may be unnecessary in the search index. If an employee needs to open a particular order, it is often safer to keep a reference to the CRM record and retrieve details under the employee's current permissions than to replicate the whole customer card in a vector index.

Distinguish three operations:

  • Deletion: the original value is not needed for the task and should not be recoverable from the index.
  • Masking or a label such as `CLIENT_17`: references need to remain linked within a document or conversation, but the person's identity is not needed for search.
  • Reversible transformation: recovery is genuinely required for a specific workflow; the key and mapping table then belong in a separate protected store, not alongside the index.

A plain hash is not anonymity. Short, predictable values may be guessed, and identical hashes make records linkable. Presidio documents the use of salt and notes that stable hashes across calls require the organisation to manage that salt deliberately. If cross-record linkage is unnecessary, do not introduce it merely for implementation convenience.

Data and integrations needed

The pilot does not need the entire archive. Choose one process and a small representative sample: different types of email, scans of varying quality, attachments, tables and exceptional cases. Annotate this sample manually inside a protected environment: which spans are sensitive, what class each belongs to and which roles may see it. The test repository itself contains source data and therefore needs access controls and a retention period.

Configure recognisers for the domain. Patterns help with email addresses and phone numbers; customer names or free-form addresses need a language model and context. Internal identifiers may require dictionaries and custom rules. Scans need OCR first, and an OCR error can break the pattern of an identifier: the detector cannot find text the extraction stage lost. Keep a link from extracted spans to the source page so a reviewer can investigate mistakes.

RAG integration must check permissions not only at ingestion but at retrieval. Masking does not replace an access-control list. A de-identified index may still hold commercial terms, salaries or project details that are not available to every employee. Document owner, version, allowed roles and validity metadata therefore have to survive extraction and feed into the search filter. A user's prompt must not be allowed to broaden those permissions.

A local setup needs a server or workstation for OCR, detection and indexing, document storage, a metadata database and backups. Memory requirements and the need for a GPU depend on the chosen language model and document throughput; Presidio imposes no single hardware configuration. For a small volume, start on CPU and measure latency, then decide about acceleration from observed load. Run heavy OCR and bulk-archive processing in a background queue rather than an interactive request.

Measure quality, not merely the number of names found

On the annotated sample, measure at least two error types. A missed sensitive span creates exposure risk. A false positive removes useful context: the model may no longer know which product or contract a passage concerns. Report recall and precision separately for each data class, not one overall percentage. Rare but critical classes such as payment details, identity documents or health information must not be hidden by a good average on common email addresses.

Test the entire route, not only the detector. Run controlled RAG queries under roles with different permissions and inspect retrieved passages, answers, application logs, traces, caches and exports. If the raw text never reaches the index but appears in an error log, the risk has not gone away. If a supposedly masked answer still identifies someone through a combination of remaining details, reconsider the retained fields and access rules.

Economics and the next step

The main costs are annotating a reference set, configuring Russian and domain-specific recognisers, reviewing exceptions and maintaining rules as document formats change. Open-source software does not make this work free. Do not promise savings before measuring what share of documents can pass automatically at an acceptable risk level.

Start with one corpus, for example a month's worth of closed support tickets. Define the search objective and user roles, annotate a sample, compare retrieval before and after masking, and route ambiguous documents to human review. The pilot passes when an authorised employee can still find the necessary answer while unnecessary personal and confidential details do not appear in the index, answer or logs. If that condition is not met, expanding RAG to the whole archive is premature.

Sources: the Presidio repository and documentation; its language configuration and recogniser-extension guide; NIST SP 800-122 for a general approach to the risk of identifying information. The architecture and pilot recommendations are editorial analysis, not a claimed outcome at a named company.