anonPL-300M

🇵🇱 Polski | 🇬🇧 English

---

🇵🇱 Polski

Fine-tune modelu GLiNER (bazowy model: knowledgator/gliner-x-small, backbone google/mt5-small, ok. 300M parametrów), dotrenowany na syntetycznych polskich dokumentach prawniczych do wykrywania danych osobowych i identyfikatorów wymagających anonimizacji.

WAŻNE OSTRZEŻENIE — to nie jest samodzielny system anonimizacji

Ten model jest przeznaczony wyłącznie jako dodatkowa warstwa wspomagająca recall (wykrywanie potencjalnie przeoczonych fragmentów), nigdy jako samodzielny, w pełni automatyczny mechanizm anonimizacji.

W docelowej architekturze, dla której model powstał, autorytatywnym mechanizmem wykrywania i maskowania danych osobowych jest deterministyczny pipeline regex + walidacja sum kontrolnych (dla PESEL, NIP, REGON, IBAN itd.) oraz klasyczny model NER. Ten pipeline jest audytowalny i, na czystym tekście, bezbłędny dla identyfikatorów o sztywnej strukturze. anonPL-300M nigdy nie zastępuje tego mechanizmu i nigdy nie trafia bezpośrednio do finalnego, zanonimizowanego dokumentu — każde wskazanie modelu, które nie pokrywa się z już istniejącą, zatwierdzoną detekcją, musi trafić do kolejki "niepewne / potencjalnie przeoczone", wymagającej ręcznej weryfikacji przez człowieka przed jakąkolwiek decyzją o usunięciu lub zamaskowaniu danych.

Powód tej decyzji architektonicznej: błąd fałszywie ujemny (model nie wykrył danej osobowej, która powinna być zamaskowana) w tym zastosowaniu oznacza realny wyciek danych osobowych klienta kancelarii — nieakceptowalne ryzyko bez warstwy ludzkiej weryfikacji.

Opis modelu i zastosowanie

Model jest wersją dostrojoną (fine-tune) architektury GLiNER, która stanowi oparty na zakresach (span-based) enkoder do ekstrakcji nazwanych encji (NER) z możliwością działania w trybie zero-shot. Został przeszkolony na syntetycznych polskich dokumentach prawniczych, takich jak pisma procesowe, umowy, akty notarialne oraz postanowienia sądowe. Głównym zadaniem modelu jest wykrywanie danych osobowych oraz różnego rodzaju identyfikatorów w dokumentacji przetwarzanej w kancelariach prawnych i instytucjach powiązanych.

W przeciwieństwie do tradycyjnych modeli NER, które opierają się na sztywnych słownikach lub predefiniowanych listach, GLiNER analizuje tekst pod kątem znaczenia i identyfikuje encje na podstawie opisów etykiet ("label description"), nie sztywnej listy słów. Takie podejście pozwala na skuteczne wykrywanie danych nawet wtedy, gdy występują one w nietypowych sformułowaniach, odmianach lub kontekstach gramatycznych, które nie pojawiły się wprost w materiałach treningowych.

anonPL-300M to mniejszy i szybszy z dwóch opublikowanych wariantów rozmiaru (drugi to anonPL-494M) — przy niższej liczbie parametrów oferuje wyraźnie szybszą inferencję i mniejsze zużycie pamięci, kosztem nieco niższej odporności na skrajnie zaszumiony tekst. W tej konkretnej ewaluacji różnica jakości między wariantami jest niewielka (patrz sekcja "Wyniki ewaluacji") — anonPL-300M jest zwykle rozsądnym domyślnym wyborem, a anonPL-494M ma sens tam, gdzie priorytetem jest maksymalna odporność na bardzo zaszumione skany.

Taksonomia etykiet

Model rozpoznaje 13 kategorii encji, podzielonych na dwie grupy o różnym uzasadnieniu:

Grupa A — encje wolnotekstowe (pełna wartość treningu)

Kategorie, które regex nie jest w stanie sensownie wykryć, bo nie mają sztywnego kształtu składniowego — wymagają zrozumienia kontekstu:

