Heißt das: nie Cloud? Nein. Aber wählen Sie bewusst:

  • Trainingsläufe oder große Vorverarbeitungsschritte, die sich gut pseudonymisieren/aggregieren lassen, können in EU‑Cloud‑Umgebungen Sinn ergeben.

  • Inferenz auf personenbezogenen oder fertigungsnahen Daten gehört aus unserer Sicht in Ihr eigenes Rechenzentrum oder in strikt isolierte VPCs mit klaren Exit‑Strategien.

Der 12‑Wochen‑Plan: Von Null zum produktiven Piloten

Ein realistischer Fahrplan für ein erstes, greifbares Ergebnis mit begrenztem Risiko:

Woche 1–2: Scope schärfen, Baseline messen

  • Problem als Messaufgabe formulieren: Welche Kennzahl verbessern wir um wie viel?

  • Datenzugänge einrichten, Golden‑Dataset definieren.

  • Prozesse und Nutzerreise skizzieren, Integration festlegen, Abnahmekriterien dokumentieren.

Woche 3–4: Datenpfad und Minimal‑System

  • Datenaufnahme stabilisieren (Konnektoren, Edge‑Pipelines).

  • Erste Baseline‑Heuristiken implementieren, Mess- und Logging‑Infrastruktur aufsetzen.

  • Security‑Basics: Secrets‑Management, Rollen, Audit‑Logs.

Woche 5–6: Modell‑Baselines

  • 1–2 Modellansätze parallel evaluieren; klare Metriken, keine Schönrechnerei.

  • Fehlerkatalog und Labeling‑Guidelines mit Fachexperten erstellen.

Woche 7–8: Integration und Nutzerfeedback

  • Integration in das Zielsystem (MES/ERP/DMS/Ticketing).

  • UI/UX minimal, aber brauchbar. Nutzer‑Feedback‑Kanäle aktivieren.

Woche 9–10: Stabilisierung, Edge‑Faktor

  • Performance, Latenz, Resilienz testen. Offline‑Szenarien simulieren.

  • Champion/Challenger‑Logik, Canary‑Rollouts, Rollback‑Pläne.

Woche 11–12: Abnahme und Entscheid

  • Gegen Baseline messen, ROI‑Signal ableiten.

  • Betriebskonzept für die nächsten 3–6 Monate: Monitoring, Retraining‑Plan, Verantwortlichkeiten.

Teamzuschnitt für den Mittelstand

Klein, interdisziplinär, mit klarer technischer Verantwortung:

  • Product Owner aus der Fachseite (0,3–0,5 FTE): Entscheidungen, Abnahme, Zugang.
  • Software Engineer mit Systemfokus: Datenpfad, Integrationen, Betrieb.
  • ML/AI Engineer: Features/Modelle, Metriken, Drift.
  • QA/Validation: Testfälle, Edge‑Cases, Akzeptanztests.
  • Domänenexperte: 1–2h/Tag verfügbar, nicht nur für Kickoffs.

So werden kleine Teams schneller als Konzerne

  • Entscheidungswege in Tagen statt Gremien‑Monaten.
  • Kein Plattform‑Theater: pragmatisches On‑Prem‑Kubernetes oder sogar Single‑Node‑Deployments, wenn es reicht.
  • Template‑First: Wiederverwendbare Pipelines, Logging, Feature‑Extraktion, nicht jedes Mal “grüne Wiese”.

Die Kehrseite: Bus‑Faktor, fehlende Wartbarkeit, Stückwerk. Gegenmittel:

  • Alles als Code: Infrastruktur, Pipelines, Policies.

  • Reproduzierbarkeit: Von Rohdaten bis Modell‑Artefakt ist alles versioniert.

  • Technische Ownership: Eine Stelle ist für das Gesamtsystem verantwortlich, nicht “die Datenabteilung” und “die IT” getrennt.

Governance ohne Bürokratie

KI‑Systeme sind Software plus Statistik. Behandeln Sie sie auch so:

  • Datenminimierung: Nur verarbeiten, was für die Aufgabe nötig ist. Pseudonymisierung, wo möglich.
  • Transparenz: Protokollieren Sie Entscheidungen, Modellversionen, Datensätze, Metriken.
  • Kontrollschleifen: Nutzer können Entscheidungen kommentieren, korrigieren, eskalieren.
  • Freigabeprozesse: Kleine, klare Gates für Änderungen (Modell, Konfiguration, Schwellenwerte).

