Qué IA usar para cada tarea: guía de decisión sin rankings

“¿Cuál es la mejor IA?” es la pregunta que más se hace y la que menos sirve. Es como preguntar cuál es el mejor vehículo sin decir si hay que mudarse, llegar rápido o aparcar en el centro.

Esta guía no trae un ranking. Trae el marco de decisión que uso, las dos variables que de verdad cambian la respuesta, y cuatro casos resueltos con su razonamiento.

Las dos variables que importan

Después de integrar estos modelos en unos cuantos proyectos, todas las decisiones que no me he arrepentido de tomar salían de cruzar dos preguntas:

¿Cuántas llamadas vas a hacer? Cien al mes o cien mil al día cambian por completo qué pesa en la factura. Con poco volumen, el precio por token es casi irrelevante; con mucho, es lo único que importa.

¿Cuánto cuesta un error? No cuánto te molesta: cuánto cuesta. Un resumen interno mal hecho lo corriges al leerlo. Una cláusula mal interpretada en un contrato que firmas tiene otro precio.

Cruzadas, dan cuatro situaciones con respuestas distintas:

Qué pesa en tu caso, no qué modelo es mejor

Fig. 01

Poco volumen·Error caro

La gama más capaz, sin dudar

Pagar el modelo bueno en cien llamadas al mes es irrelevante; equivocarse, no.

Mucho volumen·Error caro

Modelo capaz + verificación automática

El único cuadrante donde merece la pena montar comprobaciones sobre la salida.

Poco volumen·Error barato

Lo que ya tengas contratado

No optimices esto. El tiempo que inviertas en elegir cuesta más que la diferencia.

Mucho volumen·Error barato

La gama ligera, y mídelo

Clasificar o resumir en masa: aquí la diferencia de precio entre gamas sí se nota.

Datos propios

→

Lo útil de este marco es que descarta la pregunta equivocada. Si estás en el cuadrante de poco volumen y error barato, cualquier modelo actual te sirve y elegir es perder el tiempo. Si estás en mucho volumen y error caro, ningún modelo te salva solo: necesitas verificación encima.

Lo que ya no distingue a los modelos

Hay tres cosas que se usaban para comparar y que en 2026 han dejado de ser el criterio.

La ventana de contexto. Hace un par de años era el argumento central. Hoy los modelos de gama alta de los principales proveedores trabajan con ventanas enormes, y para casi cualquier tarea de empresa sobra. Sigue importando si manejas documentación recurrentemente masiva, pero ya no es lo que decide. Los números concretos y su matiz —contexto disponible no es contexto gratis— están en la comparativa de Claude y ChatGPT para empresas.

“Escribe mejor”. En textos normales la diferencia entre los modelos punteros es menor que la diferencia entre darles buenas o malas instrucciones. Si el resultado no te gusta, antes de cambiar de modelo prueba a cambiar el prompt: es gratis y suele ser la causa.

El tamaño del modelo. Más grande ya no es automáticamente mejor para tu caso. Un modelo ligero bien dirigido en una tarea acotada gana a uno grande con instrucciones vagas, y cuesta una fracción.

Cuatro casos resueltos

Atender consultas repetitivas de clientes

Mucho volumen, error de coste medio. Modelo de gama ligera, con una vía de escape a una persona.

El patrón que funciona no es un modelo que lo resuelva todo, sino uno que resuelva lo frecuente y sepa cuándo no sabe. La instrucción más valiosa en este caso es la que le dice que derive en vez de improvisar.

Y dos obligaciones que no son técnicas: hay que decir que es un chatbot —es exigible desde agosto de 2026— y hay que saber qué pasa con los datos personales que entran por ahí. Las dos cosas, con las fechas al día, en la guía de RGPD e inteligencia artificial para empresas españolas.

Revisar documentación legal o financiera

Poco volumen, error caro. La gama más capaz, y aun así con una persona revisando.

Es el cuadrante donde el precio no debe entrar en la decisión. Si revisas cincuenta contratos al mes, la diferencia entre el modelo barato y el bueno son unos euros; un error de interpretación puede costar mucho más.

Y una advertencia que viene de la práctica: estos modelos son muy convincentes cuando se equivocan. En material legal el riesgo no es que diga “no lo sé”, es que afirme algo plausible y falso con seguridad. La revisión humana aquí no es un trámite.

Clasificar o etiquetar en masa

Mucho volumen, error barato. La gama ligera, y midiendo.