Etykieta wewnętrzna	Opis (etykieta użyta w treningu/ewaluacji)
legal_role_person	osoba fizyczna (strona lub uczestnik postępowania) — imię i nazwisko wraz z rolą procesową
institution	instytucja lub sąd (np. "Sąd Rejonowy w Poznaniu")
address	adres (ulica, numer, kod pocztowy, miasto)
case_number	sygnatura sprawy
notarial_act	numer aktu notarialnego
usc_act	numer aktu stanu cywilnego lub poświadczenia dziedziczenia
inheritance_registry	numer wpisu w rejestrze spadkowym

Grupa B — identyfikatory strukturalne (trening pod odporność na szum OCR)

Te kategorie mają w 100% deterministyczny, sztywny kształt (cyfry + suma kontrolna) — na czystym tekście regex+checksum jest bezbłędny i nie potrzebuje modelu. GLiNER ma tu sens wyłącznie jako "druga szansa": gdy dokument pochodzi ze skanu/OCR i cyfry identyfikatora są zaszumione (błędne rozpoznanie znaku), walidacja sumy kontrolnej zawodzi mimo że dana faktycznie jest obecna w dokumencie — model, trenowany właśnie na takich zaszumionych wariantach, może wtedy wskazać fragment do ręcznej weryfikacji, którego regex by przeoczył.

Etykieta wewnętrzna	Opis
pesel	numer PESEL
nip	numer NIP
regon	numer REGON
iban	numer rachunku bankowego IBAN
id_card	numer dowodu osobistego
vehicle_vin	numer VIN pojazdu

13 kolejnych kategorii z pełnej taksonomii systemu docelowego (np. numer telefonu, e-mail, adres IP, numer rejestracyjny pojazdu, data) zostało celowo wyłączonych z treningu GLiNER — mają w pełni deterministyczny kształt składniowy, regex ma na nich 100% precyzji i trening neuronowy nie daje tam żadnej dodatkowej wartości.

Wyniki ewaluacji

Ewaluacja porównawcza na syntetycznym zbiorze testowym (ten sam rozkład kategorii co dane treningowe), w dwóch wariantach tekstu i przy czterech progach decyzyjnych. Wyjaśnienie parametrów, prostym językiem:

• Precision (precyzja) — z wszystkich fragmentów, które model wskazał jako daną osobową, jaki odsetek faktycznie nią był. Niska precyzja = model "krzyczy wilk" za często (dużo fałszywych alarmów trafia do kolejki ręcznej weryfikacji).
• Recall (czułość/kompletność) — z wszystkich rzeczywistych danych osobowych w dokumencie, jaki odsetek model faktycznie wykrył. To jest metryka najważniejsza dla tego zastosowania — niski recall = model przeoczył dane osobowe, które powinny być zamaskowane (realne ryzyko wycieku).
• F1 — jedna liczba łącząca precyzję i recall (średnia harmoniczna) — wysoka tylko wtedy, gdy obie są wysokie.
• Threshold (próg decyzyjny) — liczba od 0 do 1, im niższa, tym model jest "bardziej podejrzliwy" i zgłasza więcej kandydatów (wyższy recall, niższa precyzja). Dla tego zastosowania celowo testowano niskie progi (0.15–0.35), bo priorytetem jest złapanie wszystkiego potencjalnie wrażliwego, nawet za cenę większego szumu w kolejce do ręcznej weryfikacji.
• Tekst "clean" vs "OCR-noised" — "clean" to czysty tekst źródłowy (np. plik z edytora tekstu), "OCR-noised" to ten sam tekst po sztucznym wprowadzeniu błędów typowych dla skanowania/OCR (np. pomylenie znaków O/0, I/1/l, S/5, B/8) — symuluje realny scenariusz skanowanych dokumentów.
• Zero-shot baseline — wynik tego samego modelu bazowego (gliner-x-small) BEZ żadnego dotrenowania, czyli "z pudełka". Porównanie z zero-shot pokazuje, ile realnie dał fine-tuning.

Wyniki mikro-uśrednione (wszystkie kategorie łącznie), próg 0.25

