2) Dokumenten-Extraktion in Einkauf oder Service

  • Problem: Halbstrukturierte PDFs/Scans (Bestellungen, Prüfzertifikate, Serviceberichte) erfordern manuelle Erfassung.

  • Daten: 300–1000 Belege mit Ground‑Truth‑Felder (Lieferant, Positionsnummern, Maße, Seriennummern).

  • Architektur:

  • OCR on‑prem (Tesseract, PaddleOCR, TrOCR je nach Sprache/Schrift).

  • Layout-Analyse (z. B. LayoutLMv3 oder heuristische Segmentierung).

  • Extraktion: Regel‑Engine plus LLM als Fallback für unklares Layout, mit strengem Output‑Schema (JSON‑Schema Validierung).

  • Post‑Processing: Validierung gegen Stammdaten (ERP), Confidence‑Scoring -> Mensch im Loop bei Unsicherheit.

  • Speicherung: On‑prem Queue + Data Lake, Audit‑Trail je Dokument.

  • Modellstrategie:

  • 80/20 über Regeln/Regex + Validierung; LLM lokal nur für schwierige Fälle.

  • Embedding‑Suche für Tabellen/Positionsmapping.

  • Erfolgsmessung:

  • Feldgenaue Precision/Recall, Zeitersparnis pro Dokument, Prozent vollständig automatisiert.

  • Compliance:

  • PII‑Schwärzung in Persistenzschicht, Zugriff nur rollenbasiert, kein Outbound.

3) Anomalieerkennung in Maschinendaten (Predictive Maintenance light)

  • Problem: Unerwartete Stillstände kosten; vollständige Labelsets fehlen.

  • Daten: Sensorkanäle (Vibration, Strom, Temperatur) mit 1–10 Hz, Wochen bis Monate Historie.

  • Architektur:

  • Datenaufnahme via OPC UA/MQTT in on‑prem Time‑Series DB (TimescaleDB, InfluxDB).

  • Feature‑Pipelines (Statistiken, Frequenzbänder), Modelle als Services neben DB.

  • Dashboards on‑prem; Alarmierung mit Hysterese und Deadbands, Integration in bestehende Leitstände.

  • Modellstrategie:

  • Unüberwacht: Isolation Forest, Spectral Residual, Autoencoder.

  • Pro Aggregat ein Modell; Baselines pro Schicht/Betriebsmodus.

  • Feedback‑Schleife: Operator markiert Alarme als “nützlich/nicht”, Threshold‑Tuning zyklisch.

  • Erfolgsmessung:

  • Mean Time Between Alarms, Anteil “guter” Alarme laut Operator, Frühwarnzeit vor Ereignissen.

  • Edge‑Einsatz:

  • Inferenz auf IPC mit CPU möglich; GPU nur bei hoher Kanalzahl nötig.

Ein 90‑Tage‑Plan, der in der Praxis trägt

Tage 0–10: Use‑Case-Scoping

  • Problem-Statement schreiben: Was genau wird verbessert, wie messen wir Erfolg?

  • Datenpfad skizzieren: Wo kommen Daten her, wie greifen wir zu, wer verantwortet?

  • Abnahmekriterien definieren: Metriken, Gate für Go/No‑Go Pilot.

Tage 11–20: Daten- und Architektur-Assessment

  • Datenqualität prüfen: Stichprobe, Label‑Machbarkeit, Datenschutzklasse.

  • Zielarchitektur festlegen: On‑prem Komponenten, Netzwerkzonen, Egress‑Politik, IAM.

  • Risiken und Annahmen dokumentieren (ADRs).

Tage 21–40: Baselines und technische Enablement

  • Baseline ohne KI aufsetzen (Regeln/Schwellenwerte/Heuristiken).

  • MLOps‑Minimalstack hinstellen: Git, Container Registry, Model Registry, Monitoring.

  • Annotierungsplan/Tooling für die nächsten 4 Wochen.

Tage 41–60: POC unter Realbedingungen

  • Erstes Modell trainieren und an echter Schnittstelle testen.

  • Observability: Metriken, Logs, Traces; Fehlerklassen analysieren.

  • Sicherheit: Egress‑Kontrollen testen, Secrets‑Handling, Audit‑Logs.

Tage 61–80: Pilot stabilisieren

  • Performance‑Tuning, Drift‑Handling, Feedback‑Schleife schließen.

  • Betriebskonzepte: Backup/Restore, Update‑Pfad, Rollback.

  • Nutzertraining und Handover‑Dokumentation.

Tage 81–90: Entscheidungsvorlage

  • Kosten/Nutzen, Risiken, To‑Dos für produktiven Rollout.

  • Architektur-Review, Security-Review, Data‑Protection‑Check.

  • Roadmap für Phase 2 (Skalierung, zusätzliche Stationen/Belege/Aggregate).

