Qué LLM elegir para una empresa (el criterio, no la marca)

El día que el modelo elegido no alcanzó

Esto se repite con variaciones mínimas en decenas de empresas que he visto de cerca. Alguien prueba un modelo en una demo de quince minutos, lo encuentra impresionante respondiendo preguntas generales, y a partir de esa impresión firma un contrato que va a sostener la atención al cliente, la clasificación de tickets o la redacción de propuestas comerciales durante el año siguiente. La demo midió una cosa: qué tan bien conversa el modelo sobre temas amplios con quien lo prueba. La operación real mide otra distinta: qué tan bien resuelve, miles de veces por día, una tarea específica y repetida, con datos sensibles de por medio y con la obligación de que la salida tenga un formato exacto que otro sistema pueda leer.

El síntoma aparece unas semanas después del lanzamiento, casi siempre en la misma secuencia. Primero sube el gasto, porque el volumen real de uso no se parecía en nada al de la prueba piloto. Después aparece un caso donde el modelo produjo una respuesta plausible pero incorrecta, y nadie tenía forma de auditarla porque la salida no venía en un formato verificable. Más tarde, alguien en legal o en seguridad de la información pregunta por dónde pasan los datos que se están enviando, y la respuesta es un silencio incómodo. Y cuando el equipo decide que necesita cambiar de proveedor porque ya no encaja, descubre que todo el trabajo (prompts, integraciones, ajustes de comportamiento) quedó atado a ese proveedor específico, sin ninguna capa que permitiera moverlo. Ninguno de esos problemas es culpa del modelo. Es la consecuencia de haber elegido sin criterio.

Seis criterios, no una marca ganadora

La pregunta que casi todo el mundo hace primero, “¿cuál es el mejor LLM?”, no tiene una respuesta estable: cada tanto un proveedor publica una versión nueva que reordena las tablas de comparación, y la opción líder de hoy queda dos escalones más abajo mañana. Construir una decisión de negocio sobre ese ranking es construir sobre arena. Las comparaciones puntuales entre proveedores concretos tienen su lugar dentro de inteligencia artificial para empresas, pero no son el punto de partida: el punto de partida es un conjunto de criterios que no caducan, porque no dependen de qué proveedor sacó la última actualización esta semana.

Ninguno de los seis pesa lo mismo en todas las tareas: en un caso el costo por operación decide todo, en otro la latencia descarta candidatos antes de mirar cualquier otra cosa.

• La tarea: qué tiene que hacer el modelo en concreto (clasificar, extraer datos, redactar, razonar sobre un proceso, orquestar otras herramientas), porque cada tipo de tarea premia capacidades distintas.
• El costo por operación de negocio: no el precio que aparece en la página del proveedor, sino cuánto cuesta completar de principio a fin la operación real que el modelo va a sostener.
• Dónde viven los datos: en qué infraestructura se procesa la información que entra al modelo, bajo qué jurisdicción y con qué reglas sobre reutilización.
• La latencia aceptable: cuánto puede tardar una respuesta sin romper la experiencia o el proceso que depende de ella, que no es lo mismo en un chat en vivo que en un proceso por lotes durante la noche.
• El control de salida: qué tan predecible, verificable y ajustable a un formato exacto es lo que el modelo entrega.
• Qué cuesta cambiarlo después: cuánto del trabajo construido (prompts, integraciones, comportamiento ajustado) sobrevive si mañana hay que moverse a otro modelo.

Las siguientes secciones desarrollan cada uno de estos seis con el detalle suficiente para aplicarlos, no como una lista para memorizar sino como una plantilla de preguntas que cualquier equipo puede llevar a su propia decisión.

Por qué se elige por tarea y no por benchmark

Un benchmark mide desempeño promedio sobre un conjunto amplio de pruebas genéricas: razonamiento matemático, comprensión de lectura, generación de código, preguntas de cultura general. Es información real, pero responde una pregunta que casi nunca es la tuya. Tu empresa no necesita un modelo que rinda bien en promedio sobre miles de tareas que nunca va a ejecutar: necesita uno que rinda bien en las cuatro o cinco tareas concretas que sí va a ejecutar, todos los días, a un volumen alto.

Por eso el primer criterio de la lista, la tarea, va antes que cualquier otro: condiciona a todos los demás. Clasificar un ticket de soporte en una de ocho categorías es una tarea acotada, de salida corta y predecible, donde un modelo más pequeño y barato suele bastar. Redactar una propuesta comercial que refleje el tono de la marca es una tarea abierta, donde el criterio de calidad es más subjetivo y el costo por operación pesa menos que el resultado. Orquestar varios pasos (leer un documento, consultar un sistema interno, decidir la siguiente acción) es una tarea de razonamiento encadenado, donde el control de salida y la capacidad de seguir instrucciones complejas importan más que la fluidez conversacional. Tres tareas, tres perfiles de modelo distintos, y ningún ranking general dice cuál sirve para cada una.

