Qué modelo de IA elegir para cada tarea: un método por evaluación

La forma correcta de elegir un modelo de IA para una tarea es medir cuatro cosas en esa tarea concreta —calidad, coste, latencia y riesgo— y quedarte con el que mejor las equilibra, no con el que tenga mejor prensa. No hay un modelo mejor en abstracto: hay un modelo mejor para conciliar facturas, otro para redactar respuestas de soporte y otro para extraer datos de un PDF, y ese ranking cambia cada pocos meses. Por eso, cuando un comité me pregunta qué modelo usar, mi respuesta empieza por otra pregunta: para qué tarea, con qué datos y con qué tolerancia al error.

Elegir por marca es cómodo y casi siempre erróneo. Un modelo que gana los benchmarks públicos puede ser lento, caro o innecesariamente potente para el 80% de tus tareas. Lo que sigue es el método que aplico para decidirlo con datos de tu operación, no con la nota de un examen genérico.

Por qué elegir por marca es la peor heurística

El mercado empuja a decidir por reputación: el laboratorio de moda, el modelo que salió en las noticias, el que usa un competidor. Ninguna de esas señales predice cómo se va a comportar el modelo en tu tarea, con tus documentos y tus reglas. Los benchmarks públicos miden capacidades generales sobre datos que no son los tuyos. Te dicen quién es buen atleta, no quién corre bien tu carrera.

Hay un segundo problema con elegir por marca: te ata. Si diseñas el sistema alrededor de las peculiaridades de un modelo concreto, cambiarlo cuando aparezca uno mejor o más barato deja de ser una decisión y pasa a ser un proyecto. La marca del proveedor tiene que ser el detalle más fácil de cambiar de toda tu arquitectura, no el cimiento.

Las cuatro dimensiones que mido en cada tarea

Para cada tarea que va a ejecutar un agente, evalúo el modelo candidato en cuatro ejes. Ninguno se decide de oído.

Dimensión	Qué pregunto	Cómo se mide
Calidad	¿Acierta en esta tarea con mis datos?	Casos de prueba con respuesta conocida y umbral de acierto
Coste	¿Cuánto cuesta por caso al volumen real?	Coste por ejecución multiplicado por volumen mensual
Latencia	¿Responde a tiempo para este proceso?	Tiempo de respuesta bajo carga, no en una prueba aislada
Riesgo	¿Qué pasa cuando se equivoca y dónde viven mis datos?	Gravedad del fallo, reversibilidad y tratamiento de los datos

La clave es que estos ejes se ponderan distinto según la tarea. Un agente que prepara un borrador para revisión humana tolera más error a cambio de menor coste. Un agente que actúa sin supervisión sobre un sistema financiero prioriza calidad y riesgo por encima del precio. No existe una ponderación universal, sino la de cada tarea.

Cómo montar la evaluación

La evaluación es lo que convierte “este modelo parece bueno” en “este modelo acierta el 94% de los casos de esta tarea a este coste”. El proceso que uso tiene cuatro pasos.

Reúne un conjunto de casos reales. Entre unas decenas y unos cientos de casos de la tarea, con la respuesta correcta conocida. Sacados de tu operación, no inventados, porque el objetivo es medir el rendimiento sobre lo que de verdad vas a pedirle.

Define el umbral antes de mirar los resultados. Qué porcentaje de acierto es aceptable, qué tipos de error son tolerables y cuáles no. Decidir el listón después de ver las notas es cómo se aprueban sistemas que no deberían aprobarse.

Pasa los candidatos por el mismo conjunto. Cada modelo se enfrenta a los mismos casos, con el mismo prompt y las mismas herramientas. Comparar peras con peras es la mitad del valor de una evaluación.

Revisa los fallos a mano. El número agregado esconde el patrón. Los fallos concretos te dicen si el modelo se rompe en un tipo de caso que puedes acotar, o si el problema es de fondo. Ese análisis vale más que el porcentaje.

