Erkennung benannter Entitäten (NER) & Informationsextraktion aus Freitext

Ein großer Teil des operativen Wissens im Unternehmen steckt in Prosa: ein Auftrag in einer E-Mail, eine Schadenbeschreibung in einer Schadennotiz, Gegenparteien und Preise in der Nachricht eines Händlers, unerwünschte Ereignisse in einem Gesprächsprotokoll. Die Erkennung benannter Entitäten (Named-Entity Recognition, NER) und die Informationsextraktion (IE) machen aus dieser Prosa Felder, Kennungen und Beziehungen, die ERP, CRM, BI und Wissensgraphen nutzen können. Seit 2024 hat sich das Feld in zwei Werkzeuge aufgeteilt, die gut zusammenarbeiten. LLMs mit schema-beschränkter Ausgabe bewältigen beliebige Schemata anhand weniger Beispiele. Kleine Zero-Shot-Encoder (die GLiNER-Familie) und feingetunte Modelle der BERT-Klasse erledigen dieselbe Aufgabe auf einer CPU zu einem Bruchteil von Kosten und Latenz.

Problem & Nutzen

• Heute: Mitarbeitende lesen Text und tippen die Fakten von Hand in Systeme ein. Ältere Lösungen verwenden reguläre Ausdrücke, Schlagwortlisten oder NER-Modelle mit festen Labels (Person, Organisation, Ort), die die Fachentitäten übersehen, die Unternehmen tatsächlich brauchen: Produktcodes, Vertragsnummern, Schadenarten, Dosierungen, Rechtsparagrafen.
• KI-Nutzen: neue Entitätstypen ohne monatelange Annotation, konsistente Extraktion in großem Maßstab, strukturierte Daten für Analytik und Suche und weniger manuelles Neuerfassen.
• Gemessenes Beispiel: S&P Global Commodity Insights extrahiert bis zu 32 Attribute (Preis, Beteiligte, Ort, ...) aus etwa 8.000 Handelsnotizen pro Tag. Die feingetunten spaCy-Pipelines erreichen F-Werte von 0,95–0,99, sind jeweils 6 MB groß und verarbeiten etwa 15.000 Wörter pro Sekunde. Jeder Markt benötigte etwa 15 Stunden Annotation [8].
• Genauigkeits-Abwägung: In einer Studie zu klinischer NER erreichte GPT-4 mit optimierten Prompts ein gelockertes F1 von 0,861 auf MTSamples. Ein feingetuntes BioClinicalBERT erreichte 0,901, brauchte aber weit mehr gelabelte Daten [9]. LLMs mit Prompt sind der schnellste Einstieg. Feingetunte Encoder gewinnen bei engen, hochvolumigen Aufgaben tendenziell weiterhin.

Varianten

• Allgemeine NER & Anreicherung: Auszeichnen von Personen, Organisationen, Orten und Daten in Nachrichten, Archiven und Intranet-Inhalten für Suchfacetten und Wissensgraphen (Medien, Bibliotheken, öffentliche Archive, mit Verknüpfung zu Wikidata oder GND).
• Extraktion von Geschäftsereignissen: Details zu Bestellung, Liefertermin, Beschwerde oder Kündigung aus Kunden-E-Mails und Tickets. Das speist AGENT-004 (Auftragserfassung) und LANG-012 (Routing).
• Finanz- & Kapitalmarkttexte: Gegenparteien, Instrumente, Preise und Volumina aus Handels-Chats, Maklernotizen, Nachrichten und Ad-hoc-Mitteilungen. Sanktions- und Negativmedien-Screening nutzt dieselbe NER plus unscharfen Namensabgleich.
• Versicherung & Schadenbearbeitung: Schadenart, Ort, Datum, Beteiligte und Beträge aus Schadennotizen und Gutachterberichten.
• Klinik & Pharma: Diagnosen, Medikation, Dosierung und unerwünschte Ereignisse aus klinischen Notizen und Pharmakovigilanz-Berichten. Die Zuordnung zu SNOMED CT oder ICD ist HLTH-028/HLTH-005, und die vollständige Extraktion aus Krankenakten ist DOC-007.
• Recht & öffentlicher Sektor: Parteien, Aktenzeichen, zitierte Normen und Fristen aus Gerichtsentscheidungen, Schriftsätzen und Bürgeranliegen. Die Extraktion von Vertragsklauseln aus Dokumenten ist DOC-009.
• PII-Erkennung als Vorverarbeitungsschritt für Pseudonymisierung und Schwärzung. Der vollständige Schwärzungs-Workflow ist DOC-018, die unternehmensweite Datenerkennung ist SEC-017.
• Entwickler/Forschung: Extraktion von Beziehungen und Ereignissen, um Wissensgraphen (KNOW-013) und strukturierte Datensätze aus Literatur aufzubauen.
• Privatnutzung: selten eigenständig. Hobbyforscher nutzen es, um Briefe oder genealogische Quellen (Personen, Orte, Daten) mit LangExtract oder einem lokalen LLM auszuzeichnen.

