Cómo dejar que la IA consulte tu base de datos sin darle las llaves

«¿Qué clientes han bajado pedidos este trimestre?». Es la pregunta que dirección quiere hacer sin escribir un correo a sistemas ni esperar una hoja de cálculo. Los modelos de lenguaje lo hacen posible, pero la forma más obvia de construirlo —darle al modelo acceso a la base de datos y dejar que escriba SQL— es también la más arriesgada.

Esta guía explica el patrón alternativo que apliqué en AtalayaIQ, una capa de inteligencia sobre siete años de datos operativos de una empresa de eventos: el modelo decide qué preguntar; el servidor decide cómo.

El problema de dejar que el modelo escriba SQL

Un asistente «texto a SQL» parece magia en una demo. En producción plantea tres riesgos:

• Seguridad. El SQL libre amplía las consultas que puede intentar ejecutar el sistema. Lo que realmente puede leer depende de los permisos de su conexión; si son demasiado amplios, puede exponer nóminas, datos personales o información ajena a la tarea. Una instrucción maliciosa escondida en un dato puede intentar aprovechar ese acceso.
• Exactitud. Una consulta sintácticamente correcta puede responder otra pregunta. Si une mal dos tablas o ignora registros anulados, devuelve una cifra equivocada con total seguridad.
• Trazabilidad. Si cada respuesta sale de una consulta distinta e improvisada, nadie puede validar de dónde sale una cifra ni repetirla mañana.

El patrón: un catálogo cerrado de operaciones

En lugar de SQL libre, se define un catálogo de operaciones. Cada operación es una consulta escrita y revisada por una persona, con parámetros acotados.

El modelo recibe la pregunta y la lista de operaciones disponibles. Su único trabajo es elegir la operación y rellenar los parámetros. El servidor valida esos parámetros, ejecuta la consulta fija con un usuario de solo lectura y devuelve el resultado al modelo para que lo redacte.

En AtalayaIQ eso se traduce en cuatro garantías:

1. El modelo no escribe SQL ni ve credenciales.
2. Solo lectura impuesta en cada conexión, no confiada a la buena voluntad del código.
3. Al proveedor de IA solo viajan la pregunta y resultados agregados, nunca la tabla completa.
4. Los nombres de personas se ocultan salvo activación expresa.

Antes del asistente: el contrato de datos

El catálogo solo es tan bueno como la comprensión de los datos. Antes de escribir una línea del asistente redactamos un contrato de datos: qué significa cada tabla y cada campo, verificado con quien lo usa a diario.

Ahí aparecen los problemas que un modelo nunca detectaría solo: horas que se registran con días de retraso, gastos que pueden solaparse entre tipos, un calendario de festivos incompleto. Por eso en AtalayaIQ cada día se compara con el anterior del mismo tipo y al mismo retraso de registro, y las cifras se concilian con consultas escritas a mano antes de publicarse.

También decidimos qué no calcular. La base no contenía presupuestos ni ingresos, así que margen, rentabilidad y previsiones quedaron fuera. Un asistente que inventa un margen es peor que uno que dice «ese dato no existe».

Reglas antes que IA

Las alertas del informe diario salen de siete reglas deterministas, no del modelo. La IA responde preguntas; no decide qué es una alerta. Así una alerta siempre tiene una definición escrita, una evidencia y se puede probar: el proyecto tiene 36 tests automatizados.

¿Y si preguntan algo fuera del catálogo?

Es la pregunta que más me hacen. La respuesta correcta es que el asistente lo diga y registre la pregunta. Ese registro es oro: muestra qué operaciones nuevas merece la pena añadir. El catálogo crece con el uso real, revisado por una persona, en lugar de abrirse al SQL libre.

Cuándo encaja este patrón

• Tienes años de datos en un ERP o gestor propio que nadie explota.
• Dirección hace siempre un conjunto parecido de preguntas.
• No puedes —o no quieres— migrar ni modificar el sistema original.
• Los datos son sensibles y necesitas controlar qué sale hacia el proveedor del modelo.

No encaja tan bien si necesitas exploración totalmente abierta por analistas: para eso existen herramientas de BI con su propio control de permisos.

Qué debe validar el servidor antes de consultar

Un catálogo cerrado necesita validaciones fuera del modelo. La operación debe estar permitida para la persona autenticada y sus parámetros tienen que respetar tipos, fechas, rangos y volumen máximo. El identificador del cliente o empresa autorizada debe obtenerse de la sesión y sus permisos, no aceptarse sin comprobar desde el texto de una pregunta.

La documentación de privilegios de PostgreSQL ilustra cómo se conceden permisos por objeto y operación. Es una referencia general, no la tecnología del gestor de AtalayaIQ, que utiliza MySQL. En cada motor hay que comprobar los privilegios efectivos de la conexión y evitar que el usuario de la aplicación tenga permisos innecesarios.

Una credencial de lectura reduce el riesgo de modificar registros, pero no resuelve por sí sola la confidencialidad ni la carga sobre producción. Limita también el acceso por vistas, campos o filtros autorizados y acuerda el tiempo máximo de las consultas.

Cómo comprobar que responde a la pregunta correcta

Prepara un conjunto de preguntas con operaciones y resultados esperados. Incluye sinónimos, periodos ambiguos, referencias a otras empresas y preguntas que no se pueden resolver. Evalúa por separado la elección de la operación, la ejecución y la explicación final.

Prueba una consulta sin filas: ¿significa que no hay actividad, que aún no se han cargado datos o que el filtro no coincide? La respuesta debe conservar esa distinción. También conviene mostrar fecha de corte, filtros y operación utilizada para que una persona pueda contrastarla.

El registro de ejecución debería permitir repetir el cálculo sin exponer información innecesaria. Conserva versión de la operación, parámetros autorizados, resultado de validación y estado. Si cambian las definiciones del negocio, actualiza las pruebas junto a las consultas.

Preguntas frecuentes sobre IA y bases de datos

¿Un catálogo de operaciones elimina todos los errores?

No. Una operación revisada puede contener un error o usar una definición incorrecta. El catálogo facilita delimitar, probar y reproducir el comportamiento; necesita revisión y conciliación con referencias independientes.

¿El modelo puede consultar datos personales?

Solo debería recibir los necesarios y autorizados para la tarea. Una agregación también puede revelar información si el grupo es muy pequeño. Revisa el contenido de los resultados, además de ocultar nombres.

¿Cómo se amplía el catálogo?

Registra preguntas no cubiertas, prioriza las que aportan valor y define nuevas operaciones con su contrato y pruebas. Una pregunta nueva no debería abrir automáticamente permisos ni habilitar consultas improvisadas.

¿Qué debo pedir en la entrega?

Catálogo documentado, permisos efectivos comprobados, contrato de datos, pruebas y trazabilidad de respuestas. La guía de integración con ERP ayuda a preparar el acceso, y la guía de costes explica cómo limitar el consumo.

Preguntas para cualquier proveedor

1. ¿El modelo escribe SQL o elige entre operaciones definidas?
2. ¿Con qué usuario y permisos se conecta a la base de datos?
3. ¿Qué datos exactos viajan al proveedor del modelo de IA?
4. ¿Qué pasa con una pregunta que el sistema no sabe responder?
5. ¿Cómo se comprueba que una cifra es correcta antes de enseñarla?
6. ¿Qué cifras no pueden calcularse con nuestros datos actuales?

Si un proveedor responde con soltura a estas seis preguntas, la conversación va bien encaminada.