Named-entity recognition & information extraction from free text

Much of the operational knowledge in a company sits in prose: an order hidden in an e-mail, a damage description in a claim note, counterparty names and prices in a trader's message, adverse events in a call transcript. Named-entity recognition (NER) and information extraction (IE) turn that prose into fields, IDs and relations that ERP, CRM, BI and knowledge graphs can use. Since 2024 the field has split into two tools that work well together. LLMs with schema-constrained output handle arbitrary schemas from a few examples. Small, zero-shot encoders (the GLiNER family) and fine-tuned BERT-class models run the same task on a CPU at a fraction of the cost and latency.

Problem & value

• Today: staff read text and type the facts into systems by hand. Older solutions use regexes, keyword lists or fixed-label NER models (person, organisation, location) that miss the domain entities companies actually need: product codes, contract numbers, damage types, dosages, legal paragraphs.
• AI value: new entity types without months of annotation, consistent extraction at scale, structured data for analytics and search, and less manual re-keying.
• Measured example: S&P Global Commodity Insights extracts up to 32 attributes (price, participants, location, ...) from about 8,000 trade notes a day. Its fine-tuned spaCy pipelines reach F-scores of 0.95–0.99, are 6 MB each and process about 15,000 words per second. Each market needed about 15 hours of annotation [8].
• Accuracy trade-off: in a clinical NER study, GPT-4 with optimised prompts reached a relaxed F1 of 0.861 on MTSamples. A fine-tuned BioClinicalBERT reached 0.901, but it needed far more labelled data [9]. Prompted LLMs are the fastest way to start. Fine-tuned encoders still tend to win on narrow, high-volume tasks.

Variants

• Generic NER & enrichment: tagging persons, organisations, places and dates in news, archives and intranet content for search facets and knowledge graphs (media, libraries, public archives, with linking to Wikidata or GND).
• Business-event extraction: order, delivery-date, complaint or cancellation details from customer e-mails and tickets. This feeds AGENT-004 (order entry) and LANG-012 (routing).
• Financial & capital-markets text: counterparties, instruments, prices and volumes from trade chats, broker notes, news and ad-hoc disclosures. Sanctions and adverse-media screening reuses the same NER plus fuzzy name matching.
• Insurance & claims: damage type, location, date, parties and amounts from claim notes and loss-adjuster reports.
• Clinical & pharma: diagnoses, medication, dosage and adverse events from clinical notes and pharmacovigilance reports. Mapping these to SNOMED CT or ICD is HLTH-028/HLTH-005, and full medical-record extraction is DOC-007.
• Legal & public sector: parties, file numbers, cited norms and deadlines from court decisions, submissions and citizen requests. Contract clause extraction from documents is DOC-009.
• PII detection as a preprocessing step for pseudonymisation and redaction. The full redaction workflow is DOC-018, and enterprise data discovery is SEC-017.
• Developer/research: relation and event extraction to build knowledge graphs (KNOW-013) and structured datasets from literature.
• Private use: rarely stand-alone. Hobby researchers use it to tag letters or genealogy sources (people, places, dates) with LangExtract or a local LLM.

How it works

1. text intake (mail, ticket, CRM note, transcript, crawled page; PDFs via DOC-014 first)
2. cleaning, language detection, segmentation/chunking (long docs)
3. optional PII guard (decide what may leave the premises)
4. extraction a) zero-shot encoder (GLiNER/GLiNER2): labels given at runtime
5. spans + scores b) fine-tuned encoder (spaCy, Flair, BERT/XLM-R token classifier): fixed labels, max throughput c) LLM with JSON-schema-constrained output + few-shot examples
6. nested records
7. normalisation (dates, amounts, units, spelling variants) + validation rules
8. entity linking / resolution (embeddings + fuzzy match against master data or knowledge base)
9. confidence routing: high
10. write to system; low
11. review UI with highlighted source spans
12. corrections stored as new training/evaluation data

• Source grounding matters. Every extracted value should map back to a character span so that reviewers can verify it and you can detect hallucinated values. Google's LangExtract does this natively: it links each extraction to its exact position in the source and renders an HTML review view [4].
• Cascades are the common production pattern. A cheap encoder handles the bulk, and the LLM is called only for complex nested schemas or low-confidence cases.
• Human-in-the-loop: review of low-confidence fields, approval of new entity types and schema changes, and periodic sampling of auto-accepted records.