Aquí sí hay que optimizar, porque la diferencia de precio entre gamas se multiplica por el volumen. El procedimiento es sencillo: coge cien casos reales, pásalos por el modelo ligero, cuenta los fallos. Si el porcentaje te sirve, ya tienes la decisión tomada con datos en lugar de intuición.

Casi siempre el modelo ligero sirve, porque clasificar es más fácil que razonar.

Escribir contenido para publicar

Depende de qué tipo de contenido, y la respuesta real no es sobre el modelo.

Para borradores y estructura, cualquier modelo puntero vale. La elección importa menos que dónde escribes: si trabajas dentro de un gestor de contenido, la fricción de copiar y pegar se come la ventaja de usar un modelo algo mejor. Lo desarrollé por caso de uso en las mejores herramientas de IA para escribir contenido.

Y la parte que no se arregla eligiendo modelo: publicar en volumen sin criterio editorial es lo que Google sanciona, independientemente de quién escriba el texto. Esa decisión no es de herramienta.

Dos casos donde la respuesta es “ninguno”

Conviene decirlo porque casi ninguna guía lo hace: a veces la decisión correcta es no usar un modelo de lenguaje.

Cuando la tarea es determinista. Validar un NIF, calcular un IVA, comprobar si una fecha está en un rango, extraer un campo de un formato fijo. Todo eso tiene una solución exacta en veinte líneas de código, que cuesta cero por ejecución y nunca se equivoca. Pasarlo por un modelo introduce coste, latencia y una probabilidad de error donde no había ninguna. Si la respuesta correcta se puede calcular, calcúlala.

Cuando no puedes verificar el resultado. Si el modelo te da una respuesta que no sabes evaluar y nadie la va a comprobar, no has automatizado una tarea: has generado texto plausible sobre el que vas a tomar decisiones. Es peor que no tener nada, porque el formato da confianza que el contenido no respalda.

La prueba rápida: si no puedes explicar cómo sabrías que la salida está mal, no metas un modelo todavía. Primero resuelve cómo comprobarlo.

El coste que no está en la tabla de precios

Al comparar proveedores se mira el precio por millón de tokens y se para ahí. Hay tres partidas más que suelen pesar más que esa:

Los tokens de salida. Cuestan bastante más que los de entrada —habitualmente unas cinco veces— y las tablas de precios los listan aparte. Si tu caso genera textos largos, el coste real se parece poco al que calculaste con el precio de entrada.

Lo que no cacheas. Si en cada llamada mandas el mismo bloque de instrucciones, estás pagando por él cada vez. Los proveedores tienen mecanismos para cobrar mucho menos por la parte repetida, y aprovecharlos cambia la factura más que cambiar de modelo.

Los reintentos. Un modelo barato que acierta al segundo intento no es más barato que uno caro que acierta al primero. El número que importa no es el coste por llamada, es el coste por tarea terminada.

Por eso el paso de medir con casos reales no es opcional: es lo único que captura estas tres partidas, y ninguna aparece en la comparativa de precios de nadie.

Cómo decidir en diez minutos

Si tienes un caso concreto delante:

1. Estima las llamadas al mes. Un orden de magnitud basta: ¿cientos, miles, cientos de miles?
2. Pon precio al error. No “sería molesto”: cuánto cuesta arreglarlo o cuánto se pierde si pasa.
3. Sitúate en el cuadrante y coge la gama que te toque.
4. Prueba con veinte casos reales, no con ejemplos inventados. Los ejemplos de demostración siempre salen bien.
5. Mide el coste real de esos veinte y multiplica por tu volumen. Ahí sueles descubrir que la decisión que parecía estrecha no lo es.

El paso 4 es el que casi nadie hace y el que más cambia el resultado. Un modelo que responde perfecto a tus tres pruebas puede fallar en el cuarto caso real, porque tus pruebas estaban escritas por alguien que ya sabía la respuesta.

La respuesta corta

Si has llegado hasta aquí buscando una recomendación directa: empieza por la gama intermedia del proveedor que ya uses, y cámbiate solo cuando tengas una medición que lo justifique.

Cambiar de proveedor tiene un coste que no aparece en la tabla de precios: reescribir integraciones, volver a ajustar prompts, perder la caché. Ese coste solo se paga cuando hay un número que lo respalde, no cuando sale un modelo nuevo con buenas notas en un benchmark que no se parece a tu caso.