Wariant tekstu	Model	Precision	Recall	F1
Tekst czysty	anonPL-300M (ten model)	0.977	0.993	0.985
Tekst czysty	zero-shot gliner-x-small (bez treningu)	0.308	0.819	0.447
Tekst czysty	zero-shot gliner_multi-v2.1 (bez treningu)	0.457	0.584	0.513
Tekst z szumem OCR	anonPL-300M (ten model)	0.958	0.940	0.949
Tekst z szumem OCR	zero-shot gliner-x-small (bez treningu)	0.282	0.741	0.409
Tekst z szumem OCR	zero-shot gliner_multi-v2.1 (bez treningu)	0.434	0.542	0.482

Fine-tuning znacząco podnosi wszystkie metryki względem modelu bazowego "z pudełka" — recall na czystym tekście rośnie z 0.82 do 0.99, a na tekście zaszumionym OCR z 0.74 do 0.94. Widoczny jest oczekiwany, niewielki spadek skuteczności na tekście zaszumionym OCR względem czystego (recall 0.99 → 0.94) — to jest normalne, bo zaszumione znaki utrudniają rozpoznanie nawet modelowi trenowanemu na takich wariantach. Warto odnotować, że na wariancie OCR-noised anonPL-300M wypada w tej ewaluacji nieco lepiej niż większy anonPL-494M (recall 0.940 vs 0.930) — różnica jest niewielka i w granicach szumu pomiarowego jednego przebiegu ewaluacji, nie należy z niej wyciągać dalekosiężnych wniosków bez powtórzenia testu na większej próbie.

Pełna tabela z rozbiciem na 13 kategorii i 4 progi decyzyjne (0.15/0.25/0.35/0.5): plik comparative_eval.json w repozytorium treningowym.

Wykresy porównawcze recall per kategoria (ten model, anonPL-494M, oraz trzy modele zero-shot bez treningu), osobno dla tekstu czystego i zaszumionego OCR: recall_clean_vs_zeroshot.png, recall_ocr_vs_zeroshot.png.

Krzywa treningu (val F1, próg ewaluacyjny wewnątrz treningu = 0.5)

Epoka	val F1
1	0.9794
2	0.9823
3	0.9841
4	0.9845
5	0.9844
6	0.9844
7	0.9844

Trening zatrzymany przez early stopping po epoce 7 (brak dalszej poprawy val F1 w ramach ustalonej "patience").

Format modelu i eksport ONNX

Model udostępniany jest w formacie ONNX (nie GGUF — format GGUF/llama.cpp jest zaprojektowany pod architektury autoregresywne typu LLM, GLiNER to bidirekcyjny enkoder ze span-classification head i nie ma natywnego, oficjalnego wsparcia GGUF). Dostępne warianty:

• onnx/model.onnx — ONNX fp32, pełna precyzja (656 MB).
• onnx/model_quantized.onnx — ONNX int8 (dynamic quantization), znacząco mniejszy rozmiar plików i szybsza inferencja na CPU (165 MB), przy niewielkim spadku precyzji liczb — w praktyce dla tego zadania różnica w jakości detekcji jest zwykle marginalna. Dla mniejszego modelu bazowego (gliner-x-small) ten wariant jest szczególnie atrakcyjny dla wdrożeń bez GPU.

Sposób użycia (przykładowy kod inferencji ONNX Runtime)

Przykład poniżej zakłada, że eksport ONNX (onnx/model.onnx lub onnx/model_quantized.onnx) oraz pliki tokenizera znajdują się w katalogu modelu. Do uruchomienia potrzebny jest pakiet gliner (obsługuje backend ONNX Runtime natywnie) lub bezpośrednio onnxruntime z własną logiką pre/post-processingu.

from gliner import GLiNER

# Wariant fp32 (pełna precyzja) lub model_quantized.onnx (int8, szybszy)
model = GLiNER.from_pretrained(
    "sciezka/do/anonPL-300M",
    load_onnx_model=True,
    onnx_model_file="onnx/model_quantized.onnx",
)

text = """
Powodem w niniejszej sprawie jest Jan Kowalski, zamieszkały
przy ul. Długiej 15, 61-800 Poznań, PESEL 90010112345.
Sygnatura sprawy: I C 456/26.
"""

labels = [
    "osoba fizyczna (strona lub uczestnik postępowania)",
    "adres",
    "numer PESEL",
    "sygnatura sprawy",
]

