Zielzustand
Die Behörde kann auf eine gemeinsam, im Rahmen des bereitgestellte, modulare und herstellerunabhängige Plattform für agentische Anwendungen zugreifen. Für den Aufbau von KI-Agenten stehen wiederverwendbare für Modelle, & Laufzeitumgebung (), Datenzugriff, Identität, , Sicherheit und („“) zur Nachnutzung bereit. Sie umfassen auch sogenannte AgentOps-Werkzeuge, die der zuverlässigen und rechtskonformen Steuerung, Überwachung und Verwaltung der Agentendienste dienen. Darin enthalten sind auch diejenigen Dienste, die die fachliche Umsetzung der KI-Agenten in den Behörden ermöglichen.
Betrieben werden die KI-Agenten dort, wo es fachlich und technisch sinnvoll ist. Unabhängig vom Betriebsort gelten zentral vorgegebene Standards (z. B. für Protokollierung). Agenten und Workflows sind klar identifizierbar und verfügen über begrenzte Berechtigungen - es gilt eine (). Autonomie und werden je Prozessschritt nach Risiko und Reversibilität festgelegt; besonders kritische Aktionen sind bspw. durch eingeschränkte Schreibrechte, beschränkten Zugriff und verbindliche Prüfpunkte technisch abgesichert. Die Agenten werden also durch harte technische Maßnahmen und nicht allein durch Regeln eingeschränkt. Einheitliche Standards und ermöglichen Interoperabilität zwischen bestehenden und neuen Lösungen im föderalen Kontext sowie von Technologieanbietern.
Abbildung 11: Zielzustand
Designprinzip 1
Shared Platform statt Agentensilos
Agentische Anwendungen sollten auf einer zentralen technischen Plattform und einer gemeinsamen Architektur im Rahmen des aufsetzen. Wiederverwendbare Funktionen wie Modellzugriff, Identitäten, Daten- und Toolzugriffe, und werden zentral im Rahmen der Plattform bereitgestellt; fachliche Agenten konzentrieren sich auf die jeweilige Prozesslogik.
Designprinzip 2
Vorrang technischer statt promptbasierter Grenzen
Sicherheitskritische Beschränkungen dürfen nicht davon abhängen, dass ein Agent Anweisungen korrekt befolgt. Zugriffsrechte, erlaubte Aktionen und zulässige Parameter werden deshalb möglichst technisch in den angebundenen Systemen bzw. begrenzt. Sicherheitsschranken ergänzen dies.
Designprinzip 3
Autonomie pro Prozessschritt
Der Grad der Selbstständigkeit wird nicht pauschal für einen Agenten festgelegt, sondern für einzelne Aufgaben sowie für den Zugriff auf Daten und Applikationen. Entscheidend sind Risiko, Tragweite und Reversibilität einer Handlung; bei kritischen Schritten können sogar Freigaben oder Eskalationen vorgesehen werden. Übergeordnete dienen bei der Anwendung auf Fachverfahren als Grundlage für angemessene Berechtigungen der agentischen Logik.
Designprinzip 4
Modellagnostik als Architekturprinzip
Fachanwendungen sollten nicht fest an einen bestimmten Modellanbieter gekoppelt werden. Eine gemeinsame ermöglicht, Modelle abhängig von Qualität, Kosten, Geschwindigkeit, Datenschutz oder Betriebsort auszuwählen und später auszutauschen. Etwaige Unterschiede in werden durch systematische Validierung in ihrer Wirkung begrenzt.
Designprinzip 5
Agenten als verwaltete Identitäten
Jeder produktive Agent erhält eine eindeutige, jederzeit überprüfbare und fälschungssichere Identität, einen verantwortlichen Owner sowie klar definierte und widerrufbare Berechtigungen. Dadurch kann jederzeit nachvollzogen und gesteuert werden, welcher Agent auf welche Systeme und Funktionen zugreifen darf.
Designprinzip 6
Nachvollziehbarkeit von Anfang an
und Auditierbarkeit werden bereits beim Aufbau der Plattform berücksichtigt. Relevante Datenzugriffe, Aktionen, Freigaben und Fehler können über den gesamten Prozess hinweg nachvollziehbar sein.
Designprinzip 7
Konsolidierte IT-Landschaft
Für alle im Betrieb stehenden gibt es eine Perspektive zur Integration bzw. zur Ablösung (sofern Integration nicht möglich), um Interoperabilität mit agentischen Systemen sicherzustellen.
Designprinzip 8
Offene Standards und Best Practices
Die gemeinsame Plattform folgt den Best Practices der Industrie, Wissenschaft und Community. Dabei wird besonderen Wert auf industrieerprobte Standards wie gelegt, die Interoperabilität und Nachnutzbarkeit beliebiger agentischer und Pipelines ermöglicht.
Fußnoten
fungiert als Laufzeitumgebung von agentischen Workflows. In ihm werden die verschiedenen , inkl. der koordinierenden LLM-Aufrufe registriert, verwaltet und ausgeführt.
Zur Markierung springen (Fußnote 2)