Trade‑offs, die Sie bewusst treffen sollten:

  • GPU vs. CPU für Inferenz: Für CV/LLM‑Use Cases ist GPU‑Inferenz praktisch Standard. CPU‑Fallback nur für kleine Modelle/geringe Last. Planen Sie Kapazität und Batch‑Größen explizit.

  • Vektor‑DB: pgvector genügt oft als Start (ein Stack, weniger Betriebsaufwand). Dedizierte Engines (Milvus, Qdrant) lohnen sich bei sehr großen Kollektionen oder speziellen Abfrageprofilen.

  • Feintuning vs. reines RAG: Starten Sie mit reinem RAG. Feintuning (LoRA) erst, wenn Retrieval und Prompt‑Engineering ausgereizt sind und ein klarer Gap bleibt.

  • Edge vs. Zentrales Rechenzentrum: Latenz‑kritische CV‑Use Cases nahe an der Linie ausführen; LLM‑Use Cases zentral, solange Bandbreite und Datenschutz es erlauben.

3) Ergebnisse in 3 Monaten: ein belastbarer 12‑Wochen‑Plan

Ziel: Ein minimaler, aber produktionsnaher Fluss, der echte Daten verarbeitet, Metriken liefert und einen klaren Go/No‑Go‑Punkt hat. Beispiel für CV oder LLM‑RAG; die Struktur ist ähnlich.

Woche 1–2: Problemformulierung und Datenpfad

  • Fachliche Zielmetrik definieren und schriftlich fixieren.

  • „Happy Path“ des Benutzerflusses skizzieren (inkl. Feedback und Rückfallebene).

  • Dateninventur: Welche Quellen? Welche Formate? Welche rechtlichen Einschränkungen? Export/ETL minimal aufsetzen.

  • Baseline ohne KI: Heuristik/Regelwerk oder Volltextsuche definieren. Das ist die Messlatte, die KI schlagen muss.

Woche 3–4: Datenaufbereitung und Labeling

  • Datenprofiling: Verteilung, Qualität, Ausreißer, PII‑Risiken. Dokumentierte Annahmen.

  • Label‑Guidelines schreiben; 200–500 repräsentative Beispiele labeln lassen (für CV). Für RAG: 50–100 Q&A‑Paare mit Ground‑Truth beantworten lassen.

  • Eval‑Harness bauen: Fixe Train/Val/Test‑Splits, Metriken, reproduzierbare Seeds, CI‑Job für wiederholbare Auswertung.

Woche 5–6: Baseline‑Modell und erste Ergebnisse

  • CV: Transfer‑Learning mit bewährter Architektur; pragmatische Augmentierungen, keine exotischen Tricks.

  • RAG: Sauberes Chunking, sinnvolle Embeddings, konservatives Prompting mit Quellenangabe. Kein Feintuning.

  • Evaluieren gegen Baseline; dokumentieren, wo Fehler entstehen (Klassen, Dokumententypen, Längen).

Woche 7–8: Technische Integration und „Shadow Mode“

  • Containerisiertes Inferenz‑Serving on‑prem; AuthN/AuthZ (Keycloak/LDAP), Logging, Metriken.

  • UI minimal: z. B. Bild‑Review‑Maske oder Q&A‑Konsole; Feedbackknöpfe für „richtig/falsch“.

  • Shadow‑Deployment neben dem bestehenden Prozess; keine automatischen Entscheidungen.

Woche 9–10: Härtung und Governance

  • Rollback‑Mechanismen, Versionierung (Modelle, Prompts), Audit‑Logs komplettieren.

  • Security: Secrets, Netzwerkpolicies, signierte Images, abgesicherte Artefakt‑Pfade.

  • Datenschutz: PII‑Redaktion im RAG‑Pfad, Zweckbindung dokumentieren, Datenhaltbarkeit regeln. Falls erforderlich, Datenschutzfolgeabschätzung (DPIA) vorbereiten.

  • Betriebsdoku: Runbooks (Alarmierung, Kapazitätsgrenzen, Backup/Restore).

Woche 11–12: Pilotbetrieb mit klaren Grenzen

  • Aktivierung in kleinem Umfang (eine Linie, ein Standort, definierte Nutzergruppe).

  • KPI‑Messung gegen Zielmetrik und Baseline; definierte Go/No‑Go‑Kriterien anwenden.

  • Entscheid: Skalierung vorbereiten ODER ehrlich einsammeln, warum es (noch) nicht trägt. Zeit und Budget nicht „stille“ verlängern – Kill‑Kriterien sind Teil der Souveränität.

