El modelo más caro no es el mejor: cómo elegir según la tarea

Introducción

Hay una decisión que casi nunca se toma de forma consciente y que determina si una empresa puede permitirse usar inteligencia artificial o no. No es qué proceso automatizar, ni con qué proveedor trabajar. Es cuál de los modelos disponibles atiende cada tarea.

Lo habitual es no decidirlo. Se elige el modelo del que todo el mundo habla, se conecta a todo el flujo de trabajo y se descubre la factura a los dos meses. En ese momento pasa una de dos cosas: o el proyecto se recorta hasta dejarlo en una demostración simpática, o se mantiene con la sensación incómoda de estar pagando de más sin saber cuánto.

Las dos salidas son evitables, y no rebajando la ambición del proyecto. La tesis de este artículo es más incómoda que eso: usar el modelo más capaz del mercado para todas las tareas no es una decisión prudente, sino la ausencia de una decisión. Y quien lo hace no está comprando calidad. Está comprando la tranquilidad de no haber tenido que medir.

La pregunta está mal planteada

La conversación sobre coste de IA suele girar en torno al precio por millón de tokens. Es la cifra que publican los proveedores, así que es la que se compara. Y es la cifra equivocada.

Lo que le importa a una empresa es el coste por tarea resuelta correctamente. Son cosas muy distintas, porque en el segundo entra todo lo que el primero esconde: los reintentos cuando la respuesta no vale, las tareas que hay que rehacer, el tiempo de la persona que revisa, y el coste (mucho mayor y mucho peor repartido) del error que se cuela sin que nadie lo vea.

Un modelo diez veces más barato que falla un tercio de las veces y obliga a revisar todo a mano no es barato. Es carísimo, porque ha convertido un coste de software, que es predecible y escala bien, en un coste de personal, que ni es lo uno ni lo otro.

Pero el razonamiento funciona igual en la otra dirección, y esta es la parte que se omite. Si una tarea la resuelven igual de bien el modelo más caro del catálogo y uno considerablemente más modesto, la diferencia de precio no compra nada. No compra seguridad, ni calidad, ni margen de maniobra. Compra la comodidad de no haber tenido que comprobarlo.

Reformulada así, la pregunta deja de ser económica y pasa a ser técnica: ¿en qué tareas concretas, de las que hace esta empresa, se nota la diferencia entre un modelo y otro?

Por qué la diferencia se desvanece en las tareas fáciles

La respuesta tiene una estructura bastante regular, y conviene entenderla porque es lo que sostiene todo lo demás.

Cuando se comparan modelos en problemas difíciles (razonamiento matemático de competición, programación sobre repositorios reales, cadenas largas de decisiones con herramientas encadenadas) las diferencias son grandes y sostenidas. Ahí el mejor modelo es netamente mejor, y pagarlo tiene sentido.

Cuando se comparan en tareas de dificultad media, las diferencias se estrechan. Y cuando se comparan en tareas fáciles, se vuelven indistinguibles, porque todos los candidatos aciertan prácticamente siempre y lo que se está midiendo ya no es capacidad sino ruido.

El detalle relevante es este: la inmensa mayoría del trabajo que una pyme quiere automatizar cae en la tercera categoría. Determinar si un correo entrante es una reclamación, una consulta o una factura. Extraer cuatro campos de un albarán. Comprobar si un documento trae los anexos que debería. Clasificar un ticket y asignarlo. Resumir una llamada en cinco líneas.

Ninguna de esas tareas es difícil para el estado del arte actual. Son laboriosas, repetitivas y consumen tiempo caro de personas, que es exactamente por lo que merece la pena automatizarlas, pero no son intelectualmente exigentes. Y en tareas así, la diferencia entre el modelo de la portada y uno mucho más económico tiende a ser cero.

Este es el punto que hay que retener: el volumen de una empresa está en las tareas fáciles, y ahí es donde el sobrecoste se multiplica por la frecuencia. Cuarenta mil clasificaciones al mes con el modelo más caro del mercado es una factura seria para resolver un problema que no lo es.

