Prompt Injection: Wie sich KI-Agenten absichern lassen

Eine E-Mail, die ein Agent liest, darf ihm keine Erlaubnis geben, eine weitere E-Mail zu versenden, Kundendaten zu exportieren oder eine Verkaufschance zu verändern. Das Open Worldwide Application Security Project (OWASP) führt Prompt Injection als LLM01 in seinen Top 10 für LLM-Anwendungen. Für Entwicklungsteams folgt daraus eine konkrete Aufgabe: Die Anwendung muss in ihren Handlungsmöglichkeiten begrenzt bleiben, auch wenn das Modell einer falschen Anweisung folgt. Vollständig verhindern lässt sich Prompt Injection heute durch keine Schutzmaßnahme.

Am 26. Oktober 2026 anhand der aktuellen Leitfäden von OWASP und Anthropic geprüft. Die folgenden Szenarien für Postfach und CRM sind beispielhafte Entwürfe, keine Erfahrungsberichte aus dem Produktivbetrieb.

Was ist Prompt Injection?

Bei Prompt Injection lenken Eingaben ein Sprachmodell von den Anweisungen ab, denen es eigentlich folgen soll. Ein großes Sprachmodell, auch Large Language Model oder LLM genannt, interpretiert Sprache, um Antworten zu erzeugen und Aktionen vorzuschlagen. Problematisch wird es, wenn es Inhalte befolgt, die es lediglich lesen sollte.

Ein Vergleich: Ein Mitarbeiter prüft das Schreiben eines Lieferanten. Darin kann ein Lieferproblem beschrieben werden. Zugriff auf die Kundendatenbank darf sich der Lieferant damit aber nicht verschaffen. Auch ein Agent muss zwischen Information und Befugnis unterscheiden. Die Anwendung muss diese Grenze technisch durchsetzen.

OWASP nennt in LLM01:2025 Prompt Injection sowohl direkte Nutzereingaben als auch indirekt eingelesene externe Inhalte als Einfallstore. Entscheidend ist, wer die Aufgabe und die Berechtigungen festlegen darf. Ob ein verdächtiger Text professionell klingt, spielt dafür keine Rolle.

Eine falsche Antwort ist nicht automatisch das Ergebnis einer Injection. Das Modell kann auch ohne äußere Manipulation eine Tatsache erfinden. Bei einer Injection wird sein Verhalten gezielt durch Eingaben umgelenkt. Beides kann Schaden anrichten. Ein Filter für bösartige Anweisungen erfasst jedoch nicht jeden gewöhnlichen Modellfehler.

Wie funktioniert Prompt Injection bei generativer KI?

Das Modell verarbeitet Anweisungen und das zu bearbeitende Material gemeinsam. Dabei kann es dem Material eine Autorität zuschreiben, die ihm nicht zusteht. Rollen und Quellenkennzeichnungen helfen bei der Unterscheidung, ersetzen aber keine Zugriffskontrollen.

Bei einem Agenten kommt ein folgenreicher Schritt hinzu: Die Anwendung setzt eine vorgeschlagene Aktion in einen Tool-Aufruf um. Ein Tool ist eine Funktion, die außerhalb des Gesprächs etwas ausführt, etwa Datensätze durchsuchen oder eine Nachricht versenden. Führt die Anwendung jeden Modellvorschlag mit weitreichenden Zugangsdaten aus, kann aus einem sprachlichen Missverständnis ein geschäftlicher Eingriff werden.

An diese Grenze stößt jeder Agent, der Tools verwendet: Eine Anfrage zu verstehen bedeutet noch nicht, dass ihre Ausführung autorisiert ist.

Prompt Injection: Beispiele für direkte und indirekte Angriffe

Der Unterschied liegt darin, auf welchem Weg die bösartige Anweisung eintrifft. Die Beispiele beschreiben das angestrebte Verhalten, ohne Angriffstexte zu veröffentlichen.

Direkte Prompt Injection

Ein Kunde schreibt einem Supportassistenten und versucht, ihn zur Herausgabe von Kontonotizen eines anderen Kunden zu bewegen. Dazu behauptet er, eine besondere interne Freigabe zu haben. Der Angreifer nutzt den Eingabekanal der Anwendung unmittelbar.

