Puffer gegen die KI-Wirklichkeit — Ausfälle, Limits, Abhängigkeiten und technische Unsicherheit einplanen

KI-Projekte verführen zu optimistischen Zeitplänen. Ein Modell antwortet in Sekunden. Ein Agent erledigt in kurzer Zeit Aufgaben, für die früher mehrere Arbeitsschritte nötig gewesen wären. Ein Prototyp entsteht scheinbar über Nacht. Daraus entsteht schnell die Erwartung, dass sich auch das gesamte Projekt in dieser Geschwindigkeit bewegen müsse.

Genau hier beginnt ein gefährlicher Denkfehler. Die Geschwindigkeit einer einzelnen KI-Interaktion ist nicht die Geschwindigkeit eines belastbaren Projekts.

Zwischen einer Idee und einem verlässlichen Ergebnis liegen weiterhin Abhängigkeiten: Dienste müssen verfügbar sein, Zugänge funktionieren, Dateien in den vorgesehenen Kontext passen, Schnittstellen erreichbar bleiben, Modelle das benötigte Verhalten liefern, Menschen Entscheidungen treffen können und externe Module rechtzeitig bereitstehen. Ein Projekt, das nur unter idealen Bedingungen funktioniert, ist deshalb kein schnelleres Projekt. Es ist ein fragileres Projekt.

Professionelle KI-Projektplanung braucht neben Scope und Aufgabenplan eine zweite Ebene: Resilienzplanung. Sie beantwortet nicht nur, was wann passieren soll, sondern auch, was geschieht, wenn der geplante Weg vorübergehend nicht funktioniert.

Der ideale Ablauf ist nur eine Hypothese

Ein klassischer Projektplan stellt häufig eine Reihenfolge dar: Aufgabe A wird abgeschlossen, danach beginnt B, anschließend C. In der Realität entstehen jedoch Wartezeiten, Rückfragen, technische Blockaden und neue Erkenntnisse. Bei KI-Projekten kommt eine zusätzliche Klasse von Unsicherheit hinzu: Ein erheblicher Teil der Arbeitsfähigkeit liegt außerhalb des direkten Einflussbereichs des Teams.

Ein Cloud-Dienst kann nicht erreichbar sein. Ein Konto kann ein Nutzungs- oder Kapazitätslimit erreichen. Eine Funktion kann sich anders verhalten als am Vortag. Ein Modell kann einen langen Kontext schlechter verarbeiten als erwartet. Eine Integration kann nach einem Update brechen. Ein benötigtes Generierungs-, Video- oder Analysemodul kann noch nicht verfügbar sein. Selbst wenn jede einzelne Störung selten ist, wächst mit jeder zusätzlichen Abhängigkeit die Wahrscheinlichkeit, dass irgendwann irgendetwas blockiert.

Deshalb sollte ein Zeitplan nicht mit der Frage beginnen: „Wie schnell könnten wir unter perfekten Bedingungen fertig sein?" Die bessere Frage lautet: „Wie schnell können wir unter realistischen Bedingungen zuverlässig liefern?"

Diese Verschiebung verändert die Planung fundamental. Puffer ist dann keine Sicherheitsmarge, die am Ende irgendwie ergänzt wird. Puffer wird Teil der Architektur.

Puffer ist nicht gleich Puffer

Wenn Projektteams über Reserven sprechen, meinen sie oft nur zusätzliche Tage im Terminplan. Das reicht bei KI-Projekten nicht. Unterschiedliche Unsicherheiten benötigen unterschiedliche Formen von Reserve.

Diese Puffer sind miteinander verbunden. Wenn ein Dienst ausfällt, entsteht zunächst ein technisches Problem. Fehlt ein Alternativweg, wird daraus ein Zeitproblem. Muss kurzfristig auf einen teureren Dienst gewechselt werden, wird daraus zusätzlich ein Kostenproblem. Können Projektdateien nicht schnell migriert werden, wird das technische Problem schließlich zum Kontextproblem.

Resilienz entsteht deshalb nicht durch einen großen allgemeinen „Sicherheitspuffer", sondern durch eine gezielte Reserve an den Stellen, an denen das Projekt verwundbar ist.

Technische Abhängigkeiten gehören in den Projektplan

Viele KI-Projekte behandeln Tools wie neutrale Werkzeuge. Im Projektplan steht dann beispielsweise „Video generieren", „Daten analysieren" oder „Agent führt Recherche aus". Ob die dafür benötigte Plattform verfügbar ist, welche Limits gelten oder welche Alternative existiert, bleibt implizit.

Das ist vergleichbar mit einem Bauprojekt, das den Einsatz eines Krans einplant, aber weder prüft, ob der Kran verfügbar ist, noch was bei einem Defekt geschieht.

Sobald ein Tool für einen kritischen Arbeitsschritt notwendig ist, wird es zu einer Projektabhängigkeit. Damit sollte mindestens klar sein, wie kritisch die Abhängigkeit ist, wie lange ein Ausfall toleriert werden kann, ob ein funktionaler Ersatz existiert und welche Artefakte für einen Wechsel portabel sein müssen.

Nicht jede Abhängigkeit braucht vollständige Redundanz. Für einen experimentellen Nebenschritt kann es ausreichend sein, einen Tag zu warten. Bei einem Kundenmeilenstein kann dieselbe Wartezeit unvertretbar sein. Resilienz ist deshalb keine Maximalforderung. Sie ist risikoadäquat.

