Datenmanagement
Eine Implementierung unter Zuhilfenahme von Open-Source-Komponenten setzt ein föderiertes Datenmanagement voraus. Das bedeutet, dass die Daten nicht zentral in einem einzigen System gespeichert werden, sondern in mehreren, voneinander unabhängigen, aber miteinander vernetzten Systemen verwaltet werden. Jedes dieser Systeme behält dabei die Kontrolle über seine eigenen Daten, während durch gemeinsame Schnittstellen, Standards und Richtlinien ein übergreifender Zugriff und Austausch ermöglicht wird. Auf diese Weise kann ein integriertes Gesamtsystem entstehen, das verschiedene Open-Source-Tools effektiv verbindet, ohne dass die Datenhoheit oder -sicherheit einzelner Bereiche verloren geht. Das Datenmanagement umfasst dabei auf folgende Aspekte:
- User Management
- Berechtigungskonzept
- Authentifizierung
- Chatverlauf
- Prompt-Verwaltung
- Wissensbasis für RAG
- Modell-Repository & Registry
- Token-Verbrauchs & Spent-Management
- Modell-Berechtigungen
- Logging und Tracing-Daten

Identity & Access-Management (IAM)
Das IAM-System basiert auf einem Service Account-Modell mit zweistufiger Authentifizierung.
Fachliches Datenmodell
Das Datenmodell der KIVA-Plattform gliedert sich in mehrere Kernbereiche:
Service Account Management
- Service Accounts: Zweckgebundene Authentifizierungseinheiten mit eigenen Budgets und Berechtigungen
- API-Schlüssel: Token für Service Account-Authentifizierung mit konfigurierbaren Berechtigungen
- Budget & Limits: Token-Budgets, Rate-Limits (TPM/RPM) und Kostenkontrolle pro Service Account
Organisationsstrukturen (Keycloak, OpenID Connect)
- Benutzer: Individuelle Nutzer mit Profilen und Rollen
- Teams: Gruppierung von Benutzern für gemeinsame Projekte
- Organisationen: Übergeordnete Struktureinheiten für Mandantentrennung
- Kostenstellen: Zuordnung für Budgetierung und Abrechnung
KI-spezifische Daten
- Modell-Registry: Verfügbare LLM-Modelle mit Metadaten und Versionierung
- Prompt-Store: Verwaltung und Versionierung von Prompt-Templates
- Chatverlauf: Persistierung von Konversationen mit Zuordnung zu Service Accounts/Benutzern
- Wissensbasis: RAG-Datenquellen und Vektordatenbanken für kontextuelle Antworten
Monitoring & Compliance
- Request Audit Log: Vollständige Aufzeichnung aller API-Anfragen mit Service Account und optionaler Benutzerzuordnung
- Token-Verbrauch: Tracking von Input-/Output-Tokens für Kostenberechnung
- System-Logs: Technische Logs für Debugging und Systemüberwachung
- Tracing-Daten: Verteilte Traces für Performance-Analyse
Föderierte Datenhaltung
Die Daten werden über verschiedene Komponenten verteilt gespeichert:
- PostgreSQL: Strukturierte Daten (Service Accounts, Benutzer, Audit-Logs)
- ChromaDB: Vektordatenbank für Embeddings und semantische Suche
- Prometheus: Metriken und Zeitreihendaten
- Komponenten-spezifische Stores: Jede Komponente verwaltet ihre eigenen Konfigurationsdaten