No mezclar todos los datos en las mismas tablas
Una aplicación de IA maneja clases de datos muy distintas: datos transaccionales de negocio, documentos, embeddings, conversaciones, prompts, respuestas del modelo, trazas técnicas y datos de auditoría.
Mezclarlos sin una separación clara genera rápidamente problemas de rendimiento, gobernanza y seguridad. Una buena arquitectura empieza por identificar la responsabilidad de cada espacio de almacenamiento.
PostgreSQL puede seguir siendo perfectamente el núcleo del sistema, pero los esquemas y las tablas deben organizarse según su finalidad y no según la comodidad del desarrollo.
El núcleo transaccional sigue siendo relacional
Las entidades de negocio críticas deben seguir modelándose con relaciones, restricciones, claves foráneas, índices y transacciones. La IA no sustituye la coherencia relacional.
Clientes, usuarios, contratos, intervenciones, pedidos y derechos de acceso deben conservar identificadores estables y reglas de integridad estrictas.
Esta capa es la fuente de verdad. Los procesos de IA la enriquecen, pero no deben convertirse en la única representación del estado del negocio.
Separar documentos, fragmentos y embeddings
En una arquitectura RAG conviene separar el documento de origen, sus versiones, los fragmentos generados y los embeddings asociados.
Cada fragmento debe conservar una referencia a su documento, el número de versión, su posición, metadatos de negocio y, opcionalmente, un hash. Así se preserva el origen de las respuestas.
Con pgvector, los embeddings pueden residir en PostgreSQL, pero hay que planificar los índices vectoriales, la estrategia de filtrado y la eliminación coherente cuando se actualiza un documento.
Registrar las llamadas a la IA sin almacenarlo todo
Para diagnosticar un sistema de IA, los equipos necesitan recuperar el modelo utilizado, la latencia, el estado, el coste aproximado, la versión del prompt y los errores.
Sin embargo, almacenar sistemáticamente los prompts completos y todos los valores transmitidos puede crear una copia permanente de información sensible.
Es preferible separar los metadatos técnicos del contenido, enmascarar los campos sensibles y definir un periodo de conservación adecuado.
Integrar el multitenant y la seguridad en el modelo de datos
En un SaaS de IA para varias empresas, cada registro de negocio, documento, fragmento, conversación y traza debe estar vinculado explícitamente a una organización o tenant.
Los filtros por tenant no deben existir solo en la interfaz. Deben aplicarse en el backend y, cuando proceda, reforzarse con Row Level Security de PostgreSQL.
Esta disciplina es aún más importante con agentes de IA capaces de encadenar varias herramientas y fuentes de datos.
Una estructura de referencia
Una estructura sencilla puede separar los esquemas logical_business, ai_knowledge, ai_runtime y audit. Los nombres importan menos que la separación de responsabilidades.
El esquema de negocio contiene las entidades transaccionales. El esquema de conocimiento contiene documentos, fragmentos y embeddings. Runtime contiene conversaciones, ejecuciones de agentes y resultados. Audit almacena los eventos de trazabilidad.
Esta organización facilita mucho el control de las migraciones, las políticas de conservación, los permisos y la analítica a medida que la aplicación crece.
