Home › Blog › Zu viel KI-Automation kann Business zerstören

Warum zu viel KI-Automation dein Business zerstören kann

02.04.2026 · aktualisiert 05.08.2026 · Ruben Schilken · 8 Min. Lesezeit

Der Ratschlag lautet überall gleich: automatisiere alles, die KI übernimmt, du lehnst dich zurück. Was in diesen Anleitungen fehlt, ist die Frage, was passiert, wenn das System etwas Falsches tut – und zwar schnell, in Serie und ohne dass jemand hinsieht.

Dieser Text beantwortet sie mit vier Zwischenfällen aus unserem eigenen Betrieb. Alle vier sind echt, drei davon gehen auf unsere Kappe, und jeder hat zu einer Regel geführt, die heute technisch erzwungen wird.

Das eigentliche Risiko ist nicht der Fehler

Ein Agent, der sich irrt, ist kein Problem – ein Mitarbeiter irrt sich auch. Das Problem ist die Kombination aus Geschwindigkeit, Serie und fehlender Bremse. Ein Mensch, der eine Datei falsch bearbeitet, merkt es an der zweiten. Ein Agent bearbeitet in derselben Zeit hundert.

Vier Zwischenfälle, vier Lehren

1. Der Agent, der Wissen „aufgeräumt“ hat

Ein Agent kürzte die zentrale Übergabedatei eines Arbeitsbereichs von 118 auf 59 Zeilen. Er hatte nichts Falsches getan – im Gegenteil, er hatte zusammengefasst, wie man es ihm beigebracht hatte. Verloren gingen dabei die Liste bereits widerlegter Annahmen, sechs von acht dokumentierten Schnittstellen-Fallstricken und mehrere Warnungen vor Messfehlern. Also genau das Wissen, dessen einziger Zweck es ist, Arbeit nicht zweimal zu machen.

Lehre: Zusammenfassen ist eine Standardneigung von Sprachmodellen. Trifft sie auf die eigene Wissensbasis, wird aus Sorgfalt Datenverlust. Heute gilt: ergänzen erlaubt, kürzen verboten – nicht als Bitte im Anweisungstext, sondern als Sperre, die den Schreibvorgang abbricht.

2. Der Bericht, der 75 andere überschrieb

Ein zweiter Agent bekam den Auftrag, eine Sammlung von Berichten zu aktualisieren. Danach waren aus 116 Berichten 41 geworden. Kein Absturz, keine Fehlermeldung – der Auftrag war schlicht so formuliert, dass Überschreiben zulässig war.

Lehre: Schreibrechte auf gemeinsame Bestände gehören nicht an mehrere Beteiligte gleichzeitig. Wer massenhaft produziert, schreibt in ein eigenes Ausgabeverzeichnis; das Zusammenführen macht genau eine Stelle. Und vor jedem Stapellauf wird gesichert.

3. Das Prüfwerkzeug, das sechs Fehler erfand

Ein Diagnosewerkzeug meldete sechs kritische Abweichungen auf Produktionsseiten. Die Nachprüfung an den echten Seiten ergab: keine einzige existierte. Das Werkzeug hatte aus veralteten Zwischenständen geschlossen und die Ergebnisse überzeugend formuliert.

Lehre: Die Ausgabe eines Prüfwerkzeugs ist ein Verdacht, kein Befund. Vor jeder Handlung wird gegen die Wirklichkeit gegengeprüft – bei uns heißt das: frischer Abruf der Live-Seite, nie ein Zwischenspeicher älter als ein paar Stunden.

4. Der Assistent, der eine bezahlte Software löschen wollte

Der jüngste Fall, und er betrifft mich selbst. Bei einer Sicherheitsprüfung im August 2026 kam ein Assistent – mit meiner Zustimmung im Rücken – zu dem Schluss, auf dem Arbeitsrechner laufe kein Virenschutz, und begann mit der Deinstallation einer bezahlten Schutzsoftware. Der Befund war falsch, gleich doppelt: Die Prüfmethode passte nicht zur Funktionsweise des Produkts, und die Suche lief gegen Bauteilnamen einer alten Programmversion. Der Beweis, dass die Software einwandfrei arbeitete, lag die ganze Zeit als Protokolldatei auf derselben Platte.

Gestoppt wurde es nicht durch das System, sondern durch einen Menschen, der widersprach.

Lehre – und heute unsere wichtigste Regel: Je schwerer eine Handlung rückgängig zu machen ist, desto härter muss ihre Begründung belegt sein. Ein negatives Ergebnis aus einer einzigen Methode ist kein Beweis für Abwesenheit. Es kann auch bedeuten, dass die Methode nicht passt.

Die vier Stufen – und wo die Grenze verläuft

1. Beobachten. Der Agent liest, misst, meldet. Kein Risiko, jederzeit automatisch.
2. Vorbereiten. Er entwirft, schlägt vor, legt zur Prüfung. Immer noch harmlos, weil nichts wirksam wird.
3. Ausführen mit Netz. Er ändert etwas, aber umkehrbar: mit Sicherung, mit Protokoll, in einem eigenen Bereich.
4. Ausführen ohne Netz. Veröffentlichen, versenden, löschen, bezahlen, Rechte ändern. Hier endet die Automatisierung.