Lo que ha cambiado en los últimos años

Todo lo anterior sería teórico si el mercado ofreciera solo dos o tres modelos. La razón de que sea aplicable es que el abanico se ha ensanchado enormemente, y en dos direcciones a la vez.

La primera es el desplome del coste. Según el informe de Stanford HAI de 2025, el precio de obtener un rendimiento equivalente al de GPT-3.5 cayó más de 280 veces entre noviembre de 2022 y octubre de 2024 (Stanford HAI, 2025). No es que los modelos bajaran de precio: es que apareció una generación de modelos pequeños capaces de hacer por céntimos lo que antes exigía la gama alta.

La segunda es el estrechamiento de la brecha. Ese mismo informe cifró en 1,7 puntos porcentuales la distancia entre los mejores modelos de pesos abiertos y los cerrados en determinados marcadores, frente a 8 puntos un año antes. La edición de 2026 documenta el mismo fenómeno en el eje geográfico: a marzo de 2026, el mejor modelo estadounidense aventajaba al mejor modelo chino en un 2,7 %, después de que ambos se hubieran intercambiado el liderazgo varias veces desde principios de 2025 (Stanford HAI, 2026).

Conviene leer esas cifras con cuidado, porque dicen algo más preciso de lo que parece. No dicen que todos los modelos sean iguales. Dicen que la frontera se ha vuelto estrecha y disputada, que ningún proveedor la ocupa de forma estable, y que una diferencia de dos o tres puntos en un marcador general es perfectamente compatible con una diferencia de cero en una tarea concreta que ambos resuelven bien.

Hay un tercer dato del informe de 2026 que va en dirección contraria y que sería deshonesto no mencionar: el índice de transparencia de los modelos fundacionales cayó a 40 puntos desde los 58 del año anterior, y los modelos más capaces son sistemáticamente los que menos información publican sobre su entrenamiento (Stanford HAI, 2026). Es decir, la competencia ha traído mejores precios y peor información para decidir. Razón de más para medir por cuenta propia en lugar de fiarse de lo que se anuncia.

Dónde se ejecuta el modelo, que es lo que de verdad importa

Aquí es donde la conversación se suele torcer, porque se mezclan dos cosas que no tienen nada que ver.

Cuando alguien plantea usar un modelo desarrollado fuera de la Unión Europea, la objeción inmediata es la protección de datos. La objeción es razonable, pero se aplica a un escenario concreto y no a los otros dos. Conviene separarlos.

Escenario uno: llamar a la interfaz del proveedor extranjero. Los datos salen de la Unión Europea y se procesan en un país que puede no contar con decisión de adecuación. Eso activa el capítulo V del Reglamento General de Protección de Datos, con cláusulas contractuales tipo, evaluación de impacto de la transferencia y una carga documental que para muchas empresas no compensa. Es la opción que genera el problema.

Escenario dos: descargar los pesos y ejecutarlos donde se quiera. Buena parte de los modelos competitivos actuales se publican con pesos abiertos, lo que significa que el modelo es un fichero que se puede desplegar en infraestructura propia o en un proveedor europeo. Y aquí ocurre algo que se pasa por alto con demasiada frecuencia: no hay transferencia internacional en absoluto. Los datos no salen. Deja de ser "usar un modelo chino" y pasa a ser "ejecutar en Madrid un modelo publicado por un equipo de Hangzhou", que jurídicamente es una cosa completamente distinta.

Escenario tres: segmentar el flujo. La mayoría de tareas no necesitan saber quién es la persona. Para clasificar una reclamación no hace falta el nombre del reclamante; para extraer el importe de una factura no hace falta el NIF. Se puede separar la parte identificativa, resolverla localmente con una tabla de correspondencia determinista, y enviar al modelo únicamente lo que necesita para hacer su trabajo. Es el principio de minimización aplicado con algo de ingeniería.

La consecuencia práctica es que la pregunta "¿puedo usar este modelo con mis datos?" casi nunca tiene una respuesta absoluta. Depende de dónde se ejecute y de qué se le envíe, y ambas cosas son decisiones de arquitectura que están en nuestra mano.