# Niski próg decyzyjny (np. 0.2) = maksymalny recall, więcej fałszywych alarmów
# do przekazania dalej do ręcznej weryfikacji — zgodnie z przeznaczeniem modelu.
entities = model.predict_entities(text, labels, threshold=0.2)

for entity in entities:
    print(entity["text"], "=>", entity["label"], f"(score={entity['score']:.2f})")

Każde wskazanie modelu musi przejść przez proces ludzkiej weryfikacji przed usunięciem lub zamaskowaniem danych — patrz sekcja "Ograniczenia i etyka".

Licencja

Ten model jest licencjonowany na zasadach PolyForm Noncommercial License 1.0.0.

To zmiana względem wcześniejszego stanu tego projektu: model bazowy knowledgator/gliner-x-small jest publikowany na licencji Apache 2.0 i pozostaje na niej — ta licencja nie jest zmieniana ani odbierana. Jednak fine-tune (wagi tego modelu), dane treningowe oraz integracja z aplikacją "Anonimizator Pism" są od tej publikacji licencjonowane przez autora na licencji niekomercyjnej, niezależnie od licencji modelu bazowego.

Co to oznacza w praktyce:

• Użycie niekomercyjne — bezpłatne i dozwolone bez dodatkowej zgody: użycie osobiste, badawcze, edukacyjne, testowe, a także użycie przez organizacje nonprofit (non-profit) w ramach ich działalności statutowej. Obejmuje to również dowolne modyfikacje i redystrybucję w tych samych, niekomercyjnych warunkach.
• Użycie komercyjne wymaga osobnej, wyraźnej zgody autora: jakiekolwiek wykorzystanie modelu (samodzielnie lub jako część produktu/usługi) w celu generowania przychodu, w ramach działalności gospodarczej, lub przez podmiot komercyjny (w tym kancelarie prawne świadczące usługi płatne z wykorzystaniem tego modelu poza zakresem osobistego/testowego użycia) wymaga uprzedniego kontaktu z autorem i uzyskania osobnej licencji komercyjnej.
• Pełny, wiążący tekst licencji: https://polyformproject.org/licenses/noncommercial/1.0.0/

Dane treningowe są w 100% syntetyczne (wygenerowane programistycznie + warianty stylistyczne wygenerowane przez LLM), bez wykorzystania rzeczywistych dokumentów klientów jakiejkolwiek kancelarii — nie ma tu więc kwestii licencji/zgody osób trzecich dotyczącej samych danych treningowych.

Ograniczenia i etyka

Model przetwarza wrażliwe dane osobowe (PII), dlatego wszelkie operacje z jego użyciem, zarówno na etapie testowania, jak i inferencji, muszą być przeprowadzane z zachowaniem rygorystycznych standardów bezpieczeństwa oraz w pełnej zgodności z przepisami RODO.

Należy podkreślić, że model nie jest przeznaczony do w pełni zautomatyzowanej i autonomicznej anonimizacji dokumentów. Powinien być traktowany jako warstwa wspomagająca proces wykrywania (zwiększająca recall), której zadaniem jest wskazanie potencjalnie przeoczonych fragmentów tekstu. Każda wskazana przez model encja wymaga bezwzględnej weryfikacji przez wykwalifikowanego człowieka przed podjęciem decyzji o usunięciu lub zamaskowaniu danych.

W kontekście prawnym błąd fałszywie ujemny, czyli niewykrycie danej osobowej przez model, prowadzi do realnego ryzyka wycieku poufnych danych klienta kancelarii, co niesie za sobą poważne konsekwencje prawne i wizerunkowe. Ryzyko to musi być świadomie akceptowane i zarządzane przez użytkownika systemu.

Ponieważ model trenowany był wyłącznie na danych syntetycznych, a nie na rzeczywistych dokumentach klientów, istnieje ryzyko obniżonej skuteczności generalizacji na nietypowe, niestandardowe formaty dokumentów spoza rozkładu treningowego (np. bardzo nieformalny język, nietypowe skróty, dokumenty w innym rejestrze niż pisma sądowe). Model może popełniać błędy, w tym pominięcia istotnych fragmentów lub błędne wskazania (fałszywe alarmy). Jako mniejszy model, anonPL-300M może być nieco bardziej podatny na takie błędy przy skrajnie nietypowych sformułowaniach niż większy wariant anonPL-494M — nie zostało to jednak potwierdzone systematycznym testem poza standardową ewaluacją porównawczą wyżej. Korzystanie z modelu nie zwalnia użytkownika z ostatecznej odpowiedzialności prawnej za poprawność i kompletność procesu anonimizacji.