So funktioniert es

1. Texteingang (Mail, Ticket, CRM-Notiz, Transkript, gecrawlte Seite; PDFs zuerst über DOC-014)
2. Bereinigung, Spracherkennung, Segmentierung/Chunking (lange Dokumente)
3. optionaler PII-Schutz (entscheiden, was das Haus verlassen darf)
4. Extraktion a) Zero-Shot-Encoder (GLiNER/GLiNER2): Labels zur Laufzeit vorgegeben
5. Spans + Scores b) feinjustierter Encoder (spaCy, Flair, BERT/XLM-R Token-Klassifikator): feste Labels, maximaler Durchsatz c) LLM mit JSON-Schema-beschränkter Ausgabe + Few-Shot-Beispielen
6. verschachtelte Datensätze
7. Normalisierung (Daten, Beträge, Einheiten, Schreibvarianten) + Validierungsregeln
8. Entitätsverknüpfung / -auflösung (Embeddings + Fuzzy-Abgleich mit Stammdaten oder Wissensbasis)
9. Konfidenz-Routing: hoch
10. ins System schreiben; niedrig
11. Prüfoberfläche mit hervorgehobenen Quell-Spans
12. Korrekturen als neue Trainings-/Evaluationsdaten gespeichert

• Quellenbezug (Grounding) ist entscheidend. Jeder extrahierte Wert sollte auf einen Zeichenbereich zurückführbar sein, damit Prüfer ihn verifizieren und halluzinierte Werte erkennen können. Googles LangExtract tut dies nativ: Es verknüpft jede Extraktion mit ihrer exakten Position im Quelltext und erzeugt eine HTML-Prüfansicht [4].
• Kaskaden sind das übliche Produktionsmuster. Ein günstiger Encoder bewältigt die Masse, und das LLM wird nur für komplexe verschachtelte Schemata oder Fälle mit geringer Konfidenz aufgerufen.
• Mensch-in-der-Schleife (Human-in-the-Loop): Prüfung von Feldern mit geringer Konfidenz, Freigabe neuer Entitätstypen und Schemaänderungen sowie regelmäßige Stichproben automatisch akzeptierter Datensätze.

Datenaufbereitung

Benötigte Daten: die zu lesenden Freitexte (E-Mails, Tickets, Notizen, Berichte, Chat) und die Stammdaten, mit denen verknüpft wird (Kunden, Lieferanten, Artikel, Kostenstellen). Im KMU liegen Texte in Postfächern, im Ticketsystem, im DMS und auf Dateiablagen, teils als gescannte PDFs; Stammdaten im ERP oder CRM.

Typische Lücken: Scans ohne Textebene; doppelte und uneinheitliche Stammdaten (Schreibvarianten von Kundennamen); nicht definierte Liste der zu extrahierenden Entitäten und Felder; keine gelabelten Beispiele; personenbezogene Daten in Texten; unklare Zugriffsrechte auf Postfächer.

