Woche 0–1: Scoping und Daten-Audit

  • Zielprozess definieren, harte Akzeptanzkriterien schriftlich fixieren (z. B. „False-Reject-Rate <= 2 %“, „Antwortlatenz = 8 h“).

  • Datenzugänge klären, 1–2 reale Datentage sichern. Security/DSGVO-Rahmen abstecken.

  • Baseline-Ansatz definieren: Regelbasiert/klassisch wo möglich (zum Vergleich).

Woche 2–3: Pipeline-MVP

  • Dateningestion und -speicherung produktionsnah aufsetzen (Compose/k3s).

  • Labeling/Annotation für 200–1000 relevante Beispiele anstoßen (Vision) oder FAQ/Fragenkorpus definieren (RAG).

  • Schnelltest: Embeddings-/Indexierungsstrategie (Chunking, Metadaten) evaluieren.

Woche 4–6: Modell-Baselines und Offline-Evaluation

  • Vision: Erste ONNX/TensorRT-Modelle, augmentierte Trainingssätze, Offline-Precision/Recall messen.

  • RAG: Top-k-Recall, Antwortgrundierung (Zitationspflicht), Benchmarks gegen definierte Fragen.

  • Predictive: Einfache Anomalie-Detektoren (z-score, STL-Decomposition) als Base, dann ML/Hybrid. Ergebnis als ROC/PR-Kurven dokumentieren.

  • Entscheidungspunkte: Reicht 7B-LLM? Muss quantisiert werden? Reicht pgvector?

Woche 7–8: Integration und Human-in-the-Loop

  • UI/Operator-Workflow: Klare Oberflächen für Freigabe/Zurückweisung, Begründungen erfassen.

  • Schnittstellen: ERP/MES/DMS read-only integrieren; Schreibrechte erst nach Shadow-Phase.

  • Observability: Prompt-/Tool-Use-Logging, Guardrails (z. B. Redaktionsregeln, Blacklist-Fragestellungen).

Woche 9–10: Shadow Mode im Live-Betrieb

  • Echtbetrieb parallel zum Menschen/Bestandsprozess, keine automatischen Aktionen.

  • Monitoring: Drift-Indikatoren, Fehlklassen-Analyse, Latenz-/Durchsatzmessung.

  • Iteration: Gezielt Top-Fehlerklassen datenmäßig anreichern (Active Learning).

Woche 11–12: Bewertung und kontrollierte Freigabe

  • Gegen Akzeptanzkriterien aus Woche 1 testen. Wenn erfüllt: begrenzte Freigabe mit Rollback-Plan.

  • Schulung, Betriebshandbuch, Wartungsfenster, Update-Prozeduren.

  • Abschlussbericht: Was funktioniert, was als Nächstes zu tun ist (Skalierung, weitere Linien, erweiterte Agenten).

Messmetriken je Use Case

  • Vision: Precision/Recall je Defektklasse, False-Reject-Rate, Taktzeit-Impact, OEE-Einfluss in Pilot.

  • RAG/Assistenz: Top-k-Dokument-Recall, Anteil beantwortbarer Fragen, Zitationsabdeckung, Antwortlatenz P95, Anteil eskalierter Fälle.

  • Predictive: Vorwarnzeit-Median, Kosten pro False Positive, Abdeckung (Prozent der relevanten Ausfälle erkannt).

4) Datensouveränität und DSGVO ohne US-Cloud – praktisch umgesetzt

Souveränität ist kein Slogan, sondern Architektur:

  • Datenminimierung: Nur die Datenpunkte erfassen, die zur Zielmetrik nötig sind. PII aus Dokumenten frühzeitig maskieren/redigieren.

  • Rechtliche Trennung: Entwicklungs- und Produktivumgebungen trennen. Produktivdaten verlassen die Umgebung nicht.

  • Vollständige Protokollierung: Wer hat welches Modell mit welchen Daten wann in Betrieb genommen? Prompt-/Antwort-Logs für LLMs pseudonymisieren und intern speichern.

  • RAG statt „LLM weiß alles“: Antworten nur mit Belegen aus dem eigenen Korpus. Keine Wissensverunreinigung, leichter auditierbar.

  • Agenten-Governance: Kein „freier Internetzugang“, keine unkontrollierten Tools. Tool-Aufrufe erlaubnisbasiert, Outputs validiert. Observability-Plattformen wie Alpi-M unterstützen hier durch zentrale Policies, Test-Suites, Ausreißer-Erkennung und Audit-Logs – on-prem betreibbar.

