KI-Assistent: Berechtigungen im Rechnungsworkflow

Ein KI-Assistent im Rechnungsworkflow sollte nie pauschal alles dürfen, was technisch möglich ist. Ein belastbares Rechtekonzept trennt drei Stufen: Daten lesen, eine Änderung vorschlagen und eine Aktion tatsächlich ausführen. Der Assistent sieht dabei höchstens die Daten, die auch der angemeldete Mensch sehen darf. Versand, Zahlungsstatus, Stammdatenänderung oder Löschung bleiben serverseitig geschützt und benötigen je nach Auswirkung eine ausdrückliche Freigabe.

Diese Trennung ist für KMU wichtiger als eine besonders ausgefeilte Formulierung des System-Prompts. Sprachmodelle können halluzinieren, missverständliche Aufträge falsch deuten oder durch Inhalte in Dokumenten beeinflusst werden. Berechtigungen müssen deshalb außerhalb des Modells durch Anwendung, Rollen und klar begrenzte Werkzeuge erzwungen werden.

Warum ein hilfreicher Assistent schnell zu viele Rechte erhält

Ein reiner Chat beantwortet Fragen. Ein KI-Assistent mit Werkzeugen kann zusätzlich Datenbanken durchsuchen, Dateien öffnen, Rechnungen ändern, E-Mails vorbereiten oder Aktionen anstoßen. Genau hier entsteht das Risiko der übermäßigen Handlungsfreiheit. OWASP bezeichnet die Kombination aus zu vielen Funktionen, zu umfangreichen Berechtigungen und zu viel Autonomie als „Excessive Agency“.

Ein typischer Fehler beginnt bequem: Für einen Prototyp erhält der Assistent einen technischen Zugang, der alle Rechnungen lesen und verändern kann. Später nutzen Mitarbeitende den Assistenten mit unterschiedlichen Rollen, während der technische Zugang unverändert privilegiert bleibt. Die Oberfläche zeigt zwar den angemeldeten Nutzer, der nachgelagerte Dienst arbeitet aber mit einem Sammelkonto. Damit wird die Rollenprüfung faktisch umgangen.

Das Bundesamt für Sicherheit in der Informationstechnik empfiehlt für generative KI eine systematische Risikoanalyse. Besonders sensibel sind Informationen, auf die ein Modell während des Betriebs zugreifen kann. Ausgaben sollen überprüfbar sein, bevor daraus Folgeaktionen entstehen. Der klassische IT-Grundschutz ergänzt das Need-to-know- und Least-Privilege-Prinzip: Zugriffe werden auf das erforderliche Maß begrenzt.

Drei Berechtigungsstufen für den Rechnungsalltag

Stufe	Was der Assistent darf	Beispiel	Kontrolle
Lesen	Autorisierte Daten suchen und zusammenfassen	„Welche meiner Rechnungen sind überfällig?“	Rollen- und Dokumentfilter bei jeder Abfrage
Vorschlagen	Entwürfe oder strukturierte Änderungen vorbereiten	Mahnung formulieren oder Zahlung zuordnen	Vorschau mit Quellen und Änderungen, noch keine Mutation
Ausführen	Einen definierten Geschäftsvorgang anstoßen	Rechnung senden, Zahlung buchen, Datensatz löschen	Serverseitige Berechtigungsprüfung und ausdrückliche Freigabe

Die Stufen sollten technisch getrennt sein. Ein Werkzeug zum Lesen von Rechnungen braucht keine Funktion zum Löschen. Ein Werkzeug zum Erstellen eines E-Mail-Entwurfs braucht kein Senderecht. Und ein Assistent, der Zahlungsvorschläge liefert, benötigt keinen direkten Schreibzugriff auf den Zahlungsstatus.

Stufe 1: Lesen im Nutzerkontext

Der Assistent darf nur Ergebnisse erhalten, die für den aktuell angemeldeten Nutzer zulässig sind. Das gilt auch für semantische Suche, Vektordatenbanken oder Retrieval-Augmented Generation. Eine separate Wissenssuche darf keine Dokumente zurückgeben, die der Nutzer in der normalen Anwendung nicht öffnen könnte.

Praktisch bedeutet das: Rolle, Unternehmen und Dokumentfreigabe werden vor der Datenabfrage geprüft. Die KI entscheidet nicht selbst, ob ein Beleg vertraulich ist. Sie erhält bereits eine autorisierte Ergebnismenge. Das öffentlich beschriebene Team- und Rollenmodell von Claribill bietet dafür den organisatorischen Bezug: Unterschiedliche Aufgaben brauchen unterschiedliche Zugriffe.

Stufe 2: Vorschlagen ohne Zustandsänderung

