LLM-Analytics braucht harte Datengrenzen

AWS beschreibt gemeinsam mit PAR Technology eine produktive Architektur für Multi-Tenant-LLM-Analytics. Der Kern ist nicht der Text-to-SQL-Agent selbst, sondern eine klare Sicherheitsgrenze: Das Modell darf Abfragen formulieren, aber es darf nicht die Mandantentrennung garantieren.

Für Unternehmen ist das relevant, weil Self-Service-Analytics mit natürlicher Sprache sehr schnell an sensible Daten stößt. Eine Frage wie „Wie hoch war der Umsatz letzte Woche?“ kann je nach Rolle einen Filialwert, einen Markenwert oder eine Konzernzahl bedeuten. Wenn der Agent diese Grenze nur per Prompt beachten soll, wird die Governance zur Wahrscheinlichkeit.

Was AWS und PAR konkret zeigen

PAR nutzt laut AWS eine dreischichtige Architektur: kryptografisch signierte Requests mit AWS SigV4, semantische Validierung über Amazon Bedrock und programmatische Datenisolation durch Split-Plane SQL. Jede Schicht soll unabhängig verhindern, dass eine generierte Abfrage Daten eines falschen Mandanten liest.

Das ist der entscheidende Punkt: Das LLM wird nicht als Policy Engine behandelt. AWS formuliert explizit, dass ein Modell Filter zehntausendmal richtig setzen und beim nächsten Mal trotzdem auslassen oder falsch interpretieren kann. Für Multi-Tenant-Systeme mit Geschäfts- oder Kundendaten reicht diese Nicht-Deterministik nicht als Kontrollmechanismus.

Warum das in DACH-Projekten zählt

OWASP listet in den Gen-AI-Top-10 unter anderem Prompt Injection, Sensitive Information Disclosure, Improper Output Handling und Excessive Agency. Genau diese Risiken werden praktisch, sobald ein Agent Datenbankabfragen erzeugt, Tools ausführt oder Ergebnisse ungeprüft weitergibt.

Für CIOs und CFOs ist deshalb nicht die Demo entscheidend, sondern die Architekturfrage: Wo liegt die verbindliche Datenautorisierung? In der Datenbank, im Gateway, in einer Policy-Schicht oder nur im Prompt? Amazon Redshift dokumentiert Row-Level Security als Datenbankmechanismus, der Zeilen anhand von Policies sichtbar macht. Solche harten Grenzen sind für KI-Analytics belastbarer als Modellinstruktionen.

Was jetzt sinnvoll ist

Starten Sie Natural-Language-Analytics nicht mit einem breiten Datenkatalog. Wählen Sie einen begrenzten Datensatz, definieren Sie Rollen, Mandanten-IDs, erlaubte Metriken und Testfälle für Grenzüberschreitungen. Erst danach sollte ein LLM SQL generieren dürfen.

Die Leitfrage lautet: „Kann der Agent eine falsche Abfrage erzeugen, ohne falsche Daten zu sehen?“ Wenn die Antwort Nein ist, ist die Sicherheitsarchitektur noch nicht fertig.