Sicherheitsaspekte, die häufig übersehen werden

  • Prompt‑Injection und Tool‑Abuse bei LLM‑Agenten: Keine unkontrollierten Web‑Zugriffe, strenge Policies, Sandboxing.
  • Datenexfiltration: Keine “Hilfs‑APIs” mit unklaren Datenschutzpraktiken im Retrieval‑Pfad.
  • Secrets‑Hygiene: Modelle und Pipelines haben oft mehr Berechtigungen als Nutzer – Prinzip der minimalen Rechte durchsetzen.
  • Supply‑Chain: Container‑Images pinnen, Signaturen prüfen, eigene Registries, minimalistische Base‑Images.

Trade‑offs bei Modellen und Tools

  • Open‑Source‑Modelle vs. proprietär: OSS bietet Souveränität und On‑Prem‑Optionen, erfordert aber MLOps‑Reife. Proprietäre Dienste bringen oft Out‑of‑the‑box‑Qualität, kosten Souveränität. Für sensible Prozesse tendieren wir zu OSS/On‑Prem für Inferenz.
  • Vektorindizes: PostgreSQL mit pgvector reicht für viele RAG‑Szenarien und bleibt operativ simpel. Dedizierte Vektordatenbanken bringen Features, aber auch mehr Moving‑Parts.
  • Feature Stores: Für den Anfang reicht oft ein sauberes, versioniertes Feature‑Layer in einer relationalen DB. Ein ausgewachsener Feature Store lohnt sich ab mehreren Produkten/Teams.

Wann Sie lieber nicht starten sollten

  • Wenn der Zielprozess nicht in bestehende Systeme zurückspielen kann. “Insights” ohne Actuation enden als Reports.
  • Wenn Datenzugang politisch blockiert ist. Ohne Zugänge keine saubere Iteration.
  • Wenn Sie die Fachseite nicht an den Tisch bekommen. KI ohne Domänenwissen produziert Spielzeug.
  • Wenn die Erwartung ist, in 8 Wochen eine voll autonome Lösung zu erhalten. Realistisch sind 80/20‑Lösungen mit klaren Grenzen und Hand‑offs.

Konkrete erste Schritte ab nächster Woche

  • Use‑Case‑Canvas ausfüllen: Zielmetrik, Datenquellen, Nutzer, Integration, Abnahme.
  • Golden‑Dataset definieren: 1–2 Wochen reale Daten sammeln, Edge‑Cases markieren.
  • Minimal‑Stack wählen: On‑Prem‑K8s oder Single‑Node‑Deployment, Logging, Monitoring, Secrets.
  • Security‑Kickoff: Threat‑Model für den Use‑Case, besonders bei LLMs.
  • Betriebsrat/Datenschutz früh einbinden: Zweck, Datenflüsse, Minimierung, Rollen.

Warum wir auf Souveränität setzen

“Souveränität ermöglicht Intelligenz” bedeutet: Nur wer seine Datenflüsse, Modelle und Deployments beherrscht, kann verlässlich optimieren. Das gilt in der Verteidigung, in der Fertigung und in jedem datengetriebenen Prozess. On‑Premise‑fähige Architekturen, reproduzierbare Deployments und klare Governance sind keine Bremse – sie machen KI erst betriebsfähig.

FAQ

Frage: Brauchen wir zwingend eine Cloud, um mit KI zu starten?
Antwort: Nein. Für viele industrielle Use‑Cases ist On‑Premise oder Edge‑Inferenz der pragmatischste Weg: geringe Latenz, volle Datenkontrolle, weniger Abhängigkeiten. Cloud kann punktuell für rechenintensive Vorverarbeitung oder Experimente genutzt werden, sofern Daten sauber anonymisiert und die Umgebung souverän betrieben wird.

Frage: Reichen unsere Daten überhaupt aus?
Antwort: Für Qualitätsprüfung und Anomalieerkennung oft ja – insbesondere mit guten Baselines, Domänenregeln und datenarmen Verfahren. Auch bei LLM‑basierten Wissenssystemen zählt vor allem saubere Dokumentenaufbereitung und Retrieval. Wichtiger als Menge ist Struktur: klar definierte Datenschnitte, konsistente Labels, repräsentative Edge‑Cases.

Frage: Müssen wir zuerst einen Data Lake bauen?
Antwort: Nein. Bauen Sie den minimalen Datenpfad für den konkreten Use‑Case und sorgen Sie für Reproduzierbarkeit und Versionierung. Ein Data‑Lake oder ein Feature‑Store lohnt sich erst, wenn mehrere Teams/Produkte parallel arbeiten und Wiederverwendung messbar wird.