Zastosowanie w aplikacji

Ten model jest wykorzystywany jako dodatkowa warstwa detekcji w darmowej aplikacji desktopowej "Anonimizator Pism" (Windows + Linux) do anonimizacji polskich dokumentów prawniczych: https://github.com/cenkierpiotr/anonimizator-pism2 — licencjonowanej niekomercyjnie, tak samo jak ten model.

---

🇬🇧 English

A fine-tune of the GLiNER model (base model: knowledgator/gliner-x-small, google/mt5-small backbone, ~300M parameters), further trained on synthetic Polish legal documents to detect personal data and identifiers requiring anonymization.

IMPORTANT WARNING — this is not a standalone anonymization system

This model is intended solely as an additional recall-boosting layer (detecting potentially overlooked fragments), never as a standalone, fully automatic anonymization mechanism.

In the target architecture this model was built for, the authoritative mechanism for detecting and masking personal data is a deterministic regex pipeline + checksum validation (for PESEL, NIP, REGON, IBAN, etc.) combined with a classic NER model. This pipeline is auditable and, on clean text, error-free for identifiers with a rigid structure. anonPL-300M never replaces this mechanism and never flows directly into the final, anonymized document — any detection from the model that does not overlap with an already-confirmed detection must be routed to an "uncertain / potentially overlooked" queue, requiring manual human review before any decision to remove or mask data is made.

Rationale for this architectural decision: a false-negative error (the model fails to detect personal data that should have been masked) in this use case means a real leak of a law firm client's personal data — an unacceptable risk without a human verification layer.

Model description and intended use

This model is a fine-tuned version of the GLiNER architecture, a span-based encoder for named entity recognition (NER) capable of zero-shot operation. It was trained on synthetic Polish legal documents such as court filings, contracts, notarial deeds, and court rulings. The model's main task is to detect personal data and various identifiers in documentation processed by law firms and related institutions.

Unlike traditional NER models, which rely on rigid dictionaries or predefined lists, GLiNER analyzes text for meaning and identifies entities based on label descriptions rather than a fixed list of words. This approach enables effective detection of data even when it appears in unusual phrasings, inflected forms, or grammatical contexts that did not appear explicitly in the training material.

anonPL-300M is the smaller and faster of the two published size variants (the other being anonPL-494M) — with fewer parameters, it offers noticeably faster inference and lower memory usage, at the cost of slightly lower robustness to extremely noisy text. In this specific evaluation, the quality difference between the variants is small (see "Evaluation results" section) — anonPL-300M is usually a reasonable default choice, while anonPL-494M makes sense where maximum robustness to very noisy scans is the priority.

Label taxonomy

The model recognizes 13 entity categories, split into two groups with different rationale:

Group A — free-text entities (full training value)

Categories that regex cannot meaningfully detect, because they have no rigid syntactic shape — they require contextual understanding:

Internal label	Description (label used in training/evaluation)
legal_role_person	natural person (a party or participant in proceedings) — full name together with their procedural role
institution	institution or court (e.g. "District Court in Poznań")
address	address (street, number, postal code, city)
case_number	case reference number
notarial_act	notarial deed number
usc_act	civil registry act number or certificate of succession
inheritance_registry	inheritance registry entry number

Group B — structural identifiers (trained for robustness to OCR noise)

These categories have a 100% deterministic, rigid shape (digits + checksum) — on clean text, regex+checksum is error-free and does not need the model. GLiNER only makes sense here as a "second chance": when a document originates from a scan/OCR and the identifier's digits are noisy (character misrecognition), checksum validation fails even though the data is genuinely present in the document — the model, trained specifically on such noisy variants, can then flag the fragment for manual review that regex would have missed.