Die meisten Anleitungen behandeln Stufe 1 bis 3 und tun so, als sei Stufe 4 nur eine Frage besserer Modelle. Sie ist es nicht. Sie ist eine Frage der Zuständigkeit.

Fünf Bremsen, die sich in der Praxis bewährt haben

• Freigabe als eigener Zustand. Nicht „der Agent fragt nach“, sondern ein Arbeitsschritt, den nur ein Mensch weiterschalten kann. Sonst redet sich das System selbst hinein.
• Fail-closed statt fail-open. Fehlt ein Beleg, wird blockiert, nicht durchgelassen. Eine Zahl ohne aktuelle Quelle erscheint nicht – auch wenn sie stimmen dürfte.
• Prüfung von außen. Wer gebaut hat, nimmt nicht ab. Ein System, das seine eigene Arbeit bewertet, findet genau die Fehler nicht, die es gemacht hat.
• Sperren statt Sätze. Muss-Regeln gehören in eine technische Sperre. Anweisungstexte werden mit zunehmender Länge zu einem erheblichen Teil ignoriert – wir gehen von grob der Hälfte aus.
• Ein Schloss gegen Gleichzeitigkeit. Zwei Agenten, die dasselbe anfassen, sind kein theoretisches Problem. Bei uns liefen einmal zwei Aufträge parallel auf demselben Projekt – seitdem gibt es ein zentrales Schloss, ohne das kein schwerer Lauf startet.

Was das mit Wirtschaftlichkeit zu tun hat

Der übliche Einwand: Freigaben kosten Zeit, das frisst die Ersparnis auf. Rechnen wir gegen. Stufe 1 bis 3 lassen sich vollständig automatisieren – das ist der weitaus größte Teil der Arbeit. Übrig bleibt ein Freigabeklick pro Ergebnis, meist Sekunden.

Dem steht der Aufwand gegenüber, den ein einziger unbemerkter Serienfehler verursacht: die Fehlersuche, das Zurückholen, die Nacharbeit an allem, was auf falschen Daten aufbaute. In den vier Fällen oben lag der Aufwand jeweils bei Stunden bis Tagen – und drei davon wären ohne Prüfung erst Wochen später aufgefallen.

Häufige Fragen

Wo genau ziehe ich die Grenze?

An der Umkehrbarkeit, nicht an der Schwierigkeit. Eine komplizierte Analyse darf vollautomatisch laufen. Eine einfache Löschung nicht.

Was, wenn der Agent selbst sagt, es sei sicher?

Dann ist es unerheblich. Die Einschätzung stammt aus derselben Quelle wie der Vorschlag. In Fall 4 war der Assistent von seiner Diagnose vollständig überzeugt – und lag falsch.

Wie fange ich an, ohne alles umzubauen?

Schreib auf, welche Handlungen in deinem Betrieb unumkehrbar sind. Meist sind es weniger als zehn. Alles andere darf automatisch laufen, diese zehn nie ohne Freigabe. Das ist eine Stunde Arbeit und bringt den Großteil des Schutzes.

Was ist das größte Risiko bei KI-Automatisierung?

Nicht dass ein Agent Fehler macht – das tut jeder Mitarbeiter auch. Das Risiko ist, dass er einen Fehler ungebremst und in Serie ausführt, weil niemand definiert hat, welche Handlungen unumkehrbar sind und eine Freigabe brauchen.

Welche Aufgaben sollte man niemals vollautomatisch laufen lassen?

Alles, was nach außen wirkt oder sich schwer zurücknehmen lässt: veröffentlichen, versenden, löschen, Geld ausgeben, Rechte ändern. Diagnose und Vorbereitung dürfen dagegen jederzeit automatisch laufen.

Wie merkt man rechtzeitig, dass ein Agent etwas kaputt macht?

Durch Prüfungen, die nicht der Agent selbst durchführt. Ein System, das seine eigene Arbeit bewertet, findet genau die Fehler nicht, die es gemacht hat. Regelmäßige Momentaufnahmen von Kerndateien und ein Alarm bei ungewöhnlicher Veränderung fangen das ab.

Reicht es, dem Agenten in der Anweisung Regeln mitzugeben?

Nein. Regeln in Textform werden bei langen Anweisungsdateien erfahrungsgemäß etwa zur Hälfte ignoriert. Muss-Regeln gehören in eine technische Sperre, die die Handlung verhindert, statt in einen Satz, der sie verbietet.

Was bedeutet fail-closed bei KI-Systemen?

Fehlt eine Prüfung oder ein Beleg, wird die Handlung blockiert statt durchgelassen. Fehlt zum Beispiel ein aktueller Datenbeleg für eine Zahl, darf sie nicht veröffentlicht werden – auch wenn der Agent sie für richtig hält.