• „Wir hosten alles in der US‑Cloud, geht schon“: Juristische und vertragliche Risiken sowie Lieferantenabhängigkeiten bleiben an Ihnen hängen. Wenn Datensouveränität zentral ist, entscheiden Sie sich bewusst für On‑Prem oder europäische, vertraglich abgesicherte Optionen.

4) Souveränitätsarchitektur: DSGVO-konforme KI ohne US-Cloud

Grundprinzip: Souveränität ermöglicht Intelligenz. Wenn Daten, Modelle und Entscheidungen innerhalb Ihrer Kontrollsphäre bleiben, können Sie schneller iterieren und Produktionstauglichkeit erreichen.

Bausteine, die sich bewährt haben:

  • Infrastruktur:

  • On-Prem Virtualisierung (Proxmox/vSphere) oder Bare‑Metal für Edge/Datacenter.

  • Container Registry gespiegelt im Haus, signierte Images, Offline‑Updates.

  • GitLab CE/Forgejo für CI/CD, Artefakt‑Registry.

  • Sicherheit:
  • Zero-Trust auch im OT‑Netz: minimal notwendige Firewall‑Regeln, read‑only Datenabgriffe.
  • Pseudonymisierung/Maskierung für personenbezogene Daten; DLP-Filter in allen Ingestion‑Pipelines.
  • IAM zentral (Keycloak), rollenbasierte Freigaben bis auf Dokumentenebene, Auditpflicht.
  • Daten und Modelle:
  • DVC oder gleichwertig für Datensatz‑Versionierung, eindeutige Hashes für Trainings/Validierung.
  • Modell‑Registry mit Metadaten (Training, Hyperparameter, Commit‑IDs, Metriken).
  • Reproduzierbare Builds (Conda/Poetry/Containers), deterministische Seeds, Unit‑ und Smoke‑Tests für Pipelines.
  • Observability:
  • Metriken/Logs/Traces via Prometheus/Grafana/ELK. Für LLM‑Agenten zusätzlich: Prompt‑Versionierung, Tool‑Call‑Audits, Content‑Safety‑Checks, A/B‑Vergleiche. Ohne Observability sind LLM‑Use‑Cases nicht auditierbar.
  • Governance:
  • Use‑Case‑spezifische DPIA/DSFA, klare Zweckbindung, Aufbewahrungsfristen.
  • Technisch‑organisatorische Maßnahmen dokumentiert und im Betrieb verankert.

5) 12‑Wochen‑Fahrplan zum produktionsnahen Pilot

Woche 1–2: Problem präzisieren und Scope einfrieren

  • Gemba‑Walk: Linie/Anlage/Prozess live sehen, Datenquellen prüfen.

  • Zielmetrik definieren (z. B. Falsch‑Ausschuss in % reduzieren; Mean Time To Detect Anomalies; mediane Antwortzeit bei Dokumentenabfragen).

  • Nichtziele explizit festhalten (z. B. keine Retrofit‑SPS‑Änderungen im Pilot).

Woche 3–4: Datenpfad Ende‑zu‑Ende aufspannen

  • Minimaler Datenstecker (OPC‑UA/MQTT/Dateidrop) mit Puffer und Fallback.

  • Edge‑Hardware festlegen, Sicherheitsfreigaben vorbereiten.

  • Labeling‑Prozess definieren: Wer labelt, wann, mit welchem Tool?

Woche 5–8: Prototyp bauen und evaluieren

  • Erste Modellversionen trainieren, Baselines vergleichen (Regel vs. ML).

  • Inferenzpipeline containerisieren, Latenzbudget und Ressourcen messen.

  • Interne Red‑Teaming‑Tests (Fehlbedienung, Grenzfälle, Ausfälle).

  • HMI/Operator‑Feedback integrieren: Wie werden Unsicherheiten angezeigt? Wie gibt der Mensch Feedback?

Woche 9–10: Integration an der Linie/in der Domäne

  • Dry‑Run im Schattenbetrieb, keine Entscheidungen automatisieren.

  • Alarmierungswege abstimmen (Andon, Ticket, E‑Mail), Eskalationsmatrix klären.

  • Betriebsdokumentation: Wiederanlauf, Updateprozess, Rollback.

Woche 11–12: Pilot live, Messung, Entscheidung

  • Metriken erheben; Vergleich gegen Vorzustand.

  • Entscheidungsvorlage: Weiterbetrieb, Ausbau, „Kill it“ – mit Begründung.

  • Wissensübergabe: Hands‑on‑Session, Checklisten, Wartungsfenster.