Ausfall ist kein Ausnahmezustand

Ein wichtiger Mentalitätswechsel besteht darin, technische Ausfälle nicht als überraschende Sonderfälle zu behandeln. Wer KI-Dienste regelmäßig nutzt, muss damit rechnen, dass einzelne Funktionen zeitweise nicht verfügbar sind. Das muss keine Katastrophe sein. Problematisch wird es erst, wenn die gesamte Projektlogik an genau diesem einen Pfad hängt.

Ein belastbares Projekt unterscheidet deshalb zwischen Funktionsziel und Werkzeug. Das Funktionsziel kann etwa lauten: „Eine belastbare Zusammenfassung der Kundeninterviews erstellen." Das Werkzeug ist nur die aktuell bevorzugte Methode dafür. Fällt dieses Werkzeug aus, bleibt das Funktionsziel bestehen.

Damit entsteht eine einfache Fallback-Leiter. Zuerst wird geprüft, ob derselbe Arbeitsschritt später nachgeholt werden kann, ohne den kritischen Pfad zu blockieren. Falls nicht, wird eine alternative Plattform oder ein lokaler Prozess genutzt. Wenn auch das nicht sinnvoll ist, wird die Arbeit umgeordnet: Eine unabhängige Aufgabe wird vorgezogen, während der blockierte Schritt wartet. Erst wenn keine dieser Optionen funktioniert, wird der Terminplan tatsächlich verschoben.

Die wichtigste Eigenschaft eines Fallbacks ist daher nicht, dass er identisch zum Primärweg ist. Er muss den Projektfluss erhalten.

Alternative Anbieter sind noch keine echte Redundanz

Ein häufiger Fehler besteht darin, mehrere KI-Tools automatisch als Resilienz zu interpretieren. Drei Anbieter im Browser bedeuten aber nicht zwingend drei unabhängige Wege. Sie können dieselbe externe Schnittstelle verwenden, dieselbe Datenquelle benötigen, vom gleichen Authentifizierungsprozess abhängen oder dasselbe Dateiformat voraussetzen. Auch organisatorisch kann eine scheinbare Alternative unbrauchbar sein, wenn niemand vorbereitet hat, wie Projektkontext und Arbeitsstand übertragen werden.

Echte Redundanz beginnt deshalb mit der Frage: Welche Abhängigkeit fällt tatsächlich weg, wenn wir wechseln?

Wenn nur die Oberfläche wechselt, die kritische Abhängigkeit aber bestehen bleibt, handelt es sich um kosmetische Redundanz. Eine belastbarere Architektur kann dagegen unterschiedliche Ebenen kombinieren: einen bevorzugten Cloud-Dienst, eine zweite funktionale Alternative, einen lokalen oder manuellen Minimalpfad und eine Arbeitsplanung, die bestimmte Aufgaben zeitweise umordnen kann.

Das Ziel ist nicht, jede Funktion vierfach vorzuhalten. Das Ziel ist, einen Single Point of Failure dort zu vermeiden, wo sein Ausfall das ganze Projekt stoppt.

Kontextportabilität ist ein Resilienzfaktor

Einer der unterschätztesten Engpässe liegt nicht in Rechenleistung, sondern im Projektgedächtnis. Ein KI-Projekt kann technisch mehrere Alternativen besitzen und trotzdem nicht wechseln, weil der relevante Kontext nur in einem bestimmten Chat, Workspace oder proprietären Projektbereich existiert.

Dann ist das eigentliche Abhängigkeitsproblem nicht der Anbieter. Es ist die fehlende Portabilität des Arbeitsstands.

Deshalb sollte der kanonische Projektzustand außerhalb einzelner Dialoge rekonstruierbar bleiben. Dazu gehören mindestens Ziel, aktueller Scope, zentrale Entscheidungen, offene Fragen, verwendete Quellen, relevante Artefakte und der momentane Arbeitsstand. Das bedeutet nicht, dass jeder Chat vollständig archiviert werden muss. Entscheidend ist, dass ein neues System oder ein anderes Teammitglied den Projektstand wieder aufnehmen kann, ohne die gesamte Geschichte erraten zu müssen.

Gerade bei Kontext- und Dateigrenzen wird diese Disziplin wichtig. Plattformlimits ändern sich, unterscheiden sich zwischen Modi und können je nach Datei- oder Kontextgröße früher spürbar werden als erwartet. Ein robustes Projekt reagiert darauf nicht erst, wenn nichts mehr hineinpasst. Es konsolidiert Quellen, trennt Rohmaterial von Arbeitswissen und hält die wirklich entscheidenden Projektinformationen kompakt genug, um sie übertragen zu können.

Damit wird gute Kontextpflege zu einer Form von Business Continuity.

Ein voller Plan ist kein effizienter Plan

KI macht Parallelität attraktiv. Mehrere Agenten können gleichzeitig recherchieren, schreiben, testen oder analysieren. Das sieht nach maximaler Auslastung aus. Doch ein System, dessen gesamte Kapazität ständig belegt ist, besitzt keine Reserve für Abweichungen.

Sobald ein Agent Rückfragen produziert, ein Review länger dauert oder ein Arbeitspaket neu bearbeitet werden muss, entsteht ein Rückstau. Weitere Agenten erzeugen gleichzeitig neue Ergebnisse. Das Projekt wird nominell schneller, operativ aber langsamer, weil die Verarbeitungskapazität für Prüfung und Entscheidungen nicht mitwächst.