Niet alle data in dezelfde tabellen mengen
Een AI-applicatie verwerkt zeer uiteenlopende soorten data: transactionele bedrijfsdata, documenten, embeddings, gesprekken, prompts, modelantwoorden, technische traces en auditgegevens.
Wie ze zonder duidelijke scheiding mengt, krijgt al snel problemen met prestaties, governance en beveiliging. Een goede architectuur begint met het bepalen van de verantwoordelijkheid van elke opslagruimte.
PostgreSQL kan prima het hart van het systeem blijven, maar schema’s en tabellen moeten worden georganiseerd naar hun doel en niet naar wat tijdens de ontwikkeling handig is.
De transactionele kern blijft relationeel
Kritieke bedrijfsentiteiten moeten gemodelleerd blijven met relaties, constraints, foreign keys, indexen en transacties. AI vervangt geen relationele consistentie.
Klanten, gebruikers, contracten, interventies, bestellingen en toegangsrechten moeten stabiele identificatoren en strikte integriteitsregels behouden.
Deze laag is de bron van waarheid. AI-processen verrijken haar, maar mogen niet de enige weergave van de bedrijfstoestand worden.
Documenten, chunks en embeddings scheiden
In een RAG-architectuur is het nuttig om het brondocument, de documentversies, de gegenereerde chunks en de bijbehorende embeddings te scheiden.
Elke chunk moet een verwijzing naar zijn document, het versienummer, zijn positie, bedrijfsmetadata en eventueel een hash behouden. Zo blijft de herkomst van antwoorden traceerbaar.
Met pgvector kunnen embeddings in PostgreSQL staan, maar vectorindexen, de filterstrategie en consistente verwijdering bij documentwijzigingen moeten worden gepland.
AI-aanroepen loggen zonder alles op te slaan
Om een AI-systeem te analyseren, moeten teams het gebruikte model, de latentie, de status, de geschatte kosten, de promptversie en fouten kunnen terugvinden.
Het stelselmatig opslaan van volledige prompts en alle verzonden waarden kan echter een permanente kopie van gevoelige informatie opleveren.
Beter is het om technische metadata van de inhoud te scheiden, gevoelige velden te maskeren en een passende bewaartermijn vast te leggen.
Multi-tenancy en beveiliging in het datamodel inbouwen
In een AI-SaaS voor meerdere bedrijven moet elk bedrijfsrecord, document, chunk, gesprek en elke trace expliciet aan een organisatie of tenant zijn gekoppeld.
Tenantfilters mogen niet alleen in de interface bestaan. Ze moeten in de backend worden afgedwongen en waar nodig worden versterkt met PostgreSQL Row Level Security.
Deze discipline wordt nog belangrijker bij AI-agents die meerdere tools en databronnen aan elkaar kunnen koppelen.
Een referentiestructuur
Een eenvoudige structuur kan de schema’s logical_business, ai_knowledge, ai_runtime en audit scheiden. De namen zijn minder belangrijk dan de scheiding van verantwoordelijkheden.
Het bedrijfsschema bevat de transactionele entiteiten. Het kennisschema bevat documenten, chunks en embeddings. Runtime bevat gesprekken, uitvoeringen van agents en resultaten. Audit bewaart de traceerbaarheidsgebeurtenissen.
Deze organisatie maakt migraties, bewaarbeleid, rechten en analyses veel beter beheersbaar naarmate de applicatie groeit.
