Titel: KI im Mittelstand: Wo der Einstieg wirklich Sinn macht – und wie Sie in 12 Wochen souverän produktiv werden

Kurzfassung für Ungeduldige

  • Starten Sie dort, wo Datenzugang, Prozessnähe und beherrschbares Risiko zusammenfallen – nicht dort, wo das Buzzword am lautesten ist.

  • Drei pragmatische Erstprojekte, die in 3 Monaten Ergebnisse liefern: visuelle Qualitätskontrolle, dokumentenzentrierte Suche/Assistenz (RAG), zustandsorientierte Instandhaltung.

  • Architektur vor Algorithmus: Definieren Sie Betriebsmodell, Datenflüsse, Zugriff und Governance zuerst. Modelle kommen danach.

  • On-Premise heißt nicht „altmodisch“ – sondern „beherrschbar“: GitOps, Container, reproduzierbare Builds, Observability und klare Rückfallebenen.

  • Qualität messen wie in der Produktion: eindeutige Akzeptanzkriterien, Shadow-Mode, Kill-Switch, Audit-Logs, DSGVO-by-Design.

Warum dieser Artikel anders ist
Wir bauen industrielle KI-Systeme, keine Präsentationen. Mittelständische Teams in DACH brauchen Lösungen, die mit zwei bis fünf Personen tragfähig betrieben werden können, die Daten im Haus halten und die nach 12 Wochen messbaren Nutzen zeigen. Der folgende Leitfaden ist das, was wir in realen Projekten als tragfähige Startlinie sehen – inklusive konkreter Architekturmuster, Metriken und Betriebsentscheidungen.

1. Problem vor Technologie: Der echte Einstiegspunkt
Typischer Ausgangszustand im Mittelstand:

  • Daten liegen verteilt: Kameras/PLCs am Band, Messreihen in CSV, techn. Dokumente in Fileshares, Wissen im Kopf der Meister.

  • IT/OT sind entkoppelt, teils air-gapped. Internetzugang ist eingeschränkt, externe Clouds sind organisatorisch oder rechtlich unerwünscht.

  • Kleine Teams müssen Betrieb und Weiterentwicklung stemmen. Jeder zusätzliche Dienst ist eine reale Belastung.

Konsequenz:

  • Wählen Sie Use Cases, bei denen Sie a) Zugriff auf Daten und b) einen klaren Integrationstouchpoint haben und c) Qualitätsmetriken früh messen können.

  • Vermeiden Sie Cases, die beim ersten Wurf ein perfektes Rechte-/Rollenkonzept, unternehmensweite Datenharmonisierung oder risikoreiche Closed-Loop-Automation verlangen.

Go/No-Go-Check (in 5 Fragen):

  • Ist klar, welche KPI wir verbessern (Ausschussrate, Suchzeit, mittlere Ausfallzeit, Ticket-Durchlaufzeit)?

  • Haben wir für eine Linie, einen Teilprozess oder einen Dokumentensatz vollständigen Datenzugang?

  • Können wir in 8–12 Wochen in Shadow-Mode messen, ohne den Betrieb zu gefährden?

  • Gibt es eine minimale Integration (z. B. ein UI-Panel, ein API-Endpunkt, eine freigegebene Datenablage), die wir kontrollieren?

  • Haben wir ein akzeptiertes Sicherheitsnetz (Fallback, menschliche Freigabe, Betriebsrichtlinien)?

Wenn eine Frage „Nein“ ist, schneiden Sie den Scope kleiner. Wenn zwei oder mehr „Nein“ sind, verschieben oder wechseln Sie den Use Case.

2. Drei Erstprojekte, die in 3 Monaten Ergebnisse liefern

2.1 Visuelle Qualitätskontrolle an bestehenden Arbeitsplätzen
Worum es geht:

  • Erkennung von Montagefehlern, fehlenden Komponenten, Oberflächendefekten direkt am Arbeitsplatz oder am Ende der Linie.

Warum geeignet:

  • Daten sind sichtbar und annotierbar. Integration kann dezentral erfolgen (Ampel, akustisches Signal, Panel). Risiken sind beherrschbar mit menschlicher Freigabe.

