Inteligencia Artificial

Antes de revisar el SQL: confirma qué sabe realmente la IA

Antes de analizar un JOIN o buscar un error en un WHERE, hay que delimitar con qué información trabajó el modelo. ChatGPT, Claude o Gemini pueden razonar sobre el esquema que reciben, pero no conocen por defecto las tablas, convenciones y reglas propias de una base de datos. Si falta contexto, pueden completar esos huecos con relaciones, nombres o decisiones plausibles.

¿Qué conviene comprobar primero? La frontera entre información proporcionada e información inferida. Si todavía no están claras la métrica, la unidad de análisis o las relaciones necesarias, conviene resolver antes ese trabajo al pasar de una pregunta de negocio a una consulta SQL. Aquí partimos de un paso posterior: ya existe una consulta y queremos decidir si podemos confiar en ella.

Comprueba qué tablas, columnas y relaciones existen

Supongamos que pedimos calcular el importe neto de los pedidos completados por cliente. La base contiene customers, orders, order_items y refunds, pero el modelo devuelve una consulta que utiliza orders.total_amount y orders.refunded_at. La sintaxis podría ser impecable y, sin embargo, esas columnas no existen en el esquema real.

La primera revisión debe contrastar la consulta con la fuente de verdad disponible: esquema, diccionario de datos o metadatos de la base. No basta con que los nombres resulten plausibles. Hay que verificar también las relaciones que la IA ha utilizado y su cardinalidad. Un orders.customer_id = customers.id puede estar documentado, mientras que una relación deducida únicamente por nombres parecidos necesita confirmación.

Antes de continuar, la revisión debería dejar identificados al menos estos elementos:

• Esquema disponible: comprueba que cada tabla utilizada pertenece realmente a él y no ha sido inferida por el modelo.
• En las columnas, verifica nombre, tipo y significado; una denominación plausible puede esconder otra semántica.
• Comprueba las claves empleadas en los JOIN y confirma su cardinalidad real frente a las relaciones documentadas.
• Si la consulta utiliza funciones específicas, el dialecto SQL debe corresponder al motor sobre el que se ejecutará.

Si alguno de estos elementos no puede justificarse con el esquema o la documentación disponible, la consulta todavía no está lista para validarse como un todo. Primero hay que corregir o aclarar esa parte, porque cualquier revisión posterior de filtros, agregaciones o resultados partiría de una estructura potencialmente equivocada.

Distingue el esquema de los supuestos de negocio

Que una tabla y una columna existan tampoco demuestra que se estén utilizando correctamente. orders.status = 'completed' puede ser técnicamente válido, pero todavía queda una pregunta: ¿es ese el estado que la empresa considera una venta computable? El modelo no puede deducir de forma fiable una regla interna que nunca recibió.

Conviene marcar como supuesto pendiente de validación cualquier decisión que no pueda justificarse con el esquema o con una regla proporcionada. En el ejemplo, habría que aclarar cómo se tratan devoluciones parciales, cancelaciones posteriores o fechas de contabilización. Esa separación evita dedicar tiempo a depurar una consulta cuya lógica de partida ya era incorrecta.

Cómo revisar una consulta SQL generada por IA

Una vez confirmado que ChatGPT, Claude o Gemini han trabajado con tablas y relaciones reales, la siguiente pregunta no es solo si el SQL está bien escrito, sino qué decisiones ha tomado el modelo por su cuenta. La IA puede completar huecos con soluciones plausibles: elegir un tipo de JOIN, introducir un DISTINCT, seleccionar una fecha o adaptar una función al dialecto que cree más probable.

Por eso conviene revisar la consulta buscando decisiones no justificadas, no únicamente errores visibles. Una propuesta puede parecer razonable porque sigue patrones SQL habituales y, sin embargo, alterar la métrica respecto a lo que necesitabas calcular.

Detecta dónde la IA ha decidido la granularidad o los joins

Supongamos que pedimos ventas por cliente y el modelo genera una consulta que une orders con order_items antes de sumar orders.total_amount:

SELECT
    o.customer_id,
    SUM(o.total_amount) AS total_sales
FROM orders o
JOIN order_items oi ON oi.order_id = o.id
GROUP BY o.customer_id;

La consulta puede ejecutarse sin problemas, pero cada pedido aparecerá tantas veces como líneas tenga. El error no está en la sintaxis: está en que la IA ha elegido una granularidad incompatible con la métrica.

Aquí interesa revisar qué representa una fila después de cada unión y si el modelo ha introducido relaciones que multiplican o eliminan registros. También hay que desconfiar de correcciones automáticas como añadir DISTINCT: puede ocultar el síntoma sin resolver la causa.

Comprueba qué filtros y reglas ha añadido el modelo

