La mayoría de tus problemas de datos no son problemas de IA

Una versión de esta conversación pasa en casi todos los proyectos. Alguien describe un problema real — nadie encuentra los números del trimestre pasado, el equipo de ventas sigue haciendo las mismas cinco preguntas, los reportes toman un día en armarse — y la forma propuesta de la respuesta es una IA que se ha leído todo.

A veces eso es correcto. Normalmente los datos ya están estructurados, ya están en una base de datos, y la pregunta tiene una respuesta exacta que una consulta devuelve en milisegundos. La recuperación sobre embeddings te da una respuesta aproximada a una pregunta que tenía una exacta, y te cobra una llamada al modelo por el privilegio.

La revisión

Así que nos obligamos a parar en dos momentos — cuando se define el alcance, y otra vez antes de que alguien escriba código de recuperación — y preguntar:

¿Estos datos están estructurados? Si la respuesta es sí, la solución es SQL, no vectores.

El valor por defecto es no. No “probablemente no” — no, salvo que alguien pueda decir específicamente por qué falla el camino estructurado. Esa inversión importa, porque la respuesta entusiasta siempre es sí y el entusiasmo no es un insumo de diseño.

Cuándo sí es un problema de recuperación

• La fuente es prosa que nadie controla — contratos, términos de referencia, transcripciones, hilos de correo.

• La pregunta es sobre significado más que sobre valor: “qué acordamos sobre penalidades”, no “cuál era el monto de la penalidad”.

• El corpus es lo bastante grande como para que una persona leyéndolo sea el cuello de botella real.

Esos casos son reales, y construimos para ellos. Los documentos de licitación son un buen ejemplo: cien páginas de prosa donde lo que necesitas es un umbral de calificación enterrado en un anexo.

Por qué vale la pena decirlo en voz alta

Porque el fracaso caro no es elegir el modelo equivocado. Es construir un sistema impresionante que responde aproximadamente, encima de datos que podían responder exactamente, y luego pasar meses afinando la aproximación.

El proyecto de IA más barato es el que decides correctamente no construir.

Eso no es una postura en contra de la IA. Construimos automatización para vivir. Es una postura sobre que el juicio interesante ocurre antes que el modelo, y un socio que nunca te quita una idea de la cabeza no te está dando juicio.