Ein Vorschlag ist kein ausgeführter Vorgang. Der Assistent kann eine Mahnung entwerfen, eine Kontierung empfehlen oder eine mögliche Zahlungszuordnung nennen. Die Anwendung zeigt dabei, welche Rechnungsdaten verwendet wurden und welche Felder sich ändern würden. Der Nutzer kann korrigieren, verwerfen oder freigeben.

Diese Stufe bringt bereits viel Nutzen, ohne dem Modell weitreichende Aktionsrechte zu geben. Sie passt zu Aufgaben, bei denen Sprache oder Priorisierung helfen, während Betrag, Empfänger, Steuerlogik und Belegstatus aus verlässlichen Systemdaten stammen müssen.

Stufe 3: Ausführen mit enger Schranke

Folgenreiche Aktionen brauchen ein spezifisches Werkzeug statt einer allgemeinen „Rechnung bearbeiten“-Funktion. Sinnvolle Einzelaktionen sind beispielsweise „E-Mail-Entwurf speichern“, „Rechnung nach Bestätigung senden“ oder „Zahlungsvorschlag nach Freigabe übernehmen“. Jede Aktion prüft auf dem Server erneut Rolle, Mandant, Dokumentzugriff und aktuellen Status.

Die Freigabe muss die konkrete Wirkung zeigen: Empfängeradresse, Rechnungsnummer, Betrag, Anhang und Aktion. Ein allgemeines „KI verwenden“ beim Start einer Sitzung ist keine ausreichende Bestätigung für spätere Sendungen oder Löschungen. Ändert sich ein relevanter Wert nach der Vorschau, ist eine neue Freigabe nötig.

Aktionen nach Auswirkung klassifizieren

Nicht jede Zustandsänderung ist gleich kritisch. Eine praxistaugliche Richtlinie ordnet Werkzeuge nach ihrer möglichen Wirkung ein und verbindet jede Klasse mit einer passenden Kontrolle.

Aktionsklasse	Beispiele	Sinnvolle Voreinstellung
Nur intern und leicht umkehrbar	Entwurf speichern, Notiz oder Kennzeichnung vorschlagen	Einzelbestätigung oder klar begrenzte Regel
Fachlich wirksam	Kontierung, Zahlungszuordnung, Statusänderung	Vorschau, Berechtigungsprüfung und dokumentierte Freigabe
Extern oder finanziell wirksam	Rechnung oder Mahnung senden, Bankdaten ändern, Gutschrift auslösen	Explizite Freigabe des berechtigten Nutzers, bei Bedarf Vier-Augen-Prinzip
Destruktiv oder administrativ	Dokument löschen, Rechte ändern, API-Schlüssel verwalten	Für den Assistenten standardmäßig nicht verfügbar

Die Einordnung berücksichtigt nicht nur den Betrag. Eine E-Mail an den falschen Empfänger kann vertrauliche Rechnungsdaten offenlegen, obwohl sie keine direkte Buchung erzeugt. Umgekehrt kann eine interne Kennzeichnung mit guter Rückgängig-Funktion weniger kritisch sein. Entscheidend sind Vertraulichkeit, Integrität, finanzielle Wirkung, Außenwirkung und Umkehrbarkeit.

Batch-Funktionen brauchen eine eigene Grenze

Eine Aktion für einen Beleg darf nicht stillschweigend auf hundert Belege erweitert werden. Für Serienvorgänge sollte die Anwendung Anzahl, Gesamtsumme, Empfänger und Ausnahmen zusammenfassen. Oberhalb festgelegter Grenzen wird der Vorgang geteilt oder an eine höher berechtigte Rolle weitergegeben. So verhindert ein harmlos wirkender Auftrag wie „alle offenen Rechnungen bearbeiten“ einen unkontrollierten Massenversand.

Deutschland und Österreich: gleiches Sicherheitsprinzip

Für Unternehmen in Deutschland und Österreich gelten bei personenbezogenen Rechnungsdaten dieselben DSGVO-Grundsätze. Nationale Rechnungs-, Aufbewahrungs- oder Steuerregeln können den fachlichen Ablauf beeinflussen, begründen aber keine pauschalen KI-Rechte. Das Berechtigungskonzept orientiert sich an Aufgabe, Nutzerrolle und Risiko des konkreten Vorgangs.

Vier technische Leitplanken, die der Prompt nicht ersetzt

1. Autorisierung bei jedem Werkzeugaufruf

Die Anwendung behandelt einen KI-Aufruf wie jeden anderen API-Aufruf. Sie prüft Identität und Berechtigung vollständig, selbst wenn das Modell behauptet, der Nutzer sei Administrator. OWASP empfiehlt ausdrücklich, Autorisierung in den nachgelagerten Systemen durchzusetzen und nicht an das Sprachmodell zu delegieren.