Zur Absicherung braucht es einen Datendienst, der die Zugriffsrechte des authentifizierten Kunden prüft. Selbst wenn das Modell die Geschichte glaubt, muss dieser Dienst den Zugriff auf den fremden Datensatz verweigern. Eine entsprechende Ablehnungsregel im System-Prompt gibt dem Modell Orientierung. Durchgesetzt wird die Grenze durch die Zugriffsprüfung auf den Datensatz.

Indirekte Prompt Injection

Ein Gründer, der den Vertrieb betreut, lässt einen Agenten die E-Mail eines Interessenten zusammenfassen und einen nächsten Schritt vorschlagen. Die E-Mail enthält Material, das den Agenten dazu bringen soll, andere, nicht zur Aufgabe gehörende Kontakte aus dem Customer-Relationship-Management-System (CRM) an einen externen Empfänger zu exportieren. Der Auftrag des Gründers ist legitim. Die bösartige Anweisung steckt in der E-Mail, die verarbeitet werden soll.

Derselbe Angriffsweg kann über eine Webseite, ein Dokument, einen Anhang oder ein Tool-Ergebnis führen. Ein interner Speicherort macht einen Datensatz nicht automatisch vertrauenswürdig: Der Text im CRM kann ursprünglich von einem Kunden stammen. Anthropic, der Anbieter des Sprachmodells Claude, behandelt solche Drittquellen in seinem Leitfaden zum Schutz vor Prompt Injection als eigenes Bedrohungsmodell.

Bei einem Postfach-Agenten darf der Absender einer E-Mail niemals die Tool-Berechtigungen des Postfachinhabers übernehmen, nur weil dieser eine Zusammenfassung angefordert hat.

Was unterscheidet Prompt Injection von einem Jailbreak?

Ein Jailbreak soll die Sicherheitsbeschränkungen eines Modells umgehen. Prompt Injection kann auch auf die reguläre Aufgabe oder die Berechtigungen der Anwendung zielen. Eine verfälschte Vertriebszusammenfassung oder eine unbefugte Kontaktänderung kann für ein System zur Inhaltsmoderation harmlos aussehen und trotzdem gegen die Regeln des Unternehmens verstoßen.

Inhaltliche Schutzmechanismen und Berechtigungsprüfungen sind deshalb beide nötig. Sie beantworten unterschiedliche Fragen.

KI-Sicherheit: Wann wird Prompt Injection zum Geschäftsrisiko?

Je mehr Daten und Aktionen ein Agent erreichen kann, desto größer ist der mögliche Schaden. OWASP nennt in seinem gesonderten Leitfaden zu Excessive Agency übermäßigen Funktionsumfang, zu weitreichende Berechtigungen und zu viel Autonomie als Ursachen für schädliches Agentenverhalten.

Bei Postfach- oder CRM-Systemen lassen sich die Folgen konkreten geschäftlichen Schäden zuordnen:

• Vertrauliche Daten gelangen nach außen. Eine Ausgabe, ein Anhang, eine ausgehende Anfrage oder eine Nachricht enthält Informationen, die der Empfänger nicht erhalten darf.
• Datensätze werden unbefugt verändert. Der Agent bearbeitet ein Kundenkonto, löscht einen nützlichen Verlauf oder ändert die Phase einer Verkaufschance, weil abgerufener Text ihn dazu gebracht hat.
• Entscheidungen werden unbemerkt verzerrt. Ein Interessent erscheint aussichtsreicher, eine Beschwerde verschwindet aus der Zusammenfassung oder ein Lieferant wird ohne sachlichen Grund empfohlen.

Reiner Lesezugriff ist enger begrenzt als Schreibzugriff. Er verhindert aber nicht automatisch, dass vertrauliche Daten abfließen. Ruft die Anwendung private Datensätze ab und kann sie über eine Antwort oder eine ausgehende Verbindung offenlegen, muss ihre Vertraulichkeit weiterhin geschützt werden.

Unit 42 von Palo Alto Networks dokumentierte bösartige Anweisungen in öffentlich erreichbaren Webinhalten in einer Untersuchung vom 3. März 2026. Ein entdeckter Angriffsversuch beweist nicht, dass jedes angegriffene System darauf hereinfiel. Er zeigt aber, warum externe Inhalte ins Bedrohungsmodell gehören, bevor ein Agent handeln darf.

