GLiNER2-PII: Multilingual PII Extractor

• GLiNER2-PII is a multilingual extractor that uses a schema-driven design to accurately detect 42 fine-grained PII entity types at the character span level.
• The model leverages a compact transformer architecture and synthetic multilingual training data to ensure privacy-preserving extraction across diverse document formats and locales.
• Evaluated on legal and medical benchmarks, GLiNER2-PII demonstrates a high recall and a favorable precision–recall trade-off, outperforming comparable systems in F1 score.

GLiNER2-PII is a compact, multilingual, schema-conditioned entity extractor for privacy-preserving text processing, adapted from GLiNER2 and fine-tuned to a fine-grained PII taxonomy of 42 entity types. It targets precise character-span detection of personally identifiable information across heterogeneous formats, locales, and noisy or semi-structured documents. In the literature, the term also appears in a broader sense to denote the use of GLiNER2’s schema-driven interface for PII detection; in that broader usage, GLiNER2 encodes text together with a PII schema and scores spans against label embeddings, whereas the named GLiNER2-PII model is a specific multilingual fine-tuned variant released in 2026 (Zaratiana et al., 11 May 2026, Zaratiana et al., 24 Jul 2025, Minko et al., 6 May 2026).

1. Terminology, lineage, and scope

GLiNER2-PII inherits its interface and task formulation from GLiNER2, an efficient multi-task information extraction system built around a compact pretrained transformer encoder. GLiNER2 extends the original GLiNER from NER-only extraction to a unified schema interface supporting named entity recognition, hierarchical structured extraction, and text classification. Its input is organized as $[Task\ Prompt] \oplus [SEP] \oplus [Input\ Text]$, and multiple tasks can be composed in one pass as $$[Task1] \oplus [SEP] \oplus [Task2] \oplus \dots \oplus [SEP] \oplus [x_1,\dots,x_N]$$ (Zaratiana et al., 24 Jul 2025).

Within that framework, PII detection can be expressed either as NER with label descriptions or as hierarchical structured extraction with parent–child fields such as Identity, ContactInfo, and NetworkIDs. The later GLiNER2-PII model preserves the schema-conditioned design but specializes it for broad multilingual PII extraction at character-span resolution. Its stated parameter count is approximately 0.3B, whereas GLiNER2 is described as a 205M-parameter encoder in its comprehensive comparison table (Zaratiana et al., 24 Jul 2025, Zaratiana et al., 11 May 2026).

This dual usage of the term is reflected in adjacent work. The GLiNER Guard paper explicitly describes a PII use case called “GLiNER2-PII,” where GLiNER2 performs zero-shot PII detection by encoding text alongside a PII schema such as NAME, ADDRESS, or PHONE_NUMBER. That usage is not identical to the dedicated GLiNER2-PII model, but it situates the model within a broader line of schema-driven PII extraction and guardrail design (Minko et al., 6 May 2026).

2. Architecture and inference semantics

The defining interface of GLiNER2-PII is label conditioning. Entity types are provided as inputs, optionally with natural-language descriptions, so the same architecture can support fine-grained or coarse-grained PII policies without architectural changes. This is particularly useful when different subtypes must be treated differently, such as masking access_token inside a URL while preserving surrounding context (Zaratiana et al., 11 May 2026).

At inference time, the model returns exact character-level spans with associated labels and confidence scores. Character-level resolution is emphasized both in the training data and in the public inference API. The paper does not describe the internal tokenization or the specific decoding or alignment mechanism; it states only that character spans are returned and that inference exposes a threshold parameter to trade precision and recall. Overlapping and nested entities are supported, so a full_name span may contain first_name and last_name, and a URL may include an inner api_key or access_token (Zaratiana et al., 11 May 2026).

The inherited GLiNER2 mechanics clarify the underlying schema-driven extraction style. In GLiNER2’s NER head, span–label compatibility is scored as

$score(s_i, e_j) = sim(h_{s_i}, h_{e_j}),$

