Sichere KI-Automatisierung im Unternehmen: Berechtigungen und Nachweise

Dieses Handbuch unterstützt Prozessverantwortliche, Betriebsteams und die IT dabei, einen KI‑Workflow auszuwählen und dessen Daten, Berechtigungen und Ergebnis‑Checks zu definieren. Es verknüpft Sicherheitsmuster für Agenten mit Leitfäden für Fertigung, Lebensmittel, Gesundheitswesen und Pharma, Finanzen und IKT, Salons sowie Immobilienverwaltung.

Ein KI‑Agent kann Daten abrufen, eine Änderung vorbereiten, eine API aufrufen und Arbeiten erledigen, die zuvor mehrere Bildschirme und manuelle Schritte erforderten. Das ist nützlich. Derselbe Mechanismus ermöglicht es jedoch auch einem schlecht entworfenen Agenten, eine falsche Aktion schneller auszuführen.

Unsere Ausgangsregel ist einfach: Ein Modell darf Aktionen nur innerhalb von Grenzen vorschlagen und ausführen, die das System unabhängig vom Modell durchsetzen kann. Je größer die Konsequenz einer Operation, desto weniger sollten wir uns auf das eigene Urteil des Modells als Steuerung verlassen.

Das führt zu vier praktischen Fragen:

1. Welche Werkzeuge und Daten benötigt der Agent tatsächlich?
2. Welche Aktionen darf er autonom ausführen und welche benötigen menschliche Freigabe?
3. Wie verifizieren wir, was der Agent wirklich geändert hat, anstatt nur das, was er im Chat sagt?
4. Wie können wir die Entscheidung Wochen oder Monate später rekonstruieren, ohne fünf verschiedene Protokolle zusammenzusetzen?

Dieser Teil der Brillnet‑Website dokumentiert die Muster, die wir beim Arbeiten mit APIs, MCP, Automatisierung und Systemen verwenden, bei denen eine Aktion später nachgewiesen werden muss. Es handelt sich um Engineering‑Muster, nicht um eine Zertifizierung oder ein universelles Design für jedes agentenbasierte System.

Die Agenten‑Richtlinien von OWASP behandeln abgegrenzte Werkzeuge, unabhängige Kontrollen für hochwirksame Aktionen und Datenschutz [1]. Die MCP‑Dokumentation behandelt ebenfalls Autorisierungsrisiken, einschließlich Token‑Weiterleitung ohne ordnungsgemäße Validierung [2]. Das NIST‑AI‑RMF liefert freiwillige Leitlinien, jedoch keine Produktzertifizierung [4]. Diese Checklisten sind unsere praktische Anwendung.

Beginnen Sie mit einer Aufgabe, deren Ergebnis überprüfbar ist

„Das Unternehmen automatisieren“ ist zu breit für eine erste Einführung. Wählen Sie eine wiederkehrende Aufgabe mit klarem Anfang und Ergebnis: eine Liste fehlender Audit‑Belege, einen Entwurf einer Service‑Anfrage‑Antwort oder eine Liste von Mitarbeitenden, die eine aktualisierte Verfahrensanweisung prüfen müssen. Jede dieser Aufgaben hat eindeutige Eingaben und einen Entscheidungsträger.

Dokumentieren Sie die aktuelle Arbeitsweise, Informationsquellen und wiederkehrende Korrekturen, bevor Sie ein Werkzeug auswählen. Wenn der Prozess vom unausgesprochenen Wissen einer einzelnen Person abhängt, dokumentieren Sie dieses Wissen zuerst. Ein Modell kann fehlende Geschäftsregeln nicht zuverlässig liefern, nur weil seine Antwort vollständig klingt.

Die Anfangsaufgabe sollte eine Referenz besitzen, gegen die ihr Ergebnis geprüft werden kann. Daten stammen aus Quelldokumenten; Schulungen aus einer genehmigten Verfahrensanweisung; eine Service‑Antwort aus dem Fall und seiner Historie. Fehlende Informationen sollten eine explizite Ausnahme erzeugen, nicht eine erfundene Antwort, die den Workflow als abgeschlossen erscheinen lässt.

Weisen Sie vor dem Start die Verantwortung für diese Ausnahmen zu. Jemand muss widersprüchliche Dokumente auflösen, wesentliche Änderungen genehmigen und den Workflow stoppen. Ein funktionierender Eskalationsweg ist Teil des Prozesses, nicht eine nachträgliche Erfindung nach einem Vorfall.

Beginnen Sie mit der Konsequenz, nicht mit der technischen Aufmachung der Aktion

Ein komplexer Nur‑Lese‑Bericht kann ein geringes Risiko darstellen. Ein einzelner DELETE‑Aufruf kann Daten entfernen. Eine einzige enable‑Operation kann Geld ausgeben.

Eine nützliche Anfangsklassifizierung sieht so aus:

Aktionsklasse	Beispiel	Standard‑Kontrolle
Niedrig‑Risiko‑Lese	Status abrufen, Bericht oder genehmigte Ressourcen	Agent darf innerhalb einer abgegrenzten Lese‑Grenze ausführen
Änderung vorbereiten	Entwurf einer Konfiguration, Plan oder Inhalt	Agent bereitet vor; eine Person sieht das Ergebnis vor der Veröffentlichung
Reversible Schreib‑Operation	Einstellung ändern, die schnell zurückgerollt werden kann	expliziter Schreib‑Umfang, Eingabe‑Validierung, Ergebnis‑Aufzeichnung
Externe oder finanzielle Aktion	Veröffentlichen, Nachricht senden, Kampagne aktivieren, Ausgaben erhöhen	explizite menschliche Freigabe vor Ausführung
Zerstörerische oder sicherheitsrelevante Aktion	Daten löschen, Zugriff ändern, Sicherheitseinstellungen rotieren	separater Umfang, Vorschau, Freigabe und unabhängige Kontrollen, wo praktikabel

Dies ist kein mathematisches Risikomodell. Es dient dazu, zu erkennen, wo ein Modell‑Fehler zu einem Geschäfts‑ oder Sicherheitsvorfall wird.

Vier Schichten, die wir getrennt halten

1. Das Modell kann denken, aber es erteilt sich selbst keine Berechtigungen

Ein Modell darf aus den Werkzeugen wählen, die ihm zugewiesen wurden. Es sollte diesen Satz nicht selbst erweitern oder entscheiden, dass es „nur dieses eine Mal“ Administrator‑Rechte braucht.

Die Autorisierung muss von der Identität des Bedieners, der Rolle des Agenten, dem konkreten Werkzeug und der Zielressource stammen. Die Autorisierungsentscheidung liegt beim umgebenden System, nicht im vom Modell erzeugten Text.

Lesen: Least privilege for AI agents

2. Hochwirksame Aktionen durchlaufen ein Freigabegate

„Human in the loop“ bedeutet nicht, dass eine Person für jedes Lese‑Kommando „OK“ klickt. Das würde die Kontrolle schnell zu einer bloßen Formalität degradieren.

Freigaben sind sinnvoll, wenn eine Operation Geld ausgibt, extern kommuniziert, Zugriffe ändert, Daten löscht oder ein Ergebnis erzeugt, das schwer rückgängig zu machen ist. Vor der Freigabe muss die Person sehen können was sich ändern wird, wo, warum und welche wahrscheinlichen Konsequenzen zu erwarten sind.

Lesen: When should an AI agent require human approval?

3. Die Werkzeugschicht erzwingt Richtlinien unabhängig vom Prompt

Ein Prompt ist Teil der Lenkung des Modell‑Verhaltens. Er reicht nicht als Sicherheitsmechanismus für Schreib‑, Ausgaben‑ oder Administrations‑Operationen.

In unserem internen Brillnet‑Ads‑MCP‑Tool werden Beschränkungen am Gateway durchgesetzt. Die Operation wird klassifiziert, Bereiche werden geprüft und sichere Vorgaben verhindern, dass ein fehlender Parameter stillschweigend zu einer Live‑Aktion wird. Beispiel: Eine neu erstellte Kampagne bleibt PAUSED, wenn kein Status explizit angegeben wird. Das Aktivieren von Ausgaben erfordert eine operative Berechtigung und explizite Bestätigung.

Für uns ist das ein nützlicheres Kontrollmuster als das bloße Schreiben eines strengeren System‑Prompts.

Lesen: MCP and AI agents — designing safer tools

4. Audit‑Einträge beschreiben die Operation, ohne alles zu protokollieren

Ein nützliches Audit‑Protokoll kann beantworten:

• wer oder welcher Agent die Aktion initiiert hat;
• welches Werkzeug aufgerufen wurde;
• welche Ressource das Ziel war;
• welche Autorisierungsentscheidung getroffen wurde;
• ob menschliche Freigabe nötig war und wer sie erteilt hat;
• was der Anbieter zurückgab;
• welchen Endzustand das System nach dem Schreibvorgang zeigte.

Das bedeutet nicht, dass Geheimnisse, Zugriffstoken, Autorisierungs‑Header oder komplette Rohdatensätze „für alle Fälle“ gespeichert werden. Ein Log, das zu einem zweiten Speicherort sensibler Informationen wird, löst ein Problem, indem es ein weiteres schafft.

Lesen: AI agent audit trails — what to log and what not to log

Ein Dokument liefert Daten, nicht die Befugnis zu handeln

Ein Agent kann Nachrichten, Anhänge, Lieferantenseiten und Werkzeug‑Beschreibungen lesen. Jede dieser Quellen kann Anweisungen enthalten, die als Teil der Aufgabe getarnt sind. Ein Dokument könnte verlangen, dass der komplette Datensatz an eine benannte Adresse gesendet wird. Das Abrufen dieses Dokuments über eine genehmigte Suche autorisiert den Autor nicht, den Workflow zu ändern.

Wir trennen daher das Quellmaterial von den Anweisungen des Bedieners. Die erlaubten Werkzeuge, Ressourcen und Empfänger stammen aus Konfiguration und Autorisierung. Das Lesen eines Anhangs darf diese nicht erweitern. Der Agent kann eine im Dokument gefundene Anweisung melden; die Ausführung benötigt weiterhin eine unabhängige Basis.

Fügen Sie im Pilot ein bewusstes Beispiel ein. Ergänzen Sie eine Anweisung außerhalb des Geltungsbereichs zu einer Beispiel‑Anfrage und prüfen Sie, dass die Ausführung verweigert wird. Der Nachweis ist das Fehlen einer unautorisierten Wirkung im Zielsystem, nicht das Versprechen des Modells, vorsichtig zu sein.

Was wir prüfen, bevor wir einen Agenten an ein neues System anbinden

Eine kurze Design‑Checkliste:

• Zweck: Hat der Agent einen definierten Job oder breiten Zugriff „auf alles“?
• Identität: Kann jeder Aufruf dem Bediener, dem Agenten und der Aufgabe/Sitzung zugeordnet werden?
• Werkzeuge: Kann der Agent nur die Funktionen sehen, die für seine Aufgabe nötig sind?
• Ressourcen: Kann der Zugriff auf ein bestimmtes Konto, Mandanten, Projekt, Verzeichnis oder Datensatz‑Set begrenzt werden?
• Lese‑ vs. Schreib‑Rechte: Sind Lese‑ und Schreib‑Berechtigungen getrennt?
• Hoch‑Risiko‑Operationen: Benötigen sie einen separaten Umfang oder eine Freigabe?
• Validierung: Prüft das Gateway Struktur, Ressourcen‑Kennungen und Operationsklasse, bevor das Zielsystem aufgerufen wird?
• Sichere Vorgaben: Führt ein fehlender Parameter zu einem sicheren Zustand statt zur Aktivierung einer Aktion?
• Retry‑Verhalten: Kann ein automatischer Wiederholungsversuch dieselbe Schreib‑Operation zweimal ausführen? Falls ja, fügen Sie Idempotenz oder eine gleichwertige Kontrolle hinzu.
• Resultierender Zustand: Kann das System die Ziel‑Ressource nach einer Schreib‑Operation lesen und anzeigen?
• Audit: Können Entscheidung und Ergebnis ohne Geheimnisse und unnötige personenbezogene Daten aufgezeichnet werden?
• Unterbrechung: Kann eine Person den Workflow stoppen, bevor nachfolgende Schritte die Auswirkung erhöhen?

Wenn mehrere Antworten „wir wissen es nicht“ lauten, ist die Antwort nicht ein weiterer Prompt. Die Grenze zwischen Modell und Zielsystem erfordert Design‑Arbeit.

Beispiel: Warum Retry‑Verhalten und Read‑After‑Write wichtig sind

Angenommen, ein Agent erstellt über eine API eine Ressource. Er sendet die Anfrage, aber die Antwort geht im Netzwerk verloren. Der Agent weiß nicht, ob die Ressource erstellt wurde. Ein einfacher Retry kann ein Duplikat erzeugen.

Für Schreib‑Operationen verwenden wir daher einen Idempotenz‑Identifier und lesen den resultierenden Zustand nach der Änderung. Ein Netzwerkproblem wird so weniger wahrscheinlich zu einer doppelten Aktion, und der Bediener sieht den Zustand des Zielsystems, anstatt einer „erledigt“-Meldung des Agenten zu vertrauen.

Das wirkt zunächst wie ein kleines Implementierungsdetail, bis die Operation Geld, Nachrichtenempfänger oder Sicherheitskonfigurationen betrifft. Dann ist es nicht mehr klein.

Wählen Sie einen Leitfaden für Ihren Prozess und Sektor

Zugriffskontrollen teilen gemeinsame Prinzipien, aber die Konsequenz eines Fehlers hängt vom Umfeld ab. Diese Leitfäden erklären praktische Muster für konkrete Situationen. Sie stellen keinen neuen Spezial‑Brillnet‑Service dar, behaupten keine Zertifizierung und garantieren nicht, dass jedes Szenario bereits ein Produkt‑Feature ist. Prüfen Sie den Einsatz‑Umfang separat.

Fertigung und Automobil

AI automation in manufacturing and quality beginnt mit Nichtkonformitäten, Anweisungsänderungen und Nachweisen korrigierender Arbeit. Es trennt die Vorbereitung einer Analyse von der Entscheidung, ein Produkt freizugeben oder einen Prozess zu ändern. Ein ausgefeilter Entwurf beweist nicht, dass die Ursache beseitigt ist. Der Leitfaden hilft, zu bestimmen, wer die unterstützenden Nachweise prüft.

Lebensmittelunternehmen

AI automation and food safety behandelt Quell‑Aufzeichnungen, Verfahrens‑Versionen, Schulungen und Ausnahmen. Eine Dokument‑Prüfliste kann das Team unterstützen, ohne zu entscheiden, ob ein Batch sicher ist. Beginnen Sie mit der Verantwortung für die Gefahrenbeurteilung, die Entscheidung und einem Protokoll der genutzten Informationen.

Gesundheitswesen und Pharmazeutika

AI automation in healthcare and pharmaceuticals fokussiert Dokumenten‑Arbeit und Zugriffskontrolle. Es trennt administrative Unterstützung von klinischen oder Qualitäts‑Entscheidungen. Bevor Sie ein Modell auswählen, prüfen Sie, ob der gewählte Prozess überhaupt Patientendaten benötigt. Die Beschränkung von Informationen ist häufig ein praktischer Weg, die Exposition zu reduzieren und gleichzeitig den administrativen Mehrwert zu erhalten.

Finanzen und IKT

AI automation in finance and ICT behandelt Kontroll‑Nachweise, Ausnahmen und Lieferanten‑Bewertung. Einen Bericht vorbereiten, Berechtigungen ändern, eine Transaktion ausführen und eine externe Benachrichtigung senden sind unterschiedliche Aktionen. Jede benötigt ihre eigene Zugriffs‑Grenze. Ein allgemeines Token, das alle Systeme umfasst, verschleiert Verantwortung und erhöht die Folgen eines einzelnen Fehlers.

Salons und Tattoo‑Studios

AI automation in salons and tattoo studios verbindet Termine, Kundendaten und Mitarbeitervorschriften. Eine Buchungsannahme bestätigt nicht die Eignung des Kunden für eine Behandlung, und eine automatisierte Nachricht ersetzt nicht die Beurteilung des Praktizierenden. Definieren Sie die Informationen, die für Termine nötig sind, und die Entscheidungen, die eine Person behalten muss.

Immobilienverwaltung

AI automation in property management deckt Fälle, Dokumente, Fristen und Kommunikation mit Eigentümern ab. Es trennt einen Entwurf einer Antwort vom Versand und eine vorbereitete Zusammenfassung von einer finanziellen Entscheidung. Jeder Datensatz benötigt klare Gebäude‑ und Fall‑Grenzen. Ohne diese kann ein Agent Dokumente verschiedener Objekte vermischen und eine überzeugende, aber falsche Antwort erzeugen.

