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.

Woche 1: Prozess-Audit und Auswahl des Umfangs#

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.

Woche 2: Datenvorbereitung und Architekturdesign#

Dieser Plan setzt eine maßgeschneiderte Entwicklung voraus – RAG, einen Klassifikator oder einen Agenten auf euren Daten. Wenn ein fertiges Produkt (ChatGPT, Copilot, ein Branchen-SaaS) den Prozess 1:1 abdeckt und du weder Integration noch Kontrolle über die Daten benötigst, kaufe es, statt zu bauen – vergleiche die Entscheidung im Entscheidungsbaum eigener Assistent oder fertige Lösung oder in der Analyse eigener vs. fertiger Assistent.

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.

Woche 3: Entwicklung und erste Tests#

Diese vierwöchige Abfolge setzt die einfachste Architektur aus der Tabelle oben voraus – RAG-FAQ oder einen Klassifikator (1–2 Wochen Bau). Bei der Extraktion aus Dokumenten (2–4 Wochen) oder einem mehrstufigen Agenten (3–6 Wochen) sind Woche 3–4 der Start von Bau und Pilot in einer Testumgebung, während der Gang auf begrenzten Produktions-Traffic sich entsprechend um 1–4 Wochen verschiebt – im Einklang mit den Spannen aus Tabelle und FAQ.

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 DSGVO-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 beantwortet 60–70% des vorbereiteten Testsets korrekt (kontrollierte, repräsentative Fälle). Der Rest wird eskaliert. Das ist ein gutes Ergebnis in dieser Phase – bedenke aber, dass im Live-Betrieb der Anteil der vollständig automatisch abgeschlossenen Fälle niedriger ausfällt als im Testset, weil reale Anfragen breiter und verrauschter sind. Du suchst nicht nach Perfektion, sondern nach der Überprüfung der Hypothese.

Woche 4: Produktion, Messung und Entscheidung über Skalierung#

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:

Rechne die vollen Kosten pro Fall, nicht nur die Infrastruktur: Bei 30–40% Eskalation stammt die Ersparnis aus dem automatisierten Teil, während du in die TCO die Menschen einrechnest, die Eskalationen bearbeiten und die Wissensbasis pflegen (siehe TCO). Erst diese voll belastete Größe vergleichst du mit den voll belasteten Kosten manueller Arbeit.

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 – die Formel ist transparent und wiederholbar, und das Ergebnis ist nur so gut wie deine Eingaben (Stundenzahl, Stundensatz, realistischer Automatisierungsanteil).

Was nach 30 Tagen kommt: der Wartungsrhythmus#

Der Pilot ist nicht das Ende – aber auch nicht der Beginn eines „ewigen Kostenfaktors“. Nach der Stabilisierung folgt die Wartung einem vorhersehbaren Rhythmus:

• Wer: Der in Woche 1 benannte Systemverantwortliche kümmert sich um die laufende Wartung, nicht das Projektteam.
• Wissensaktualisierung: Die RAG-Wissensbasis oder die Klassifikator-Beispiele werden zyklisch aufgefrischt (z. B. monatlich oder nach jeder wesentlichen Änderung am Prozess oder Angebot) – ein paar Stunden Arbeit, kein neues Projekt.
• Qualitätsüberwachung (Drift): Du verfolgst weiterhin dieselben Metriken aus Woche 4 (% automatisiert, % Fehler, % Eskalationen) aus den Observability-Logs; eine steigende Eskalationsrate ist ein Signal, dass die Daten veraltet sind.
• Guardrail-Retests: Nach jeder Modell- oder Prompt-Änderung wiederholst du die Sicherheits-Testbatterie (Injection, thematischer Rahmen, Vertrauensschwelle), bevor die Änderung in Produktion geht.
• Kosten: Nach der Stabilisierung dominieren die Infrastruktur- und Modellkosten pro Fall (berechenbar im ROI-Rechner) plus der vorhersehbare Aufwand des Verantwortlichen – kein steigender „ewiger Kostenfaktor“, solange der Umfang eng bleibt.

Was tun, wenn der Pilot nicht liefert#

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% oder mehr der FAQ-Fälle eskaliert – deutlich über der akzeptablen Schwelle –, 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.

Sicherheit und Compliance: Was vor dem Produktionsstart vorhanden sein muss#

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

DSGVO 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 DSGVO 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, der ab dem 2. August 2026 gilt. Es lohnt sich, ihn von Anfang an umzusetzen – die Umsetzung ist einfach (ein Satz in der ersten Nachricht), und das Weglassen nach diesem Datum ist ein Verstoß.

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

Wie man die Einsatzbereitschaft vor dem Start bewertet#

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.

Live ausprobieren#

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):

FAQ#

Wie lange dauert die erste AI-Einführung?#

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.

Brauche ich viele Daten, um anzufangen?#

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.

Was kostet die AI-Einführung in den ersten 30 Tagen?#

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.

Muss ein AI-System Kunden darüber informieren, dass es ein Bot ist?#

Ja. AI Act Art. 50 verlangt, dass jedes System, das mit Menschen interagiert, diese zu Beginn der Kommunikation darüber informiert; diese Pflicht gilt ab dem 2. August 2026 (am 2. Februar 2025 traten die früheren Verbote nach Art. 5 und die Pflicht zur AI-Kompetenz nach Art. 4 in Kraft). 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.

Was, wenn der Pilot nicht die erwarteten Ergebnisse bringt?#

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.