Esto no significa ignorar las comparaciones entre proveedores concretos, significa no empezar por ahí. Una vez que la tarea está definida con precisión, comparar candidatos puntuales tiene sentido, y ese ejercicio, con nombres propios que aquí se evitan porque cambian cada trimestre, es el que desarrolla ChatGPT vs Claude para empresas: cómo elegir sin perder el criterio. Empezar por la marca y buscarle una tarea después es el orden invertido que produce los problemas de la primera sección.

El costo por operación: el criterio real de negocio

El precio que un proveedor publica está expresado en una unidad que ningún gerente de operaciones usa para pensar su negocio: costo por millón de unidades de texto procesadas. Esa cifra sirve para comparar proveedores en abstracto, pero no dice nada sobre lo que de verdad importa: cuánto cuesta resolver una operación completa de tu proceso, atender un ticket hasta cerrarlo, generar un resumen que un analista pueda usar sin corregirlo, calificar un lead con la confianza suficiente para pasarlo a ventas.

Hay que traducir el precio a costo por operación porque dos modelos con el mismo precio de lista pueden salir muy distintos en la práctica. Un modelo más barato que necesita reintentos, revisión humana adicional y corrección de formato en la mitad de los casos termina costando más por operación completada que uno más caro que acierta a la primera. Y al revés: pagar de más por capacidad de razonamiento en una tarea de clasificación simple, donde un modelo mucho más económico ya llega al mismo resultado, es presupuesto quemado que nadie nota hasta el cierre del trimestre.

Calcular esto exige tres números: el costo directo de la llamada al modelo, el costo del trabajo humano que corrige o revisa lo que entrega, y la tasa de fallo real sobre un volumen representativo, no sobre los diez ejemplos fáciles de la demo. Sin esos tres números, “barato” y “caro” son etiquetas de marketing, no una decisión de negocio.

Dónde viven los datos: la pregunta que casi siempre llega tarde

De los seis criterios, este es el que con más frecuencia se salta al elegir y el que con más fuerza vuelve después, normalmente en forma de correo de legal o de un cliente que pregunta por su contrato de confidencialidad. Dónde vive el dato no es una pregunta abstracta de cumplimiento: define qué información puede entrar al modelo y cuál no. Datos de salud, información financiera de clientes, contratos con cláusulas de confidencialidad estricta o cualquier dato personal bajo un marco regulatorio exigente no se procesan igual con cualquier proveedor, y la diferencia no siempre está visible en la interfaz de uso diario.

Aquí entra una decisión que va más allá de elegir un proveedor: si el modelo se ejecuta sobre infraestructura propia, con un modelo de código abierto que la empresa aloja y controla, o si se consume como servicio de un proveedor externo. La diferencia práctica se desarrolla en Modelo open source vs modelo propietario: el criterio real para decidir; el resumen para este criterio es simple: alojar el modelo da control total sobre dónde vive el dato, a cambio de asumir la operación técnica, y consumir un servicio externo da velocidad de implementación, a cambio de depender de las políticas de retención y reutilización de datos que ese proveedor tenga publicadas.

Este criterio no se resuelve leyendo un titular de marketing sobre privacidad. Se resuelve pidiendo, por escrito, la política real de retención, de uso de las entradas para entrenamiento futuro y de la ubicación de los centros de datos donde se procesa la información, y comparando esa política contra la clasificación de sensibilidad que tu propia empresa le da a cada tipo de dato.

Latencia y control de salida: lo que se siente cuando el modelo ya está en producción

Estos dos criterios se sienten juntos porque ambos aparecen recién cuando el modelo deja de ser una prueba y empieza a sostener un proceso real. La latencia aceptable no es un número universal: depende de qué espera el otro lado de la interacción. Una respuesta que tarda unos segundos es invisible en un flujo por lotes que corre de madrugada sobre miles de registros, y es una experiencia rota en un chat donde una persona espera en tiempo real. Definir la latencia como criterio significa preguntar, para cada tarea, quién está esperando la respuesta y cuánto puede esperar sin que el proceso se rompa.