Data preparation

Data needed: the free texts to read (e-mails, tickets, notes, reports, chat) and the master data to link to (customers, suppliers, articles, cost centres). In an SMB texts sit in mailboxes, the ticket system, the DMS and file shares, sometimes as scanned PDFs; master data in the ERP or CRM.

Typical gaps: scans without text layer; duplicate and inconsistent master data (spelling variants of customer names); undefined list of entities and fields to extract; no labelled examples; personal data inside texts; unclear access rights to mailboxes.

Preparation steps: 1. Define the target schema: which entities and fields, which are mandatory (PREP-019, PREP-012). 2. OCR scanned documents and convert mail formats (PREP-006, PREP-007). 3. Clean master data and build synonym and abbreviation lists for matching (PREP-015, PREP-011). 4. Collect 50-100 correctly annotated gold-standard examples and use them as test set (PREP-016, PREP-018). 5. Pseudonymise personal data where the use does not need it (PREP-022).

Tools: Paperless-ngx or an OCR service, Excel or OpenRefine for master data, n8n for the pipeline.

Effort share: roughly 40 % of the project; master-data cleaning is often the largest block.

Implementation paths

Which path for whom

• SMB — B: extraction must write into your own ERP, CRM or DMS fields and no off-the-shelf product knows your entities; a cloud-API workflow with human check fits.
• Enterprise — B: entity schemas and master-data linking are core to your processes; API-based extraction keeps flexibility, with C for high volumes or sensitive data.
• Developer — B: structured-output LLM APIs with a schema and validation are the fastest build; fine-tuned small models later if volume grows.
• Public sector — C: records often contain personal data and fall under procurement rules, so open models in a sovereign environment fit best.

Path A — Buy (off-the-shelf)

• Inside existing platforms: many CRM, ticketing, DMS and e-discovery tools now ship "AI fields" or extraction actions (Salesforce, ServiceNow, Microsoft Power Automate AI Builder, Zendesk). These are enough when the schema is simple.
• Text-analytics / NLP platforms: expert.ai (IT, EU), Lettria (FR, EU), Averbis (DE, clinical and patent text), Ontotext/Graphwise (BG, linking to knowledge graphs), and Explosion's Prodigy annotation tool (DE) for teams that want to own their models.
• Choose A when the source system already offers extraction, or the domain (clinical, legal) has a specialist vendor with pre-built ontologies.

Path B — Build on cloud APIs (recommended default)

• LLM extraction with structured outputs: Mistral (EU provider; custom JSON-schema structured outputs) [13], Gemini via Vertex AI EU regions (JSON Schema/Pydantic; some schema constraints are not enforced, so validate in code) [14], Claude and GPT via EU data-residency offerings, and German-hosted open models on STACKIT or IONOS.
• Classic NER APIs: Azure AI Language NER and custom NER (EU regions; prebuilt categories plus trainable custom entities) [5], Amazon Comprehend entities (fixed types such as PERSON, ORGANIZATION, QUANTITY, with offsets and confidence) and custom entity recognisers [6], and Google Cloud Natural Language entity analysis.
• Libraries: LangExtract (Apache-2.0; Gemini, OpenAI-compatible and Ollama backends; chunking and multi-pass recall for long documents) [4], Instructor or Pydantic for schema validation, spacy-llm for LLM-backed NER/REL components inside spaCy pipelines (still experimental) [7].
• Integration: n8n or Power Automate triggers on mailbox or ticket events → extraction service → ERP/CRM write-back.

Path C — Self-host (open source)

• Zero-shot encoders (CPU-friendly): GLiNER (Apache-2.0; arbitrary labels at runtime, claimed to be competitive with much larger LLMs in zero-shot NER) [1][2]. Variants include multilingual PII models covering 100+ languages. GLiNER2 (EMNLP 2025 demo) adds classification, relation and JSON-style structured extraction in one 74M–340M-parameter model and is designed "CPU first" [3]. Knowledgator's GLiNER-X covers 20+ languages, including German and most EU languages [15].
• Supervised NER: spaCy (Explosion, Berlin) and Flair (HU Berlin). For example, flair/ner-german-large scores F1 92.31 on CoNLL-03 German (revised) [10]. Hugging Face token-classification fine-tunes of XLM-R or GBERT are another option.
• Small open LLMs/VLMs for extraction: NuExtract 2.0 (2B/4B/8B, Qwen-VL based, multilingual, text and image input; the 2B and 8B models are MIT-licensed) [11]. General open models such as Qwen3, Mistral Small or Gemma 3 can also serve this, through vLLM or Ollama with JSON-schema guided decoding.
• PII layer: Microsoft Presidio (MIT; regex, checksums and pluggable NER models) [12].
• Annotation & evaluation: Prodigy, Label Studio or Argilla (see DATA-023).
• Hardware: HW1 (CPU server) is enough for GLiNER, spaCy and Flair at thousands of documents per hour. HW2 (one 24–32 GB GPU) is needed for a 7–30B extraction LLM. Ops effort is low to medium.

