Diese Seite wird auf Englisch angezeigt, während eine geprüfte Übersetzung für Ihre Sprache vorbereitet wird.

Warum wir die Handlungsabsicht als Governance-Vertrag und nicht als Stimmung behandeln

Eine leicht verständliche Perspektive von Perspectis AI: Wo die agentische Absicht in der Unternehmens-KI ihren Platz hat (Richtlinien, Identität, Tools, Beobachtbarkeit) – nicht nur in Aufforderungen – und wie wir über Risikostufen und die Eingabe von Aufforderungen nachdenken.

5 Min. Lesezeit2026-04-15

Ein leicht verständlicher Hinweis für Führungskräfte, Risikoverantwortliche und Kundenteams (April 2026)

Die Kurzfassung

„Agentische“ Systeme sind in aller Munde: Assistenten, die planen, Tools aufrufen und selbstständig handeln. Wir sind überzeugt, dass die Ideen hinter diesem Wandel veröffentlichungswürdig sind – denn die entscheidende Frage ist nicht, ob Modelle selbstbewusst klingen können, sondern ob ein Unternehmen im Fehlerfall oder bei Nachfragen von Aufsichtsbehörden begründen kann, wer was tun durfte und warum.

Perspectis AI ist so konzipiert, dass die Absicht (welche Aufgabe angefordert wird und unter wessen Verantwortung) an governancefreundlichen Stellen – Identität, Richtlinien, Tool-Grenzen und Beobachtbarkeit – und nicht nur in der Modelleingabeaufforderung enthalten ist. So bringen wir die Energie eines „hilfreichen Assistenten“ mit der Sorgfaltspflicht im professionellen Umfeld in Einklang.

Was wir unter „Absicht“ verstehen

Im Alltag ist Absicht einfach das Ziel einer Anfrage: „Diese Angelegenheit zusammenfassen“, „eine E-MAIl verfassen“, „eine Rechnung erstellen“, „eine Compliance-Prüfung durchführen“.

Auf einer professionellen Plattform ist die Absicht auch strukturell:

Wer hat die Arbeit initiiert (eine Person, eine Rolle, ein Dienst)?
Welche Funktion darf ausgeführt werden (z. B. der Pfad „Persönlicher Agentenvertreter“ im Vergleich zu einem Hintergrundprozess)?
Welche Art von Aktion ist beteiligt (Datensätze lesen, bearbeiten, Geld überweisen, irreversible administrative Änderungen)?

Nichts davon sollte allein durch geschickte Formulierungen in einem Chatfenster angedeutet werden. Wir betrachten dies als Information, die die Plattform verstehen und umsetzen muss – daher ist das Modell nicht der einzige Ort, an dem „Absicht“ existiert.

Warum Absichten nicht nur innerhalb des Modells existieren können

Ein großes Sprachmodell kann Sprache interpretieren; es kann jedoch nicht allein als Referenzsystem für Berechtigungen, Vertraulichkeit oder Abrechnungsrichtlinien dienen.

Wir entwickeln nach einem einfachen Prinzip: Governance gehört in die Anwendungs- und Datenebene, nicht nur in Anweisungen an ein Modell.

Das bedeutet:

Richtlinienprüfungen (Funktionen, Rollen, Organisationsgrenzen) entscheiden, ob eine Aktion ausgeführt werden darf – selbst wenn das Modell einer schädlichen oder missverständlichen Anfrage „zustimmt“.
Tool- und Aktionsregister legen fest, welche Funktionen vorhanden sind und wie riskant jede einzelne ist; das Modell kann nicht durch überzeugenden Text neue privilegierte Endpunkte erfinden.
Informationsbarrieren und ähnliche Kontrollen gelten weiterhin, wenn ein Assistent sensible Daten abruft oder zusammenfasst – denn Zugriffsregeln sind in natürlicher Sprache nicht verhandelbar.

Diese Vorgehensweise erleichtert eine ganze Reihe von Fehlermöglichkeiten, bei denen eine flüssige Antwort zwar autorisiert wirkt, es aber nicht ist.

Wie wir über Risiken nachdenken, ohne jemanden mit Fachjargon zu überfordern

Unterschiedliche Handlungen bergen unterschiedliche Risiken in der Praxis. Wir ordnen diese Idee in einer praktischen Risikoskala zusammen, die vielen Teams bereits bekannt ist:

| Einfache Idee | Was sie im operativen Geschäft bedeutet |

| --- | --- |

| Lesen | Informationen nachschlagen; erfordert weiterhin korrekte Zugriffs- und Vertraulichkeitsregeln, führt aber an sich nicht zu dauerhaften Änderungen. |

** Handeln (Daten ändern) | Datensätze erstellen oder aktualisieren; erfordert klare Verantwortlichkeiten und in risikoreicheren Kanälen oft eine Bestätigung. |

