Ich merke bei vielen KI-Workflows ein Muster, das mich mehr interessiert als die nächste Modellankündigung.

Am Anfang sieht alles nach Entlastung aus. Ein Modell antwortet schnell. Ein Agent kann Dateien lesen. Ein Chatbot schreibt Texte, sortiert Ideen oder fasst Dokumente zusammen. Die Demo funktioniert.

Und dann kommt der Alltag.

Plötzlich besteht die Aufgabe nicht mehr nur aus der Aufgabe. Sie besteht aus Prompting, Kontextsuche, Nachkontrolle, Korrekturen, neuen Prompts, kleinen Hilfsdateien und der Frage, ob das Ergebnis überhaupt belastbar ist.

Dann ist keine Automatisierung entstanden.

Dann ist eine neue Arbeitsschicht entstanden.


Die Demo misst den falschen Moment

Viele KI-Demos messen den Moment, in dem das Modell antwortet.

Das ist verständlich. Es sieht gut aus. Vorher musste jemand eine E-Mail schreiben, einen Bericht lesen oder eine Liste sortieren. Jetzt tippt jemand eine Anweisung ein und nach wenigen Sekunden kommt etwas zurück.

Aber das ist nicht der ganze Prozess.

Der ganze Prozess beginnt früher und endet später. Vorher muss jemand wissen, welche Informationen das Modell braucht. Jemand muss den Kontext beschaffen. Jemand muss das Ergebnis prüfen. Jemand muss Fehler finden, Quellen nachziehen, Formate korrigieren und entscheiden, ob der Output wirklich genutzt werden darf.

Wenn man diese Arbeit nicht mitzählt, sieht KI fast immer produktiver aus.

Im Betrieb zählt aber nicht, wie schnell ein Modell antwortet. Im Betrieb zählt, ob der gesamte Ablauf besser wird.


Die versteckte Arbeit

Ich halte diese versteckte Arbeit für einen der wichtigsten blinden Flecken in vielen KI-Projekten.

Nicht weil KI schlecht wäre. Sondern weil KI oft an der falschen Stelle in den Prozess gesetzt wird.

Ein früher einfacher Vorgang kann mit KI länger werden, wenn der Mensch plötzlich alles um das Modell herum betreuen muss. Er schreibt Prompts. Er füttert Kontext. Er erstellt Markdown-Dateien, damit der Agent nicht den Faden verliert. Er prüft Quellen. Er repariert Formatfehler. Er erklärt dem System dieselbe Sache immer wieder.

Das kann nützlich sein.

Aber es ist nicht automatisch Entlastung.

Es ist betreutes Arbeiten mit einem sehr schnellen Werkzeug, das viel kann und trotzdem dauernd Führung braucht.

An dieser Stelle wird aus einem technischen Thema ein organisatorisches.


Produktivität ist nicht gleich verteilt

Es gibt gute Gründe, KI nicht vorschnell abzuschreiben.

Die NBER-Studie “Generative AI at Work” von Erik Brynjolfsson, Danielle Li und Lindsey Raymond untersuchte 5.179 Customer-Support-Agents. Der durchschnittliche Produktivitätsgewinn lag dort bei 14 Prozent. Bei neuen und weniger erfahrenen Beschäftigten lag der Effekt sogar bei 34 Prozent. Bei erfahrenen und hochqualifizierten Beschäftigten war der Effekt dagegen minimal.

Das ist ein wichtiger Befund.

KI kann helfen, wenn die Aufgabe klar genug ist, wenn der Kontext passt und wenn das System gute Arbeitsmuster in einen wiederholbaren Ablauf bringt. Gerade weniger erfahrene Menschen können davon profitieren, weil ein Modell ihnen etwas von der Routine erfahrener Kollegen zugänglich macht.

Aber daraus folgt nicht, dass KI überall Arbeit spart.

METR hat 2025 erfahrene Open-Source-Entwickler an eigenen Repositories untersucht. In diesem Setting waren die Entwickler mit frühen 2025er-KI-Werkzeugen 19 Prozent langsamer als ohne KI. METR markiert dieses Ergebnis selbst als Momentaufnahme, nicht als ewige Wahrheit. Trotzdem ist es für die Praxis wertvoll.

Es zeigt: Je kontextreicher, erfahrungsabhängiger und prüfintensiver eine Aufgabe ist, desto eher kann KI zusätzlichen Aufwand erzeugen.

Meine Schlussfolgerung daraus ist einfach: Die Frage lautet nicht, ob KI produktiv macht. Die Frage lautet, bei welcher Aufgabe, für wen, mit welchem Prozess und zu welchem Prüfaufwand.


KI als Mitarbeiter ist eine gefährliche Abkürzung

Ich verstehe, warum viele von KI-Mitarbeitern sprechen.

Die Metapher ist eingängig. Ein Mitarbeiter bekommt ein Ziel, versteht den Kontext, führt Arbeit aus, meldet Probleme und verbessert sich mit Erfahrung.

Nur ist ein KI-Agent kein Mitarbeiter.