Path D — Custom training

Worth it when volume is high, latency is tight or labels are very domain-specific. In those cases, fine-tune a GLiNER or BERT-class model, or distil an LLM into one. The usual recipe is to let a frontier LLM pre-annotate a few thousand texts, correct them in Prodigy, Label Studio or Argilla, and train a small encoder. The S&P case needed 1,400–1,700 training examples and about 15 hours of annotation per market [8]. Fine-tuning a small LLM such as NuExtract on your own schema is the middle ground for nested records.

State of the art (2026)

• Two paradigms have converged. "Generalist" encoders take labels or schemas as input, so open-type NER no longer needs an LLM. LLMs with constrained decoding guarantee valid JSON against a schema.
• Grounding plus multi-pass: libraries such as LangExtract combine chunking, parallel passes for recall and span alignment. This addresses the two classic LLM failure modes: missed entities in long text, and values that are not in the source.
• Multilinguality is good for major EU languages. Low-resource languages, dialects, OCR noise and code-switching still degrade quality.
• Limits: LLM extraction is non-deterministic and can normalise too much or invent values. Boundaries of nested and overlapping entities, coreference ("the supplier", "he") and implicit relations remain the hardest parts. Entity linking against messy master data often limits end-to-end quality more than NER itself. Benchmarks such as CoNLL and CrossNER say little about your own schema, so always build an in-house test set.

Shared resources & combinations

• Same encoder stack (text-classifier on HW1): LANG-012 routing, LANG-013 sentiment, LANG-014 moderation and DOC-018 redaction. One GLiNER2 or spaCy service can tag, classify and detect PII in one pass.
• Same LLM endpoint (llm-general/llm-small with structured outputs): AGENT-004 order entry, LANG-033 transaction enrichment, LANG-031 tariff classification, DATA-010 product data enrichment.
• Upstream: DOC-014 (PDF→text), SPEECH transcription for calls, DATA-004 web extraction.
• Downstream: KNOW-013 knowledge graphs/GraphRAG, KNOW-026 entity resolution and link analysis, DATA-003 master data deduplication, DATA-007 catalogue enrichment, LANG-016 trend detection on extracted entities, LANG-017 market intelligence, KNOW-001 faceted search.
• Shared data assets: the entity schema, master-data index (embeddings + fuzzy index) and annotated gold set are reusable across all of the above. HLTH-028 reuses the linking layer for medical terminologies.

Effort, cost & KPIs

• Path A: days. Cost is per-seat or per-record pricing in the host platform.
• Path B: 2–8 weeks for a production pipeline with validation and write-back. Cost is driven by tokens per document and the number of passes. Cascading to an encoder cuts it sharply.
• Path C: 1–3 months including evaluation set, review UI and monitoring. Encoder-only stacks run on existing CPU servers.
• Path D: add 2–6 weeks of annotation and training per domain.
• KPIs: precision/recall/F1 per entity type on a held-out gold set (strict and relaxed span match), field-level accuracy after normalisation, linking accuracy, straight-through rate, review minutes per 100 documents, latency and cost per 1,000 documents.

People & change

Who and when: management names the process to start with; the department lead defines which fields count and validates samples; data owners of ERP and CRM release access and clean master data; IT builds the connection; the DPO checks personal data in texts early. Suppliers or partners are involved if their documents or data are processed.

Works council: depends. Extraction from business documents alone is usually not monitoring; it becomes co-determined under §87(1) no. 6 BetrVG when internal e-mails, chats or tickets are processed and traceable to employees. Inform under §90(1) no. 3 in any case and exclude personal evaluation.