Team und Rollen (schlank):

  • Domänenverantwortlicher mit Entscheidungsrecht (0,2–0,4 FTE).

  • Technischer Owner/Lead (1 FTE).

  • Software‑Engineer mit Edge/Backend‑Erfahrung (1 FTE).

  • Data/ML‑Engineer (0,5–1 FTE).

  • IT/OT‑Sec für Freigaben (zeitweise).

6) LLM‑Agenten im Mittelstand: nur mit Observability und Guardrails

Sobald LLMs Tools ansteuern (Datenbanken abfragen, Tickets anlegen), brauchen Sie:

  • Strikte Tooling‑Schnittstellen: Jedes Tool mit klarer Spezifikation, Rate‑Limits, Eingabe‑/Ausgabe‑Validierungen.

  • Prompt‑ und Policy‑Versionierung: Jede Änderung nachvollziehbar.

  • Output‑Kontrollen: JSON‑Schemas, Schema‑Enforcement, PII‑Filter.

  • Human‑in‑the‑Loop: Unsichere Antworten erfordern Freigabe.

  • Telemetrie und Audits: Welche Dokumente wurden zitiert? Welche Tools wurden aufgerufen, mit welchen Parametern? Welche Policies griffen?

Eine Observability‑ und Governance‑Schicht für LLM‑Agenten ist kein „Nice to have“, sondern die Betriebserlaubnis. Ohne diese Schicht bleiben LLM‑Lösungen Demos – nicht Produktion.

7) Warum der Mittelstand oft schneller ist als der Konzern

In Projekten sehen wir drei strukturelle Vorteile:

  • Nähe zur Wertschöpfung: Der Meister oder Instandhalter sitzt mit am Tisch. Entscheidungen werden schneller getroffen, Hypothesen schneller falsifiziert.

  • Geringere Pfadabhängigkeit: Weniger harte Abhängigkeiten in globalen Plattformvorgaben; On‑Prem‑Lösungen sind realistisch.

  • Realistische Zielbilder: Statt „Plattform zuerst“ wird problemorientiert gebaut. Das spart Monate.

Das Risiko: Wissenssilos. Gegenmittel: Saubere Repos, IaC, wiederholbare Deployments, Observability by default.

8) Technologieauswahl: pragmatisch und ersetzbar

  • Komponenten statt Monolithen:
  • CV: OpenCV, ONNX Runtime, Modelle, die sich quantisieren lassen (INT8 via OpenVINO/TensorRT).
  • Zeitreihen: Scikit‑Learn‑basierte Anomaliedetektoren, einfache Autoencoder; Persistenz in Timeseries‑DB (InfluxDB/Timescale) optional – reicht oft ein leichtgewichtiges Filesystem‑Backed Storage für Piloten.
  • RAG: Qdrant/Milvus, selbstgehostete Embeddings, LLM lokal (quantisiert). Kein externer Anruf für Kernlogik.
  • Infrastruktur:
  • Edge: Industrie‑PC mit iGPU/GPU oder Jetson; Lüfter, Staub, Temperatur beachten.
  • Datacenter: 1–2 Server mit ausreichendem RAM/GPU für Inferenz und Tests. Keine exotische Hardware, die nur ein Lieferant bedienen kann.
  • Betrieb:
  • Updates offline signiert; Blue/Green‑Rollout auch im Edge‑Umfeld.
  • Backup/Restore getestet, insbesondere Vektorindex und Modell‑Registry.
  • Lizenzprüfung: OSS‑Lizenzen verstehen, kommerziellen Support dort einkaufen, wo Risiko/Komplexität hoch ist.

9) Kennzahlen und Akzeptanz

Definieren Sie eine Geschäftsmetrik und maximal zwei technische Metriken:

  • Geschäftsmetrik: z. B. Reduktion Falschausschuss, vermiedene Stillstandsminuten, Suchzeitersparnis pro Ticket.

  • Technische Metriken: z. B. False‑Positive‑Rate unter Produktivlast; 95‑Perzentil‑Latenz.

Akzeptanz entsteht durch Transparenz:

  • Anzeigen, wenn das System unsicher ist.

  • Immer Gründe/Quellen nennen (warum Alarm? welches Dokument?).

  • Feedback leicht machen (ein Klick „falsch/richtig“), dieses Feedback sichtbar in Verbesserungen umsetzen.

10) Startcheckliste für nächste Woche

  • Ein Use Case, eine Metrik, ein Team. Keine Parallelwetten.
  • Dateneingang technisch klären (Kamera/OPC‑UA/Datei), Rechtslage klären (Zweckbindung, Löschkonzept).
  • Edge‑Hardware ordern oder bereitstellen.
  • Repositories/CI anlegen, Container‑Baseline bauen.
  • Minimaler Observability‑Stack aufsetzen (Logs, Metriken).
  • Labeling‑Workflow festlegen.

FAQ