Não misturar todos os dados nas mesmas tabelas
Uma aplicação de IA lida com categorias de dados muito diferentes: dados transacionais de negócio, documentos, embeddings, conversas, prompts, respostas do modelo, registos técnicos e dados de auditoria.
Misturá-los sem uma separação clara cria rapidamente problemas de desempenho, governação e segurança. Uma boa arquitetura começa por identificar a responsabilidade de cada espaço de armazenamento.
O PostgreSQL pode perfeitamente continuar a ser o núcleo do sistema, mas os esquemas e as tabelas devem ser organizados pela sua finalidade e não pela conveniência do desenvolvimento.
O núcleo transacional continua relacional
As entidades de negócio críticas devem continuar a ser modeladas com relações, restrições, chaves estrangeiras, índices e transações. A IA não substitui a coerência relacional.
Clientes, utilizadores, contratos, intervenções, encomendas e direitos de acesso devem manter identificadores estáveis e regras de integridade rigorosas.
Esta camada é a fonte de verdade. Os processos de IA enriquecem-na, mas não se devem tornar a única representação do estado do negócio.
Separar documentos, fragmentos e embeddings
Numa arquitetura RAG, é útil separar o documento de origem, as suas versões, os fragmentos gerados e os embeddings associados.
Cada fragmento deve manter uma referência ao seu documento, o número de versão, a posição, metadados de negócio e, opcionalmente, um hash. Assim se preserva a proveniência das respostas.
Com o pgvector, os embeddings podem ficar no PostgreSQL, mas é preciso planear os índices vetoriais, a estratégia de filtragem e a eliminação coerente quando um documento é atualizado.
Registar as chamadas à IA sem guardar tudo
Para diagnosticar um sistema de IA, as equipas precisam de recuperar o modelo utilizado, a latência, o estado, o custo aproximado, a versão do prompt e os erros.
No entanto, guardar sistematicamente os prompts completos e todos os valores transmitidos pode criar uma cópia permanente de informação sensível.
É preferível separar os metadados técnicos do conteúdo, mascarar os campos sensíveis e definir um período de conservação adequado.
Integrar o multi-tenant e a segurança no modelo de dados
Num SaaS de IA para várias empresas, cada registo de negócio, documento, fragmento, conversa e registo técnico deve estar explicitamente ligado a uma organização ou tenant.
Os filtros por tenant não devem existir apenas na interface. Devem ser aplicados no backend e, quando adequado, reforçados com a Row Level Security do PostgreSQL.
Esta disciplina torna-se ainda mais importante com agentes de IA capazes de encadear várias ferramentas e fontes de dados.
Uma estrutura de referência
Uma estrutura simples pode separar os esquemas logical_business, ai_knowledge, ai_runtime e audit. Os nomes importam menos do que a separação de responsabilidades.
O esquema de negócio contém as entidades transacionais. O esquema de conhecimento contém documentos, fragmentos e embeddings. O runtime contém conversas, execuções de agentes e resultados. O audit guarda os eventos de rastreabilidade.
Esta organização torna muito mais fácil controlar migrações, políticas de conservação, permissões e análises à medida que a aplicação cresce.
