Cómo auditar SQL generado por IA antes de usarlo

Por qué una consulta ejecutable puede estar equivocada

Una consulta SQL generada por IA puede compilar, ejecutarse y devolver filas sin responder correctamente a la pregunta de negocio. La base de datos ejecuta las operaciones que recibe; no sabe si una suma representa la métrica que el equipo llama «ingresos», si el periodo elegido es el adecuado o si un JOIN duplicó registros. La sintaxis correcta es solo una condición de ejecución, no una prueba de corrección lógica.

El riesgo suele estar en decisiones plausibles que pasan inadvertidas: relacionar tablas con una clave equivocada, aplicar un filtro no solicitado, agregar valores después de multiplicar filas o interpretar de forma distinta los valores NULL. Antes de ejecutar, hay que poder explicar qué representa cada fila y por qué cada condición aparece en la consulta. Después, hay que contrastar el resultado con una referencia que no dependa de la misma generación de IA.

Este protocolo se centra en consultas analíticas sobre bases relacionales. No reemplaza la definición de las reglas de negocio ni una revisión de seguridad completa. Propone una secuencia práctica: aclarar la pregunta, inspeccionar estáticamente el SQL, probarlo con alcance limitado y validar la salida. El acceso de solo lectura reduce el daño posible, pero por sí solo no garantiza que los resultados sean correctos.

Paso 1: convertir la pregunta de negocio en criterios comprobables

Antes de leer el SQL, fija qué significa la petición. «Ventas del trimestre por cliente» deja cuestiones abiertas: ¿ventas brutas o netas?, ¿pedidos creados o completados?, ¿qué fechas delimitan el trimestre?, ¿se descuentan las devoluciones?, ¿qué zona horaria se aplica? Si esas decisiones no están documentadas, una consulta aparentemente razonable puede responder a una interpretación distinta.

Escribe una especificación breve con la métrica, la unidad de análisis, el periodo, los filtros y el nivel de agrupación. Identifica también la fuente autorizada para cada dato. Por ejemplo, si el total está en la cabecera del pedido y los productos en una tabla de detalle, explicita que la métrica debe conservar una fila lógica por pedido antes de sumar. La IA no debe completar silenciosamente reglas que el equipo aún no ha acordado.

Aclara el esquema real y el dialecto de SQL. Comprueba tablas, columnas, tipos, claves y relaciones documentadas en la base o el diccionario de datos; no te fíes de nombres que parezcan plausibles. En una integración de lenguaje natural a SQL, el esquema y las reglas que recibe el modelo son contexto útil, pero la salida aún debe comprobarse en el código y en el motor objetivo. Microsoft Learn muestra, por ejemplo, generación de SQL con valores parametrizados y una comprobación posterior de consultas prohibidas; también advierte que las instrucciones al modelo no sustituyen la planificación de medidas de seguridad.

Si falta una definición necesaria, detén la revisión y aclárala con quien sea responsable del indicador. Añadir una condición inventada para «hacer que funcione» no resuelve la ambigüedad; solo la convierte en una decisión difícil de detectar después.

Paso 2: inspección estática antes de ejecutar

Lee la consulta de fuera hacia dentro y marca cada tabla, JOIN, filtro, agregación, subconsulta y función de ventana. Compara los objetos con el esquema real. Después, sigue el recorrido de las filas: qué relación introduce cada JOIN, qué condiciones descartan registros y en qué momento cambia la granularidad. No des por buena una condición solo porque su nombre suene familiar.

Los JOIN merecen especial atención. Confirma que las claves utilizadas representan la relación correcta y averigua su cardinalidad: uno a uno, uno a muchos o muchos a muchos. Si una tabla contiene una fila por pedido y otra una fila por artículo, unirlas puede repetir el importe de cabecera por cada artículo. Sumar entonces el importe del pedido puede inflar el total sin producir ningún error de sintaxis. Un DISTINCT añadido a posteriori tampoco prueba que la lógica haya quedado reparada.

Revisa cada filtro frente a la especificación. Verifica estados, fechas, límites inclusivos o exclusivos y condiciones sobre NULL. Comprueba si el SQL elimina registros que deberían contar o incorpora otros que no corresponden. En una condición como `columna = valor`, los NULL no se comportan como un valor ordinario; las reglas deben ser deliberadas, no supuestas.

Examina las agregaciones y las funciones de ventana con una pregunta concreta: ¿sobre qué conjunto de filas se calcula cada valor? Comprueba si las columnas seleccionadas y agrupadas corresponden al nivel requerido. En subconsultas anidadas, anota qué filas devuelve cada nivel y cómo se conecta con el siguiente. Por último, confirma que las funciones y la sintaxis corresponden al dialecto del motor de destino.

Paso 3: limitar el alcance y ejecutar en un entorno controlado

La primera ejecución debe realizarse fuera de producción siempre que sea posible: en una base de pruebas aislada con datos sintéticos, o en una copia anonimizada y actualizada según las políticas de la organización. Los datos sintéticos permiten construir casos deliberados —incluidos duplicados, valores nulos y fechas límite— sin exponer registros reales. Una copia anonimizada puede reproducir mejor la distribución, pero exige verificar que el proceso de anonimización sea adecuado y que la copia no tenga permisos de escritura sobre producción.