Una advertencia sobre la anonimización

Existe la tentación de resolverlo todo diciendo que los datos se anonimizan antes de enviarlos y, por tanto, el problema desaparece. Es una afirmación frágil y conviene no construir nada encima.

El Reglamento distingue entre seudonimizar (sustituir los identificadores por claves, manteniendo en otro sitio la información que permite revertirlo) y anonimizar (romper la cadena de identificación de forma irreversible). Solo lo segundo sale del ámbito de la norma. Lo primero sigue siendo dato personal y sigue sujeto a todas sus obligaciones, tal como recoge el considerando 26.

Y anonimizar de verdad es difícil, sobre todo con texto libre, porque lo que reidentifica no suelen ser los identificadores evidentes sino la combinación de detalles del contexto. El trabajo de referencia en esta materia estimó que el 99,98 % de los ciudadanos estadounidenses podrían ser reidentificados correctamente en cualquier conjunto de datos a partir de quince atributos demográficos (Rocher et al., 2019). Un correo del que se ha borrado el nombre pero que menciona la localidad, el sector y el importe de una operación no es un dato anónimo: es un dato personal con el nombre tachado.

El Comité Europeo de Protección de Datos ha ido en la misma dirección al fijar un listón alto para considerar anónimo un modelo de inteligencia artificial, exigiendo un análisis caso por caso de la probabilidad razonable de identificación en lugar de aceptar declaraciones genéricas (CEPD, 2024).

Nada de esto invalida la técnica. La minimización reduce la exposición y es una buena práctica que conviene aplicar siempre. Lo que no es, es un salvoconducto que permita saltarse el análisis. Quien la venda como tal está trasladando un riesgo al cliente sin decírselo.

Cómo se decide en la práctica

Todo lo anterior converge en un procedimiento que es menos glamuroso de lo que suena y bastante más eficaz.

Construir el conjunto de evaluación antes de elegir nada

Esto es lo que separa la ingeniería de la intuición, y es el paso que casi nadie da. Consiste en reunir entre cincuenta y doscientos casos reales de la empresa con su respuesta correcta anotada por alguien que sepa del asunto. Casos normales, y sobre todo casos raros: el proveedor que factura en otro formato, el cliente con dos razones sociales, el documento escaneado torcido.

Ese conjunto es el activo más valioso de todo el proyecto, más que cualquier decisión de modelo, porque es lo único que permite responder con datos a la pregunta de si algo funciona. Y sobrevive a los modelos: cuando dentro de seis meses aparezca otro, se pasa por el mismo conjunto y se sabe en una tarde si merece la pena.

Sin él, la única estrategia defendible es pagar el modelo más caro y confiar. Por eso digo que quien no puede permitirse bajar de gama es quien no tiene evaluación. La capacidad de usar un modelo modesto no es una concesión al presupuesto: es una consecuencia de haber medido.

Probar de abajo arriba, no de arriba abajo

El orden natural es empezar por el modelo más capaz, comprobar que funciona y quedarse ahí. Es cómodo y garantiza no volver a plantearse el asunto.

El orden útil es el inverso: empezar por el modelo más pequeño que pueda plausiblemente resolver la tarea, medirlo contra el conjunto de evaluación y subir un escalón solo si no llega al umbral. Suele bastar con menos de lo que se supone, y en las tareas donde no basta, la subida está justificada con un número en la mano en lugar de con una sensación.

Fijar el umbral desde el negocio

Qué tasa de acierto es suficiente no es una decisión técnica. Depende de cuánto cuesta un error frente a cuánto cuesta una revisión, y eso solo lo sabe quien conoce el proceso.

Un sistema que clasifica correo interno puede vivir perfectamente con un 92 % de acierto. Uno que dispara pagos, no. Cuando el coste del error es alto, la conclusión correcta puede ser tanto usar el modelo más caro como añadir una confirmación humana, y a menudo las dos cosas.