Warum Mittelstand hier oft schneller ist als Konzerne

  • Fokus: Ein klarer Engpass und ein dediziertes, kleines Team schlagen 15 Stakeholder-Runden.
  • Eigentum an Prozessen und Daten: Kürzere Wege zur Linie/Werkstatt, schnelleres Feedback.
  • Architekturdisziplin statt Tool‑Zoo: Ein schlanker, selbst gehosteter Stack ist wartbarer als fünf Cloud‑Dienste plus Integrationslast.

Was Mittelständler aktiv managen müssen

  • Single‑Point of Failure vermeiden: Technische Ownership klar regeln, Bus‑Faktor > 1.

  • Lieferkettenrisiko: SBOMs verlangen, Updateprozesse fordern, keine Black‑Box‑Abhängigkeiten.

  • Technische Schuld begrenzen: Von Beginn an Tests, Versionierung, Reproduzierbarkeit.

Pragmatischer Minimal‑Stack für souveräne KI

  • Versionsverwaltung: Git mit klaren Branch‑Policies, ADR‑Ordner im Repo.
  • Daten-/Modell‑Versionierung: DVC oder einfache, bewusste Artefaktpflege mit Checksums; Model Registry (MLflow o. Ä.) on‑prem.
  • Containerisierung: Docker/Podman, signierte Images, private Registry.
  • Orchestrierung: Lightweight (Docker Compose) für POC/Pilot, Kubernetes erst bei Bedarf (HA, Multi‑Tenant).
  • Observability: Metriken (Prometheus), Logs (Loki/ELK), Traces je nach Bedarf.
  • Security: Secrets‑Management, Egress‑Policies, signierte Builds, SBOM‑Pflicht.
  • LLM‑Governance: Prompt-/Response‑Logging, RBAC bis auf Tool‑Ebene, definierte Guardrails; ein Observability‑/Governance‑Layer ist Pflicht, ob eigengebaut oder als Plattform.

Beispielarchitektur für ein souveränes LLM‑Assistenzsystem im Service

  • Wissensquellen: PDF‑Handbücher, interne Wikis, Wartungsprotokolle in einem on‑prem DMS.
  • Ingestion: Konnektor extrahiert Text + Metadaten, führt Chunking und Embedding on‑prem durch, speichert in Vektorstore (pgvector in Postgres).
  • Inferenzservice: Lokal deploytes LLM (z. B. 7B–13B quantisiert) hinter API‑Gateway, ohne Internetzugriff.
  • Retrieval‑Layer: Query -> semantische Suche mit strikter Filterung (Anlagen‑Typ, Baujahr, Sprache) -> kontextualisierte Prompt‑Vorlage.
  • Tooling: Funktionsaufrufe für Ersatzteilsuche (nur lesend), Ticketanlage (schreibend mit RBAC).
  • Guardrails: Output‑Schema, Quellen‑Zitate verpflichtend, Confidence‑Score; bei Unsicherheit Übergabe an Menschen.
  • Observability: Pro Anfrage werden Embeddings, Dokumentquellen, Prompt, Antwort, Latenz, Kostenstellen-Tagging und Feedback erfasst.
  • Sicherheit: Egress‑Firewall, Secrets im Vault, Audit‑Pfad unveränderlich.

Kennzahlen, die wirklich steuern

  • Technisch: Latenz p95, Throughput, Fehlerraten je Klasse, Drift‑Indikatoren, Ressourcenauslastung.
  • Fachlich: Einsparungen je Einheit (Minuten, Ausschuss, Nacharbeit), Erstlösungsquote, Alarme‑Präzision, Nutzerakzeptanz.
  • Betrieb: MTTR bei Rollbacks, Zeit bis Modell‑Update, Anteil reproduzierbarer Builds.

Risiken und Abmilderungen

  • Daten-Drift: Regelmäßige Re‑Evaluation, Canary‑Releases, automatisierte Tests auf repräsentativen Batches.
  • “Glue‑Code‑Hölle”: Klare Serviceschnittstellen, ADRs, regelmäßiges Refactoring.
  • Sicherheitslücken in Third‑Party: SBOM‑Pflicht, CVE‑Scanning in CI, Update‑Fenster definieren.
  • Abhängigkeit von Einzelpersonen: Pairing, Code‑Reviews, Runbooks, On‑Call‑Rotation.
  • Scope Creep: Harte Abnahmekriterien je Phase, Feature‑Freeze vor Pilot.

Beschaffungs‑Checkliste für souveräne KI‑Bausteine