Data protection: AVV with each API provider (Art. 28 GDPR); a DPIA is likely when special categories (health, HR) or systematic evaluation of individuals are involved (GUIDE-005).

AI literacy and communication: support staff literacy under Art. 4 AI Act: how extraction errs, why values must be checked (GUIDE-006). Choose a pilot group of 3-5 clerks in one document type (GUIDE-009).

Typical concerns: "the tool will make mistakes in bookings" - keep a confidence threshold and human approval before anything is written to the ERP; show saved time openly (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: extraction for business processes or search is typically minimal risk. Only the AI-literacy duty (Art. 4) applies. Classification rises to high-risk when the system is part of an Annex III use. Examples: parsing CVs to rank candidates (Annex III point 4), extracting profile information for law-enforcement analysis (point 6), or assessing eligibility for public benefits (point 5). Art. 6(3) can exempt narrow preparatory tasks, but never where the system profiles natural persons. Art. 50 transparency duties do not apply because no content is generated for end users [16].
• GDPR: NER on text about people is processing of personal data and needs a legal basis and purpose limitation. Extracting health data, union membership or similar falls under Art. 9. Building person-centric profiles from free text can trigger a DPIA (Art. 35) [17]. Use data minimisation in the schema (extract only needed fields), EU hosting or self-hosting for sensitive text, and a PII guard before calls to external APIs.
• Sector rules: healthcare (professional secrecy §203 StGB, health-data laws), banking (BaFin outsourcing and DORA ICT third-party rules for cloud APIs), public sector (BSI C5 cloud attestation for providers).
• Risks: hallucinated or mis-linked entities feeding master data, silent quality drift when text sources change, and bias in person-name recognition across languages and cultures. Mitigations include span grounding, validation rules, confidence routing, regular gold-set evaluation and audit logs of model version per record.

Getting started

1. Pick one text stream (e.g. a customer-service inbox) and write the target schema: 5–15 fields with definitions and examples.
2. Annotate 200–300 real texts as a gold set. Use Prodigy, Label Studio or Argilla, with an LLM pre-annotating.
3. Benchmark three options on the gold set: GLiNER2 (CPU), an EU-hosted LLM with structured outputs (or LangExtract), and your platform's built-in extractor. Compare F1, cost and latency.
4. Add normalisation, master-data linking and a review UI with highlighted spans. Route by confidence.
5. Log corrections and retrain or distil into a small encoder once volume justifies it.

Sources

1. GLiNER — generalist NER model (GitHub, Apache-2.0) — https://github.com/urchade/GLiNER
2. Zaratiana et al., "GLiNER: Generalist Model for Named Entity Recognition using Bidirectional Transformer", NAACL 2024 — https://arxiv.org/abs/2311.08526
3. GLiNER2 — schema-driven multi-task IE (GitHub; EMNLP 2025 System Demonstrations) — https://github.com/fastino-ai/GLiNER2 and https://aclanthology.org/2025.emnlp-demos.10/
4. Google LangExtract — LLM-based extraction with source grounding — https://github.com/google/langextract
5. Microsoft Learn — Azure Language named entity recognition overview — https://learn.microsoft.com/en-us/azure/ai-services/language-service/named-entity-recognition/overview
6. AWS — Amazon Comprehend entities — https://docs.aws.amazon.com/comprehend/latest/dg/how-entities.html
7. spaCy — Large language models (spacy-llm) — https://spacy.io/usage/large-language-models
8. Explosion — S&P Global Commodity Insights case study — https://explosion.ai/blog/sp-global-commodities
9. Hu et al., "Improving Large Language Models for Clinical Named Entity Recognition via Prompt Engineering" — https://arxiv.org/abs/2303.16416
10. Flair — ner-german-large model card — https://huggingface.co/flair/ner-german-large
11. NuMind — NuExtract 2.0 model card — https://huggingface.co/numind/NuExtract-2.0-8B
12. Microsoft Presidio — PII detection & de-identification — https://github.com/microsoft/presidio
13. Mistral AI — Structured outputs documentation — https://docs.mistral.ai/capabilities/structured_output/
14. Google — Gemini API structured output — https://ai.google.dev/gemini-api/docs/structured-output
15. Knowledgator — GLiNER-X multilingual model card — https://huggingface.co/knowledgator/gliner-x-large
16. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
17. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj