Vom Prototyp zur ausgerollten Änderung: KI mit begrenzten Berechtigungen integrieren

1. Die Vertrauensgrenze festlegen

Stell dir eine interne Funktion vor, die eine Aktualisierung für einen Datensatz vorbereitet. Das Modell darf die unbedingt erforderlichen Informationen lesen und neue Feldwerte vorschlagen, erhält aber weder Zugangsdaten für die Datenbank noch die Möglichkeit, die Änderung selbst auszuführen. Die gewöhnliche Anwendungslogik behält die Kontrolle: Sie authentifiziert die Person, prüft ihre Berechtigungen, validiert den aktuellen Zustand und entscheidet, ob die Änderung übernommen wird. Diese Trennung begrenzt die Folgen fehlerhafter oder manipulierter Antworten.

Zeichne den Datenfluss, bevor du Code schreibst. Halte fest, was die Person eingibt, welcher Kontext ergänzt wird, welche Antwort erwartet wird und welche Systeme betroffen sein könnten. Behandle aus Dokumenten, Tickets und Datensätzen abgerufenen Text als nicht vertrauenswürdige Daten: Er kann irreführende Anweisungen enthalten und darf die Befugnisse des Modells nicht erweitern. Nimm keine Geheimnisse oder personenbezogenen Daten auf, die für den Vorschlag nicht erforderlich sind.

Definiere eine eng begrenzte Ausgabe. Bitte das Modell zum Beispiel nicht darum, einen Datensatz zu aktualisieren, sondern um ein Objekt mit der Datensatzkennung, den vorgeschlagenen Feldänderungen und einer kurzen Begründung. Die Begründung kann der prüfenden Person helfen, ersetzt aber keine serverseitigen Kontrollen. Das Modell darf weder entscheiden, wer autorisiert ist, noch welche Geschäftsregeln gelten.

Ein Aufruf von Tools oder Funktionen ermöglicht es einem Modell, in einer Anwendung verfügbare Operationen anzufordern; dadurch wird die Anfrage nicht automatisch autorisiert. Die Anwendung muss sie als Vorschlag behandeln und ihre eigene Richtlinie anwenden. Wenn eine ausgewählte Funktion einen Schreibvorgang auslöst, sollte die dem Modell bereitgestellte Schnittstelle nur das Vorbereiten, nicht aber das Bestätigen der Operation ermöglichen.

2. Einen Adapter zwischen Modell und internen Diensten einsetzen

Der Adapter ist Anwendungscode, der zwischen der Anfrage der nutzenden Person, der Schnittstelle des Modellanbieters und den internen Diensten vermittelt. Er verwahrt die Zugangsdaten, begrenzt den übermittelten Kontext, validiert die Antwort und ruft deterministische Geschäftsoperationen erst auf, wenn alle Prüfungen bestanden sind. So verbindet sich das Modell weder direkt mit der Datenbank noch bestimmt es, wie eine Person authentifiziert wird.

Teile die Zuständigkeiten in überschaubare Module auf: Authentifizierung und Autorisierung, Kontextaufbau, Modellaufruf, Ausgabevalidierung, Anzeige zur Prüfung und Ausführung der bestätigten Operation. Diese Trennung erleichtert einen Anbieterwechsel, ohne die Geschäftsregeln neu schreiben zu müssen, und ermöglicht es, die Generierung abzuschalten, ohne die herkömmliche Funktion außer Betrieb zu setzen.

Lege einen versionierten Ein- und Ausgabevertrag fest. Eine strukturierte Antwort kann Pflichtfelder, konkrete Datentypen und abgeschlossene Aufzählungen verlangen. Strukturierte Ausgabe verringert Formatierungsmehrdeutigkeiten, beweist aber nicht, dass Werte richtig oder sicher sind. Validiere das Objekt auf dem Server, weise unbekannte Felder zurück, sofern der Vertrag das vorsieht, und prüfe zusätzlich die domänenspezifischen Regeln.

