AI-Einführungsplan Schritt für Schritt: die ersten 30 Tage

Jedes Unternehmen, das „AI einführen“ möchte, steht vor derselben Weggabelung: Man kann drei Monate mit Strategie, Workshops und Ausschreibungen verbringen oder innerhalb von 30 Tagen ein funktionierendes System für einen Prozess starten und echte Daten sammeln. Der zweite Ansatz ist schwieriger, weil er Entscheidungen erfordert – aber er liefert ein Ergebnis, das messbar ist, und nicht nur beschreibbar.

Im Folgenden findest du einen konkreten Plan, Woche für Woche. Das ist kein Verkaufsschema – es ist eine Abfolge von Schritten, die tatsächlich das Risiko reduzieren und den Weg zum ersten messbaren ROI verkürzen.

Die erste Woche dient nicht dem Schreiben von Dokumenten – es geht um Gespräche und Zahlen. Drei Fragen, die du bis Ende der Woche beantworten musst:

Welcher Prozess verbraucht die meisten Stunden und ist wiederholbar? Kategorisierung von Anfragen, Rechnungsfreigabe, Beantwortung von Kunden-FAQs, Datenextraktion aus Dokumenten – das sind typische Kandidaten. Nutze das Tool zur Identifizierung von Prozessen, das hilft, Daten ohne Rätselraten zu sammeln.

Verfügst du über Eingabedaten? RAG arbeitet mit bestehendem Wissen (FAQs, Richtlinien, Anfragehistorie). Ein Klassifikator benötigt Beispiele mit Labels. Du musst nicht alles haben – aber ein enger Ausschnitt der Daten für den ersten Prozess muss existieren.

Wer wird nach der Einführung der Systemverantwortliche sein? Einführungen ohne definierten Ansprechpartner im Unternehmen enden nach einem Quartal mit einem toten System. Bestimme eine Person.

Am Ende der Woche solltest du haben: einen ausgewählten Prozess, eine geschätzte monatliche Stundenzahl (eine Zahl, nicht „viel“), eine Liste der vorhandenen Daten und den Namen des Verantwortlichen. Nutze die Bewertung der Einsatzbereitschaft, um zu prüfen, ob die Organisation ohne infrastrukturelle Blockaden einsatzbereit ist.

Daten sind selten bereit. Sie müssen nicht perfekt sein – aber ausreichend für den Piloten.

Praktische Regel: Wenn du FAQ-Bearbeitung gewählt hast, brauchst du mindestens 50–100 Frage-Antwort-Paare, die 80% der tatsächlichen Anfragen abdecken. Wenn du Klassifizierung gewählt hast, brauchst du einige hundert Beispiele mit korrekten Labels. Wenn du Datenextraktion aus Dokumenten gewählt hast, brauchst du repräsentative Dokumentenproben – nicht unbedingt Tausende.

In derselben Woche wird die Architektur festgelegt. Die häufigste Wahl für die erste Einführung:

Einfache Auswahlregel: Wenn das System nur antworten soll (keine Aktionen ausführen), reicht RAG. Wenn es etwas tun soll (speichern, ändern, senden), braucht es einen Agenten mit Human-Handoff für nicht umkehrbare Aktionen.

Wähle den Technologie-Stack entsprechend der Art der Daten und den Anforderungen an Data Residency – einige Kunden verlangen, dass Daten polnische Server nicht verlassen. In diesem Fall ist das Self-Hosting von Modellen eine Voraussetzung für die Einführung, keine Option.

Die dritte Woche steht im Zeichen des Builds. Ziel: ein funktionierendes System in einer Testumgebung, das du dem Prozessverantwortlichen zeigen und Feedback einholen kannst.

Einige Regeln, die gute von schlechten Einführungen unterscheiden:

PII vor dem Cloud-Modell maskieren. Wenn die Daten Namen, Kundennummern oder Adressen enthalten, müssen sie vor dem Senden an das LLM anonymisiert werden. Das ist keine optionale Zusatzfunktion, sondern eine zwingende Voraussetzung aus RODO-Sicht. Ein Verstoß gegen diesen Schritt kann das Projekt beenden – und das zu Recht.