Aufbereitungsschritte: 1. Das Zielschema festlegen: welche Entitäten und Felder, welche davon Pflicht sind (PREP-019, PREP-012). 2. Gescannte Dokumente per OCR erfassen und Mailformate konvertieren (PREP-006, PREP-007). 3. Stammdaten bereinigen und Synonym- und Abkürzungslisten für den Abgleich aufbauen (PREP-015, PREP-011). 4. 50-100 korrekt annotierte Referenzbeispiele (Gold Standard) sammeln und als Testmenge verwenden (PREP-016, PREP-018). 5. Personenbezogene Daten pseudonymisieren, wo der Zweck sie nicht braucht (PREP-022).

Werkzeuge: Paperless-ngx oder ein OCR-Dienst, Excel oder OpenRefine für Stammdaten, n8n für die Pipeline.

Aufwandsanteil: etwa 40 % des Projekts; die Stammdatenbereinigung ist oft der größte Block.

Umsetzungswege

Welcher Weg für wen

• KMU — B: Die Extraktion muss in Ihre eigenen ERP-, CRM- oder DMS-Felder schreiben, und kein Standardprodukt kennt Ihre Entitäten; ein Cloud-API-Workflow mit menschlicher Prüfung passt.
• Enterprise — B: Entitätsschemata und Stammdatenverknüpfung sind für Ihre Prozesse zentral; API-basierte Extraktion bewahrt die Flexibilität, mit C für hohe Volumina oder sensible Daten.
• Entwickler — B: LLM-APIs mit strukturierter Ausgabe, Schema und Validierung sind der schnellste Aufbau; später feingetunte kleine Modelle, wenn das Volumen wächst.
• Öffentlicher Sektor — C: Akten enthalten oft personenbezogene Daten und unterliegen Vergaberegeln, daher passen offene Modelle in einer souveränen Umgebung am besten.

Weg A — Kaufen (Standardsoftware)

• In bestehenden Plattformen: Viele CRM-, Ticketing-, DMS- und E-Discovery-Werkzeuge liefern inzwischen „KI-Felder" oder Extraktionsaktionen mit (Salesforce, ServiceNow, Microsoft Power Automate AI Builder, Zendesk). Sie genügen, wenn das Schema einfach ist.
• Textanalytik-/NLP-Plattformen: expert.ai (IT, EU), Lettria (FR, EU), Averbis (DE, klinische Texte und Patente), Ontotext/Graphwise (BG, Verknüpfung mit Wissensgraphen) und das Annotationswerkzeug Prodigy von Explosion (DE) für Teams, die ihre Modelle selbst besitzen wollen.
• A wählen, wenn das Quellsystem bereits Extraktion anbietet oder die Domäne (Klinik, Recht) einen spezialisierten Anbieter mit vorgefertigten Ontologien hat.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlener Standard)

• LLM-Extraktion mit strukturierter Ausgabe: Mistral (EU-Anbieter; eigene strukturierte JSON-Schema-Ausgaben) [13], Gemini über Vertex-AI-EU-Regionen (JSON Schema/Pydantic; einige Schemabeschränkungen werden nicht durchgesetzt, daher im Code validieren) [14], Claude und GPT über Angebote mit EU-Datenresidenz sowie in Deutschland gehostete offene Modelle bei STACKIT oder IONOS.
• Klassische NER-APIs: Azure AI Language NER und Custom NER (EU-Regionen; vordefinierte Kategorien plus trainierbare eigene Entitäten) [5], Amazon Comprehend Entities (feste Typen wie PERSON, ORGANIZATION, QUANTITY, mit Offsets und Konfidenz) und eigene Entitätserkenner [6] sowie die Entity-Analyse von Google Cloud Natural Language.
• Bibliotheken: LangExtract (Apache-2.0; Backends für Gemini, OpenAI-kompatible Dienste und Ollama; Chunking und Mehrfachdurchläufe für höheren Recall bei langen Dokumenten) [4], Instructor oder Pydantic für die Schemavalidierung, spacy-llm für LLM-gestützte NER/REL-Komponenten in spaCy-Pipelines (noch experimentell) [7].
• Integration: n8n- oder Power-Automate-Auslöser bei Postfach- oder Ticket-Ereignissen → Extraktionsdienst → Rückschreiben in ERP/CRM.