Minimal-Architektur:

  • Edge-Kamera oder bestehende Kameraquelle.

  • Inferenzrechner am Arbeitsplatz (Industrie-PC; GPU optional, je nach Latenz und Komplexität).

  • Containerisierte Inferenz-Services, lokal orchestriert (z. B. systemd + Docker oder leichtgewichtiges k3s).

  • Versionierte Modelle (Artifact-Repository), Model-Metrics-Logging (z. B. MLflow oder schlanke Eigenlösung).

  • Offline-Trainingspipeline auf einer Workstation im Haus, Datenversionierung (z. B. DVC + Git).

Daten und Qualität:

  • Starten Sie mit wenigen hundert repräsentativen Bildern je Fehlerklasse. Ergänzen Sie pro Woche Batches mit gezielter Nachannotation.

  • Metriken: Recall auf kritischen Fehlerklassen, Falsch-Alarm-Rate pro Schicht, Latenz pro Bild, Eingriffsrate des Menschen.

  • Betriebsregeln: Bei Unsicherheit immer menschliche Bestätigung; jede Fehlentscheidung wird für Retraining markiert.

Integration:

  • UI auf dem Arbeitsplatzrechner mit drei Buttons: „OK“, „Unsicher – Mensch prüft“, „Fehler“. Kein Overengineering.

  • Export ins Qualitätssystem als einfacher JSON/CSV-Feed oder REST-Aufruf.

2.2 Dokumentenassistenz per On-Prem Retrieval-Augmented Generation (RAG)
Worum es geht:

  • Techniker, Einkauf, Service: Antworten auf konkrete Fragen aus eigenen Dokumenten (Handbücher, Prüfprotokolle, Normenkommentare), ohne Daten das Haus verlassen zu lassen.

Warum geeignet:

  • Hoher Zeitgewinn, geringer Integrationsaufwand, sauber separierbarer Scope (ein Bereich, ein Datenraum).

Minimal-Architektur:

  • On-Prem konfigurierbarer Inferenzserver für ein schlankes Sprachmodell (7–13B Parameter-Klasse reicht oft für gut formulierte, faktennahe Antworten).

  • Embedding- und Vektor-Datenbank on-prem (z. B. containerisiert; SSD, Backup integriert).

  • Ingestion-Pipeline: Chunking nach Dokument-Logik (Überschriften, Tabellen), Metadaten (Quelle, Gültigkeit, Version), Berechtigungslabels.

  • Zugriff und SSO über Ihr IAM (z. B. Keycloak), Protokollierung aller Abfragen, PII-Scrubbing im Prompt.

  • Observability und Governance: Prompt-, Retrieval- und Antwort-Traces, konfigurierbare Guardrails (z. B. Antwort nur aus Zitaten, sonst „keine ausreichende Grundlage“).

Qualität und Sicherheit:

  • Metriken: Retrieval-Top-k-Abdeckung, Zitat-Genauigkeit, Rate an „Grounded“-Antworten, Eskalationsquote zum Menschen.

  • Betriebsregeln: Temperatur niedrig, Antworten nur mit Quellenzitaten; unbekannt -> explizites „weiß ich nicht“.

  • Rechte: Dokumente bleiben in ihrem Berechtigungsraum; Vektorindex erzwingt dieselben Labels.

Hinweis zu Observability:

  • LLM-Agents ohne Nachvollziehbarkeit sind ein Audit-Risiko. Traces, Tool-Aufrufe, verwendete Kontexte, Modell-/Prompt-Versionen müssen lückenlos nachvollziehbar sein. Deshalb setzen wir in Projekten eine eigenständige Observability- und Governance-Schicht ein, die on-prem betreibbar ist.

2.3 Zustandsorientierte Instandhaltung mit vorhandenen Sensordaten
Worum es geht:

  • Früherkennung von Anomalien in Motoren, Pumpen, Lagern; Priorisierung von Wartungsfenstern.

Warum geeignet:

  • Daten liegen oft bereits vor (SPS/SCADA-Export, CSV, Historian). Sie können mit einem Asset beginnen und iterativ ausrollen.

Minimal-Architektur:

  • Batch-orientierter Start: nächtlicher Export, Feature-Engineering, Baseline-Modelle (z. B. einfache Autoencoder, Isolation Forest oder robuste Schwellen).

  • Visualisierung im bestehenden Dashboard; Alarme mit Konfidenz und Klartext-Gründen.

  • Später Streaming ausbauen (Message-Bus, Fensterfunktionen), wenn es Nutzen bringt.