Nicht alle Daten in dieselben Tabellen mischen
Eine KI-Anwendung verarbeitet sehr unterschiedliche Datenarten: transaktionale Fachdaten, Dokumente, Embeddings, Konversationen, Prompts, Modellantworten, technische Traces und Audit-Daten.
Werden sie ohne klare Trennung vermischt, entstehen schnell Probleme bei Performance, Governance und Sicherheit. Eine gute Architektur beginnt damit, die Verantwortung jedes Speicherbereichs festzulegen.
PostgreSQL kann durchaus das Herz des Systems bleiben, doch Schemas und Tabellen sollten nach ihrem Zweck organisiert sein, nicht nach Bequemlichkeit in der Entwicklung.
Der transaktionale Kern bleibt relational
Kritische Fachobjekte sollten weiterhin mit Beziehungen, Constraints, Fremdschlüsseln, Indizes und Transaktionen modelliert werden. KI ersetzt keine relationale Konsistenz.
Kunden, Benutzer, Verträge, Einsätze, Bestellungen und Zugriffsrechte brauchen stabile Kennungen und strenge Integritätsregeln.
Diese Schicht ist die Quelle der Wahrheit. KI-Prozesse reichern sie an, dürfen aber nicht zur einzigen Darstellung des fachlichen Zustands werden.
Dokumente, Chunks und Embeddings trennen
In einer RAG-Architektur ist es sinnvoll, Quelldokument, Dokumentversionen, erzeugte Chunks und zugehörige Embeddings zu trennen.
Jeder Chunk sollte einen Verweis auf sein Dokument, die Versionsnummer, seine Position, fachliche Metadaten und optional einen Hash behalten. So bleibt die Herkunft einer Antwort nachvollziehbar.
Mit pgvector können Embeddings in PostgreSQL liegen, doch Vektorindizes, Filterstrategie und konsistentes Löschen bei Dokumentänderungen müssen eingeplant werden.
KI-Aufrufe protokollieren, ohne alles zu speichern
Um ein KI-System zu analysieren, müssen Teams das verwendete Modell, die Latenz, den Status, die ungefähren Kosten, die Prompt-Version und Fehler nachvollziehen können.
Werden jedoch vollständige Prompts und alle übermittelten Werte systematisch gespeichert, entsteht womöglich eine dauerhafte Kopie sensibler Informationen.
Besser ist es, technische Metadaten vom Inhalt zu trennen, sensible Felder zu maskieren und eine angemessene Aufbewahrungsdauer festzulegen.
Mandantenfähigkeit und Sicherheit im Datenmodell verankern
In einem KI-SaaS für mehrere Unternehmen sollte jeder Fachdatensatz, jedes Dokument, jeder Chunk, jede Konversation und jede Trace ausdrücklich einer Organisation oder einem Mandanten zugeordnet sein.
Mandantenfilter dürfen nicht nur in der Oberfläche existieren. Sie müssen im Backend durchgesetzt und bei Bedarf mit PostgreSQL Row Level Security verstärkt werden.
Diese Disziplin wird noch wichtiger bei KI-Agenten, die mehrere Werkzeuge und Datenquellen verketten können.
Eine Referenzstruktur
Eine einfache Struktur kann die Schemas logical_business, ai_knowledge, ai_runtime und audit trennen. Die Namen sind weniger wichtig als die Trennung der Verantwortlichkeiten.
Das Fachschema enthält die transaktionalen Objekte. Das Wissensschema enthält Dokumente, Chunks und Embeddings. Runtime enthält Konversationen, Agentenausführungen und Ergebnisse. Audit speichert die Ereignisse zur Nachvollziehbarkeit.
Diese Organisation erleichtert Migrationen, Aufbewahrungsrichtlinien, Berechtigungen und Auswertungen erheblich, wenn die Anwendung wächst.
