Diseñar un agente SQL de solo lectura con Make

Un agente SQL convierte preguntas en lenguaje natural en consultas y devuelve una explicación de los resultados. Esta adaptación se basa en la guía oficial de Make, capturada el 3 de julio de 2026. La consulta del 26 de septiembre de 2026 devolvió HTTP 403.

La propuesta sirve como diseño de un flujo controlado, no como garantía de seguridad ni como confirmación del catálogo actual de módulos, proveedores o planes. Un modelo puede generar SQL incorrecto aunque la respuesta parezca convincente.

Las precisiones sobre autenticación, validación SQL, consultas predefinidas y revisión humana son aportaciones editoriales de seguridad, no prestaciones atribuidas a un módulo de Make. No se ha ejecutado este flujo contra una base de datos real.

Preparar un entorno limitado

Empieza con una base de pruebas o una réplica autorizada. El usuario de base de datos debe tener acceso de solo lectura únicamente a las tablas o vistas necesarias. No utilices una cuenta administrativa.

Prepara un catálogo con nombres de tablas, columnas, tipos y significado de los datos. Excluye los campos que no deban consultar los usuarios o recibir el proveedor del modelo. Define quién puede formular preguntas y quién revisará las consultas rechazadas.

1. Recibir la pregunta

La fuente propone un webhook o un canal de mensajería. El flujo debe recibir la pregunta y los identificadores necesarios para devolver la respuesta y registrar la solicitud.

Un campo como user_id enviado por el cliente no demuestra su identidad. La autenticación y la autorización deben resolverse antes de permitir acceso a datos.

2. Cargar el esquema autorizado

Recupera el catálogo correspondiente a esa base y a ese usuario. No entregues al modelo un inventario completo si solo necesita una vista de informes. Si el esquema ha cambiado, actualízalo antes de generar otra consulta.

3. Pedir una propuesta de SQL

Envía al modelo la pregunta y el esquema permitido. Pide una respuesta estructurada con la consulta y una explicación de su propósito. Si falta información —por ejemplo, el período de un informe—, el flujo debe solicitar una aclaración en lugar de inventarla.

La salida estructurada y una temperatura baja no garantizan SQL válido ni resultados deterministas. Trata la respuesta como una propuesta pendiente de validación.

4. Validar antes de ejecutar

La guía sugiere restringir la operación a lectura y rechazar tablas no permitidas. Aplica esas restricciones también en los permisos reales de la base de datos.

Un Router distribuye rutas; no es un analizador SQL. Un filtro de palabras como DELETE o DROP tampoco constituye una barrera completa. Para el primer piloto, utiliza consultas predefinidas con parámetros o exige revisión humana de la consulta generada. Si más adelante automatizas la validación, usa un mecanismo que comprenda el dialecto SQL.

Parametriza los valores cuando el conector lo permita; no confundas parametrizar un valor con validar una sentencia completa generada por un modelo.

5. Ejecutar con límites

Ejecuta solo consultas aprobadas mediante una conexión de solo lectura. Define límites de duración y volumen en la base de datos o en el mecanismo de ejecución disponible. Una consulta de lectura puede consumir muchos recursos o revelar información que el solicitante no debe ver.

Ante errores de sintaxis o permisos, devuelve el caso a revisión. No aumentes permisos ni repitas indefinidamente una consulta fallida para hacerla funcionar.

6. Construir y entregar la respuesta

Agrupa únicamente las filas necesarias y redacta una explicación que conserve el período, los filtros y las unidades del resultado. Comprueba los números contra la salida de la base: el texto del modelo no sustituye a los datos.

Entrega la respuesta solo al destinatario autorizado. Registra la consulta, el estado, el número de filas y la duración según la política de tu organización, evitando copiar datos sensibles a registros compartidos.

7. Probar el flujo completo

Mantén el escenario inactivo hasta comprobar:

• Una pregunta con respuesta conocida devuelve el resultado esperado.
• Una pregunta ambigua solicita aclaración.
• Una solicitud de modificar datos se rechaza.
• Una consulta sobre una tabla no autorizada no se ejecuta.
• Un resultado vacío se explica sin inventar información.
• Un error de conexión o de tiempo límite produce una salida controlada.

Amplía el catálogo solo después de revisar estas pruebas. Esta guía no determina qué plan contratar ni autoriza conectar un agente a producción.