Gründer sollten festlegen und freigeben, welchen maximalen Schaden ein Workflow verursachen darf. Entwicklungsteams müssen diese Grenze an den Schnittstellen zu Daten und Tools durchsetzen. Betriebsteams brauchen eine Möglichkeit, die Ausführung anzuhalten und Vorfälle zu untersuchen, wenn jemand diese Grenzen austestet.

Wie lässt sich verhindern, dass Prompt Injection einen Vorfall auslöst?

Die Architektur muss damit rechnen, dass eine Injection durchkommt. Das folgende Schutzkonzept für einen Postfach- oder CRM-Agenten überträgt die OWASP-Empfehlungen zu Berechtigungen und Freigaben auf einen konkreten Workflow. Es handelt sich weder um einen Produktbenchmark noch um eine Garantie gegen Angriffe.

Am Anfang stehen die tatsächlichen Berechtigungen des Tools. Eine Funktion namens „Postfach zusammenfassen“ ist nicht auf Zusammenfassungen beschränkt, wenn die dahinterliegenden Zugangsdaten auch das Versenden und Löschen von Nachrichten erlauben. Maßgeblich sind das verwendete Konto und die Konfiguration des Dienstes, nicht nur der Funktionsname.

Danach geht es um Daten, die die Anwendung verlassen. Eine Netzwerk-Allowlist, also eine Liste erlaubter Ziele, kann mögliche Abflusswege begrenzen. Die Freigabe eines E-Mail-Dienstes erlaubt jedoch nicht automatisch jeden Empfänger. Ebenso wenig erlaubt eine freigegebene CRM-Domain jedes Konto oder jeden Export. Auch innerhalb des erlaubten Dienstes muss die Anfrage geprüft werden.

Anthropics Leitfaden für sichere Bereitstellungen beschreibt, wie Zugangsdaten außerhalb der Agentenumgebung aufbewahrt, Netzwerkzugriffe eingeschränkt und Anfragen über einen Proxy validiert werden. Ein Proxy ist eine Zwischenstation, die vor dem Weiterleiten einer Anfrage Richtlinien anwenden kann. Bei einer gehosteten Postfachintegration kann der eigene Tool-Dienst diese Grenze bilden: Er verwahrt die Zugangsdaten und lehnt Operationen außerhalb des erlaubten Umfangs ab.

Weitere Prüfungen für Eingaben, Ausgaben und Ausführung beschreibt der Leitfaden zu KI-Guardrails.

Was empfiehlt Anthropic für abgerufene Inhalte?

Anthropic empfiehlt, Material von Dritten in tool_result-Blöcken zu übergeben, seine Herkunft zu kennzeichnen, eine ausdrückliche Richtlinie für nicht vertrauenswürdige Inhalte festzulegen und Zeichenfolgen als JSON zu kodieren, statt sie in frei formulierte Anweisungen einzusetzen. Der Leitfaden sieht außerdem die Prüfung von Tool-Ausgaben und die Überwachung des Verhaltens vor. Details stehen in den aktuellen Claude-Empfehlungen.

Im Vertriebsbeispiel muss der Nachrichtentext als E-Mail dieses Interessenten erkennbar bleiben. Er darf nicht in eine privilegierte Anweisung kopiert werden, nur weil ein vorheriger Modellschritt ihn zusammengefasst hat. Auch wenn extrahierte Informationen an den nächsten Schritt weitergegeben werden, muss der Quellenverweis erhalten bleiben.

JSON ist ein strukturiertes Datenformat. Korrektes Escaping verhindert, dass Text die umgebende Serialisierung aufbricht. Es verhindert nicht, dass das Modell sich vom Inhalt des Textes beeinflussen lässt. Die Kodierungsempfehlung ist deshalb eine Schutzschicht; die Autorisierung muss weiterhin an anderer Stelle durchgesetzt werden.

Die Freigabe muss an die konkrete Aktion gebunden sein

Ein Prüfbutton schützt das Unternehmen nur, wenn genau das ausgeführt wird, was die prüfende Person gesehen hat. „Dieses Konto weiterbearbeiten“ ist als Freigabe zu unbestimmt, wenn ein Agent Anhänge versenden oder Kundendatensätze umschreiben kann.