Este es el mismo esqueleto que uso para medir el sistema completo una vez desplegado, y lo desarrollo en evaluación de agentes de IA. La diferencia es de alcance: aquí evalúas el modelo aislado en una tarea; allí, el agente entero en producción.

Cuándo hay que re-evaluar

Una elección de modelo no es permanente, y tratarla como si lo fuera es un error caro. Los modelos cambian de precio, de velocidad y de capacidad a un ritmo que ninguna otra pieza de tu stack iguala. Vuelvo a evaluar cuando pasa cualquiera de estas cosas:

• Aparece un modelo nuevo que promete mejor relación en la tarea, o el que usas baja de precio.
• La calidad observada en producción se degrada respecto a la evaluación inicial.
• Cambia la tarea: nuevas reglas, nuevos tipos de caso, mayor volumen.
• Cambia el marco de riesgo: nuevos requisitos de dónde pueden tratarse los datos.

La disciplina de re-evaluar solo es sostenible si el conjunto de casos y los umbrales están guardados y versionados. Si cada revisión exige reconstruir la evaluación desde cero, no se hará. La evaluación es un activo que se mantiene, no un trámite de arranque.

La sustituibilidad es un requisito de arquitectura

Todo lo anterior solo funciona si puedes cambiar de modelo sin reescribir el sistema. Por eso trato la sustituibilidad como un requisito de diseño, no como una aspiración. En la práctica significa que el proceso —sus reglas, sus controles, sus trazas y sus integraciones— no queda codificado dentro de las primitivas propietarias de un laboratorio. El modelo es un componente conectado por detrás, y la lógica de tu operación vive fuera de él.

Esta es la diferencia entre desplegar el catálogo de un fabricante y construir una operación agnóstica. Un ingeniero enviado por el proveedor del modelo tiene el mandato de desplegar el stack que su empresa vende. Yo mantengo abierta la puerta de cambiar el modelo cuando los números de la evaluación lo pidan. No es desconfianza hacia ningún laboratorio, sino alinear la arquitectura con el hecho de que los modelos son utility y se comportan como tal. Cómo encaja esto en el sistema completo lo trato en la arquitectura de agentes de IA.

Este artículo es el criterio de decisión por tarea. Si lo que buscas es el mapa de qué tipos de modelo existen y para qué encaja cada categoría, está en LLM para empresas. Dónde se ejecuta cada modelo —en tu infraestructura o por API— es una decisión aparte que abordo en agentes de IA en local o en la nube, y afecta directamente al eje de riesgo cuando entran datos personales, tema que desarrollo en IA y protección de datos. Todo esto es una pieza del panorama de fondo que enmarco en agentes de IA para empresas.

Preguntas frecuentes

¿Cuál es el mejor modelo de IA para una empresa?

No existe uno mejor para todo. El mejor modelo depende de la tarea: para una tarea de extracción de datos, otro para redacción, otro para razonamiento sobre reglas. Se decide midiendo calidad, coste, latencia y riesgo en cada tarea concreta con tus propios casos, no eligiendo una marca para toda la operación.

¿Debo usar el mismo modelo para todas las tareas?

Casi nunca conviene. Distintas tareas tienen distinta exigencia de calidad, tolerancia al coste y sensibilidad de datos. Un sistema bien diseñado enruta cada tarea al modelo que mejor la equilibra, y esa asignación se revisa cuando cambian los modelos o las tareas.

¿Cada cuánto hay que revisar la elección de modelo?

No hay un calendario fijo, se revisa por disparadores. Cuando aparece un modelo mejor o más barato para la tarea, cuando la calidad en producción se degrada, cuando cambia la tarea o cuando cambian los requisitos de tratamiento de datos. Mantener guardado el conjunto de evaluación es lo que hace viable esa revisión.

¿Por qué no elegir directamente el que gana los benchmarks?

Porque los benchmarks públicos miden capacidades generales sobre datos que no son los tuyos, y no predicen coste ni latencia en tu operación. Un modelo que puntúa alto puede ser lento o caro para tus tareas más frecuentes. La única medida fiable es tu propia evaluación sobre tus casos.