Guardrails ab dem ersten Tag. Es macht keinen Sinn, ein System ohne Guardrails zu testen, da die Ergebnisse nicht repräsentativ für die Produktion sind. Minimum: thematischer Rahmen, Vertrauensschwelle (unterhalb der Schwelle → Eskalation zum Menschen), Blockade von Instruktionsinjektionen.

Observability von Anfang an, nicht nachträglich. Jeder Modellaufruf sollte einen Log mit (anonymisierter) Anfrage, Antwort, Latenz und Eskalationsstatus hinterlassen. Ohne Logs weißt du nicht, was funktioniert und was nicht.

In der Praxis: Ein am Ende der dritten Woche fertiges System ist eine Version, die 60–70% der Testfälle korrekt bearbeitet. Der Rest wird eskaliert. Das ist ein gutes Ergebnis für die Pilotphase – du suchst nicht nach Perfektion, sondern nach der Überprüfung der Hypothese.

Die vierte Woche steht im Zeichen des produktiven Starts mit begrenztem Traffic und der Sammlung erster realer Daten.

Einführungsmodell: Beginne mit 10–20% des Traffics oder einer Nutzergruppe. Der Rest läuft über den alten (manuellen) Weg. Nach einer Woche hast du einen Vergleich: Wie viele Fälle hat das System ohne menschliches Eingreifen abgeschlossen, wie viele eskaliert, wie war die Bearbeitungszeit, sind Fehler aufgetreten.

Messbare Ergebnisse nach 30 Tagen Pilotbetrieb:

Wenn alle vier Metriken im akzeptablen Bereich liegen, hast du eine Grundlage für die Skalierungsdiskussion. Wenn nicht – die Diagnose ist in den Metriken enthalten: Zu viele Eskalationen deuten auf Datenlücken hin, zu viele Fehler auf Guardrail-Mängel.

Berechne den Return on Investment mit dem ROI-Rechner – das ist deterministische Mathematik, kein Schätzwert.

Einführungen sind nicht immer beim ersten Mal erfolgreich – und das ist normal. Typische Ursachen und Lösungen:

Zu geringer Datenumfang. Wenn das System 70% der Fälle eskaliert, ist die Wissensbasis unvollständig. Abhilfe: Zwei Wochen Datenergänzung und erneute Tests – nicht Projektabbruch.

Zu breiter Umfang des ersten Prozesses. Statt „Automatisierung des Kundenservice“ nimm konkret „Antworten auf Fragen zum Lieferstatus“. Engerer Umfang = höhere Erfolgsquote = schnellerer ROI.

Fehlende Guardrails. Wenn das Modell Fragen außerhalb des Bereichs beantwortet oder Zahlen halluziniert, sind die Guardrails unzureichend konfiguriert. Mehr dazu im Artikel zur Begrenzung von Halluzinationen.

Integration mit dem Quellsystem funktioniert nicht. Der Agent kann CRM, ERP oder die Wissensdatenbank nicht in Echtzeit lesen. Das ist ein infrastrukturelles Problem, kein AI-Problem – gelöst wird es durch Integration via n8n oder direkte API.

Keiner dieser Gründe ist ein Grund aufzugeben. Jeder ist eine Diagnose mit einer konkreten Lösung. Einführungsprobleme sind selten mysteriös – häufiger sind sie einfach undiagnostiziert.

Bevor das System in Produktion geht, müssen drei Punkte geklärt sein – nicht „in Planung“, sondern tatsächlich bereit:

RODO und Datenverarbeitung. Wenn das System personenbezogene Kundendaten verarbeitet, benötigst du eine Informationsklausel, eine rechtliche Grundlage für die Verarbeitung und einen Auftragsverarbeitungsvertrag mit dem Infrastrukturanbieter. Details im Leitfaden zu AI Act und RODO 2026.