where similarity is a dot product with sigmoid activation, and spans above a threshold such as $0.5$ are selected. GLiNER2 also uses learned special tokens—[P], [E], [C], [L], and [[SEP](https://www.emergentmind.com/topics/semantic-entropy-production-sep-metric)]—to encode task metadata, entity labels, structured fields, and classification options. GLiNER2-PII is described as retaining this flexible label-conditioning interface while specializing it for PII extraction rather than for the full multi-task surface of the base model (Zaratiana et al., 24 Jul 2025, Zaratiana et al., 11 May 2026).

A common misconception is to treat GLiNER2-PII as a purely masking-oriented or rule-based privacy filter. The model itself is a span extractor: downstream masking or redaction is a separate step, and the paper describes post-processing for redaction only at the level of masking returned spans rather than through a built-in redaction engine (Zaratiana et al., 11 May 2026).

3. PII taxonomy and span annotation policy

GLiNER2-PII is fine-tuned to a taxonomy of 42 PII entity types organized into seven semantic groups (Zaratiana et al., 11 May 2026).

• Person/identity: person, full_name, first_name, middle_name, last_name, date_of_birth.
• Contact/location: email, phone_number, address, street_address, city, state_or_region, postal_code, country.
• Government/tax identifiers: government_id, national_id_number, passport_number, drivers_license_number, license_number, tax_id, tax_number.
• Banking/payment: bank_account, account_number, routing_number, iban, payment_card, card_number, card_expiry, card_cvv.
• Digital identity: username, ip_address, account_id, sensitive_account_id.
• Secrets/credentials: password, secret, api_key, access_token, recovery_code.
• Sensitive dates: sensitive_date, document_date, expiration_date, transaction_date.

Examples given in the paper include [email protected] as email, +1 415 555 0199 as phone_number, GB33BUKB20201555555555 as iban, and a URL containing an access_token. The design is explicitly intended for fine-grained, policy-aligned label sets. This suggests that GLiNER2-PII is not limited to a fixed compliance checklist; rather, the schema interface supports selective masking policies at subtype granularity, provided that the relevant labels are supplied at inference time (Zaratiana et al., 11 May 2026).

The annotation policy requires exact substrings of PII values, excluding surrounding words, punctuation, and field labels unless they are part of the value. Exact offsets matter because evaluation uses strict span matching. Nested and overlapping spans are permitted, which is important for values embedded inside larger structures and for compound name representations (Zaratiana et al., 11 May 2026).

The broader GLiNER2 framework supports an alternative way to represent PII through hierarchical structures. For example, Identity(name::str::Full legal name, ssn::str::US Social Security Number, passport_number::str::Government-issued passport number, driver_license_number::str::Driver license ID) and ContactInfo(email::list::All email addresses present, phone_number::list::All telephone numbers present, address::list::Postal addresses) can be extracted in a single schema. GLiNER2-PII focuses on span extraction rather than on reporting such hierarchical structures in its benchmark results, but the underlying interface remains relevant for applications that need grouped identities or contact blocks rather than only flat spans (Zaratiana et al., 24 Jul 2025).

4. Synthetic multilingual corpus and training regime

The training corpus for GLiNER2-PII consists of 4,910 annotated texts and is fully synthetic. The paper motivates this choice by noting that real PII is difficult to collect and share and presents privacy risk. To generate the corpus, the authors use the Pioneer Agent constraint-driven pipeline. Given a label inventory and a natural-language task description, the framework samples constraints and queries a “large frontier decoder” with temperature 0.01 to produce both text and gold span annotations (Zaratiana et al., 11 May 2026).

Two classes of constraints are described. Programmatic constraints derived from the label inventory control entity-type counts, exclusion subsets, and at-least-one requirements. Diversity constraints derived from the task description control document type, locale, register, tone, and related stylistic factors. The result is a multilingual synthetic corpus spanning English, French, Spanish, German, Italian, Portuguese, and Dutch, with occasional mixed-language passages. Domains and formats include chat logs, support tickets, CRM notes, KYC forms, invoices, medical records, and credential files, introducing semi-structured and noisy artifacts such as forms and logs (Zaratiana et al., 11 May 2026).

The paper states that no real-world PII is used. It also states that nested and overlapping entities are permitted in the annotations. These design choices matter because they align the supervision signal with the exact-match span evaluation used later and with the intended deployment setting of downstream masking and auditing (Zaratiana et al., 11 May 2026).

By contrast, the paper does not report preprocessing specifics, tokenization or character-handling details, optimizer, learning rate, batch size, number of steps or epochs, compute hardware, or training duration. No curriculum or sampling schedule is specified beyond the constraint sampling inherent to the data pipeline. This absence is a significant part of the model’s published profile: the dataset design is described in detail, but the optimization recipe is not (Zaratiana et al., 11 May 2026).

For context, related work on scalable multilingual PII annotation describes a human-in-the-loop framework spanning 13 locales and approximately 336 locale-specific PII types, with phased Pilot → Training → Production curation and explicit QA procedures. That work does not mention GLiNER2-PII, but it provides a contrasting data strategy built around expert annotation rather than synthetic-only generation (Meena et al., 3 Oct 2025).

5. Evaluation protocol and empirical performance

GLiNER2-PII is evaluated on SPY (Synthetic PII Yesterday), specifically on two naturally formatted out-of-distribution subsets: Legal Questions with 100 documents from legal Q&A forums and Medical Consultations with 100 documents from medical transcripts. SPY uses seven categories—name, address, email, phone_num, id_num, url, and username—so each model’s native labels are deterministically mapped to these seven categories for comparison (Zaratiana et al., 11 May 2026).

The evaluation uses span-level exact-match precision, recall, and F1:

$$P = \frac{TP}{TP + FP}, \qquad R = \frac{TP}{TP + FN}, \qquad F1 = \frac{2 \cdot (P \cdot R)}{P + R}.$$

A predicted span counts as correct only if both its label and its start and end character offsets equal a gold span. No overlap or IoU variants are used. The paper emphasizes recall because false negatives are especially costly in redaction settings. It does not report micro versus macro aggregation details or confidence intervals (Zaratiana et al., 11 May 2026).

On this benchmark, GLiNER2-PII achieves the highest average F1 among the five compared systems. Its reported results are:

• Legal: precision 0.354, recall 0.722, F1 0.475
• Medical: precision 0.355, recall 0.681, F1 0.467
• Average F1: 0.471

The compared systems are reported as follows:

• OpenAI Privacy Filter: average F1 0.373, with high recall 0.640–0.671 but lower precision 0.250–0.271
• urchade/gliner_multi_pii-v1: average F1 0.384, with the highest precision 0.483–0.522 but the lowest recall 0.308–0.314
• nvidia/gliner-PII: average F1 0.391
• knowledgator/gliner-pii-base-v1.0: average F1 0.368

The paper further states that GLiNER2-PII delivers the best F1 on both domains and the highest recall among GLiNER variants, with a favorable precision–recall trade-off for redaction. It also notes that the main precision issue is over-predicting name entities, including confusions with common nouns, organizations, or product names, and proposes label-specific thresholds, lightweight filtering, or calibration using a small validation set as mitigations. The authors hypothesize that the 42-label granularity improves representation of broader categories such as names, although no explicit ablations are reported (Zaratiana et al., 11 May 2026).

6. Position within the GLiNER ecosystem, deployment implications, and limitations

GLiNER2-PII occupies a specific place in the GLiNER family. GLiNER2 provides the schema-driven multi-task substrate and emphasizes CPU-efficient, privacy-preserving local inference with a 205M-parameter encoder, context length 2048 tokens, and support for task composition in one pass. GLiNER Guard then specializes the GLiNER2 line for production LLM safety and PII detection under strict latency and cost constraints, introducing compact uni- and bi-encoders and a 209M Omni variant that perform safety classification and span-level PII detection in a single forward pass (Zaratiana et al., 24 Jul 2025, Minko et al., 6 May 2026).

This relationship is important because GLiNER2-PII and GLiNER Guard solve overlapping but non-identical problems. GLiNER2-PII is a multilingual PII extractor trained on a synthetic 42-type taxonomy and evaluated on SPY. GLiNER Guard is a unified moderation-and-PII guardrail trained on 467,273 multi-task examples, with 108,702 span-labeled examples over 32 entity types, and evaluated not only on PII but also on public safety benchmarks. In GLiNER Guard’s reported serving setup, the compact uni-encoder reaches 193.6 RPS with P99 900 ms under dynamic batching on a single A100 using ONNX TensorRT FP16, and its pipeline evaluation on PII-Bench emphasizes context-dependent entities such as Name and Address while relying primarily on rule-based components for structured identifiers (Minko et al., 6 May 2026).

The contrast highlights an important deployment distinction. The GLiNER2-PII paper does not report latency, throughput, or memory footprints. By contrast, GLiNER Guard is explicitly deployment-oriented, with serving data, batching configurations, and cascade guidance. A plausible implication is that GLiNER2-PII should be understood primarily as a research model for multilingual span extraction rather than as a fully characterized production serving artifact (Zaratiana et al., 11 May 2026, Minko et al., 6 May 2026).

The limitations reported for GLiNER2-PII are substantial and technically consequential. Training data are entirely synthetic and not human-validated. Evaluation is limited to legal and medical domains on SPY’s seven labels. No per-language breakdowns or statistical tests are reported. Precision remains the main area for improvement, especially for name-like spans, and boundary errors and entity confusions are common. The paper also notes that broader multilingual, locale-specific, and domain-diverse evaluations are needed. These points caution against equating multilingual synthetic training with verified multilingual robustness. This suggests that future work could combine GLiNER2-PII’s schema-conditioned extractor with the kind of locale-specific, human-in-the-loop annotation framework described in multilingual PII curation research, especially for rare scripts, locale-dependent identifiers, and compliance-sensitive deployment regimes (Zaratiana et al., 11 May 2026, Meena et al., 3 Oct 2025).