4) Warum Mittelständler oft schneller sind – und wie man das nutzt

Stärken des Mittelstands:

  • Kürzere Entscheidungswege: Technische Stakeholder und Domänenexperten sitzen näher zusammen.

  • Tiefe Domänenkompetenz: Label‑Guidelines und Fehlertaxonomien entstehen schneller und präziser.

  • Pragmatismus: „So wenig Plattform wie möglich, so viel wie nötig“ – das ist ein Vorteil, wenn sauber umgesetzt.

Typische Fallstricke und Gegenmaßnahmen:

  • „Tool‑Zoo“ ohne Betrieb: Statt vieler Insellösungen eine minimale, wartbare Plattformbasis etablieren (s. o.).

  • Fehlende Qualitätssicherung: Eval‑Harness und feste Testsets von Tag 1 an; Metriken gehören ins Dashboard, nicht ins Projektwiki.

  • Abhängigkeit von Einzelpersonen: Containerisierte Jobs, GitOps, Runbooks. Kein „Laptop‑ML“.

5) Ressourceneinsatz und Sizing – pragmatische Leitlinien

  • Inferenz statt Training: Im Mittelstand ist das Training großer Modelle selten sinnvoll. Setzen Sie auf Transfer‑Learning (CV) und RAG (LLM). Feintuning nur gezielt (LoRA), wenn ein klarer Nutzen entsteht.
  • Hardware: Für CV/LLM‑Inferenz rechnen Sie mit mindestens einer produktionsfähigen GPU‑Karte im Rechenzentrum oder an der Linie. Nutzen Sie Quantisierung und Batch‑Inferenz, um Durchsatz/Latenz zu balancieren.
  • Speicher und Datenfluss: Planen Sie früh die Datenlebenszyklen (Rohdaten, bearbeitete Daten, Artefakte). Objekt‑Storage plus Postgres reicht oft erstaunlich weit.
  • Betrieb: CI/CD für Modelle ist Pflicht. Jedes Modell/Prompt ist ein Versionierungs‑ und Freigabethema wie eine Softwarebibliothek.

6) Governance und Sicherheit als Enabler – nicht als Bremse

  • Rollen und Verantwortlichkeiten: Produkt‑Owner in der Linie, technischer Owner, Datenschutz, IT‑Betrieb. Klare Schnittstellen.
  • Modellrisiko klassifizieren: Was passiert, wenn das Modell irrt? Danach richten sich Freigabekriterien, Monitoringtiefe und Rückfallebenen.
  • Auditierbarkeit: Reproduzierbare Trainingsläufe, versionierte Daten/Prompts/Modelle, signierte Artefakte, Prüfpfade für Entscheidungen.
  • LLM‑spezifische Absicherung: Prompt‑Injection‑Schutz (Kontext‑Sanitizing, Tool‑Allowlists), Abruf auf definierte Dokumentkollektionen beschränken, Abfrageprotokolle mit PII‑Schutz.
  • Lieferkettensicherheit: SBOMs prüfen, Container signieren/verifizieren, keine „curl | bash“‑Builds, Offline‑Mirrors.

7) Aus Projekten: Was in der Praxis trägt

Beispiel visuelle Qualitätsprüfung in der Fertigung:

  • Problem: Wiederkehrende visuelle Montagefehler, menschliche Ermüdung, schwankende Lichtverhältnisse.

  • Lösung: On‑prem CV‑Pipeline mit robusten Augmentierungen, Inferenz direkt an der Linie, UI für Prüfer mit Korrekturfeedback, regelmäßiges Re‑Training kleiner Batches.

  • Technische Besonderheit: Deterministische, versionierte Pipelines; Shadow‑Mode vor Aktivierung; RBAC‑Zugriff auf Bilder wegen möglicher Personenbezüge in Randbereichen.

  • Ergebnis: Stabiler Betrieb im Pilot, skalierbar, fachlich akzeptiert, weil Fehlalarme adressiert und Rückfallebene gesichert.

Beispiel prädiktive Instandhaltung in Textilmaschinen:

  • Problem: Ungeplante Stillstände durch Lagerdefekte; Teilediagnose bisher reaktiv.

  • Lösung: Streaming‑Anomalieerkennung mit isolierten Grenzwertmodellen pro Aggregat, keine automatischen Abschaltungen; Ampellogik, Wartungsplanung integriert.

  • Technische Besonderheit: On‑prem Zeitreihen‑Stack, erklärbare Features (Spektren), Drift‑Monitoring, tägliche Rekalibrierung im Wartungsfenster.