2. Kleine Werkzeuge statt offener Vollmacht

Ein universelles Werkzeug mit beliebigen Datenbankoperationen vergrößert den möglichen Schaden. Besser sind eng definierte Funktionen mit validierten Eingaben. Ein Lesewerkzeug akzeptiert etwa Rechnungsstatus und Zeitraum, aber keinen freien Datenbankbefehl. Ein Versandwerkzeug akzeptiert nur eine bereits freigegebene Rechnungs-ID und erzeugt keine neuen Empfänger.

3. Bestätigung, Grenzen und Wiederholungsschutz

Für kritische Aktionen helfen Betragsgrenzen, zulässige Statusübergänge, Rate-Limits und Idempotenzschlüssel. Wird dieselbe Anweisung wegen eines Netzwerkfehlers wiederholt, darf daraus kein doppelter Versand oder eine doppelte Buchung entstehen. Serienaktionen benötigen eine sichtbare Liste der betroffenen Belege und eine gesonderte Freigabe.

4. Protokollierung mit fachlichem Kontext

Ein Audit-Eintrag sollte festhalten, wer den Assistenten beauftragt hat, welches Werkzeug aufgerufen wurde, welche Datensätze betroffen waren, welche Freigabe vorlag und ob die Aktion erfolgreich war. Sensible Prompts oder vollständige Rechnungsinhalte gehören nicht automatisch ins Protokoll. Es genügt häufig, Referenzen, Prüfergebnis, Modellversion und relevante Parameter nachvollziehbar zu dokumentieren.

Datenschutz: Zugriff begrenzen, bevor Daten an die KI gehen

Rechnungen enthalten häufig Namen, Anschriften, Ansprechpartner, Bankdaten oder Leistungsbeschreibungen. Sobald personenbezogene Daten verarbeitet werden, gelten insbesondere Zweckbindung, Datenminimierung sowie Integrität und Vertraulichkeit nach der DSGVO. Artikel 32 verlangt ein dem Risiko angemessenes Schutzniveau. Die konkrete Umsetzung hängt vom Einsatz, Anbieter, Vertrag und Datenfluss ab.

Der Europäische Datenschutzausschuss empfiehlt für KMU differenzierte Berechtigungsprofile nach Bedarf, eindeutige Nutzerkennungen und regelmäßige Überprüfungen der Rechte. Für einen KI-Assistenten folgt daraus: Er erhält nicht vorsorglich den gesamten Rechnungsbestand. Die Anwendung stellt nur die für die konkrete Aufgabe und den konkreten Nutzer erforderlichen Daten bereit.

Prüfen Sie außerdem, ob Eingaben oder Ausgaben beim KI-Anbieter gespeichert, zu Trainingszwecken verwendet oder in Drittländer übertragen werden. Ein Rechtekonzept innerhalb der Anwendung löst diese Fragen nicht. Die Claribill-Sicherheitsseite zeigt, welche technischen und organisatorischen Schutzthemen Unternehmen bei einem Rechnungsdienst grundsätzlich bewerten sollten. Diese Hinweise ersetzen keine individuelle Datenschutz- oder Rechtsberatung.

Drei Praxisbeispiele aus KMU

Beispiel 1: Überfällige Rechnungen priorisieren

Eine Mitarbeiterin im Vertrieb fragt: „Welche überfälligen Rechnungen meiner Kunden brauchen heute Aufmerksamkeit?“ Der Assistent darf nur Rechnungen sehen, die ihr zugeordnet oder mit ihr geteilt sind. Er liefert eine priorisierte Liste und nennt Fälligkeit sowie dokumentierten Kontakt. Rechnungen anderer Teams bleiben unsichtbar. Eine Mahnung wird erst als separater Vorschlag erzeugt.

Beispiel 2: Mahnung vorbereiten und senden

Ein Finanzmitarbeiter lässt einen Textentwurf erstellen. Betrag, Restforderung und Frist kommen aus dem Rechnungsdatensatz; der Assistent verändert diese Fakten nicht. Vor dem Versand zeigt die Anwendung Empfänger, Betreff, Text und Anhang. Erst der berechtigte Nutzer löst den Versand aus. Das entspricht dem im Claribill-Blog beschriebenen Vier-Augen-Prinzip im Rechnungsprozess, wenn das Unternehmen für Mahnungen eine zusätzliche Freigabe vorsieht.

Beispiel 3: Zahlung zuordnen