Halte Entscheidungen, die deterministisch sein müssen, außerhalb des Modells: die Identität der Person, Berechtigungen, Ressourcengrenzen, Zustandsübergänge, exakte Berechnungen und persistente Schreibvorgänge. Dokumentation zu Integrationsplattformen zeigt Muster für die Verbindung von Modellen und Workflows; konkrete Konfiguration, verfügbare Konnektoren und deren Berechtigungen hängen jedoch vom Produkt ab und müssen anhand der aktuellen Dokumentation geprüft werden.

3. Den Vorschlag in eine autorisierbare Operation umwandeln

Die Antwort des Modells ist kein vertrauenswürdiger Befehl. Prüfe vor einer Änderung, ob sie dem erwarteten Schema entspricht, die Ressource zum autorisierten Bereich gehört und die aktuelle Person genau diese Operation ausführen darf. Leite eine Berechtigung weder aus einer Erklärung des Modells noch aus einer vorgeschlagenen Kategorie oder aus Inhalten in Dokumenten ab.

Prüfe den Datensatz unmittelbar vor dem Schreibvorgang erneut. Hat sich sein Zustand seit der Erstellung des Vorschlags geändert, übernimm nicht stillschweigend Werte, die auf einer älteren Version beruhen. Du kannst den Fall erneut zur Prüfung vorlegen, den Vorschlag mit dem neuen Zustand erzeugen oder einen Konflikt anzeigen, über den die Person entscheidet. Der Schreibvorgang sollte eine für den verwendeten Speicher geeignete Nebenläufigkeitskontrolle nutzen.

Definiere Geschäftsregeln unabhängig vom Modell. Ein Vorschlag kann beispielsweise syntaktisch gültig, aber unzulässig sein, weil das Ticket bereits geschlossen ist. Begrenze die Zahl der änderbaren Felder, weise Werte außerhalb des zulässigen Bereichs zurück und verhindere, dass das Modell Kennungen von Ressourcen einführt, die nicht zuvor autorisiert wurden.

Eine menschliche Prüfung ist besonders sinnvoll, wenn die Änderung sensibel, schwer rückgängig zu machen oder für andere Personen relevant ist. Die Entscheidung muss fundiert sein: Zeige aktuelle und vorgeschlagene Werte, kennzeichne die zu ändernden Felder und ermögliche einen Abbruch. In regulierten Kontexten hängen die konkreten Pflichten von der jeweiligen Funktion und Einstufung ab. Die praktischen AESIA-Leitfäden richten sich an die Umsetzung der KI-Verordnung und werden als unverbindliche Empfehlungen beschrieben; sie ersetzen nicht die geltenden Rechtsvorschriften.

4. Zugangsdaten, Tools und Kontext begrenzen

Wende das Prinzip der geringsten Berechtigung auf jede Komponente an: Zugangsdaten dürfen nur die erforderlichen Operationen auf den erforderlichen Ressourcen erlauben. Muss der Ablauf Daten lesen und eine Aktualisierung vorschlagen, trenne die Leseidentität von der Identität für Schreibvorgänge. Halte Letztere vom Modellprozess fern und verwende sie ausschließlich in einem vom Server kontrollierten Anwendungspfad.

Stelle dem Modell keine allgemeinen Tools zur Verfügung, etwa beliebige Abfragen auszuführen, auf sämtliche Datensätze zuzugreifen oder beliebige interne APIs aufzurufen. Biete eng umrissene Operationen an, zum Beispiel eine autorisierte Datensatzübersicht abzurufen oder eine Änderung der Kategorie vorzubereiten. Wenn eine Plattform die Auswahl von Tools oder Funktionen ermöglicht, bildet diese Liste eine Befugnisgrenze, ersetzt aber nicht die von der Anwendung implementierte Autorisierung.