Weg C — Selbst betreiben (Open Source)

• Zero-Shot-Encoder (CPU-tauglich): GLiNER (Apache-2.0; beliebige Labels zur Laufzeit, nach eigenen Angaben konkurrenzfähig zu deutlich größeren LLMs bei Zero-Shot-NER) [1][2]. Varianten umfassen mehrsprachige PII-Modelle für über 100 Sprachen. GLiNER2 (EMNLP-2025-Demo) ergänzt Klassifikation, Beziehungs- und JSON-artige strukturierte Extraktion in einem Modell mit 74M–340M Parametern und ist „CPU first" ausgelegt [3]. GLiNER-X von Knowledgator deckt über 20 Sprachen ab, darunter Deutsch und die meisten EU-Sprachen [15].
• Überwachte NER: spaCy (Explosion, Berlin) und Flair (HU Berlin). Zum Beispiel erreicht flair/ner-german-large F1 92,31 auf CoNLL-03 Deutsch (revidiert) [10]. Feintunes von XLM-R oder GBERT für Token-Klassifikation bei Hugging Face sind eine weitere Option.
• Kleine offene LLMs/VLMs für die Extraktion: NuExtract 2.0 (2B/4B/8B, auf Qwen-VL basierend, mehrsprachig, Text- und Bildeingabe; die Modelle 2B und 8B stehen unter MIT-Lizenz) [11]. Auch allgemeine offene Modelle wie Qwen3, Mistral Small oder Gemma 3 können dies leisten, über vLLM oder Ollama mit JSON-Schema-geführtem Decoding.
• PII-Schicht: Microsoft Presidio (MIT; reguläre Ausdrücke, Prüfsummen und austauschbare NER-Modelle) [12].
• Annotation & Bewertung: Prodigy, Label Studio oder Argilla (siehe DATA-023).
• Hardware: HW1 (CPU-Server) genügt für GLiNER, spaCy und Flair bei Tausenden Dokumenten pro Stunde. HW2 (eine GPU mit 24–32 GB) wird für ein Extraktions-LLM mit 7–30 Mrd. Parametern benötigt. Der Betriebsaufwand ist gering bis mittel.

Weg D — Eigenes Training

Lohnt sich bei hohem Volumen, knapper Latenz oder sehr domänenspezifischen Labels. In diesen Fällen ein GLiNER- oder BERT-Modell feintunen oder ein LLM in ein solches destillieren. Das übliche Vorgehen: ein Spitzen-LLM annotiert einige Tausend Texte vor, Sie korrigieren sie in Prodigy, Label Studio oder Argilla und trainieren einen kleinen Encoder. Der S&P-Fall benötigte 1.400–1.700 Trainingsbeispiele und etwa 15 Stunden Annotation pro Markt [8]. Das Feintuning eines kleinen LLM wie NuExtract auf Ihrem eigenen Schema ist der Mittelweg für verschachtelte Datensätze.

Stand der Technik (2026)

• Zwei Paradigmen sind zusammengewachsen. „Generalisten"-Encoder nehmen Labels oder Schemata als Eingabe, sodass offene NER keinen LLM mehr braucht. LLMs mit eingeschränktem Decoding garantieren gültiges JSON gegenüber einem Schema.
• Grounding plus Mehrfachdurchläufe: Bibliotheken wie LangExtract kombinieren Chunking, parallele Durchläufe für den Recall und die Ausrichtung auf Quellbereiche. Das adressiert die beiden klassischen LLM-Fehlerbilder: übersehene Entitäten in langem Text und Werte, die nicht in der Quelle stehen.
• Mehrsprachigkeit ist für die großen EU-Sprachen gut. Ressourcenarme Sprachen, Dialekte, OCR-Rauschen und Sprachwechsel innerhalb eines Textes verschlechtern die Qualität weiterhin.
• Grenzen: LLM-Extraktion ist nicht deterministisch und kann zu stark normalisieren oder Werte erfinden. Grenzen verschachtelter und überlappender Entitäten, Koreferenz („der Lieferant", „er") und implizite Beziehungen bleiben die schwierigsten Teile. Die Entitätsverknüpfung mit unsauberen Stammdaten begrenzt die Gesamtqualität oft stärker als die NER selbst. Benchmarks wie CoNLL und CrossNER sagen wenig über Ihr eigenes Schema aus; bauen Sie daher stets eine hausinterne Testmenge auf.