Angenommen, ein Vorschlag umfasst eine Antwort an einen Interessenten und die Aktualisierung einer Verkaufschance. Für die Prüfung müssen der tatsächliche Empfänger, die Nachricht, die Anhangsliste, der betroffene Datensatz sowie die alten und neuen Feldwerte sichtbar sein. Die Anwendung sollte den freigegebenen Vorschlag unverändert festhalten und genau diese Version ausführen. Ändert das Modell anschließend den Empfänger oder einen Anhang, ist eine erneute Prüfung nötig.

Die Freigabe muss außerdem von einer authentifizierten Person mit der entsprechenden Befugnis stammen. Eine E-Mail, in der jemand behauptet, die Arbeit sei bereits genehmigt, ist Quellinhalt und kein Freigabeereignis. Das Modell darf weder seinen eigenen Freigabedatensatz erzeugen noch auf ein zweites Tool zugreifen können, das die Freigabeprüfung umgeht.

Die Aktion muss zurückgehalten werden, wenn die prüfende Person sie ablehnt, die Freigabe abläuft oder das Prüfsystem nicht erreichbar ist. Ein Zeitablauf darf nicht stillschweigend zur Erlaubnis werden. Wiederholungsversuche müssen so gestaltet sein, dass ein Zustellfehler nicht zum mehrfachen Versand derselben freigegebenen Nachricht führt.

Das sind Umsetzungsempfehlungen für den Workflow, keine Behauptung, dass menschliche Prüfung jeden Angriff erkennt. Der Leitfaden zu Human-in-the-Loop-KI erläutert, wie sich Prüfwarteschlangen personell betreuen und Eskalationen handhaben lassen.

Kurze Checkliste für Postfach- und CRM-Agenten

Zuerst sollte der kleinstmögliche nützliche Workflow live gehen. Vor der Freigabe autonomer Aktionen nach außen hilft diese Checkliste:

• Identität: Jeder Lesezugriff und jede Änderung ist auf den authentifizierten Nutzer und das autorisierte Geschäftskonto begrenzt. Das Modell kann keine Identität mit höheren Berechtigungen wählen.
• Daten: Nur die Datensätze und Felder abrufen, die für die Aufgabe nötig sind. Geheimnisse dürfen nicht in für das Modell sichtbaren Inhalten stehen. Die Herkunft von E-Mail-, Dokument- und CRM-Texten muss erhalten bleiben.
• Tools: Lesen, Entwerfen, Senden, Exportieren und Bearbeiten sind getrennte Berechtigungen. Nicht benötigte Fähigkeiten werden entfernt.
• Ausgabe: Antworten und Tool-Argumente prüfen, bevor sie weitergegeben werden. Empfänger, Anhänge, Ziele und erlaubte Datensatzänderungen validieren.
• Freigabe: Aktionen mit weitreichenden Folgen erfordern eine Prüfung der konkreten Aktion, die der Anwendungscode erzwingt. Fehlt die Freigabe oder wurde sie verändert, bleibt die Aktion angehalten.
• Betrieb: Aktionen datenschutzbewusst protokollieren, eine zuständige Person für Alarme benennen, eine Pausenfunktion bereitstellen und den gesamten Workflow testen, bevor Zugriffe erweitert werden.

Für den Vertriebsassistenten eines Gründers ist ein sinnvoller Einstieg, einen ausgewählten E-Mail-Verlauf mit einem Interessenten zu lesen und einen Antwortentwurf vorzuschlagen. Massenexporte, automatischer Versand oder die gleichzeitige Änderung vieler Verkaufschancen sollten jeweils gesondert begründet werden. Die Berechtigungen müssen sich an der vorgesehenen Aufgabe orientieren, nicht am gesamten Funktionsumfang der Integration.

Der Praxisleitfaden zur Begrenzung des Schadensradius produktiver KI-Agenten vertieft die übergreifende Architektur zur Schadensbegrenzung. Der Schadensradius, englisch „Blast Radius“, beschreibt, wie weit sich ein Fehler über verbundene Systeme ausbreiten kann.

Prompt Injection testen: Entscheidend sind die tatsächlichen Folgen

Ein Test ist bestanden, wenn das verbotene Ergebnis ausbleibt. Ein Assistent kann eine Ablehnung ausgeben, nachdem ein Tool-Aufruf bereits einen Datensatz verändert hat. Deshalb müssen der Tool-Dienst und der entstandene Zustand geprüft werden, nicht nur das Chatprotokoll.