Ein Mitarbeiter trägt Verantwortung. Ein Mitarbeiter hat Erfahrung, situatives Urteilsvermögen, soziale Rückkopplung und rechtliche Einbettung. Ein KI-Agent hat Prompts, Kontextfenster, Wahrscheinlichkeiten, Tool-Zugriffe und Systemgrenzen.

Das ist nicht dasselbe.

Wenn man die Metapher zu wörtlich nimmt, entsteht ein gefährliches Zwischenwesen. Der Agent ist nicht zuverlässig genug, um wirklich autonom zu arbeiten. Aber er ist komplex genug, dass er dauernd Betreuung braucht.

Dann arbeitet der Mensch für die Automatisierung.

Er bereitet vor, korrigiert nach, prüft Quellen, setzt Grenzen und räumt Fehler auf. Genau das sollte die Automatisierung eigentlich reduzieren.


Der Prozess muss vorher entschieden sein

Ich würde bei KI-Automation nicht mit dem Modell anfangen.

Ich würde mit dem Prozess anfangen.

Was soll passieren? Wo beginnt die Aufgabe? Welche Informationen werden gebraucht? Welche Quellen sind erlaubt? Welche Werkzeuge darf der Agent nutzen? Was ist ein akzeptables Ergebnis? Was muss geloggt werden? Welche Aktion braucht menschliche Freigabe? Wann muss der Agent stoppen?

Das klingt weniger spannend als ein neues Modell.

Es ist aber der Punkt, an dem aus Spielerei Betrieb wird.

Wenn der Prozess selbst unklar ist, kann KI ihn nicht sauber automatisieren. Sie kann ihn höchstens schneller unklar machen. Dann entstehen mehr Zwischenstände, mehr Annahmen und mehr Nachkontrolle.

Ein guter KI-Workflow braucht deshalb nicht zuerst mehr Autonomie.

Er braucht Grenzen.


Kleine Werkzeugkästen sind oft besser

In der IT-Sicherheit ist das kein neuer Gedanke.

Rechte so weit wie nötig, so eng wie möglich. Keine unnötigen Zugriffe. Keine Werkzeuge ohne Zweck. Keine Aktion ohne Nachweis, wenn sie Risiko erzeugt.

Bei KI-Agenten wird dieses Prinzip oft vergessen, weil mehr Fähigkeiten beeindruckender aussehen.

Ein Agent, der eine Rechnung prüfen soll, braucht nicht automatisch E-Mail, Kalender, Browser, Shell, CRM, Dateisystem und Kundendatenbank. Er braucht die Informationen und Werkzeuge, die für diesen konkreten Prozess notwendig sind.

Nicht mehr.

Je größer der Werkzeugkasten, desto größer wird auch die Kontrollfläche. Jeder zusätzliche Zugriff erzeugt neue Fehlerwege. Jede neue Quelle kann falschen Kontext liefern. Jede neue Aktion braucht Logging, Freigabe oder Rollback.

Das ist keine Bürokratie.

Das ist Betriebssicherheit.


Die ehrliche Rechnung

Vor jeder KI-Automation würde ich eine einfache Rechnung machen.

Wie lange dauert die Aufgabe heute manuell?

Wie lange dauert sie mit KI, wenn ich alles mitzähle: Prompting, Kontextsammlung, Prüfung, Korrektur, Dokumentation und Pflege?

Wie häufig läuft der Prozess?

Wie teuer ist ein Fehler?

Wie viel Kontrolle bleibt beim Menschen?

Was muss in drei Monaten noch gepflegt werden, damit der Ablauf nicht zerfällt?

Viele KI-Projekte sehen nur gut aus, weil diese Kosten nicht in der Rechnung stehen. Die Demo zeigt den Moment, in dem etwas funktioniert. Der Betrieb zeigt, ob es tragfähig ist.

Und genau dort entscheidet sich, ob KI entlastet oder beschäftigt.


Was ich daraus mitnehme

Ich bin nicht gegen KI-Automation.

Im Gegenteil. Ich halte sie für einen der spannendsten Bereiche der nächsten Jahre, gerade in Security, Governance, Recherche und Wissensarbeit.

Aber ich glaube nicht, dass gute KI-Automation aus mehr Magie entsteht.

Sie entsteht aus klaren Aufgaben, guten Quellen, kleinen Werkzeugkästen, Review-Gates, Logs, Stop-Bedingungen und der Bereitschaft, den Prozess ehrlich zu messen.

Meine Meinung ist: Wer KI einsetzen will, sollte weniger fragen, was der Agent alles kann.

Er sollte fragen, welche Arbeit der Agent zuverlässig übernehmen darf.

Mit welchen Grenzen.

Mit welchem Nachweis.

Und mit welchem Stopp-Signal.

Erst dann wird aus KI ein Werkzeug, das entlastet.

Nicht eins, das uns beschäftigt.

Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.

Quellen: Brynjolfsson, Li & Raymond, “Generative AI at Work”; METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”.

lyttek.org · gregor@lyttek.org