El control de salida es el criterio que más se subestima y el que más duele cuando falta, sobre todo donde el modelo no conversa con una persona sino que alimenta a otro sistema: una integración que espera un formato con campos exactos, un flujo de agentes de IA empresariales donde la salida de un paso se convierte en la entrada del siguiente, un reporte que se genera automáticamente y nadie revisa antes de enviarlo. Ahí, una respuesta “casi correcta” en formato libre no sirve: rompe el paso siguiente o produce un error silencioso que nadie detecta hasta que el reporte ya salió mal. El criterio no es solo si el modelo acierta, es si su salida se puede restringir, validar y auditar.

Cuanto más autónoma es la tarea, con más pasos encadenados sin revisión humana en el medio, más pesa el control de salida, porque un error ahí no se corrige antes de tener consecuencia: se propaga.

Cuándo conviene usar más de un modelo, no uno solo

La pregunta de si conviene estandarizar en un único modelo o usar varios según la tarea se responde con el mismo criterio de tarea del que ya se habló: si las tareas de la empresa son parecidas entre sí en volumen, sensibilidad y complejidad, un solo modelo bien elegido simplifica la operación, el contrato y el mantenimiento. Si son muy distintas, clasificar miles de correos cortos por un lado y redactar informes largos y matizados por el otro, forzarlas a un único modelo casi siempre significa pagar de más en una de las dos, o sacrificar calidad en la otra.

Cuando sí conviene sumar un segundo o tercer modelo es cuando el primero, elegido bien para su tarea principal, empieza a usarse fuera de ese perfil solo porque ya está integrado: es el mismo error de origen de la primera sección, repetido puertas adentro. La decisión de sumar un modelo debe pasar por los mismos seis criterios que la primera elección, no por la comodidad de no abrir un segundo contrato. Este balance entre estandarizar y diversificar se desarrolla en usar varios modelos de IA en una empresa o estandarizar en uno.

Cómo se hace la prueba comparada con tus propios casos

La prueba que de verdad predice cómo va a funcionar un modelo en tu empresa no es la demo del proveedor, es una prueba comparada armada con tus propios casos, y el proceso es más simple de lo que suena. Se reúne una muestra real de la tarea, entre treinta y cien casos ya resueltos, con el resultado correcto ya conocido (tickets ya clasificados, resúmenes ya validados, correos ya respondidos), y se corre la misma tarea, con el mismo texto de entrada, sobre cada modelo candidato.

Después se mide contra tres cosas, no contra la impresión de que “se ve bien”: la exactitud comparada contra el resultado correcto que ya conocías de antemano, el costo real de haber procesado esa muestra, y cuántos casos salieron en un formato usable sin corregir nada. Conviene incluir a propósito los casos difíciles de tu operación (el ticket ambiguo, el documento mal escaneado, el correo en un tono raro), no solo los fáciles, porque ahí se nota la diferencia real entre candidatos.

Dos cuidados marcan la diferencia entre una prueba útil y una que solo confirma lo que ya se quería creer: evaluar a ciegas, sin que quien revisa los resultados sepa qué modelo generó cada respuesta, para no favorecer al proveedor de moda; y repetir la prueba cada cierto tiempo, porque los proveedores actualizan sus modelos con frecuencia y una prueba de hace seis meses ya no describe al modelo de hoy. El detalle de cómo montar esto dentro de un despliegue completo se cubre en cómo implementar un LLM en una empresa.

El criterio que sigue en pie cuando el ranking ya cambió

Para cuando esta página se lea de nuevo dentro de un año, el modelo que hoy encabeza cualquier comparación va a haber sido superado por otro, y probablemente más de una vez. Eso no es un defecto del mercado, es su ritmo normal, y una empresa que ancla su decisión al nombre del proveedor que gana hoy construye sobre un piso que se mueve cada trimestre. Los seis criterios (tarea, costo por operación, dónde viven los datos, latencia aceptable, control de salida y qué cuesta cambiarlo) no dependen de qué proveedor lanzó la última versión. Son las preguntas que se le pueden hacer a cualquier modelo, hoy o dentro de tres años, y siguen siendo las correctas aunque cambien todos los nombres propios.

El sexto criterio, qué cuesta cambiarlo después, es el que convierte esta lista en una decisión con memoria, no en un ejercicio que se repite desde cero cada vez que sale un modelo nuevo. Diseñar la integración pensando en portabilidad desde el primer día (prompts documentados fuera del código, formatos de salida definidos por la empresa, datos de evaluación propios que sirven para cualquier candidato futuro) es lo que separa a la empresa que puede migrar en semanas de la que queda atrapada en un proveedor porque todo su conocimiento operativo quedó escrito en el idioma de ese proveedor. Ese es el desarrollo completo de cómo cambiar de modelo de IA sin perder lo construido. El criterio, al final, no se aplica una vez: se aplica cada vez que el mercado se mueve, y el mercado siempre se mueve.