Jeder zweite CTO stellt sich heute dieselbe Frage: „Wo fangen wir mit KI an, ohne wieder Geld zu verbrennen?" Die Antwort liegt nicht in der Technologie. Sie liegt in der Disziplin der ersten drei Monate — darin, was Sie kartieren, was Sie ablehnen, wem Sie Verantwortung übertragen und wie Sie das Ergebnis messen. Dieser Artikel ist ein Entscheidungsrahmen für die ersten 90 Tage, kein technisches Installationshandbuch für ein Modell.
Die meisten Quellen geben an, dass 75–95 % der KI-Projekte den geplanten Geschäftswert nicht erreichen. Die genauen Zahlen mögen von der Studienmethodik abhängen, aber der Trend ist konsistent: Pilots entstehen, enden nach 3–6 Monaten, der Mehrwert bleibt aus. Der Grund ist meist derselbe — nicht schlechte Technologie, sondern fehlende Vorbereitung vor dem ersten import openai.
Tag 1–30: Gelände kartieren, bevor Sie graben
Inventur der Use-Cases, keine Einkaufsliste
Der erste Monat dreht sich nicht um die Wahl der Technologie. Er dreht sich darum zu verstehen, wo das Unternehmen Zeit und Geld bei wiederkehrenden kognitiven Aufgaben verliert — beim Lesen von Dokumenten, beim Beantworten immer gleicher Fragen, beim Extrahieren von Daten aus Formularen, beim Verfassen von Standardberichten.
Schnelle Methode: Bitten Sie 5–10 Personen aus verschiedenen Abteilungen, auf ein Blatt Papier zu schreiben, was sie jede Woche wiederholt tun und was sie nervt. Das meiste davon wird kategorisch anders sein als „wir wollen einen Chatbot". Es werden Dinge stehen wie: manuelles Übertragen von Kunden-E-Mails ins CRM, Suche nach Antworten in technischer Dokumentation, Vorbereitung von Unterlagen für Angebote, Kontrolle von Lieferscheinen.
Bewerten Sie jeden Use-Case auf zwei Achsen: Häufigkeit (wie oft er vorkommt) und Wert (was eine Ausführung kostet — Zeit × Stundensatz × Anzahl der Wiederholungen pro Monat). Das ist keine akademische Übung — es ist die Grundlage für das ROI-Gespräch, das Sie in 60 Tagen mit der Geschäftsführung führen werden.
Unterscheidung: Chatbot, Copilot oder Agent
Bevor Sie ein Tool auswählen, klären Sie, was Sie eigentlich brauchen. Chatbot, Copilot und Agent sind unterschiedliche Architekturmuster mit unterschiedlichen Kosten und Komplexitäten.
Chatbot beantwortet Fragen — geeignet für Kundensupport oder internes FAQ. Am einfachsten einzusetzen, niedrigste Erwartungen.
Copilot unterstützt den Mitarbeiter in seinem Werkzeug — im Fertigungs-MES-System, im ERP, in der Dokumentation. Der Mitarbeiter trifft Entscheidungen, die KI schlägt vor und bereitet vor. Typischer erster Schritt für Industrieunternehmen.
Agent plant, ruft Tools auf, führt mehrstufige Aktionen autonom aus. Leistungsfähiger, aber um ein Vielfaches komplexer — erfordert Error Handling, Observability und gründliches Piloting. Nicht für das erste Projekt.
Für 80 % der Unternehmen in den ersten 90 Tagen lautet die richtige Antwort: Copilot über interner Dokumentation oder RAG über der firmeninternen Knowledge Base.
Daten: die Büchse der Pandora sofort öffnen
KI-Projekte scheitern an Daten, nicht an Modellen. Klären Sie im ersten Monat:
- Wo liegen Dokumente, Handbücher, technische Vorschriften, Serviceprotokolle — und in welchem Format (PDF, Word, Tabellen, Datenbanken)?
- Wer hat Zugriff? Ist die Datensensitivität definiert (DSGVO, Geschäftsgeheimnis)?
- Wie aktuell sind die Daten — sind die Dokumente auf dem neuesten Stand oder stammen sie aus dem Jahr 2018?
Der Cisco AI Readiness Index gibt an, dass nur ~34 % der Unternehmen ihre Datenbereitschaft als ausreichend einschätzen. In der Praxis bedeutet das: eingescannte Archiv-PDFs, manuell kodierte Excel-Tabellen und Dokumentation, die im Kopf langjähriger Mitarbeiter existiert. Das ist kein Grund, nicht anzufangen — es ist ein Grund, mit einem Datenaudit zu beginnen, nicht mit einem Modell.
Tag 31–60: Ein Pilot, der etwas entscheidet
Auswahl des ersten Use-Cases: ROI-positiv, nicht am verlockendsten
Der häufigste Fehler: Das Unternehmen wählt den ambitioniertesten Use-Case — „wir wollen KI zur Vorhersage von Ausfällen der Fertigungslinie" — und der Pilot kommt wegen unzureichender historischer Daten, unklaren Erfolgskriterien und fehlendem Domainexperten im Team zum Stillstand.
Der erste Use-Case muss gleichzeitig drei Bedingungen erfüllen:
- 1.Messbare Baseline — Sie wissen, wie viele Stunden die jeweilige Aufgabe aktuell kostet. Ohne Baseline können Sie das Ergebnis nicht bewerten.
- 2.Begrenzter Umfang — der Pilot passt in 4–6 Wochen inklusive Auswertung. Je länger der Pilot, desto geringer die Wahrscheinlichkeit, dass er abgeschlossen wird.
- 3.Reale Datenbasis — Sie haben mindestens 50–200 Dokumente oder Transaktionen, an denen der Pilot getestet werden kann. Keine Datenbank aus der Zukunft.
Guter erster Use-Case für ein Fertigungsunternehmen: Q&A über technische Dokumentation (RAG über Servicehandbücher, Zertifikate, Normen). Techniker suchen täglich zehnmal nach denselben Antworten, Dokumente sind ausreichend vorhanden, und die Messbarkeit ist klar (Suchzeit vor vs. nach der Einführung).
Architektur des Pilots: lokal oder Cloud?
Für Unternehmen mit sensiblen technischen Dokumenten oder regulatorischer Belastung (Maschinenbau, Chemieindustrie, Gesundheitswesen) lautet die erste Frage: „Dürfen unsere Daten das Netzwerk verlassen?"
Falls nein — ein lokales Modell (Ollama mit Qwen 3 oder Mistral, laufend auf einem Firmenserver oder einer Workstation) mit einer lokalen Vektordatenbank ist die richtige Wahl. Die Leistung wird niedriger sein als bei einem Frontier-Cloud-Modell, aber das Compliance-Risiko ist null.
Falls ja — Cloud-API (Claude Sonnet, GPT, Gemini Flash) mit Azure OpenAI oder direkt über die API bietet in der Pilotphase bessere Out-of-the-Box-Leistung bei geringerem IT-Aufwand.
Ein detaillierterer Vergleich findet sich im Artikel Lokale LLMs vs. Cloud sowie in der Diskussion RAG vs. Fine-Tuning — wann was.
Erfolgskriterien vor dem Pilotstart
Definieren Sie, was Erfolg bedeutet, vor dem Pilot. Nicht danach. Typische Metriken:
- Eingesparte Zeit pro Aufgabe — Ziel: -30 % oder eine konkrete Minutenzahl
- Antwortgenauigkeit — Ziel: >85 % korrekte Antworten bei Bewertung durch einen Domainexperten (20–50 Testfragen)
- Nutzeradoption — Ziel: >60 % der Teammitglieder nutzen das System mindestens 3× pro Woche nach 4 Wochen
- Fehlerrate — Ziel: <5 % der Antworten enthalten sachlich falsche Informationen
Ohne diese Zahlen endet der Pilot in der Debatte „funktioniert das?" statt in Daten, die mit Ja oder Nein antworten.
Tag 61–90: Ergebnisse, Entscheidung, Plan
Pilotauswertung: drei Fragen
Nach 4–6 Wochen Pilot beantworten Sie drei Fragen:
1. Funktioniert es gut genug? Vergleichen Sie mit der Vor-Pilot-Baseline. Wenn das Ziel erreicht wurde — weiter. Falls nicht — warum nicht? Daten, Prompt, Integration oder war der Use-Case die falsche Wahl?
2. Wird es von den Menschen angenommen? Ein technisch funktionierendes System, das niemand benutzt, hat keinen Geschäftswert. Die Adoption in den ersten Wochen sagt den langfristigen Erfolg voraus. Wenn die Adoption niedrig ist, herausfinden warum — UI, Vertrauen, Schulung, oder spart das System schlicht keine Zeit?
3. Wo ist der größte Widerstand? Jedes KI-Projekt trifft auf „das wird nicht funktionieren". Identifizieren Sie, woher der Widerstand kommt — IT-Sicherheit (Daten), mittleres Management (Kontrolle), Mitarbeiter (Angst vor Jobverlust). Jedes Problem hat eine andere Antwort.
ROI-Kalkulation: einfach, aber ehrlich
Für Entscheidungsträger, die die Fortsetzung rechtfertigen müssen, brauchen Sie Zahlen. ROI von KI-Projekten messen ist ein eigenständiges Thema, aber der grundlegende Rahmen:
- Zeitersparnis: (Stunden/Monat eingespart) × (Stundensatz des Mitarbeiters) × 12 = Jahreswert
- Projektkosten: Infrastruktur + API-Kosten + Ingenieurzeit (Pilot + Produktion)
- Amortisationsdauer: Kosten / monatlicher Wert = Anzahl der Monate bis zur Amortisation
Für einen typischen RAG-Copilot bei 5–10 technischen Mitarbeitern mit einer Einsparung von 30–60 Minuten/Tag: der Jahreswert ist bei mitteleuropäischen Stundensätzen in Zehntausenden Euro messbar. Die Pilotkosten liegen in der Regel 10–30-mal darunter, wenn bestehende Infrastruktur und einige Tage Ingenieurarbeit vorhanden sind.
Build vs. Buy: die Entscheidung am 90. Tag
Nach dem Pilot haben Sie genug Daten für die Build-vs.-Buy-Entscheidung. Faustregeln aus der Praxis:
Kaufen (SaaS-Tool, integriertes Plugin), wenn: der Use-Case generisch ist (Kundensupport, E-Mail-Zusammenfassung), keine kritische Differenzierung vorliegt und das Team keine KI-Engineering-Kapazität hat.
Selbst bauen (eigene RAG-Pipeline, eigener Agent), wenn: Daten sensibel sind und nicht in die Cloud dürfen, der Use-Case domainspezifisch ist (Maschinenbaunormen, interne Prozesse) oder Skalierung auf mehrere Use-Cases geplant ist, bei denen sich gemeinsame Komponenten (Embedding, Vektordatenbank, Orchestrierung) zu teilen lohnen.
Kombinieren — die häufigste richtige Antwort in 2026: kaufen für Commodity-Schichten (Modell-API, Vektordatenbank), bauen für die „letzte Meile" (Prompts, Retrieval-Logik, Integrationen, Eval Harness).
Was zu vermeiden ist: fünf Fallen der ersten 90 Tage
1. Hype-Use-Case ohne Baseline
„Wir wollen Predictive Maintenance" oder „wir wollen eine KI als strategischen Analysten" — ambitioniert, optisch attraktiv und bei genauerem Hinsehen ohne messbare Baseline, ohne historische Daten und ohne Domainexperten im Team. Diese Projekte sterben im dritten Monat.
Regel: Wenn Sie keine Baseline haben, haben Sie eine Ambition, kein Projekt.
2. Vendor Lock-in in der Pilotphase
Manche Anbieter bieten einen „kostenlosen Pilot" im Austausch gegen eine Verpflichtung. Bevor Sie unterschreiben, testen Sie eine Alternative — ein Open-Source-Stack (LangChain/LlamaIndex + Qdrant + lokales Modell) kann die meisten Pilots ohne Bindung umsetzen. Vendor Lock-in ist sinnvoll nach der Validierung eines Use-Cases, nicht davor.
3. KI-Team ohne Domainexperten
Ein KI-Ingenieur kann eine Pipeline bauen. Er kann nicht beurteilen, ob eine Antwort über einen Hydraulikkreis korrekt ist. Ohne einen Techniker oder Technologen, der die Ausgaben im Pilot validiert, haben Sie keine Grundlage für die Genauigkeitsmessung. Der Domainexperte ist kein „Nice to have" — er ist ein Blocker.
4. Ein Pilot gleich Produktionsstrategie
Pilots beweisen ein Prinzip, nicht Produktionsreife. Vom Pilot in die Produktion braucht es: Sicherheitsaudit (Prompt Injection, Daten-Egress), MLOps (Monitoring, Prompt-Versionierung, Eval Regression) und Change Management (Nutzerschulung, SLA, Eskalationsweg, wenn die KI falsch antwortet).
5. EU AI Act ignorieren
Wenn Ihr Use-Case in eine Entscheidungskette mit Einfluss auf Menschen eingreift (Einstellung, Bewertung, Risikoklassifizierung), gelten ab 2. August 2026 die Anforderungen des EU AI Act an Transparenz und Risikoklassifizierung. Compliance ist nicht nur eine juristische Übung — sie beeinflusst die Systemarchitektur (Audit-Log, Explainability, Human Oversight). Je früher Sie das im Design berücksichtigen, desto günstiger ist die Änderung.
Team: wen Sie brauchen und wen nicht
Ein KI-Projekt ist keine Solo-Disziplin. Ein Produktionssystem (nicht nur ein Pilot) erfordert typischerweise eine Kombination aus:
- KI/ML-Ingenieur — RAG-Pipeline, Fine-Tuning, Agenten-Orchestrierung, Eval
- Dateningenieur — Datenpipeline, Bereinigung, Vektordatenbank
- Domainexperte — Validierung der Ausgaben, Erstellung des Eval-Datensatzes
- Product Owner — Erfolgsmetriken, Priorisierung der Use-Cases, Stakeholder Management
- IT/Sicherheit — Daten-Egress, Zugänge, Compliance
Für die Pilotphase ist keine vollständige Besatzung erforderlich. KI-Ingenieur + Domainexperte + Product Owner können einen Pilot stemmen. MLOps und Dateningenieur kommen für die Produktion.
Warnung: Ein Team mit weniger als 3 Personen, die für das KI-Projekt verantwortlich sind, ist selbst für einen Pilot riskant. Ein Ausfall einer Schlüsselperson stoppt das gesamte Geschehen.
Internes Team vs. externer Partner hängt von der Strategie ab: Wenn KI eine langfristige Kernkompetenz des Unternehmens sein soll, intern aufbauen. Wenn Sie schnell 2–3 Use-Cases validieren müssen und keine KI-Kapazität haben, ist ein externer Partner mit festem Projektrahmen schneller. Die Kombination — externer Partner pilotiert, internes Team übernimmt die Produktion — ist ein vernünftiges Hybridmodell.
Messung nach 90 Tagen: vier Fragen zur Retrospektive
Am Ende der ersten 90 Tage beantworten Sie ehrlich:
- 1.Hat der Pilot die Erfolgskriterien erreicht, die wir vor seinem Start definiert haben? (Wenn Sie sie nicht definiert haben — das ist selbst schon eine Lektion.)
- 2.Können wir 2–3 weitere Use-Cases benennen, bei denen dieselbe Infrastruktur weiteren Mehrwert liefert? (Falls nicht — besteht das Risiko, dass wir ohne Strategie pilotieren.)
- 3.Hat das Projekt einen Sponsor auf Führungsebene, der den Geschäftswert formulieren kann? (Projekte ohne CEO/COO-Sponsor scheitern historisch statistisch deutlich häufiger als solche mit.)
- 4.Wissen wir, wie das System in der Produktion aussehen wird — Monitoring, Eval, Update-Zyklus? (Falls nicht — der Pilot ist ein Proof-of-Concept, keine Grundlage für eine Skalierung.)
Diese vier Fragen bewerten nicht die Technologie. Sie bewerten die Organisationsreife — und diese entscheidet über das Ergebnis mehr als jedes Modell.
Häufige Fragen
Was kostet das alles — die ersten 90 Tage?
Das hängt vom Umfang ab, aber als Orientierung: Ein Pilot mit einem RAG-Copilot über interner Dokumentation, auf Cloud-API, mit einem externen Partner — in der Größenordnung von einigen Tausend Euro für Ingenieurstunden zuzüglich niedriger monatlicher API-Kosten (für KMU typischerweise Dutzende bis Hunderte Euro bei normalem Volumen). Eine lokale Einrichtung (eigener Server, Open-Weight-Modell) hat höhere Einmalkosten, aber niedrigere Betriebskosten.
Brauchen wir eine eigene GPU?
Für die Pilotphase in der Regel nicht. Cloud-API (Claude, Gemini Flash, GPT) oder Ollama auf einem vorhandenen Firmenserver mit normaler CPU schafft einen Pilot. Eine eigene GPU macht Sinn, wenn: Daten nicht in die Cloud dürfen, das Inferenzvolumen hoch ist (Tausende Anfragen täglich) oder Fine-Tuning geplant ist.
Was wenn unsere Daten nicht bereit sind?
Datenunbereitschaft ist kein Blocker für einen Pilot — sie ist ein Eingangsparameter. Ein Pilot mit 50 gut vorbereiteten Dokumenten ist besser als ein Pilot mit 5.000 schlechten. Starten Sie mit einem Golden Set von 50–100 Dokumenten, die Sie manuell prüfen. Die Produktionsskalierung lösen Sie nach der Validierung des Use-Cases.
Wie erklären wir den Mitarbeitern, dass wir KI einführen?
Direkt und konkret — nicht „KI übernimmt Ihren Arbeitsplatz", sondern „KI übernimmt die Suche in Handbüchern, damit Sie mehr Zeit für die Problemlösung haben". Binden Sie die Mitarbeiter als „KI-Evaluatoren" in den Pilot ein — ihre Aufgabe ist es, das System zu testen und Fehler zu melden. Ownership des Pilots reduziert den Widerstand gegen die Produktion.
Ist es besser, mit einem großen Projekt oder mehreren kleinen Pilots zu starten?
Aus der Praxis: Ein gut gewählter Pilot mit klarem ROI ist besser als drei parallele Experimente. Parallele Pilots zerstreuen die Aufmerksamkeit, verschlechtern die Datenqualität für jeden einzelnen und erschweren die Auswertung. Skalieren Sie auf mehrere Use-Cases nach dem ersten Erfolg — nicht davor.
*MP Industrial Solutions begleitet Unternehmen strukturiert durch die ersten 90 Tage — von der Use-Case-Inventur über die Architekturwahl bis zur Definition messbarer Erfolgskriterien. Wenn Sie überlegen, wo Sie anfangen sollen, und Pilots vermeiden möchten, aus denen nichts wird, sitzen wir gerne zu einer kostenlosen Erstberatung zusammen.*