** Transaktionen (Geld oder Abrechnung) | Finanz- oder rechnungsbezogene Tätigkeiten; erfordert eine explizite Bestätigung und strenge Genehmigungen – denn Fehler können zu wirtschaftlichen und reputationsbezogenen Ereignissen führen. |

** Irreversibel oder destruktiv | Administrator-ähnliche oder schwer rückgängig zu machende Vorgänge erfordern strengste Kontrollen – und gemäß unserer Designvorgabe sollten wir nicht zulassen, dass Vorgänge unbemerkt über risikoreiche Freisprechkanäle wie Sprache ohne zusätzliche Sicherheitsvorkehrungen ausgeführt werden.

Neben dem Risiko einzelner Aktionen achten wir auch auf die Interaktion des Menschen auf Produktebene: Wo eine Genehmigung erforderlich ist, wo ein Mensch überwacht und eingreifen kann und wo die Autonomie bewusst eingeschränkt wird. Das ist keine Bürokratie um ihrer selbst willen, sondern die evidenzbasierte Arbeitsweise regulierter und reputationssensibler Organisationen.

Prompt-Injection und „emergentes“ Verhalten: Was wirklich zählt

Prompt-Injection (Versuche, einen Assistenten mit feindlichem Text zu manipulieren oder zu verwirren) ist ein bekanntes Problem in der Branche. Wir nehmen es ernst – und geben offen zu, dass kein Textfilter ein Allheilmittel ist.

Was wir unseren Kunden vermitteln, ist das Konzept der gestaffelten Verteidigung:

Maßnahmen zur Risikominderung an der Modellgrenze (Erkennung, Bereinigung, Protokollierung) reduzieren, wie viele schädliche Texte unverändert in das Modell gelangen.
Harte Sicherheitsmechanismen in der Software entscheiden weiterhin darüber, ob Tools ausgeführt, Geld transferiert oder vertrauliche Daten zurückgegeben werden – so wird ein manipuliertes Modell nicht zu einer stillen Umgehung der Unternehmensrichtlinien.

Diese Kombination ermöglicht es uns, über Sicherheit zu sprechen, ohne vorzugeben, das Modell sei unfehlbar.

Vergleich auf einen Blick (strukturell, keine wöchentliche Feature-Bewertung)

**Diese Tabelle dient der Positionierung und nicht dem Abhaken von Checklisten. Produkte entwickeln sich schnell; die Architekturausrichtung ändert sich langsamer.

| --- | ---: | ---: | ---: | | Wo die Absicht verankert sein muss | Identität, Richtlinien, Register, strukturierte Anfragen, Beobachtbarkeit | Hauptsächlich in der Kommunikation | Was auch immer die einzelnen Teams implementieren |

Wer ist für die Durchsetzung verantwortlich? | Die Plattformschicht, die wir bereitstellen und weiterentwickeln | Die Produkt- und Mandantenverwaltungsoptionen des Anbieters | Die Entwicklungs- und Sicherheitsteams der übernehmenden Organisation |

Geldtransfers und irreversible Arbeiten | Explizite Risikobewertung, Bestätigungen, Kanalbeschränkungen in unserer Richtung | Oft außerhalb des Geltungsbereichs oder generisch | Vollständig individualisiert – leistungsstark und mit hoher Verantwortung |

Modellkontextprotokoll und Tools | Wir behandeln Tools als kontrollierte Funktionen, nicht als stille Superkräfte | Variiert je nach Produkt | Hängt vollständig von der Implementierungsqualität ab |

Audit-Bericht | Konzipiert für die Frage „Wer hat was und warum genehmigt?“ als Plattformproblem | Variiert; oft schlanker | Vollständig individualisiert |

Bestes mentales Modell in einer Zeile | Gesteuerter Assistent innerhalb einer Betriebsplattform | Hilfreiche Gesprächsoberfläche | Benutzerdefinierter Agenten-Stack |

Warum wir diese Art von Perspektive veröffentlichen

Unsere Kunden erwerben nicht einfach nur „eine KI-Funktion“. Das eigentliche Ziel ist ein nachvollziehbarer Betrieb: Kontinuität, Aufgabentrennung und eine überzeugende Argumentation, auch wenn etwas schiefgeht. Wir investieren in eine verständliche, öffentliche Kommunikation – neben detAIllierteren technischen Informationen für Sicherheits- und Architekturexperten –, denn unsere Kunden verdienen Klarheit darüber, was Marketing und was strukturell ist.

Die Perspectis AI Demo Environment dient unter anderem dazu, diesen Unterschied greifbar zu machen: keine einzelne, aufwendig gestaltete Demo, sondern ein breites Spektrum realistischer Szenarien, in denen Absicht, Richtlinien und Workflow höchste Priorität haben.

Quellen (extern, für den allgemeinen Branchenkontext)

Dieses Dokument richtet sich an externe, nicht-technische Leser. Ausführlichere technische Bewertungen von Kontrollen, Implementierungsstatus und Nachweisen finden Sie in unserer Sicherheits- und Architekturdokumentation für Kunden und Auditoren.