rizzo-pii: a reversible pseudonymization layer for Italian legal documents sent to cloud LLMs
Local-first privacy guard: anonymize your documents before sharing with LLMs.
At a glance
- What is it?
- rizzo-pii is an Italian-first token-classification model plus a local workflow that replaces personal data with typed placeholders before a document goes to ChatGPT, Claude or Gemini, then restores the real values on the user's machine. The design is sound for a narrow, well-defined job, but the README overstates how much of the privacy problem the tool actually removes.
- Who is it for?
- Adopt rizzo-pii if you are processing Italian-language documents containing codice fiscale, partita IVA or dati catastali and you want to keep using a cloud model without pasting raw identifiers into it. Do not adopt it if your documents are primarily English, if your threat model includes the cloud provider correlating pseudonymized text, or if your workflow depends on the model seeing exact dates and amounts.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 37 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The specific failure rizzo-pii is built to prevent
The README opens with a concrete scenario: a professional summarizes a contract or drafts a reply by pasting the document into a chat interface. That is fast, and it moves names, addresses, tax codes, IBANs and health details onto servers the user does not control. rizzo-pii targets Italian legal and accounting work specifically. The stated audience is law firms, accountants and notaries bound by the GDPR. The project's own framing of the alternative is worth quoting because it defines the scope: running a frontier-grade open model locally is described as costing roughly 9,000 to 10,000 euros in hardware, while small models that fit a laptop are described as not competitive on legal reasoning and dense contracts. rizzo-pii does not try to close that gap. It accepts the cloud model and tries to remove the data from the equation instead.
How the placeholder round trip actually works
The mechanism is a three-local-step, one-remote-step loop. Locally, the token-classification model tags every span of personal data. Each span is replaced with a stable, type-aware placeholder such as [FULLNAME_1], [IBAN_1] or [CF_1]. The mapping from placeholder to real value is written to a dictionary that stays on disk. Identical values receive the same placeholder, which matters: the remote model sees a text where the same person is referred to consistently, so pronoun resolution and cross-references still work. The anonymized text is sent to the cloud model. When the answer returns, a local pass substitutes the real values back in. The README states that everything except the frontier query runs on the user's CPU and that only placeholder text crosses the boundary. That is the whole architecture, and it is the part of the project I find most defensible, because it does not depend on trusting a vendor's retention policy.
The model: 22 categories, an mmBERT backbone, and where the Italian coverage sits
rizzo-pii:0.3B is a token-classification model with roughly 0.3 billion parameters built on an mmBERT / ModernBERT backbone. The README lists 22 PII categories and singles out three Italian-legal identifiers as differentiators: codice fiscale, partita IVA and dati catastali. The claim is that no other open model covers them. I cannot verify that claim from the supplied material, and it is the kind of claim that ages quickly, but the category choice is the most interesting design decision here. A generic English NER model will catch a person's name and often an address; it will not reliably catch an Italian tax code in its 16-character alphanumeric form. The advertised resource profile is about 0.5 GB of RAM on CPU, and the README reports a micro-F1 of 0.989 on what it calls real Italian validation. Treat that number carefully. It is a single aggregate, the README does not break it down per entity type, and aggregate F1 on a validation set says nothing about the long tail of a specific firm's document templates.
Getting it running: releases, not a pip install
The distribution model is a desktop application rather than a library. The releases page carries v2.0.0 (dated 2026-08-08) and v1.0.0 (2026-06-28, labelled Windows-Linux-macOS). The README links three platform-specific downloads: a Windows installer, a macOS build for Apple Silicon, and a Linux AppImage. There is no pip install line, no Python API example and no CLI invocation shown in the supplied README, so if you were expecting to import this into an existing pipeline, the material does not tell you how. The README does state there is no API key and no telemetry. The homepage at rizzo-ai-academy.github.io/rizzo-pii is listed as the documentation entry point, and a full technical report PDF is linked at report/rizzo-pii-report.pdf covering the model, dataset, method and experiments. If you need to evaluate the training data composition before trusting the detector on your own corpus, that PDF is the only place in the supplied material where it would be described.
The GDPR framing is stronger than the guarantee
The README describes the workflow as implementing data minimization under Article 5 almost literally, on the grounds that the third-party processor only ever sees pseudonymized text. This is where I would push back hardest. Pseudonymized data is still personal data under the GDPR; the regulation distinguishes pseudonymization from anonymization explicitly, and the README's own vocabulary is correct on this point even while the surrounding marketing language blurs it. Removing identifiers reduces the risk of a transfer, but it does not by itself create a legal basis for one, and it does not address the fact that a dense legal document with names stripped can still be identifying through context, dates, case numbers or a distinctive fact pattern. The EU AI Act alignment badge is similarly broad. The README says keeping personal data under local control supports the Act's emphasis on data governance. That is a reasonable statement about direction, not a compliance certification. Nothing in the supplied material is legal advice, and none of it should be read as a substitute for a data protection review of your specific processing.
Where reversible pseudonymization breaks down
The design has failure modes that the README does not discuss. Detection recall is the whole ballgame: a single missed codice fiscale in a 40-page contract defeats the purpose, and no aggregate F1 figure tells you the miss rate on your document type. Second, the placeholder scheme assumes the cloud model treats placeholders as opaque tokens. In practice a model may hallucinate a plausible value for [FULLNAME_1], drop a placeholder during summarization, or merge two placeholders, and the local restore step then either leaves a placeholder in the output or substitutes the wrong value. The README does not describe validation on the restore pass. Third, the approach is wrong for tasks where the identifiers are the substance. If you are asking the model to check whether a codice fiscale is internally consistent, or to compare two IBANs, replacing them with [CF_1] and [IBAN_1] makes the question unanswerable. Reversible pseudonymization preserves readability, not analytical content.
The honest alternative: run the model locally and skip the round trip
The obvious alternative is to run an open-weight model on the same machine and never send anything anywhere. The README itself frames this as the trade-off it is trying to avoid, citing the hardware cost of a frontier-grade open model and the quality gap on legal reasoning. That framing is more honest than most. But there is a second alternative the README does not name: using a general-purpose multilingual NER model from a model hub and wiring your own placeholder logic around it. The difference in approach is coverage versus assembly. A general model gives you names, organizations and locations, and you write the placeholder and restore layers yourself. rizzo-pii gives you the Italian-legal identifier categories and the round trip in one package, at the cost of accepting its category list and its desktop distribution model. If your documents are in English, the Italian-first design is a liability rather than a feature, and the general model is the better starting point.
Licence, maintenance and what to verify before you commit
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive and carries no copyleft obligation, though I am not giving legal advice and your organisation should confirm how MIT interacts with any bundled model weights, since the licence shown here covers the repository and the README does not separately state the terms of the model itself. The release cadence visible in the supplied material is two releases in about six weeks, v1.0.0 in late June 2026 and v2.0.0 in early August 2026, with the last push to main on 2026-08-09. A major version bump that quickly suggests the interface is still moving, and the README does not describe a migration path from 1.x to 2.0.0 or state whether the placeholder dictionary format is stable across versions. If you build a workflow around the on-disk dictionary, that is the first thing to test on upgrade. The concrete next step is to take twenty of your own documents, run them through the desktop build, and count the entities the model misses before you rely on it for anything that leaves your network.
Editorial conclusion
Adopt rizzo-pii if you are processing Italian-language documents containing codice fiscale, partita IVA or dati catastali and you want to keep using a cloud model without pasting raw identifiers into it. Do not adopt it if your documents are primarily English, if your threat model includes the cloud provider correlating pseudonymized text, or if your workflow depends on the model seeing exact dates and amounts. Before deploying, run your own documents through the model and measure recall on the entity types you actually care about, because the 0.989 micro-F1 in the README is a validation figure on the authors' own Italian test set and the README does not break it down per category.
Community notes