Bewertung des Piloten über die Demonstration hinaus

Vergleichen Sie gleichwertige Arbeit vor und nach der Automatisierung. Berücksichtigen Sie die von Menschen aufgewendete Zeit für das Sammeln von Quellen, das Prüfen des Ergebnisses und das Korrigieren von Fehlern. Die reine Modell‑Antwortzeit erfasst die Kosten nicht. Eine schnell generierte Antwort kann wenig Nutzen bringen, wenn eine Person jeden Satz über mehrere Systeme hinweg prüfen muss.

Wählen Sie ein Haupt‑Kriterium, etwa Fall‑Abschlusszeit, fehlende Nachweise oder Zeit zur Erstellung eines genauen Schulungs‑Entwurfs. Ergänzen Sie Schutz‑Maßnahmen: Korrekturen, Umfangs‑Verstöße, doppelte Operationen und die Kosten eines korrekt abgeschlossenen Falls. Der Prozess‑Verantwortliche sollte Akzeptanz‑Kriterien vor dem Piloten festlegen.

Beziehen Sie fehlende Dokumente, widersprüchliche Informationen und eine unterbrochene Verbindung ein. Das korrekte Stoppen und Weitergeben einer Ausnahme ist ein nützliches Ergebnis. Wenn der Workflow nur bei perfekten Eingaben Zeit spart, halten Sie den Anwendungs‑Umfang begrenzt. Erweitern Sie erst nach nachgewiesenen zuverlässigen Ergebnissen, nicht nach einer überzeugenden Präsentation.

Was wir nicht behaupten

• Es gibt keinen einzigen Autonomie‑Grad, der für jeden Prozess passt.
• MCP allein macht ein Werkzeug nicht sicher.
• Logging allein ist kein Audit‑Trail, wenn Ereignisse nicht mit Entscheidung und Ergebnis verknüpft werden können.
• Ein menschlicher Freigabeschritt repariert keine schwache Zugriffskontrolle.
• Diese Muster ersetzen kein Threat‑Modelling, keine Sicherheitstests und keine rechtliche Analyse für eine konkrete Implementierung.

Wie geht es weiter

Wenn Sie Brillnet als Lieferanten prüfen, beginnen Sie mit unseren öffentlichen Informationen zu Security und Compliance and AI oversight.

Haben Sie einen konkreten Prozess, bei dem ein Agent Daten in einem anderen System lesen oder ändern soll, beschreiben Sie eine Aktion, die er ausführen dürfen soll, und eine, die er niemals ausführen darf. Das ist ein besserer Ausgangspunkt als ein generisches „Wir wollen KI‑Agenten einsetzen“.

Quellen

Diese Quellen unterstützen Referenz‑Prinzipien, nicht die Compliance oder Wirksamkeit einer konkreten Brillnet‑Implementierung. Die Checklisten, Aktions‑Klassifizierung und Sektor‑Beispiele sind die praktischen Empfehlungen des Autors. Kundenidentifizierende Informationen und geheime Werte sind nicht erforderlich, um dieses Handbuch zu nutzen.

1. OWASP — AI Agent Security Cheat Sheet. Werkzeuge, Least‑Privilege, Datenschutz und Kontrollen für hochwirksame Aktionen. Zugriff: 2026‑10‑02.
2. Model Context Protocol — Security Best Practices, 2026‑07‑28 documentation. MCP‑Autoriserungs‑Risiken und Vertrauens‑Grenzen. Zugriff: 2026‑10‑02.
3. Model Context Protocol — 2026‑07‑28 specification release. Offizielle Protokoll‑Version‑Ankündigung. Zugriff: 2026‑10‑02.
4. NIST — AI Risk Management Framework. Freiwilliges KI‑Risikomanagement‑Framework; AI RMF 1.0 veröffentlicht: 2023‑01‑26. Zugriff: 2026‑10‑02.
5. OWASP — Logging Cheat Sheet. Ereignis‑Aufzeichnungen, Log‑Schutz und auszuschließende Informationen. Zugriff: 2026‑10‑02.

• Google: Optimizing your website for generative AI features on Google Search.