So vermeiden Sie ungewollte Datenabflüsse:

  • Keine Telemetrie zu externen Modellanbietern in Produktion.

  • Modell- und Embedding-Inferenz lokal betreiben.

  • Updates nur über signierte Container/Artefakte; ausgehender Traffic restriktiv.

5) Warum der Mittelstand oft schneller ist – und die typischen Gegenkräfte

Vorsprung

  • Kürzere Entscheidungswege: Werksleiter, IT und Fachbereich sitzen an einem Tisch.

  • Klarere Prozesse: Ein Produkt, eine Linie, definierte Taktzeiten – perfekte Bedingungen für sauber abgegrenzte Use Cases.

  • Höhere Domänentiefe: Jahrzehnte an implizitem Wissen, das sich in Daten-Features und Heuristiken konkretisieren lässt.

Gegenkräfte – und Gegenmaßnahmen

  • Knappe IT-Ressourcen: Bauen Sie eine „thin platform“ statt eines „Data Lakehouse“. Wenige, robuste Komponenten, die Sie wirklich betreiben können.

  • Heldenabhängigkeit: Dokumentieren, standardisieren, Rollen klären (PO, Data/ML, Software, Betrieb).

  • Schatten-IT: Frühe Einbindung von IT-Security, klare Freigabewege, Identity-Management von Tag 1.

6) Typische Fallen – und wie Sie sie vermeiden

  • Technologie vor Problem: „Wir brauchen einen Vektorstore/Agenten“ ohne definierte Zielmetrik. Gegenmittel: Akzeptanzkriterien vor der ersten Zeile Code.
  • Zu breite Scope: „Alle Dokumente, alle Anwender“. Gegenmittel: Ein Korpus, eine Nutzergruppe, eine KPI.
  • Vernachlässigte Integration: Ein großartiges Modell ohne UI/Workflow ist wertlos. Gegenmittel: Human-in-the-Loop, UI früh mitdenken.
  • Mangelnde Versionierung: Kein reproduzierbarer Weg von v0.1 zu v0.2. Gegenmittel: Git + DVC/MLflow, Artefakt-Registry, Release-Notizen.
  • Vendor-Lock-in: Proprietäre SaaS im Kernpfad. Gegenmittel: On-prem-fähige Open-Source-Bausteine, klare Exit-Strategie, Datenportabilität.

7) Hardware- und Kostenüberlegungen – ohne Zahlenzauber

Planen Sie entlang des tatsächlichen Lastprofils:

  • Vision Edge: Industrie-PC oder Jetson mit NVIDIA-GPU reicht oft. Rechenlast ist gut vorhersagbar (Taktzeit, Bildauflösung).

  • Zentrales LLM/RAG: 7–13B-Modelle mit quantisierter Inferenz liefern oft ausreichende Qualität bei moderatem Speicherbedarf. Wichtig ist VRAM für Kontextlängen und Concurrency.

  • Training vs. Inferenz: Training (oder Feintuning) braucht Spitzenleistung – das kann in einer EU-Cloud-Phase stattfinden. Dauerhafte Inferenz gehört on-prem.

  • 24/7-Dienst: Verlässlichkeit vor Maximalleistung. Planen Sie Redundanzen (N+1), Ersatzgeräte und klar definierte Wartungsfenster ein.

  • Netzwerk: Bandbreite und Latenz zwischen Edge und Zentrale sind echte Systemparameter. Komprimieren Sie Bilddaten, übertragen Sie Metadaten statt Rohvideo wenn möglich.

8) Governance, Qualitätssicherung und Wartbarkeit

  • Test-first: Legen Sie einen festen Offline-Testkorpus an (Bilder, Fragen, Zeitreihen-Segmente). Jeder Modellwechsel muss diesen Korpus schlagen.
  • Canary/Shadow-Deployments: Neue Modelle erst im Schattenmodus, dann gestaffelte Freigaben.
  • Drift-Monitoring: Eingabeverteilungen und Ausgabequalitäten überwachen, Retraining/Review auslösen.
  • Dokumentation: Prozessdiagramm, Datenflüsse, Konfigurationsparameter, Abnahmekriterien – ausführbar in einem Repo.
  • Rollen & Verantwortung:
  • Product Owner (Fachbereich): Problem, KPI, Akzeptanz.
  • Software/ML-Engineer: Pipeline, Modelle, Qualität.
  • IT/Operations: Betrieb, Sicherheit, Backups, Monitoring.

9) Wann Sie nicht starten sollten