Etiketten aus vorhandenen Geschäftsdaten gewinnen

Jedes KMU besitzt bereits tausende etikettierte Beispiele: die Kategorie, die ein Servicemitarbeiter gewählt hat, das Sachkonto, das die Buchhaltung zugeordnet hat, die Fehlerursache, die das Qualitätsteam erfasst hat, ob ein Angebot gewonnen wurde. Statt Menschen für das Annotieren von Daten zu bezahlen, exportieren Sie diese früheren Entscheidungen, prüfen, wie vertrauenswürdig sie sind, und nutzen sie, um KI zu trainieren, zu testen oder zu konfigurieren. Typischer Nutzen: ein brauchbarer Bewertungsdatensatz in Tagen statt Wochen manueller Annotation.

Problem & Nutzen

• Heute: KI-Projekte bleiben bei der Frage stecken: „Woher wissen wir, dass es funktioniert?“ Teams nehmen an, sie müssten bei null annotieren. Dabei liegt die Antwort im ERP, CRM, Ticketsystem oder in der DATEV-Buchungshistorie.
• KI-Nutzen: frühere Entscheidungen werden (a) zu einem Bewertungsdatensatz, um Werkzeuge und Prompts zu vergleichen, (b) zu Few-Shot-Beispielen für ein LLM, (c) zu Trainingsdaten für einen kleinen Klassifikator oder ein tabellarisches Modell (z. B. Gewinnwahrscheinlichkeit).
• Einschränkung: Ein erfasstes Ergebnis ist nicht automatisch die Wahrheit. Mitarbeitende wählen die erste passende Kategorie, Ticketkategorien ändern sich im Lauf der Zeit, und „verlorene“ Angebote tragen oft keinen echten Grund. Die Prüfung der Verlässlichkeit ist der Kern dieses Anwendungsfalls. Eine belegte Kennzahl zu typischen Rauschraten in KMU-Geschäftsdaten wird hier nicht genannt; messen Sie sie an Ihren eigenen Daten.

Varianten

• Service-Desk: Kategorie, Priorität, Team und Lösung geschlossener Tickets als Etiketten für die Triage (zum Kategorieschema siehe PREP-019).
• Finanzen: endgültiges Buchungskonto und Kostenstelle je Lieferant/Rechnungszeile als Etiketten für Buchungsvorschläge (DOC-001).
• Vertrieb: gewonnen/verloren je Angebot plus Produktmix, Rabatt und Kundensegment für Modelle zur Gewinnwahrscheinlichkeit.
• Qualität/Produktion: Fehlerursachencodes aus Reklamations- oder 8D-Berichten.
• Enterprise: Auszüge aus dem Data Warehouse in großem Umfang; Entwickler: wiederverwendbare Extraktions-Pipelines je Quellsystem.

So funktioniert es

source system (ERP/CRM/ticketing/DATEV export)
  -> extract (API, CSV, n8n/Power Automate)
  -> join record + outcome, keep timestamps and who-decided
  -> reliability checks (class balance, drift over time, rule conflicts, model-based label-issue detection)
  -> human review of a sample / flagged conflicts  [human-in-the-loop]
  -> frozen labelled set: train / validation / evaluation split by time

Wichtige Bausteine: - Zeitbasierte Aufteilung: Bewerten Sie an den jüngsten Monaten, nie an einer zufälligen Mischung, um Datenlecks zu vermeiden und Drift zu erkennen. - Schwache Überwachung (Weak Supervision): Mehrere unvollkommene Quellen (Kategoriefeld, Schlüsselwörter im Lösungstext, spätere Neuzuordnung) lassen sich als „Labeling Functions“ kombinieren, deren Rauschen modelliert wird; die Open-Source-Software Snorkel hat diese Idee bekannt gemacht [1]. Behandeln Sie das Ergebnis als wahrscheinlichkeitsbasiert, nicht als Wahrheit. - Erkennung fehlerhafter Etiketten: Trainieren Sie ein einfaches Modell mit Kreuzvalidierung und lassen Sie die Open-Source-Bibliothek cleanlab Beispiele einstufen, deren erfasstes Etikett wahrscheinlich falsch ist, zur Prüfung durch Menschen [2]. - LLM als zweite Meinung: Ein kleines lokales oder in der EU gehostetes LLM etikettiert eine Stichprobe neu; Abweichungen vom erfassten Etikett gehen an einen Menschen.

Datenaufbereitung