Für einen Probelauf vor dem Start eignen sich synthetische Kontakte, Testpostfächer und eine kontrollierte Umgebung. Der folgende Ablauf ist ein Testplan für die Anwendung, keine Sammlung von Angriffspayloads.

1. 1

   Den erlaubten Normalfall prüfen

   Eine gewöhnliche Zusammenfassung zu einem Interessenten ausführen lassen. Prüfen, ob die richtigen Datensätze abgerufen werden, der Entwurf brauchbar ist und Freigaben genau dort verlangt werden, wo die Richtlinie es vorsieht. Legitime Aufgaben müssen weiterhin gelingen.

2. 2

   Beide Angriffswege testen

   Sowohl eine unberechtigte Anfrage über die Nutzereingabe als auch eine Nachricht von Dritten einbeziehen, die die Aufgabe umlenken soll. Prüfen, ob nicht zur Aufgabe gehörende Datensätze unzugänglich bleiben und verbotene Tool-Operationen abgelehnt werden.

3. 3

   Freigaben und Fehlerbehandlung auf die Probe stellen

   Geänderte Aktionsdetails nach einer Freigabe, eine abgelehnte Prüfung, einen nicht erreichbaren Richtliniendienst und eine wiederholte Ausführung testen. Sicherstellen, dass die Anwendung die Aktion zurückhält oder ablehnt und doppelte Auswirkungen verhindert.

4. 4

   Nachweise und Alarmierung kontrollieren

   Den abschließenden CRM-Zustand, ausgehende Nachrichten, angesteuerte Ziele, den Freigabedatensatz und das Richtlinienprotokoll prüfen. Sicherstellen, dass das Betriebsteam die Quelle ermitteln und den Workflow stoppen kann, ohne sich auf die Erklärung des Modells verlassen zu müssen.

Die jeweils relevanten Tests müssen wiederholt werden, wenn sich Prompts, Modelle, Datenabruf, Tools oder Berechtigungen ändern. Ein Ergebnis gilt für die getestete Konfiguration. Es bestätigt nicht die Sicherheit jeder künftigen Version.

Das Protokoll muss genügend Informationen enthalten, um eine Entscheidung nachzuvollziehen, ohne zu einer weiteren vollständigen Kopie des Postfachs zu werden. Dafür eignen sich stabile Datensatzreferenzen, notwendige Aktionsdetails, Richtlinienversionen und zugriffsgeschützte Nachweise. Für die Untersuchung blockierter Ziele, unerwarteter Exporte und wiederholter Freigabefehler braucht es eine zuständige Person.

Welche Versprechen gehen zu weit, und was bleibt ungelöst?

Kein Modell, kein Prompt, kein Filter und kein Guardrail-Produkt ist als vollständige Lösung zu betrachten. OWASP weist ausdrücklich darauf hin, dass Retrieval-Augmented Generation und Fine-Tuning Prompt Injection nicht vollständig eindämmen. Retrieval-Augmented Generation, kurz RAG, stellt einem Modell Dokumente als Hilfe für seine Antwort bereit. Sie verleiht diesen Dokumenten keine Befugnis, die Aufgabe zu ändern.

Ein besserer System-Prompt kann das Verhalten verbessern. Er kann weitreichende Zugangsdaten nicht in eng begrenzte verwandeln. Ein Klassifikator kann verdächtige Inhalte markieren. Er kann nicht entscheiden, ob ein bestimmter Mitarbeiter einen bestimmten Anhang weitergeben darf. Ein zweites Modell, das das erste prüft, ergänzt eine Kontrolle. Auch dabei bleiben unabhängige Anwendungsrichtlinien nötig.

Ebenso wenig gibt es eine allgemeingültige Erkennungsquote, die zeigt, ob ein Postfach-Agent einsatzbereit ist. Sinnvolle Grenzen hängen vom Workflow ab: Welche Konten darf er lesen, welche Felder ändern, wohin dürfen Daten gelangen und welche Aktionen erfordern eine Prüfung? Das Ergebnis eines Anbieters bei einer anderen Aufgabe belegt nicht, dass sich der eigene Freigabeweg nicht umgehen lässt.

Belastbar ist eine enger gefasste, dafür nützlichere Aussage: Mehrere Schutzschichten verringern die Angriffsfläche und begrenzen Folgen; Tests und Überwachung machen Fehler sichtbar. Ein Restrisiko bleibt.