Y no fiarse de las tablas de clasificación públicas

Los marcadores generales sirven para orientarse, y para poco más. Tienen un problema estructural bien documentado: la contaminación de los datos de entrenamiento. Cuando un conjunto de pruebas circula por internet el tiempo suficiente, acaba dentro del material de entrenamiento de los modelos siguientes, que entonces no lo resuelven sino que en parte lo recuerdan. La revisión sistemática de este fenómeno documenta que afecta a los marcadores más utilizados y que infla las puntuaciones de forma difícil de cuantificar (Xu et al., 2024).

Incluso las comparaciones basadas en preferencia humana a gran escala, que evitan ese problema concreto, miden algo distinto de lo que a una empresa le interesa: miden qué respuesta gusta más a un evaluador anónimo en una conversación abierta (Chiang et al., 2024), no si un modelo extrae bien el vencimiento de las facturas de tus proveedores.

Un modelo que va tercero en una tabla general puede ser el primero en tu tarea concreta. La única forma de saberlo es probarlo con tus casos.

No metas el modelo dentro del código

Llegamos a la parte que ordena todo lo demás, y que es de arquitectura, no de ahorro.

Si de todo lo anterior se deduce que distintas tareas quieren distintos modelos, la consecuencia inmediata es que en un sistema real conviven varios. Y si además el mercado se mueve tan deprisa como muestran los datos de los últimos tres años, la vida útil de cualquier decisión de modelo se mide en meses.

Un sistema que tenga el modelo escrito directamente en el código convierte cada una de esas revisiones en un encargo de desarrollo: valorar, presupuestar, programar, probar y desplegar, para algo que debería ser un cambio de configuración. Al cabo de un año, la mayoría de esos cambios no se hacen, y el sistema se queda funcionando con una decisión que se tomó en otro contexto y que ya nadie recuerda por qué se tomó.

La alternativa es separar la decisión de la implementación mediante una capa de enrutado: el sistema no llama a un modelo concreto, sino que pide "resolver esta tarea", y una configuración determina qué modelo la atiende. Es desacoplamiento, el principio de ingeniería más viejo y más rentable que existe, aplicado al componente que más rápido se mueve del sistema.

Sobre esa capa se puede construir un panel donde el responsable ve qué modelo atiende cada tarea, cuánto cuesta y qué tasa de acierto está dando contra el conjunto de evaluación, y donde puede cambiarlo sin tocar una línea de código. Eso permite además lo que de otro modo es imposible: probar un modelo nuevo contra una fracción del tráfico real y compararlo con el que está en producción antes de decidir.

Que esto funciona no es una intuición nuestra. Es un área con literatura propia. El trabajo que sistematizó el enfoque de cascada demostró que una arquitectura que encadena modelos de capacidad creciente, escalando solo cuando el resultado no supera un control de calidad, podía igualar el rendimiento del mejor modelo individual disponible con reducciones de coste de hasta el 98 % (Chen et al., 2023). Los sistemas de enrutado que aprenden a distribuir cada consulta entre un modelo fuerte y uno débil han documentado reducciones de coste superiores al doble sin degradar la calidad de las respuestas (Ong et al., 2024).

Conviene señalar que esto no es gratis: introduce una pieza más que mantener, y una capa de enrutado mal construida añade latencia y un punto de fallo nuevo. Compensa cuando hay varias tareas distintas y volumen suficiente para que la diferencia importe. Para un proceso único y de poco volumen, es sobreingeniería, y decirlo forma parte del trabajo.

Errores frecuentes

Elegir modelo antes de tener con qué evaluarlo. Es el error que hace inevitables todos los demás, porque deja la decisión en manos de la intuición y del marketing.

Optimizar el precio por token. Es la métrica visible y la equivocada. Un modelo que necesita tres intentos no es barato, y uno que obliga a revisar a mano tampoco.

Bajar de modelo en la tarea que no tocaba. Si hay que elegir dónde poner la gama alta, va en la tarea difícil y de bajo volumen, no en la fácil y masiva. Suele hacerse justo al revés, porque la tarea difícil es la que se enseña en las demostraciones.