Der Assistent erkennt eine mögliche Übereinstimmung zwischen Bankumsatz und Rechnung. Er zeigt Betrag, Verwendungszweck, Kundenname und Abweichungen. Bei eindeutiger Übereinstimmung kann ein berechtigter Nutzer den Vorschlag übernehmen. Bei Teilzahlung, Sammelzahlung oder abweichendem Zahler bleibt der Fall offen. Der Assistent darf weder einen Differenzbetrag erfinden noch eine Forderung selbstständig als bezahlt markieren.

Typische Fehlerbilder

Ein gemeinsames Administratorkonto: Alle KI-Aktionen laufen unter einer technischen Identität mit Vollzugriff.
Rollen nur im Prompt: Eine Textanweisung wie „Du bist nur Leser“ ersetzt keine serverseitige Sperre.
Lesen und Schreiben im selben Werkzeug: Eine Zusammenfassung kann unbeabsichtigt zur Änderung oder Löschung führen.
Verdeckte Serienaktion: Eine einzelne Bestätigung löst den Versand an viele Empfänger aus, ohne die Liste zu zeigen.
Keine Prüfung des aktuellen Zustands: Der Assistent arbeitet mit einer alten Vorschau, obwohl Rechnung oder Empfänger inzwischen geändert wurden.
Zu umfangreiche Protokolle: Vollständige Dokumente und personenbezogene Prompts werden ohne Zweck dauerhaft gespeichert.

Auch manipulierte Anweisungen in Rechnungen oder Anhängen bleiben relevant. Ein Dokument darf den Assistenten nicht dazu bringen, seine Werkzeuge anders zu verwenden. Der Beitrag Prompt Injection in Rechnungen erklärt diesen Angriffsweg im Detail. Das Rechtekonzept begrenzt den Schaden, selbst wenn eine Manipulation nicht rechtzeitig erkannt wird.

Checkliste für einen sicheren Pilotbetrieb

Ist der konkrete Anwendungsfall auf eine fachliche Aufgabe begrenzt?
Sind Lesen, Vorschlagen und Ausführen technisch getrennt?
Erbt jede Abfrage Unternehmen, Rolle und Dokumentfreigaben des Nutzers?
Besitzt jedes Werkzeug nur die minimal erforderlichen Funktionen und Rechte?
Werden Berechtigungen bei jedem Aufruf serverseitig erneut geprüft?
Zeigt die Freigabe alle betroffenen Belege, Empfänger und Änderungen?
Verhindern Idempotenz und Statusprüfungen doppelte oder veraltete Aktionen?
Kann der KI-Zugang zentral deaktiviert und ein laufender Vorgang gestoppt werden?
Protokolliert das System Akteur, Werkzeug, Freigabe und Ergebnis ohne unnötige Inhaltskopien?
Sind Aufbewahrung, Anbieterzugriff, Trainingsnutzung und Datenübermittlung geklärt?
Werden Fehlversuche, Rechteverstöße und ungewöhnliche Serienaktionen überwacht?
Testet das Unternehmen den Ablauf mit absichtlich falschen und manipulierten Eingaben?

Häufige Fragen

Darf ein KI-Assistent Rechnungen automatisch versenden?

Technisch ist das möglich. Für einen sicheren KMU-Prozess sollte der Versand jedoch ein eng begrenztes Werkzeug mit serverseitiger Berechtigungsprüfung, konkreter Vorschau und menschlicher Freigabe sein. Vollautomatik braucht eine eigene Risikoentscheidung und deutlich strengere Grenzen.

Reicht die normale Benutzerrolle aus?

Sie ist die Grundlage, reicht aber nur, wenn jeder Daten- und Werkzeugaufruf diese Rolle tatsächlich übernimmt. Ein privilegiertes Sammelkonto hinter dem Assistenten würde die sichtbare Benutzerrolle umgehen.

Muss jede KI-Antwort freigegeben werden?

Nicht jede reine Auskunft braucht eine formale Freigabe. Entscheidend ist die Wirkung. Sobald eine Antwort Daten verändert, etwas versendet, einen Status setzt oder eine externe Folge auslöst, sollte die konkrete Aktion bestätigt und protokolliert werden.

Fazit

Ein sicherer KI-Assistent ist kein digitaler Geschäftsführer mit Generalvollmacht. Er liest im Nutzerkontext, erstellt nachvollziehbare Vorschläge und führt nur eng definierte, erneut autorisierte Aktionen aus. Diese Architektur verbindet praktischen Nutzen mit Rollen, Datenschutz und interner Kontrolle. Sie bleibt wirksam, wenn ein Modell irrt oder ein Dokument manipulierte Anweisungen enthält.

Lesen, vorschlagen, ausführen: So begrenzen KMU die Rechte von KI-Assistenten