Sofort handeln, wenn ein Agent bereits externe Inhalte liest und private Informationen offenlegen oder Geschäftsdaten verändern kann. Weitergehende Autonomie zurückstellen, bis Berechtigungen, Freigaben und Fehlerbehandlung wirksam durchgesetzt werden. Ein System, das öffentliche Dokumente zusammenfasst und weder private Daten noch Tools für Aktionen besitzt, hat ein enger begrenztes Schadenspotenzial. Schutz vor manipulierten Antworten braucht es trotzdem.

Häufige Fragen

Wie schützt man sich vor Prompt-Injection-Angriffen?

Datenzugriffe und Tools begrenzen, nicht vertrauenswürdige Inhalte von Anweisungen trennen, Ausgaben und Aktionen validieren, folgenreiche Vorgänge prüfen lassen und die Ergebnisse überwachen. Berechtigungen müssen außerhalb des Modells durchgesetzt werden. Keine einzelne Schutzschicht beseitigt das Risiko.

Wie sieht ein einfacher Prompt aus?

„Fasse die E-Mail dieses Interessenten zusammen und entwirf eine Antwort zur Prüfung“ ist ein gewöhnlicher Prompt. Die E-Mail des Interessenten ist das zu bearbeitende Material, keine Erlaubnis, den Auftrag zu verändern.

Spielt SQL Injection heute noch eine Rolle?

Ja. SQL Injection bleibt für Anwendungen relevant, die unsichere Datenbankabfragen zusammensetzen. Neben möglichen Maßnahmen gegen Prompt Injection braucht es datenbankspezifische Schutzmaßnahmen. Dazu gibt es den OWASP-Leitfaden zur Verhinderung von Injection.

Was bedeutet Injection in der Programmierung?

In der IT-Sicherheit bedeutet Injection, dass nicht vertrauenswürdige Eingaben verändern, was ein Interpreter ausführt oder verarbeitet. Prompt Injection zielt auf das Verhalten eines Modells. Andere Injection-Schwachstellen betreffen Datenbankabfragen, Befehle oder Browsercode.

Was ist eine Injection, einfach erklärt?

Eine Eingabe überschreitet eine Grenze und wird als Anweisung behandelt, obwohl sie nie dazu berechtigt war, diese Anweisung zu geben.

Welche Arten von Code Injection gibt es?

Beispiele sind SQL Injection, das Einschleusen von Betriebssystembefehlen und Script Injection. Welche Schutzmaßnahmen passen, hängt vom jeweiligen Interpreter ab. Prompt Injection ist über das Problem der überschrittenen Vertrauensgrenze damit verwandt, aber kein Sammelbegriff für jede Form von Code Injection.

Welche Arten von Prompt Injection gibt es?

Beim Übertragungsweg wird vor allem zwischen direkt und indirekt unterschieden: Der Angriff kommt über die Nutzereingabe oder über Inhalte, die die Anwendung abruft. Auch Text in Bildern und anderen Medien kann Anweisungen transportieren. Übertragungsweg und Medienformat sind unterschiedliche Merkmale.

Was sind die 7 wichtigsten Hacker-Typen?

Hacker-Kategorien ergeben keine brauchbare Berechtigungsrichtlinie für einen Agenten. Maßgeblich ist, wer authentifiziert ist, wer die Inhalte beeinflussen kann und worauf die Anwendung zugreifen oder was sie verändern darf.

Was sind DDoS und SQL Injection?

DDoS steht für Distributed Denial of Service und bezeichnet einen Angriff auf die Verfügbarkeit aus verteilten Quellen. SQL Injection manipuliert Datenbankabfragen. Beides sind eigenständige Probleme neben Prompt Injection. Der OWASP-Leitfaden zu Denial of Service behandelt den Schutz der Verfügbarkeit.

Der nächste Schritt für Montag

Einen laufenden Postfach- oder CRM-Workflow auswählen und seine erreichbaren Daten, Tools und externen Ziele auflisten. Überflüssige Zugriffe entfernen, folgenreiche Aktionen bis zur Freigabe der konkreten Aktion zurückhalten und nachweisen, dass ein abgelehnter Vorschlag keine Wirkung nach außen hat. Die Autonomie erst erweitern, wenn sowohl die eigentliche Aufgabe als auch die Ablehnungswege funktionieren.

Praktische Anleitungen für den Aufbau von KI-Workflows gibt es im Newsletter.