• Wo sie liegen: Ticketwerkzeuge (Jira Service Management, Zendesk, Freshdesk), ERP (Business Central, SAP Business One, Odoo), CRM (HubSpot, Salesforce, Dynamics), DATEV-Buchungsexporte, Excel-Qualitätsprotokolle.
• Typische Lücken: Freitext-Kategorien „Sonstiges“, über die Jahre umbenannte oder zusammengelegte Kategorien, nie geänderte Voreinstellungen, Ergebnisse, die erst Wochen später eingetragen werden, Dubletten, personenbezogene Daten im Freitext.
• Schritte und Aufwand (ein Anwendungsfall, eine Quelle): Zieletikett festlegen und unbrauchbare Zeiträume ausschließen (0,5 Tag); exportieren und zusammenführen (1-2 Tage, mehr ohne API: siehe PREP-005); Klassenverteilung und Drift in Excel oder einem Notebook profilieren (1 Tag); 100-300 markierte oder gezogene Datensätze gemeinsam mit der Prozessverantwortlichen bzw. dem Prozessverantwortlichen prüfen (1-2 Tage); Datensatz einfrieren und dokumentieren (0,5 Tag). Realistische Summe: 4-6 Arbeitstage.
• Verwandt: PREP-011 für saubere Tabellen, PREP-018 für von Fachleuten erstellte Testdatensätze, PREP-022 für Pseudonymisierung vor dem Export. Siehe auch GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: C. Die Daten beziehen sich auf Kunden und Beschäftigte; die Arbeit ist klein genug für einen Laptop oder CPU-Server mit Python, cleanlab und n8n, und dieselbe Pipeline bedient viele Anwendungsfälle (Baukasten-Effekt).
• Enterprise: B. Größere Mengen und zentrale Datenplattformen; Cloud-ML-Dienste und LLM-APIs in EU-Regionen passen zur bestehenden Governance.
• Entwickler: C. Open-Source-Aufbau, versionierte Datensätze, reproduzierbare Pipelines.

Weg A — Kaufen (Standardsoftware)

Etiketten sind meist ein Nebenprodukt von Werkzeugen: Ticketsysteme mit eingebauter KI-Kategorisierung lernen aus Ihrer Historie (Zendesk, Freshdesk, Jira Service Management); HubSpot und Dynamics bieten Lead-/Deal-Scoring auf Basis der Gewonnen/Verloren-Historie. Plattformen zur Datenetikettierung (Label Studio Enterprise, Snorkel Flow) gibt es, sie werden im KMU-Maßstab aber selten benötigt. Sinnvoll, wenn der Anbieter bereits auf Ihrer Historie trainiert und eine EU-Datenregion sowie einen AVV bietet.

Weg B — Auf Cloud-KI-Diensten aufbauen

Nutzen Sie eine LLM-API in einer EU-Region (Mistral, Azure OpenAI EU Data Boundary, souveräne Angebote im Stil von Aleph Alpha) als zweiten Etikettierer für pseudonymisierte Stichproben; orchestrieren Sie mit n8n (in der EU hostbar) oder Power Automate; schreiben Sie die Ergebnisse zur Prüfung in eine Tabelle zurück.

Weg C — Selbst betreiben (Open Source)

Python (pandas, scikit-learn, cleanlab), optional Snorkel, Label Studio Community für den Prüfschritt, Ollama mit einem kleinen Modell für Etiketten als zweite Meinung. Läuft auf HW1; HW2 nur, wenn Sie große Textmengen mit einem 14-30B-Modell neu etikettieren. Betriebsaufwand: wenige Stunden pro Monat, sobald die Pipelines stehen. Ein selbst betriebenes n8n auf Nextcloud oder eigenem Server hält die Daten in der EU.

Weg D — Eigenes Training

Erst wenn der gewonnene Datensatz verlässlich ist: einen Encoder-Klassifikator feintunen, wenn je Klasse mehrere tausend konsistente Etiketten vorliegen. Meist unnötig; beginnen Sie mit Few-Shot-LLM oder einem Gradient-Boosting-Modell.

Stand der Technik (2026)

• Kleine tabellarische/Text-Klassifikatoren, die auf sauberen historischen Etiketten trainiert wurden, erreichen oder übertreffen bei eng gefassten internen Kategorien weiterhin Zero-Shot-LLMs, bei weit geringeren Kosten je Vorgang; LLMs sind stark, wenn es wenige Etiketten gibt.
• Werkzeuge für Confident Learning wie cleanlab sind etabliert, um Etikettenprobleme zu markieren [2]; schwache Überwachung kombiniert verrauschte Quellen [1].
• Grenzen und Fehlerbilder: Historische Etiketten enthalten vergangene Fehler und vergangene Verzerrungen (z. B. wer Rabatte bekam); Konzeptdrift nach Prozessänderungen; Überlebensverzerrung (nur geschlossene/gewonnene Datensätze werden ausführlich erfasst); ein Modell, das auf programmatischen Etiketten trainiert wurde, kann deren Annahmen als Wahrheit lernen [1].

Gemeinsame Bausteine & Kombinationen

• Teilt Extraktion (PREP-005), saubere Tabellen (PREP-011), Bewertungsdatensätze (PREP-018), Kategorieschemata (PREP-019) und Rückmeldungserfassung (PREP-021).
• Speist Rechnungskontierung (DOC-001), Ticket-Triage und Vertriebs-Scoring. Dieselbe n8n-Instanz und dieselbe Python-Umgebung bedienen alle.
• Nicht Teil dieses Anwendungsfalls: Werkzeuge zur manuellen Annotation (DATA-023) und synthetische Daten (DATA-005).