Configura la conexión con privilegios mínimos. Para una prueba de consulta, usa una identidad de solo lectura y limita el acceso a las tablas o vistas necesarias. Revisa también restricciones de recursos: tiempo máximo, volumen de filas y capacidad de cancelación. Una consulta de solo lectura aún puede consumir recursos en exceso o devolver datos que el usuario no debería ver; la seguridad y la corrección son controles relacionados, pero distintos.

No ejecutes SQL generado por IA sin validación del lado de la aplicación. Las instrucciones del prompt pueden orientar el modelo, pero no son un límite de seguridad. Acepta únicamente las operaciones y objetos permitidos, valida parámetros y utiliza consultas parametrizadas para los valores. Microsoft Learn describe un ejemplo en el que el servidor añade cadenas como parámetros y comprueba la consulta antes de ejecutarla; la lista de palabras prohibidas presentada allí es demostrativa, no una defensa completa aplicable sin adaptación.

Empieza con el menor alcance que permita probar la lógica: una entidad conocida, un periodo corto o una muestra pequeña. Si necesitas inspeccionar un plan de ejecución, hazlo en el entorno autorizado y considera el coste. El objetivo no es demostrar que la consulta puede correr sobre toda la base, sino comprobar de forma segura las hipótesis relevantes antes de ampliar el alcance.

Paso 4: probar con casos conocidos y comparar resultados

Una salida plausible no es una referencia. La validación debe utilizar casos cuyo resultado pueda anticiparse sin pedirle al mismo modelo que confirme su propia consulta. Prepara ejemplos pequeños con resultados calculables, registros en los límites del periodo, entidades con y sin relaciones y filas con valores NULL cuando sean pertinentes. En datos sintéticos puedes controlar exactamente esas condiciones.

Compara el resultado con una fuente de referencia autorizada: una consulta simplificada revisada por una persona, un informe cuya definición coincida con la especificación o un cálculo manual sobre un conjunto pequeño. Asegúrate de que ambos métodos usan el mismo periodo, filtros, reglas de exclusión y granularidad. Dos consultas que difieren en esos aspectos no son comparables aunque compartan el nombre de la métrica.

Valida tanto la estructura como los valores. Comprueba cantidad de filas, claves duplicadas, totales por grupos y casos extremos. Si el resultado debe contener una fila por cliente, verifica esa unicidad; si se agrupa por mes, inspecciona meses sin actividad y límites de fecha. Cuando haya una diferencia, reduce el caso: examina primero el conjunto antes del JOIN, luego después de cada unión y finalmente tras los filtros y agregaciones. Así puedes localizar en qué etapa cambia la cifra.

La validación cruzada no convierte una prueba limitada en garantía universal. Un caso conocido puede confirmar que la consulta responde correctamente en esa situación, pero no necesariamente en todos los periodos o combinaciones de datos. Convierte los casos que detectaron errores en pruebas de regresión para comprobar que futuras modificaciones no reintroduzcan el mismo problema.

Errores, resultados vacíos y ambigüedad

Un error de sintaxis indica que el motor no puede interpretar la consulta, pero corregirlo no valida la lógica. Comprueba el dialecto, los nombres y los tipos antes de pedir una nueva generación. Si solicitas una corrección, describe el error concreto y conserva las condiciones de negocio verificadas; no pidas simplemente «arréglalo», porque la respuesta puede alterar otras partes de la consulta.

Un resultado vacío tampoco tiene una sola explicación. Puede deberse a un filtro demasiado restrictivo, a diferencias de capitalización o formato, a una fecha incorrecta, a una relación que excluye filas o a que realmente no existen coincidencias. Inspecciona cada condición por separado en el entorno de prueba. No elimines filtros de forma automática para conseguir resultados: podrías pasar de un problema de interpretación a una consulta que incluye datos fuera del alcance.

Si el modelo no puede explicar de dónde procede una tabla, una relación o una regla, trata ese elemento como no verificado. Reformula la pregunta con la definición que falte o solicita aclaración a la persona responsable de la métrica. Las explicaciones del modelo pueden ayudar a entender la propuesta, pero no son evidencia independiente de que sea correcta.

Si aparece una discrepancia entre el SQL y la referencia, conserva la consulta, los parámetros, la versión del esquema, el caso de prueba y el resultado observado con las protecciones de privacidad correspondientes. Corrige la causa, no solo el valor visible. Después, repite los controles afectados y añade una prueba de regresión si el fallo puede reaparecer.

Checklist final antes de incorporar la consulta

Antes de utilizar SQL generado por IA en un análisis o pipeline, confirma que la pregunta original tiene una definición comprobable; que cada tabla, columna y relación existe en el esquema; y que los JOIN conservan la granularidad necesaria. Revisa filtros, agregaciones, NULL, fechas, funciones y dialecto. Asegúrate también de que la consulta se probó en un entorno autorizado con datos adecuados y permisos de solo lectura cuando el caso lo permita.

La salida debe superar una comprobación independiente con casos conocidos o datos de referencia comparables. Si el control falla, no presentes el resultado como confirmado. Corrige o reformula, vuelve a ejecutar las pruebas y registra la versión aprobada junto con su alcance. La lista no elimina la necesidad de revisión especializada para indicadores de alto impacto, datos sensibles o consultas complejas.

La regla práctica es sencilla: una consulta solo está lista cuando se entiende, está limitada al acceso autorizado y produce resultados consistentes bajo pruebas que reflejan la pregunta de negocio. Si alguna de esas condiciones no puede demostrarse, conserva la incertidumbre y solicita revisión antes de usarla.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.