La tesis en una frase: cambiar de modelo de IA es lo primero que se hace cuando algo no funciona y lo último que debería hacerse. Sale un modelo nuevo, alguien lee que es más listo, y la conversación del equipo pasa de «¿por qué esto no rinde?» a «¿nos pasamos al último?». Es la reacción más cómoda del mundo —no exige mirar hacia dentro— y casi siempre es la equivocada. El cuello de botella rara vez es el modelo. Son el proceso que nadie definió bien y los datos que nadie limpió.
Cambiar de modelo de IA es tratar el síntoma, no la enfermedad
Cuando un proyecto de IA decepciona, hay dos culpables posibles: el motor o todo lo que lo rodea. El motor es el modelo; lo que lo rodea es cómo le llega la información, qué se le pide, con qué datos trabaja y qué se hace con su respuesta. La industria entera te empuja a mirar el motor, porque es lo que se vende, se compara y sale en los titulares. Pero en la mayoría de los proyectos que se atascan, el motor no es el problema: el problema es que le estás pidiendo que adivine sobre un proceso que ni tú tienes claro, alimentado con datos que contradicen entre sí.
Piénsalo con una analogía aburrida pero exacta: si tu coche no arranca porque el depósito está vacío, cambiar el motor por uno más potente no lo mueve un metro. Cambiar de modelo cuando el freno es el proceso es exactamente eso —una obra cara que no toca la causa—. Y mientras tanto, el equipo se convence de que «lo han intentado todo», cuando en realidad no han tocado lo único que importaba.
El verdadero cuello de botella: proceso mal definido y datos sucios
Un modelo de IA es tan bueno como la claridad del trabajo que le encargas y la calidad de lo que le das para trabajar. Cuando falla, casi siempre falla por una de estas dos, no por falta de inteligencia bruta:
Proceso mal definido
Si tú no puedes explicar el proceso en pasos claros, la IA tampoco lo va a inventar por ti. Muchos «casos de uso de IA» son en realidad procesos que nunca se documentaron: cada persona los hacía a su manera, con excepciones en la cabeza y criterios que nadie escribió. Le pides a la IA que automatice ese caos y, lógicamente, produce caos con mejor gramática. Un modelo más potente no te va a dar la definición del proceso que a ti te falta. Cómo desmenuzar una tarea en instrucciones que una IA puede seguir de verdad es la mitad del trabajo, y lo abordamos en automatizar tareas con ChatGPT.
Datos sucios
La otra mitad es de qué se alimenta. Si la IA responde a partir de información desactualizada, duplicada, contradictoria o repartida en diez sitios que no se hablan, la respuesta será mala por mucho que el modelo sea excelente. Basura entra, basura sale —eso no lo arregla ningún release—. Este freno es tan común que le dedicamos un artículo entero: los datos desordenados son el freno real de la IA. Y si tu caso exige que el modelo conozca tu negocio, el arreglo casi nunca es cambiar de modelo: es darle acceso ordenado a tu información, algo que desglosamos en entrenar el agente con tu propia información.
Por qué cambiar de modelo es tan tentador (y tan inútil)
Si el problema casi siempre es el proceso, ¿por qué la reacción por defecto es cambiar de modelo? Porque es lo fácil. Cambiar de modelo es una decisión de una tarde: tocas una configuración, apuntas a otro endpoint y ya. Arreglar el proceso y los datos es una decisión de semanas, exige hablar con la gente que hace el trabajo, documentar lo que nadie documentó y limpiar lo que nadie quiere limpiar. Ante esa elección, el ser humano prefiere la que parece progreso sin ser incómoda.
- Da sensación de acción sin serlo. Migrar de modelo se siente productivo —hay algo que tocar, un antes y un después— aunque el resultado no se mueva. Es teatro de progreso.
- El marketing te da la coartada. Cada release viene con benchmarks que prometen un salto. Es facilísimo convencerte de que ESTE sí es el que faltaba, en lugar de aceptar que el fallo está en tu casa.
- Mirar hacia dentro incomoda. Reconocer que tu proceso no estaba definido o que tus datos son un desastre señala a decisiones propias. Cambiar de proveedor externaliza la culpa: fue el modelo, no nosotros.
Y hay un coste que casi nadie contabiliza: cada migración de modelo no es gratis. Reescribes prompts, revalidas resultados, ajustas la integración y vuelves a probar todo. Si lo haces persiguiendo un problema que no estaba en el modelo, gastas ese esfuerzo para acabar en el mismo sitio —con el proceso igual de roto, pero con un modelo distinto al que echarle la culpa la próxima vez—.
Cuándo cambiar de modelo sí es la decisión correcta
Esto no es «no cambies nunca de modelo». A veces el motor sí es el límite, y entonces cambiar es lo sensato. La diferencia es que lo haces después de descartar lo demás, no antes de mirarlo. Estas son las señales de que el modelo es de verdad tu techo:
- Un humano con tus mismas instrucciones y datos lo hace bien, y la IA no. Si la tarea está bien definida, los datos están limpios y una persona con esa misma información acierta, pero el modelo falla en un tipo de razonamiento concreto, ahí sí el motor es el límite.
- Chocas con un límite técnico real. Ventana de contexto insuficiente para tu caso, idioma que el modelo maneja mal, latencia o coste por token que no cuadran a tu volumen: son límites del motor, no del proceso.
- Lo has probado en igualdad de condiciones. Cambiaste solo el modelo, con el mismo proceso y los mismos datos ya ordenados, y el nuevo gana de forma medible y repetible —no en una demo afortunada—.
Fíjate en el orden: primero arreglas proceso y datos, y solo entonces, con esa base limpia, comparar modelos se vuelve una decisión con sentido en lugar de una huida hacia delante. Sobre cómo montar esa base para poder cambiar de motor sin dolor —desacoplando la aplicación del proveedor— escribimos en IA open source vs API cerrada.
Qué hacer el lunes en vez de cambiar de modelo
- Escribe el proceso a mano, en pasos. Si no puedes explicarlo en una página clara, la IA no va a rescatar lo que tú no tienes definido. Ese documento es el arreglo, no el modelo.
- Mira de qué datos come la IA. Rastrea la información que usa hasta su origen y comprueba si está actualizada, es única y no se contradice. Ordena eso antes de tocar nada más.
- Haz la prueba del empleado nuevo. ¿Un humano brillante con esas instrucciones y esos datos haría bien la tarea? Si no, arregla las instrucciones y los datos. Si sí y la IA falla, entonces —y solo entonces— compara modelos.
Si al hacer esto descubres que el freno no era el modelo sino el proceso —que es lo más probable—, ese es exactamente el trabajo que hacemos: definir el proceso, ordenar los datos y dejar la automatización funcionando encima, con automatización de operaciones. El modelo es la parte fácil; que el trabajo se haga bien, la difícil.