Internal label	Description
pesel	Polish national identification number (PESEL)
nip	Polish tax identification number (NIP)
regon	Polish business statistical number (REGON)
iban	IBAN bank account number
id_card	national ID card number
vehicle_vin	vehicle VIN number

13 further categories from the target system's full taxonomy (e.g. phone number, email, IP address, vehicle registration plate, date) were intentionally excluded from GLiNER training — they have a fully deterministic syntactic shape, regex achieves 100% precision on them, and neural training adds no additional value there.

Evaluation results

Comparative evaluation on a synthetic test set (same category distribution as the training data), across two text variants and four decision thresholds. Plain-language explanation of the parameters:

• Precision — of all fragments the model flagged as personal data, what fraction actually was. Low precision = the model "cries wolf" too often (many false alarms end up in the manual review queue).
• Recall (sensitivity/completeness) — of all the real personal data present in the document, what fraction the model actually detected. This is the most important metric for this use case — low recall means the model missed personal data that should have been masked (a real risk of data leakage).
• F1 — a single number combining precision and recall (harmonic mean) — high only when both are high.
• Threshold — a number from 0 to 1; the lower it is, the more "suspicious" the model becomes and the more candidates it flags (higher recall, lower precision). For this use case, low thresholds (0.15–0.35) were deliberately tested, because the priority is catching everything potentially sensitive, even at the cost of more noise in the manual review queue.
• "clean" vs "OCR-noised" text — "clean" is the original source text (e.g. a text-editor file); "OCR-noised" is the same text after artificially injecting errors typical of scanning/OCR (e.g. confusing O/0, I/1/l, S/5, B/8) — simulating a real scenned-document scenario.
• Zero-shot baseline — the result of the same base model (gliner-x-small) WITHOUT any fine-tuning, i.e. "out of the box". Comparison against zero-shot shows how much value the fine-tuning actually added.

Micro-averaged results (all categories combined), threshold 0.25

Text variant	Model	Precision	Recall	F1
Clean text	anonPL-300M (this model)	0.977	0.993	0.985
Clean text	zero-shot gliner-x-small (untrained)	0.308	0.819	0.447
Clean text	zero-shot gliner_multi-v2.1 (untrained)	0.457	0.584	0.513
OCR-noised text	anonPL-300M (this model)	0.958	0.940	0.949
OCR-noised text	zero-shot gliner-x-small (untrained)	0.282	0.741	0.409
OCR-noised text	zero-shot gliner_multi-v2.1 (untrained)	0.434	0.542	0.482

Fine-tuning significantly improves all metrics compared to the base model "out of the box" — recall on clean text rises from 0.82 to 0.99, and on OCR-noised text from 0.74 to 0.94. There is an expected, small drop in performance on OCR-noised text relative to clean text (recall 0.99 → 0.94) — this is normal, since noisy characters make recognition harder even for a model trained on such variants. It is worth noting that on the OCR-noised variant, anonPL-300M performs slightly better in this evaluation than the larger anonPL-494M (recall 0.940 vs 0.930) — the difference is small and within the measurement noise of a single evaluation run, and should not be over-interpreted without repeating the test on a larger sample.

Full breakdown by 13 categories and 4 decision thresholds (0.15/0.25/0.35/0.5): file comparative_eval.json in the training repository.

Comparative recall-per-category charts (this model, anonPL-494M, and three untrained zero-shot models), separately for clean and OCR-noised text: recall_clean_vs_zeroshot.png, recall_ocr_vs_zeroshot.png.

Training curve (validation F1, in-training evaluation threshold = 0.5)

Epoch	val F1
1	0.9794
2	0.9823
3	0.9841
4	0.9845
5	0.9844
6	0.9844
7	0.9844

Training was stopped by early stopping after epoch 7 (no further val F1 improvement within the configured patience).

Model format and ONNX export

The model is distributed in ONNX format (not GGUF — the GGUF/llama.cpp format is designed for autoregressive LLM-style architectures; GLiNER is a bidirectional encoder with a span-classification head and has no native, official GGUF support). Available variants:

• onnx/model.onnx — ONNX fp32, full precision (656 MB).
• onnx/model_quantized.onnx — ONNX int8 (dynamic quantization), significantly smaller file size and faster CPU inference (165 MB), at a small cost in numeric precision — in practice, for this task the difference in detection quality is usually marginal. For the smaller base model (gliner-x-small), this variant is especially attractive for GPU-less deployments.