Speichere Schlüssel und Tokens im für die Umgebung zugelassenen Geheimnisspeicher. Füge sie weder in Anweisungen noch in Debug-Protokolle oder Antworten an Nutzende ein. Lege Rotation und Widerruf fest, trenne Zugangsdaten nach Umgebung und verwende keine Entwicklungsschlüssel in der Produktion. Sicherheitsmechanismen einer API wie Tokens, Schlüssel oder Zertifikate haben unterschiedliche Anwendungsbereiche und Voraussetzungen: Prüfe, was auf deiner Plattform tatsächlich konfiguriert ist, und leite aus der Bezeichnung eines Mechanismus nicht auf minimale Berechtigungen ab.

Begrenze auch die an das Modell übermittelten Informationen. Entferne irrelevante Felder, verschleiere Kennungen, wenn sie nicht benötigt werden, und setze Größenlimits. Prüfe, welche Daten an den Anbieter übertragen werden, welche aktuellen Bedingungen für Verarbeitung und Aufbewahrung gelten und welche Optionen für die gewählte Region und den gebuchten Dienst verfügbar sind. Diese Details unterscheiden sich je nach Anbieter, Produkt, Konfiguration und Zeitpunkt; sie lassen sich nicht aus einem allgemeinen Architekturmuster ableiten.

5. Zeitlimits, Wiederholungen und Duplikate handhaben

Ein Modellaufruf kann dauern, eine unvollständige Antwort liefern oder wegen einer vorübergehenden Unterbrechung fehlschlagen. Lege ein maximales Zeitlimit fest und behandle eine Überschreitung so, als wäre kein Vorschlag verfügbar; führe keine Aktion auf Grundlage eines Teilergebnisses aus. Informiere klar über den Status und ermögliche einen erneuten Versuch, ohne die Möglichkeit zu verlieren, die ursprüngliche Anfrage zu prüfen.

Unterscheide zwischen einer Wiederholung der Generierung und einer Wiederholung des Schreibvorgangs. Eine erneute Anfrage an das Modell kann ein anderes Ergebnis liefern; bewahre deshalb die Kennung der Anfrage auf und zeige, welcher Vorschlag gerade geprüft wird. Dagegen kann die Wiederholung eines Schreibvorgangs nach einer Zeitüberschreitung den Effekt verdoppeln, falls die erste Anfrage das System doch erreicht hat. Verwende einen Idempotenzschlüssel oder ein entsprechendes Verfahren, wenn der Dienst es unterstützt, und prüfe das Ergebnis, bevor du die Anfrage erneut sendest.

Eine idempotente Operation führt bei Wiederholung unter denselben Bedingungen zum gleichen effektiven Zustand. Das ist nicht dasselbe, wie eine beliebige Anfrage folgenlos wiederholen zu können. Entwirf bei nicht idempotenten Schreibvorgängen eine Methode, mit der sich feststellen lässt, ob die Änderung bereits erfolgt ist, etwa indem die Operationskennung zusammen mit dem Ergebnis gespeichert wird. Kannst du den Ausgang nach einem Fehler nicht ermitteln, stoppe automatische Wiederholungen und leite den Fall zur Abgleichprüfung weiter.

Schütze Schreibvorgänge vor gleichzeitigen Änderungen. Übermittle eine Versions- oder Zustandsbedingung, die die Anwendung zuvor gelesen hat, und weise den Schreibvorgang zurück, wenn sie nicht mehr übereinstimmt. Lege fest, was rückgängig gemacht werden kann: Manchmal genügt es, Felder wiederherzustellen; in anderen Fällen gibt es externe Auswirkungen oder Benachrichtigungen, die sich nicht zurücknehmen lassen. Bestimme in solchen Fällen eine Ausgleichsmaßnahme und wer über ihre Anwendung entscheidet.

6. Schrittweise ausrollen und einen Notausstieg vorsehen