AI Act – Risikoklassifizierung. AI-Systeme in Hochrisikobereichen (Rekrutierung, Kreditbewertung, Gesundheit) unterliegen zusätzlichen Pflichten: DPIA, Human-Oversight und Systemregistrierung. Prüfe die Klassifizierung vor der Einführung, nicht danach.

Transparenz. Wenn das System mit Kunden kommuniziert, müssen diese wissen, dass sie mit einer AI sprechen. Das verlangt AI Act Art. 50 ab dem 2. Februar 2025. Die Umsetzung ist einfach – ein Satz in der ersten Nachricht – aber das Weglassen ist ein Verstoß.

Mehr zur Sicherheitsarchitektur von Agenten im Artikel zur Sicherheit von AI-Systemen.

Vor der Einführung lohnt es sich, drei Bereiche zu prüfen:

Daten: Hast du eine Wissensquelle, die indexiert werden kann? Dokumente, FAQs, Anfragehistorie, Preislisten – alles, was der Agent wissen müsste. Keine Daten = kein Kontext = Halluzinationen.

Infrastruktur: Ist die API zu den Quellsystemen (CRM, ERP, Wissensdatenbank) verfügbar? Selbst ein einfacher CSV-Export reicht für den Piloten, aber Live-Zugriff ist für die Produktion notwendig.

Organisation: Gibt es einen benannten Systemverantwortlichen, der Wissensaktualisierungen verwaltet und Eskalationen bearbeitet? AI-Systeme erfordern Wartung wie jede andere Software.

Nutze die Bewertung der AI-Einsatzbereitschaft – ein 10-minütiges Tool, das diese drei Bereiche abfragt und ein konkretes Ergebnis liefert, statt einer allgemeinen Antwort.

Beschreibe deinen Prozess unten, und das Modell zerlegt ihn in Pilotphasen und zeigt, welche Schritte in den ersten 30 Tagen automatisiert werden können (Playground: PII maskiert, keine Speicherung):

Ein Pilot für einen eng definierten Prozess dauert in der Regel 2–4 Wochen von der Datensammlung bis zum funktionierenden System in der Testumgebung. Die vollständige produktive Einführung mit Systemintegration und Sicherheitstests – je nach Komplexität – zwischen 4 und 8 Wochen. Wir geben keine festen Termine an, da der Umfang zwischen Unternehmen stark variiert.

Nein. RAG für Kundenfragen startet mit einigen Dutzend FAQ-Paaren. Ein Klassifikator benötigt einige hundert Beispiele mit Labels. Für den Piloten reicht ein enger Datenausschnitt aus einem Prozess – nicht die gesamte Firmendatenbank. Daten werden iterativ nach jedem Testzyklus ergänzt.

Die Kosten hängen vom Umfang und der Architektur ab. Ein einfacher RAG-Pilot für FAQs hat ein anderes Budget als ein Agent, der sich in CRM und ERP integriert. Berechne deinen Fall mit dem ROI-Rechner oder vereinbare ein Gespräch über das Kontaktformular – wir geben eine Spanne an, sobald wir den konkreten Prozess verstanden haben, nicht mit Standardpreisen.

Ja. Seit dem 2. Februar 2025 verlangt AI Act Art. 50, dass jedes System, das mit Menschen interagiert, diese zu Beginn der Kommunikation darüber informiert. Die Pflicht gilt für in der EU eingesetzte Systeme, unabhängig davon, ob das Unternehmen seinen Sitz in Polen hat. Die Umsetzung ist technisch einfach – eine Zeile in der ersten Nachricht.

Ein gescheiterter Pilot ist eine Diagnose, kein Scheitern. Die häufigsten Ursachen sind: zu geringer Datenumfang (Abhilfe: Wissensbasis ergänzen), zu breiter Prozessumfang (Abhilfe: Fokus auf engeren Anwendungsfall) oder fehlende Guardrails (Abhilfe: Konfiguration von Eskalationsschwellen). Jede dieser Ursachen hat eine konkrete Lösung – wir besprechen sie im Rahmen eines Gesprächs nach dem Piloten.