Aufwand, Kosten & Kennzahlen

• Weg A: Stunden an Konfiguration; Lizenzkosten der Ticket-/CRM-Stufe. Weg B: 4-8 Tage plus geringe API-Gebühren. Weg C: 4-8 Tage, keine Lizenzkosten, vorhandene Hardware. Kostentreiber: Datenzugang (keine API), Prüfzeit der Prozessverantwortlichen.
• Kennzahlen: Anteil der Datensätze mit brauchbarem Etikett; geschätztes Etikettenrauschen in der geprüften Stichprobe; Übereinstimmung zwischen erfasstem Etikett und LLM-Zweitmeinung; Zeit bis zum Bewertungsdatensatz; später: Genauigkeit des nachgelagerten Werkzeugs am eingefrorenen Bewertungsdatensatz.

Menschen & Veränderung

• Einbeziehen: Abteilungsleitung und Endanwender früh; sie wissen, warum Kategorien gewählt wurden, und müssen die markierten Datensätze prüfen. Dateneigner geben Exporte frei; die IT baut die Pipeline; die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte prüft Zweck und Rechtsgrundlage (GUIDE-005).
• Betriebsrat: Gewonnene Etiketten enthalten oft, wer was entschieden hat. Könnten der Datensatz oder die daraus entstehenden Modelle die Leistung einzelner Mitarbeitender bewerten (z. B. „Mitarbeiter X etikettiert falsch“), ist eine Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG wahrscheinlich, und § 90 Abs. 1 Nr. 3 verlangt eine rechtzeitige Unterrichtung, wenn Arbeitsabläufe mit KI geplant werden. Nutzen Sie aggregierte, pseudonyme Auswertungen und vereinbaren Sie das vorab (GUIDE-004). Öffentlicher Dienst: Personalrat nach BPersVG/Landesrecht.
• Kommunikation: Sagen Sie klar, dass das Ziel die Verbesserung des Prozesses ist und nicht die Benotung von Menschen; lassen Sie Fachleute Etiketten korrigieren und zeigen Sie ihnen das Ergebnis (GUIDE-008).
• KI-Kompetenz (Art. 4): Betreiber müssen Maßnahmen zur Förderung der KI-Kompetenz ihres Personals ergreifen; kurze Einheiten für Prüfende zum Thema „Etiketten sind verrauscht“ (GUIDE-006).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Aufbereitung von Datensätzen birgt minimales Risiko. Das Risiko ändert sich mit der nachgelagerten Nutzung: Modelle für Einstellung oder Beschäftigtenbewertung gelten nach Anhang III als Hochrisiko (Pflichten ab 2. Dez. 2027 gemäß Verordnung (EU) 2026/1744). Etiketten aus Tickets, Buchungen und Qualität sind normalerweise unproblematisch (GUIDE-014).
• DSGVO: Die Wiederverwendung von Datensätzen für KI ist ein neuer Zweck; prüfen Sie Vereinbarkeit und Rechtsgrundlage (Art. 5 Abs. 1 lit. b, Art. 6; siehe PREP-025). Entfernen oder pseudonymisieren Sie Namen und Kennungen im Freitext (PREP-022). AVV (Art. 28) mit jedem Werkzeug, das die Daten verarbeitet; DSFA (Art. 35), wenn Mitarbeiterleistung oder besondere Kategorien betroffen sind.
• Risiken: versteckte Verzerrung, Datenlecks, Etiketten mit vertraulichen Inhalten. Gegenmaßnahmen: Prüfung von Stichproben, zeitbasierte Bewertung, auf das Projekt beschränkter Zugriff, dokumentierte Datensatzversion.

Erste Schritte

1. Wählen Sie eine Entscheidung mit erfasstem Ergebnis und klarer Verantwortung (z. B. Ticketkategorie).
2. Exportieren Sie 12-24 Monate als CSV und profilieren Sie Klassen und Drift je Quartal in Excel.
3. Lassen Sie die Prozessverantwortliche bzw. den Prozessverantwortlichen 100 zufällige plus 50 markierte Datensätze prüfen; notieren Sie die Fehlerquote.
4. Frieren Sie den bereinigten Datensatz als Bewertungsdatensatz ein, bevor Sie ein Werkzeug auswählen.
5. Legen Sie fest, welche Felder ab jetzt besser erfasst werden sollen, und führen Sie Korrekturen zurück (PREP-021).

Quellen

1. Snorkel - rapid training data creation with weak supervision (VLDB Journal): https://link.springer.com/article/10.1007/s00778-019-00552-1 (accessed 2026-10)
2. cleanlab documentation - finding label issues: https://docs.cleanlab.ai/v2.2.0/index.html (accessed 2026-10)
3. GDPR text (Art. 5, 6, 28, 35): https://eur-lex.europa.eu/eli/reg/2016/679/oj (accessed 2026-10)
4. Snorkel research - Interactive Programmatic Labeling for Weak Supervision: https://snorkel.ai/research-paper/interactive-programmatic-labeling-for-weak-supervision/ (accessed 2026-10)