Dashboards wirken auf den ersten Blick harmlos. Sie zeigen Kennzahlen, Entwicklungen, Verteilungen und Vergleiche. In einem Family-Office-Kontext steckt dahinter aber ein sicherheitskritischer Datenzugriff: Gesellschaften, Vermögenswerte, Assetnamen, Exposures, Fälligkeiten, Verbindlichkeiten, Währungen, Regionen und teilweise auch technische Herkunftsinformationen.
Wenn ein Agent solche Dashboards erstellen oder aktualisieren soll, reicht es nicht, ihm einfach eine Datenbankverbindung zu geben und darauf zu vertrauen, dass er nur die richtigen Fragen stellt. Das eigentliche Risiko liegt nicht im Diagramm. Es liegt in der Frage, welche Daten der Agent sehen darf, welche Daten er nicht sehen darf und ob diese Grenze technisch durchgesetzt wird.
Das entwickelte Konzept macht deshalb aus dem Vorgang „Agent baut Dashboard“ einen kontrollierten Prozess: Der Agent hilft bei Struktur, Planung und Umsetzung. Die Entscheidung über Datenzugriff, Quellen, Spalten, Körnung, Status und Audit liegt aber beim Gateway.
Der Kern des Konzepts
Im Mittelpunkt steht ein Semantic Dashboard Gateway für Assetmanager-Dashboards. Der Agent arbeitet nicht direkt auf SQL-Tabellen und formuliert keine freien produktiven SQL-Abfragen. Stattdessen bewegt er sich innerhalb definierter Dashboard-Klassen.
Der Ablauf ist klar getrennt:
- Ein Nutzer fordert ein Dashboard an oder möchte ein bestehendes Dashboard aktualisieren.
- Der Dashboard-Finder prüft zuerst, ob es bereits ein passendes Dashboard gibt.
- Die Registry liefert Metadaten, Status, Version und vorhandene Artefakte.
- Der Agent erzeugt einen Dashboard-Plan innerhalb einer erlaubten Klasse.
- Das Gateway prüft Klasse, Parameter, Quellen, Spalten, Körnung und Limits.
- Nur freigegebene Assetmanager-Views, Query-Templates oder Helper-Routen werden verwendet.
- Das Dashboard wird versioniert, validiert, mit Fingerprints versehen und registriert.
Damit wird der Agent vom freien Datenbanknutzer zum kontrollierten Planer. Er darf fachlich helfen, aber nicht selbst über Credentials, Tabellenzugriff, Mandantenfilter, SQL-Logik, Statusregeln oder Audit-Ausnahmen entscheiden.
Die Dashboard-Taxonomie
Ein wichtiger Bestandteil ist die Taxonomie der Dashboard-Klassen. Die vorhandenen Assetmanager-Dashboards werden nicht mehr als lose Einzelfälle behandelt, sondern als Instanzen klar definierter Klassen.
Jede Klasse beschreibt, was erlaubt ist: Scope, Datenkörnung, erlaubte Views, erlaubte Spalten, Parameter, Outputs, Statusregeln, Zeilenlimits und Validierungspflichten.
Das ist entscheidend, weil ein Portfolio-Dashboard nicht plötzlich zum Rohdatenbrowser werden darf. Ein Single-Asset-Dashboard darf nicht heimlich technische IDs, IBANs oder Depotnummern ausgeben. Und ein Liquiditätsdashboard darf nicht finalisiert werden, solange die fachliche Definition liquider Mittel noch offen ist.
Quellen werden bewusst getrennt
Das Konzept unterscheidet mehrere Quellenklassen.
internal_sql umfasst Assetmanager-Daten aus PostgreSQL: Vermögenswerte, Gesellschaften, Assets, Exposures, Fälligkeiten, Verbindlichkeiten und daraus abgeleitete Kennzahlen. Diese Daten sind schutzbedürftig und werden streng kontrolliert.
local_import umfasst lokale Importdateien, Exporte oder Zwischendateien. Sie können fachlich relevant sein, dürfen aber nicht automatisch als autorisierte Datenquelle gelten. Auch hier braucht es Herkunft, Zeitraum, Mapping, Transformationslogik und Freigabe.
public_research umfasst öffentlich recherchierte Informationen wie Inflationsdaten, Marktindizes, makroökonomische Daten oder regulatorischen Kontext. Diese Daten sind weniger vertraulich, weil sie nicht aus dem internen Family-Office-Datenbestand stammen. Trotzdem brauchen sie Kontrolle: Quelle, Abrufdatum, Zeitraum, Transformationslogik und Hash müssen dokumentiert werden.
generated_artifact umfasst vom Agenten erzeugte Texte, Zusammenfassungen, Labels oder Interpretationen. Solche Inhalte können ein Dashboard verständlicher machen, dürfen aber nicht mit geprüften Daten verwechselt werden.
Der Unterschied ist wichtig. Öffentliche Daten dürfen ein internes Dashboard erklären oder kontextualisieren. Sie dürfen aber keine internen SQL-Kennzahlen überschreiben und nicht so dargestellt werden, als kämen sie aus dem Assetmanager. Bei gemischten Dashboards braucht es deshalb eine Evidence Map: Jede zentrale Aussage muss auf ihre Quelle zurückführbar sein.
Was der Ist-Check gezeigt hat
Die Prüfung der vorhandenen Views hat zwei konkrete Punkte sichtbar gemacht.
Erstens liefert list_views nicht nur die fachlich relevanten etl_dashboard-Views, sondern auch information_schema und pg_catalog. Für einen Agent-Control-Test ist das ein klarer Hinweis: Discovery muss im Gateway begrenzt werden. Der Agent soll keine Systemkataloge explorieren.
Zweitens enthalten breite Views zu viele Felder, die für Dashboards nicht pauschal freigegeben werden dürfen. Dazu gehören technische IDs, Hashes, Benutzerfelder, IBAN, Depotnummern und andere interne Spalten. Deshalb ist SELECT * auf solchen Views nicht nur schlechter Stil, sondern eine echte Kontrolllücke.
Die Konsequenz ist eine Allowlist: Aggregierte Start-Views können direkt als Dashboard-Quelle dienen. Breite Vermögens-Views dürfen nur über freigegebene Query-Templates mit expliziten Spaltenlisten verwendet werden.
Was das Konzept verhindert
Das Konzept verhindert vor allem, dass ein Dashboard-Wunsch zu freier Datenbank-Exploration wird.
Konkret verhindert es:
- freie SQL-Abfragen durch den Agenten
SELECT *auf breiten Views mit sensiblen oder technischen Feldern- Zugriff auf interne Schemas und Systemkataloge
- unkontrollierte Dashboard-Neuerstellungen ohne vorherige Registry-Prüfung
- Vermischung von internen SQL-Daten, lokalen Importen und öffentlicher Recherche ohne Quellenkennzeichnung
- feinere Datenkörnung, als die jeweilige Dashboard-Klasse erlaubt
- Status-Umgehungen, bei denen ein fachlich offener Draft als final markiert wird
- nicht reproduzierbare Dashboard-Versionen ohne Metadaten, Quellen, Parameter, Fingerprints, Validierungsnotizen und Registry-Eintrag
Damit wird Sicherheit nicht in den Prompt ausgelagert. Sie wird in der Architektur durchgesetzt.
Warum das praktisch relevant ist
Der Nutzen liegt nicht nur in Sicherheit. Die Architektur macht Dashboards auch wartbarer.
Wenn das interne SQL-Modell geändert wird, muss nicht jeder Agent-Prompt angepasst werden. Entscheidend ist der stabile Datenvertrag: Dashboard-Klasse, erlaubte Views, erlaubte Spalten und erlaubte Outputs. Solange dieser Vertrag stabil bleibt, kann sich die technische Datenbasis darunter weiterentwickeln.
Gleichzeitig wird klarer, welche Dashboards fachlich belastbar sind. Ein Dashboard mit vollständigem Fingerprint, dokumentierten Quellen und bestandener Validierung kann anders bewertet werden als ein Draft mit offenen Annahmen. Das ist besonders wichtig bei Liquiditätsplanung, Datenqualität und gemischten Dashboards mit öffentlichen Kontextdaten.
Das Konzept verschiebt die Rolle des Agenten
Er ist nicht Besitzer des Datenzugriffs, sondern kontrollierter Planer innerhalb eines definierten Dashboard-Systems.
Die harten Entscheidungen liegen im Gateway, im Datenvertrag, in der Registry, in den Fingerprints und in den Release-Gate-Tests. Genau dort gehören sie hin.
So entsteht aus Assetmanager-Dashboards kein unkontrollierter Analysekanal, sondern ein nachvollziehbarer, versionierter und prüfbarer Prozess: bekannte Dashboard-Klasse, erlaubte Quellen, erlaubte Spalten, erlaubte Körnung, harte Limits, Validierung und Audit.
Schreibe einen Kommentar