Künstliche Intelligenz ist in vielen Unternehmen vom Experiment zum Alltagswerkzeug geworden. Zwei aktuelle Meldungen rücken dabei dieselbe Frage in den Mittelpunkt: Lösen KI-Werkzeuge tatsächlich bestehende Probleme – oder erzeugen sie an anderer Stelle neue?

Im t3n-Podcast MeisterPrompter fällt ein teilweise ernüchterndes Zwischenfazit. Genannt werden Halluzinationen, also erfundene, aber plausibel formulierte Antworten von Sprachmodellen, der hohe Ressourcenbedarf solcher Systeme sowie Produktivitätsgewinne, die sich nicht eindeutig beziffern lassen. Das ist keine Absage an KI, aber ein Hinweis darauf, dass der Nutzen je nach Anwendungsfall stark schwankt.

Parallel dazu ein Fall aus der Medienproduktion: Ein KI-Agent soll das Rohmaterial einer kompletten Staffel der Serie „The Challenge Sverige“ gelöscht haben. Die Ausstrahlung der zweiten Staffel war für November geplant, nun muss das Material erneut geschnitten werden. Die Formulierung in der Berichterstattung ist vorsichtig – bestätigt ist der Hergang nicht in allen Details. Als Lehrstück taugt der Vorfall trotzdem.

Autonomie ist kein Selbstzweck

Ein KI-Agent ist ein System, das nicht nur Texte erzeugt, sondern eigenständig Aktionen ausführt: Dateien verschieben, Skripte starten, Schnittstellen aufrufen. Genau hier verschiebt sich das Risiko. Ein falsch formulierter Absatz in einem generierten Text ist ärgerlich und wird im Lektorat gefunden. Eine irreversible Aktion auf einem Produktivsystem ist etwas anderes.

Der entscheidende Unterschied liegt in der Umkehrbarkeit. Solange eine Aktion rückgängig gemacht werden kann, ist ein Fehler ein Zeitverlust. Sobald sie das nicht mehr kann, wird aus dem Fehler ein Schaden. Diese Unterscheidung sollte am Anfang jeder Überlegung stehen, wie viel Autonomie ein KI-Werkzeug im eigenen Betrieb erhält.

Halluzinationen sind ein Prozessproblem

Dass Sprachmodelle Inhalte erfinden, ist technisch bekannt und bisher nicht vollständig gelöst. Für den Projektalltag heißt das: Jede Stelle, an der ein Modell Fakten liefert, braucht eine Prüfinstanz. In der Entwicklung betrifft das generierten Code, der kompiliert, aber falsche Annahmen über eine Schnittstelle enthält. In der Redaktion betrifft es Produktangaben, Zahlen oder Rechtshinweise.

Praktisch bedeutet das nicht, jede KI-Ausgabe doppelt von Hand nachzubauen. Es bedeutet, Prüfungen dorthin zu verlagern, wo sie automatisiert ablaufen können: Tests, Linting, Schema-Validierung, Vier-Augen-Prinzip bei Veröffentlichungen. Wo keine solche Prüfung existiert, ist der KI-Einsatz an dieser Stelle schlicht riskanter, als er auf den ersten Blick wirkt.

Produktivität muss messbar werden

Der Hinweis auf unklare Produktivitätsgewinne verdient besondere Aufmerksamkeit. KI-Werkzeuge fühlen sich schnell an, weil die erste Ausgabe in Sekunden vorliegt. Ob der gesamte Vorgang – inklusive Korrektur, Abstimmung und Nacharbeit – tatsächlich kürzer ist, zeigt erst eine ehrliche Betrachtung des kompletten Ablaufs.

Hilfreich sind dafür einfache, aber konsequent erhobene Kennzahlen:

  • Durchlaufzeit eines typischen Vorgangs vor und nach Einführung des Werkzeugs
  • Anteil der KI-Ergebnisse, der ohne Nacharbeit übernommen werden kann
  • Fehler, die erst spät im Prozess auffallen
  • Aufwand für Betrieb, Lizenzen und Schulung

Ohne solche Zahlen bleibt die Bewertung Geschmackssache – und damit anfällig für Erwartungen, die von außen gesetzt werden.

Backups als Grundbedingung, nicht als Option

Der Fall aus der Serienproduktion erinnert an eine Selbstverständlichkeit, die in der Praxis oft nicht vollständig umgesetzt ist: Ein Backup ist nur dann ein Backup, wenn es getrennt vom Produktivsystem liegt und die Wiederherstellung regelmäßig geprobt wurde. Sobald ein automatisiert handelndes System Schreibrechte auf Daten hat, gilt das doppelt.

Ebenso wichtig sind abgestufte Berechtigungen. Ein Agent, der Inhalte analysieren soll, braucht in der Regel nur Lesezugriff. Ein Agent, der Dateien verwalten soll, braucht keinen Zugriff auf das Archiv. Diese Trennung kostet in der Einrichtung Zeit und spart im Ernstfall ein Projekt.

Ein pragmatischer Rahmen

Für den Einstieg hat sich eine einfache Reihenfolge bewährt:

  1. Anwendungsfall benennen und das Problem beschreiben, das gelöst werden soll – nicht umgekehrt vom Werkzeug her denken.
  2. Prüfen, ob die Ergebnisse überprüfbar sind und wer die Verantwortung trägt.
  3. Zugriffsrechte auf das notwendige Minimum begrenzen.
  4. Rückfallebene definieren: Backup, Versionierung, manueller Weg.
  5. Nach einigen Wochen messen, ob der erwartete Effekt eintritt.

Dieser Rahmen verhindert keine Fehler, aber er begrenzt deren Reichweite. Und er macht die Diskussion über KI im Unternehmen sachlicher, weil sie sich an konkreten Abläufen orientiert statt an allgemeinen Versprechen.

Einordnung für Web- und Softwareprojekte

Für Web- und Softwareprojekte heißt das: KI gehört dort hin, wo Ergebnisse überprüfbar sind und Fehler sich korrigieren lassen – etwa bei Entwürfen, Recherche oder Codevorschlägen mit anschließendem Test. Je weitreichender und unumkehrbarer eine automatisierte Aktion ist, desto strenger müssen Rechte, Freigaben und Backups geregelt sein. Wer diese Leitplanken vor dem Rollout definiert, nutzt die Vorteile, ohne das Projektrisiko unkontrolliert zu erhöhen.

Quellen