Gemeinsame Bausteine & Kombinationen

• Gleicher Encoder-Stack (text-classifier auf HW1): LANG-012 Routing, LANG-013 Stimmungsanalyse, LANG-014 Moderation und DOC-018 Schwärzung. Ein GLiNER2- oder spaCy-Dienst kann in einem Durchgang auszeichnen, klassifizieren und PII erkennen.
• Gleicher LLM-Endpunkt (llm-general/llm-small mit strukturierter Ausgabe): AGENT-004 Auftragserfassung, LANG-033 Transaktionsanreicherung, LANG-031 Tarifklassifikation, DATA-010 Anreicherung von Produktdaten.
• Vorgelagert: DOC-014 (PDF→Text), SPEECH-Transkription für Gespräche, DATA-004 Webextraktion.
• Nachgelagert: KNOW-013 Wissensgraphen/GraphRAG, KNOW-026 Entitätsauflösung und Verknüpfungsanalyse, DATA-003 Deduplizierung von Stammdaten, DATA-007 Kataloganreicherung, LANG-016 Trenderkennung auf extrahierten Entitäten, LANG-017 Marktbeobachtung, KNOW-001 Facettensuche.
• Gemeinsame Datenbestände: das Entitätsschema, der Stammdaten-Index (Embeddings + Fuzzy-Index) und die annotierte Referenzmenge sind für alle genannten Fälle wiederverwendbar. HLTH-028 nutzt die Verknüpfungsschicht für medizinische Terminologien erneut.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage. Die Kosten fallen pro Lizenz oder pro Datensatz in der Host-Plattform an.
• Weg B: 2–8 Wochen für eine Produktiv-Pipeline mit Validierung und Rückschreiben. Die Kosten richten sich nach Tokens pro Dokument und der Anzahl der Durchläufe. Eine Kaskade zu einem Encoder senkt sie deutlich.
• Weg C: 1–3 Monate inklusive Bewertungsmenge, Prüfoberfläche und Monitoring. Reine Encoder-Stacks laufen auf vorhandenen CPU-Servern.
• Weg D: 2–6 Wochen Annotation und Training pro Domäne zusätzlich.
• Kennzahlen: Precision/Recall/F1 je Entitätstyp an einer zurückgehaltenen Referenzmenge (strikter und gelockerter Span-Abgleich), Genauigkeit auf Feldebene nach der Normalisierung, Genauigkeit der Verknüpfung, Durchlaufquote ohne Eingriff (Straight-Through-Rate), Prüfminuten pro 100 Dokumente, Latenz und Kosten pro 1.000 Dokumente.

Menschen & Veränderung

Wer und wann: Die Geschäftsführung benennt den Prozess, mit dem begonnen wird; die Fachabteilungsleitung legt fest, welche Felder zählen, und validiert Stichproben; die Datenverantwortlichen von ERP und CRM geben Zugriff frei und bereinigen Stammdaten; die IT baut die Anbindung; die/der Datenschutzbeauftragte prüft früh die personenbezogenen Daten in Texten. Lieferanten oder Partner werden einbezogen, wenn ihre Dokumente oder Daten verarbeitet werden.

Betriebsrat: abhängig vom Einzelfall. Extraktion aus Geschäftsdokumenten allein ist meist keine Überwachung; sie wird nach §87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig, wenn interne E-Mails, Chats oder Tickets verarbeitet werden und sich Beschäftigten zuordnen lassen. Informieren Sie in jedem Fall nach §90 Abs. 1 Nr. 3 und schließen Sie eine personenbezogene Bewertung aus.

