Stell dir vor, die Werkstatt, die deine Bremsen einbaut, stellt dir gleich selbst das Pickerl aus. Kein:e unabhängige:r Prüfer:in. Keine zweite Meinung. Nur ein freundliches: "Passt schon." Würdest du damit losfahren? Vermutlich nicht.
Bei KI-Agenten machen Unternehmen gerade genau das. Ein internes Team baut den Agenten. Es integriert ihn. Es testet ihn. Es schaltet ihn live. Und danach betreibt es ihn auch noch selbst. Vier Rollen. Eine Instanz. Und dann wundern wir uns, wenn niemand die eigenen blinden Flecken gesehen hat.
Ein Agent liest nicht nur Daten – er liest potenzielle Befehle
Nehmen wir einen ganz normalen Support-Agenten. Er liest E-Mails. Er verarbeitet Tickets. Er schaut vielleicht auf Webseiten oder in Dokumente. Das klingt harmlos. Ist es aber nicht. Denn ein klassisches Softwaresystem trennt relativ sauber zwischen Code und Daten. Ein Agent verwischt diese Grenze. Text ist für ihn nicht nur Information. Text kann auch Anweisung sein. Damit wird jede eingehende Mail, jedes Ticket und jede fremde Webseite potenziell zur Angriffsfläche.
Genau das steckt hinter sogenannter indirekter Prompt Injection. Der:die Angreifer:in muss dem Agenten nicht einmal direkt etwas sagen. Es reicht, eine Anweisung in einer Quelle zu verstecken, die der Agent später liest. Und plötzlich verarbeitet dein System nicht mehr nur fremde Daten. Es verarbeitet fremden Willen.
Das ist kein theoretisches Problem mehr
OWASP führt Prompt Injection als eines der zentralen Risiken für Anwendungen mit großen Sprachmodellen. Und es gibt längst reale Fälle. Bei der als EchoLeak bekannt gewordenen Schwachstelle in Microsoft 365 Copilot konnte eine präparierte E-Mail ausreichen, um einen Angriff auszulösen, ohne dass der:die Nutzer:in bewusst etwas anklicken musste.
Das ist der Moment, an dem aus "unser Chatbot beantwortet E-Mails" plötzlich eine völlig andere Risikoklasse wird. Denn sobald ein Agent handeln darf, reicht es nicht mehr zu fragen: "Antwortet er richtig?" Du musst auch fragen: "Wem gehorcht er eigentlich?"
Wir prüfen Agenten inzwischen wie technische Systeme
Genau deshalb beschäftigen wir uns bei biteme.digital seit Monaten sehr intensiv mit dieser zweiten Ebene. Nicht theoretisch. Operativ. Wir bauen Agenten, aber wir prüfen auch externe Agenten. Wir zertifizieren Systeme für einen definierten Stand. Wir rezertifizieren sie, wenn sich Modelle, Prompts, Wissensstände oder Angriffsmuster verändern. Zu solchen Prüfungen gehören bei uns Prompt-Audits, Halluzinations-Screenings, Prompt-Injection-Tests und Red-Teaming. Wir prüfen also nicht nur, ob ein Agent seine Aufgabe erledigt. Wir versuchen bewusst, ihn aus der Spur zu bringen.
Dafür setzen wir unterschiedliche Modellfamilien gegeneinander ein. Bewusst auch Systeme mit anderer Trainings- und Sicherheitskultur, darunter asiatische Modelle, weil sie andere Schwächen finden und andere Angriffsmuster ausprobieren. Nicht, weil eines grundsätzlich besser wäre. Sondern, weil Vielfalt beim Angreifen ein Vorteil ist. Ein Modell findet die blinden Flecken des anderen. Das ist dieselbe Logik, die wir auch beim Bau unserer Wissenssysteme einsetzen. Selbst-Review zählt nicht.
Das eigentliche Problem ist nicht die Sicherheitslücke
Sicherheitslücken wird es geben. Menschen machen Fehler. Modelle machen Fehler. Entwickler:innen machen Fehler. Die Überraschung ist eher, wie viele Unternehmen gerade Agenten auf reale Prozesse loslassen, ohne unabhängige Abnahme und ohne regelmäßige Nachprüfung.
Das beschäftigt mich zunehmend. Ich halte es für gut möglich, dass wir in den kommenden Monaten größere Vorfälle sehen werden, bei denen produktive Agenten Dinge tun, die niemand vorgesehen hat. Nicht, weil KI plötzlich böse geworden ist. Sondern weil sehr viele Unternehmen gleichzeitig anfangen zu bauen, während Erfahrung, Prüfverfahren und regelmäßige Updates noch fehlen.
Ein Agent wird einmal getestet. Dann läuft er. Monatelang. Während sich außen alles verändert. Neue Modelle. Neue Angriffsmethoden. Neue Datenquellen. Neue Schnittstellen. Warum sollten wir ein dynamisches System einmal prüfen und danach so behandeln, als wäre es eingefroren?
Eine Zertifizierung ist kein Denkmal
Genau deshalb halte ich Rezertifizierung für mindestens so wichtig wie die erste Abnahme. Wir bauen Systeme bewusst mit Zeitpunkten, an denen sie wieder auf den Prüfstand müssen. Nicht, weil der Agent automatisch schlechter geworden ist. Sondern, weil sich seine Umwelt verändert hat. Das Modell dahinter kann wechseln. Sein Verhalten kann sich verändern. Seine Wissensbasis altert. Quellen ändern sich. Und auch die Menschen, die solche Systeme angreifen wollen, lernen dazu.
Eine Zertifizierung kann deshalb immer nur sagen: Für diesen Stand, unter diesen Bedingungen, haben wir dieses System geprüft. Mehr wäre unseriös.
Reife Technik institutionalisiert Misstrauen
Das klingt härter, als es gemeint ist. Aber genau so funktioniert Sicherheit. Du baust ein System nicht und hoffst danach, dass du alles gesehen hast. Du setzt jemanden davor, dessen Aufgabe es ist, dir zu beweisen, dass du etwas übersehen hast. Vier-Augen-Prinzip. Unabhängige Reviews. Penetration Tests. Red Teaming. Audits. Nicht aus Misstrauen gegenüber den Entwickler:innen. Sondern aus Respekt vor ihrer menschlichen Begrenztheit.
Bei uns gilt deshalb ein sehr einfaches Prinzip: Wer baut, prüft nicht allein. Und wer prüft, sollte nicht nur bestätigen, dass alles funktioniert. Er sollte versuchen, es kaputtzumachen.
Wer nur Happy Paths testet, testet zu wenig
Viele KI-Piloten laufen heute ungefähr so ab: Wir geben dem Agenten ein paar vernünftige Aufgaben. Er löst die meisten gut. Alle freuen sich. Go-live. Aber echte Systeme scheitern selten an den vernünftigen Aufgaben. Sie scheitern an der komischen Mail. Am manipulierten Dokument. An der widersprüchlichen Anweisung. An einer neuen Angriffsmethode, die beim letzten Test noch niemand kannte.
Genau deshalb endet unsere Arbeit bei Agenten nicht mit dem Bau – dort beginnt sie eigentlich erst! Prüfung, Zertifizierung, Angriffs-Updates und Rezertifizierung gehören für mich zum System genauso dazu wie Prompt und Oberfläche. Das ist weniger sexy als die nächste spektakuläre Agenten-Demo. Aber genau dort entscheidet sich, ob ein Unternehmen einen Showroom baut oder Infrastruktur.
Bauen ja – selbst freigeben nein
Ich will Unternehmen ausdrücklich nicht davon abhalten, eigene Agenten zu bauen. Im Gegenteil. Viele der wertvollsten Systeme werden aus dem eigenen Unternehmen kommen müssen. Weil dort das Wissen liegt. Die Prozesse. Die Besonderheiten. Aber bauen und Betriebserlaubnis sind zwei verschiedene Tätigkeiten. Die Werkstatt darf deine Bremse einbauen. Sie sollte nur nicht allein entscheiden, ob das Auto danach sicher genug für die Straße ist.
Je mehr Verantwortung wir Agenten geben, desto wichtiger wird diese Trennung. Sie werden lesen. Entscheiden. Priorisieren. Schreiben. Buchen. Auslösen. Vielleicht irgendwann verhandeln. Wer solche Systeme baut, braucht deshalb nicht weniger Mut. Er braucht mehr professionelle Skepsis.
Baut Agenten. Gebt ihnen Verantwortung. Aber gebt ihnen niemals selbst das Pickerl. Und wenn du wissen willst, ob dein Agent gegen meinen Angriff besteht – schick ihn in unser Bootcamp ;)
biteme.digital, Wien. Wir bauen, prüfen und zertifizieren KI-Systeme für Unternehmen. Wenn dich das Thema beschäftigt, melde dich gern bei mir.
www.ahoi.biteme.digital
Kommentare auf LEADERSNET geben stets ausschließlich die Meinung des jeweiligen Autors bzw. der jeweiligen Autorin wieder, nicht die der gesamten Redaktion. Im Sinne der Pluralität versuchen wir, unterschiedlichen Standpunkten Raum zu geben – nur so kann eine konstruktive Diskussion entstehen. Kommentare können einseitig, polemisch und bissig sein, sie erheben jedoch nicht den Anspruch auf Objektivität.
Kommentar veröffentlichen