Una IA puede introducir condiciones razonables que nunca le pediste: status = 'completed', excluir nulos, utilizar la fecha de creación en lugar de la de pago o interpretar un periodo con límites distintos a los esperados.

Cada filtro debe poder justificarse con una regla proporcionada o documentada. Si no puedes explicar por qué está ahí, trátalo como una decisión pendiente de validar, aunque el resultado parezca coherente.

Verifica que no ha adaptado la consulta al dialecto equivocado

Cuando no se especifica el motor, el modelo puede recurrir a funciones habituales de PostgreSQL, BigQuery, SQL Server o MySQL y mezclarlas con una lógica que, en abstracto, parece correcta.

Revisa especialmente funciones de fecha, conversiones, concatenaciones y sintaxis específica del proveedor. Si pides a la IA que adapte la consulta al motor correcto, esa nueva versión sigue necesitando revisión: cambiar el dialecto no valida automáticamente la lógica.

Cómo validar el resultado antes de confiar en la consulta

Una consulta revisada sigue necesitando una prueba independiente. Si la propia IA genera el SQL, explica por qué es correcto y después lo valida sin datos de referencia, estamos utilizando el mismo razonamiento como comprobación de sí mismo. Para romper ese círculo hacen falta casos cuyo resultado podamos anticipar sin depender de la respuesta del modelo.

La validación debe servir además para localizar el fallo. Saber que el total final es incorrecto no indica si el problema está en un JOIN, un filtro o una agregación. Cuanto más pequeño sea el caso de prueba, más fácil será devolver a la IA una corrección concreta en lugar de pedir otra consulta completa a ciegas.

Contrasta la salida con casos conocidos y consultas de control

Si sabemos que un cliente realizó tres pedidos computables durante un periodo concreto, podemos filtrar ese cliente antes de aceptar el total general. Si la consulta devuelve seis filas porque cada pedido tiene dos líneas en order_items, el caso conocido revela inmediatamente dónde se ha roto la granularidad.

No hace falta construir un segundo análisis completo. Pueden utilizarse controles pequeños y deliberados: contar filas antes y después de una unión, comprobar una entidad conocida, inspeccionar registros situados en el límite de una fecha o calcular manualmente una muestra reducida. El objetivo es obtener una referencia que no dependa de que ChatGPT, Claude o Gemini considere plausible su propia respuesta.

Checklist final y cómo devolver a la IA una corrección útil

Antes de aceptar el SQL generado, recorre una secuencia estable de controles:

• Origen de los objetos: confirma que tablas y columnas existen en el esquema real y no han sido inventadas o deducidas.
• En cada relación, comprueba si las claves y la cardinalidad del JOIN coinciden con el modelo de datos.
• Pregunta qué representa cada fila tras las uniones y verifica que se mantiene la granularidad necesaria para calcular la métrica.
• Los estados, exclusiones y fechas deben proceder de reglas conocidas, no de supuestos introducidos por la IA.
• Revisa si agregaciones, nulos o un DISTINCT están corrigiendo realmente la lógica o simplemente ocultando duplicaciones.
• Si el modelo ha elegido funciones específicas, confirma el dialecto y el comportamiento en el motor objetivo.
• Termina con un caso conocido que permita comprobar el resultado esperado de forma independiente.

Si uno de estos controles falla, no pidas simplemente “corrige la consulta”. Indica qué has comprobado, cuál es la causa observada y qué condición debe respetar la nueva versión. Puedes, por ejemplo, explicar que order_items introduce varias filas por pedido, que la métrica procede de orders.total_amount y que la consulta debe conservar una fila lógica por pedido antes de sumar por cliente.

Ese contexto convierte la siguiente interacción en una corrección dirigida, no en otra generación desde cero. Es el mismo principio que aplicamos al redactar prompts efectivos: aportar información suficiente y restricciones verificables. La nueva consulta debe pasar otra vez por los controles afectados, porque una respuesta corregida por la IA sigue siendo una propuesta pendiente de validación.

Conclusiones

ChatGPT, Claude o Gemini pueden acelerar la escritura de SQL, pero generar una consulta no equivale a validarla. El control sigue dependiendo de comprobar qué información recibió la IA, qué tuvo que inferir y si las decisiones incorporadas a la consulta encajan con el esquema y las reglas reales del negocio.

La revisión más útil no empieza buscando únicamente errores de sintaxis. Empieza por distinguir datos conocidos de supuestos, continúa comprobando granularidad, joins, filtros, fechas y agregaciones, y termina contrastando el resultado con casos conocidos o consultas de control. Una sentencia puede ejecutarse perfectamente y seguir respondiendo a una pregunta distinta.

El objetivo es establecer un procedimiento repetible de validación en el que la IA proponga y corrija, pero el analista conserve el criterio. Así es posible aprovechar la velocidad de estos asistentes sin trasladar al análisis errores plausibles, silenciosos y difíciles de detectar después.