Datenschutz: AVV mit jedem API-Anbieter (Art. 28 DSGVO); eine DSFA ist wahrscheinlich, wenn besondere Kategorien (Gesundheit, Personal) oder eine systematische Bewertung von Personen betroffen sind (GUIDE-005).

KI-Kompetenz und Kommunikation: KI-Kompetenz der Beschäftigten nach Art. 4 KI-Verordnung (AI Act) fördern: wie Extraktion irrt und warum Werte geprüft werden müssen (GUIDE-006). Eine Pilotgruppe von 3-5 Sachbearbeitenden bei einem Dokumenttyp wählen (GUIDE-009).

Typische Bedenken: „Das Werkzeug macht Fehler bei Buchungen" – eine Konfidenzschwelle und menschliche Freigabe vorsehen, bevor etwas ins ERP geschrieben wird; die eingesparte Zeit offen zeigen (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Extraktion für Geschäftsprozesse oder Suche hat typischerweise minimales Risiko. Es gilt nur die Pflicht zur KI-Kompetenz (Art. 4). Die Einstufung steigt auf Hochrisiko, wenn das System Teil eines Anhang-III-Einsatzes ist. Beispiele: Auswertung von Lebensläufen zur Rangfolge von Bewerbern (Anhang III Nr. 4), Extraktion von Profilinformationen für Analysen der Strafverfolgung (Nr. 6) oder Beurteilung der Anspruchsberechtigung für öffentliche Leistungen (Nr. 5). Art. 6 Abs. 3 kann eng begrenzte vorbereitende Aufgaben ausnehmen, jedoch nie, wo das System natürliche Personen profiliert. Die Transparenzpflichten nach Art. 50 gelten nicht, weil keine Inhalte für Endnutzer erzeugt werden [16].
• DSGVO: NER auf Texten über Personen ist Verarbeitung personenbezogener Daten und braucht eine Rechtsgrundlage und Zweckbindung. Die Extraktion von Gesundheitsdaten, Gewerkschaftszugehörigkeit oder Ähnlichem fällt unter Art. 9. Der Aufbau personenzentrierter Profile aus Freitext kann eine DSFA auslösen (Art. 35) [17]. Nutzen Sie Datenminimierung im Schema (nur benötigte Felder extrahieren), EU-Hosting oder Selbstbetrieb für sensible Texte und einen PII-Schutz vor Aufrufen externer APIs.
• Branchenregeln: Gesundheitswesen (Schweigepflicht §203 StGB, Gesundheitsdatengesetze), Banken (BaFin-Auslagerung und DORA-Regeln für IKT-Drittanbieter bei Cloud-APIs), öffentlicher Sektor (BSI-C5-Cloud-Testat für Anbieter).
• Risiken: halluzinierte oder falsch verknüpfte Entitäten, die in Stammdaten gelangen, schleichender Qualitätsverlust bei sich ändernden Textquellen und Verzerrung bei der Erkennung von Personennamen über Sprachen und Kulturen hinweg. Gegenmaßnahmen: Quellenbezug auf Span-Ebene, Validierungsregeln, Routing nach Konfidenz, regelmäßige Bewertung an der Referenzmenge und Audit-Logs der Modellversion je Datensatz.

Erste Schritte

1. Einen Textstrom wählen (z. B. ein Kundenservice-Postfach) und das Zielschema schreiben: 5–15 Felder mit Definitionen und Beispielen.
2. 200–300 reale Texte als Referenzmenge annotieren. Prodigy, Label Studio oder Argilla nutzen, mit einem LLM als Vorannotation.
3. Drei Optionen an der Referenzmenge vergleichen: GLiNER2 (CPU), ein in der EU gehostetes LLM mit strukturierter Ausgabe (oder LangExtract) und den eingebauten Extraktor Ihrer Plattform. F1, Kosten und Latenz vergleichen.
4. Normalisierung, Stammdatenverknüpfung und eine Prüfoberfläche mit hervorgehobenen Spans ergänzen. Nach Konfidenz routen.
5. Korrekturen protokollieren und in einen kleinen Encoder nachtrainieren oder destillieren, sobald das Volumen es rechtfertigt.

Quellen

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