Usage (example ONNX Runtime inference code)

The example below assumes the ONNX export (onnx/model.onnx or onnx/model_quantized.onnx) and the tokenizer files are located in the model directory. Running it requires the gliner package (which natively supports the ONNX Runtime backend), or onnxruntime directly with your own pre/post-processing logic.

from gliner import GLiNER

# fp32 variant (full precision), or model_quantized.onnx (int8, faster)
model = GLiNER.from_pretrained(
    "path/to/anonPL-300M",
    load_onnx_model=True,
    onnx_model_file="onnx/model_quantized.onnx",
)

text = """
Powodem w niniejszej sprawie jest Jan Kowalski, zamieszkały
przy ul. Długiej 15, 61-800 Poznań, PESEL 90010112345.
Sygnatura sprawy: I C 456/26.
"""

labels = [
    "natural person (a party or participant in proceedings)",
    "address",
    "PESEL number",
    "case reference number",
]

# Low decision threshold (e.g. 0.2) = maximum recall, more false positives
# to be passed on for manual review — consistent with the model's intended use.
entities = model.predict_entities(text, labels, threshold=0.2)

for entity in entities:
    print(entity["text"], "=>", entity["label"], f"(score={entity['score']:.2f})")

Every detection made by the model must go through a human verification process before any data is removed or masked — see the "Limitations and ethics" section.

License

This model is licensed under the PolyForm Noncommercial License 1.0.0.

This is a change from the earlier state of this project: the base model knowledgator/gliner-x-small is published under the Apache 2.0 license, and that license remains unchanged and is not being revoked. However, the fine-tuned weights of this model, the training data, and the integration with the "Anonimizator Pism" application are, as of this publication, licensed by the author under a noncommercial license, independently of the base model's license.

What this means in practice:

• Noncommercial use — free and permitted without additional consent: personal, research, educational, and testing use, as well as use by nonprofit organizations as part of their statutory activities. This also includes any modification and redistribution under the same noncommercial terms.
• Commercial use requires the author's separate, explicit consent: any use of the model (standalone or as part of a product/service) for the purpose of generating revenue, as part of a business activity, or by a commercial entity (including law firms providing paid services using this model beyond personal/testing use) requires prior contact with the author and a separate commercial license.
• Full, binding license text: https://polyformproject.org/licenses/noncommercial/1.0.0/

The training data is 100% synthetic (programmatically generated plus stylistic variants generated by an LLM), without the use of any real client documents from any law firm — so there is no third-party licensing/consent issue regarding the training data itself.

Limitations and ethics

The model processes sensitive personal data (PII), so all operations involving its use — both during testing and inference — must be carried out in compliance with rigorous security standards and full GDPR compliance.

It should be emphasized that the model is not intended for fully automated, autonomous document anonymization. It should be treated as a layer that supports the detection process (increasing recall), whose job is to flag potentially overlooked text fragments. Every entity flagged by the model requires mandatory verification by a qualified human before any decision is made to remove or mask the data.

In a legal context, a false-negative error — i.e. the model failing to detect personal data — leads to a real risk of leaking a law firm client's confidential data, which carries serious legal and reputational consequences. This risk must be knowingly accepted and managed by the user of the system.

Because the model was trained exclusively on synthetic data rather than real client documents, there is a risk of reduced generalization performance on unusual, non-standard document formats outside the training distribution (e.g. very informal language, unusual abbreviations, documents from a different register than court filings). The model may make errors, including missing significant fragments or flagging false positives. As a smaller model, anonPL-300M may be somewhat more prone to such errors on extremely unusual phrasings than the larger anonPL-494M variant — however, this has not been confirmed by systematic testing beyond the standard comparative evaluation above. Use of the model does not relieve the user of ultimate legal responsibility for the correctness and completeness of the anonymization process.

Application use

This model is used as an additional detection layer in a free desktop application called "Anonimizator Pism" (Windows + Linux) for anonymizing Polish legal documents: https://github.com/cenkierpiotr/anonimizator-pism2 — licensed noncommercially, exactly like this model.