Richte eine Testumgebung mit nicht produktiven oder angemessen geschützten Daten und getrennten Zugangsdaten ein. Prüfe den vollständigen Ablauf: Vorschlag erzeugen, ungültige Ausgabe zurückweisen, fehlende Berechtigungen ablehnen, Zustandskonflikt erkennen, Zeitüberschreitung behandeln und Schreibfehler verarbeiten. Ziel ist, das Verhalten der gewählten Integration zu prüfen, nicht davon auszugehen, dass ein Anbieter eine bestimmte Sicherheitsfunktion bereitstellt.

Beginne im Vorschlagsmodus ohne Ausführung: Die Anwendung darf Ergebnisse erzeugen und anzeigen, aber keine Änderungen übernehmen. Aktiviere anschließend die Bestätigung für eine kleine Gruppe oder eine begrenzte Operationsklasse und benenne dafür verantwortliche Personen. Lege im Voraus fest, unter welchen Bedingungen die Funktion gestoppt wird, wer sie ein- oder ausschalten darf und wie Nutzende über die Änderung informiert werden.

Das Zurücksetzen muss eine tatsächlich verfügbare Betriebsmaßnahme sein. Baue einen Schalter ein, der Generierung oder Aktionsausführung deaktiviert, ohne vorhandene Daten zu verändern, stelle einen herkömmlichen Weg zur Erledigung der Aufgabe bereit und definiere ein Verfahren zur Prüfung ausstehender Vorschläge. Wird über eine API oder Pipeline ausgerollt, trenne die technische Bereitstellung von der Veröffentlichung für Nutzende und prüfe, in welcher Phase tatsächlich Traffic ankommt. Die Details hängen von der konkreten Plattform ab.

Dokumentiere vor einer Ausweitung des Zugriffs bekannte Grenzen, effektive Berechtigungen, Datenverarbeitung und die für die gewählte Konfiguration geltenden Anbieteranweisungen. Die AESIA-Leitfäden halten ausdrücklich fest, dass ihre Dokumente unverbindliche Empfehlungen sind und regelmäßig überprüft werden. Nutze sie als Orientierung im jeweiligen Kontext, nicht als automatisch auf jede Integration anwendbares Rechtsgutachten.

7. Vorlage für eine Architekturprüfung

Beantworte vor der Umsetzung schriftlich Fragen, die sich anhand des Codes, der Konfiguration oder der aktuellen Dokumentation überprüfen lassen. Betrachte eine Frage nicht deshalb als geklärt, weil ein Anbieter allgemein eine Funktion ankündigt: Bestätige, dass sie im Produkt, in der Version, Region und Servicestufe verfügbar ist, die du tatsächlich verwenden wirst.

Nimm in die Prüfung die genaue Schnittstelle des Adapters, das Antwortschema, deterministische Regeln, die Identität jeder Komponente, zugängliche Ressourcen und den Weg von der Bestätigung bis zum Schreibvorgang auf. Dokumentiere außerdem Fehlerszenarien, Wiederholungsverhalten, Duplikaterkennung, Nebenläufigkeitsbedingungen und die Möglichkeit, die Funktion abzuschalten.

Halte dokumentierte Fakten, Designentscheidungen und offene Annahmen getrennt. Dass eine Plattform Funktionsaufrufe unterstützt, beweist beispielsweise nicht, dass eine bestimmte Funktion unabhängig autorisiert werden kann. Dass ein Leitfaden Authentifizierungsmechanismen beschreibt, beweist nicht, welche davon in deiner Bereitstellung aktiv sind. Bestätige jedes Detail anhand der entsprechenden Primärdokumentation und der wirksamen Konfiguration.

Für ergänzende Informationen kannst du den Lernleitfaden zu KI, den Leitfaden zu lokalen Modellen und die Glossareinträge zu Tool-Aufrufen, dem Prinzip der geringsten Berechtigung, strukturierter Ausgabe und Prompt-Injection heranziehen. Diese internen Links sollten zu Seiten von Inferama führen und diesen Leitfaden ergänzen; sie ersetzen nicht die Dokumentation des ausgewählten Anbieters.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.