Confundir dónde se desarrolló un modelo con dónde se ejecuta. Son dos cosas independientes, y solo la segunda tiene consecuencias legales sobre tus datos.

Cambiar de modelo sin volver a medir. Un cambio que mejora el resultado medio puede empeorarlo en el 5 % de casos raros que son justo los que importan. Sin el conjunto de evaluación, eso no se detecta hasta que se detecta mal.

Conclusión

La decisión no es entre calidad y precio. Esa forma de plantearlo ya contiene el error, porque supone que existe un único eje y que hay que elegir un punto en él.

La decisión real es entre tener criterio y no tenerlo. Con criterio (es decir, con un conjunto de casos reales que permita comprobar qué pasa) se puede poner la gama alta donde se nota y algo más modesto donde no, ejecutar cada cosa donde legalmente conviene, y cambiar de opinión dentro de seis meses sin rehacer nada. Sin criterio solo quedan dos opciones, que son pagar el modelo más caro para todo o arriesgarse a ciegas, y las dos son malas por el mismo motivo.

Un apunte final, que es también una prueba de lo que se ha defendido aquí. Este artículo se ha escrito deliberadamente sin nombrar modelos concretos ni citar precios, salvo cuando aparecen dentro de un dato fechado. La razón es que cualquier afirmación de ese tipo estaría desfasada en unos meses: la ventaja que hoy tiene un proveedor puede haber cambiado de manos para cuando alguien lea esto, y probablemente lo habrá hecho más de una vez.

Ahora conviene aplicar esa misma observación a otra cosa. Si un texto sobre este asunto envejece en unos meses, merece la pena preguntarse en qué estado se encuentra el sistema que tiene el nombre del modelo escrito a fuego en el código desde hace dos años, y qué haría falta para cambiarlo.

Si la respuesta es "un proyecto", ahí está el problema real, y no es de coste.

Referencias

Chen, L., Zaharia, M., & Zou, J. (2023). FrugalGPT: How to use large language models while reducing cost and improving performance (arXiv:2305.05176). arXiv. https://arxiv.org/abs/2305.05176

Chiang, W.-L., Zheng, L., Sheng, Y., Angelopoulos, A. N., Li, T., Li, D., Zhang, H., Zhu, B., Jordan, M., Gonzalez, J. E., & Stoica, I. (2024). Chatbot Arena: An open platform for evaluating LLMs by human preference (arXiv:2403.04132). arXiv. https://arxiv.org/abs/2403.04132

Comité Europeo de Protección de Datos [CEPD]. (2024). Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models. https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf

Ong, I., Almahairi, A., Wu, V., Chiang, W.-L., Wu, T., Gonzalez, J. E., Kadous, M. W., & Stoica, I. (2024). RouteLLM: Learning to route LLMs with preference data (arXiv:2406.18665). arXiv. https://arxiv.org/abs/2406.18665

Parlamento Europeo y Consejo. (2016). Reglamento (UE) 2016/679 relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos. Diario Oficial de la Unión Europea. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32016R0679

Rocher, L., Hendrickx, J. M., & de Montjoye, Y.-A. (2019). Estimating the success of re-identifications in incomplete datasets using generative models. Nature Communications, 10, 3069. https://doi.org/10.1038/s41467-019-10933-3

Stanford Institute for Human-Centered Artificial Intelligence [Stanford HAI]. (2025). The 2025 AI Index Report. Universidad de Stanford. https://hai.stanford.edu/ai-index/2025-ai-index-report

Stanford Institute for Human-Centered Artificial Intelligence [Stanford HAI]. (2026). The 2026 AI Index Report. Universidad de Stanford. https://hai.stanford.edu/ai-index/2026-ai-index-report

Xu, C., Guan, S., Greene, D., & Kechadi, M.-T. (2024). Benchmark data contamination of large language models: A survey (arXiv:2406.04244). arXiv. https://arxiv.org/abs/2406.04244