Cómo elegir un LLM para tu empresa

Para elegir un LLM para tu empresa, empieza por la tarea, no por el modelo. Define qué debe hacer el modelo y cómo es un buen resultado, fija tus restricciones (protección de datos, presupuesto, velocidad, integración), preselecciona unos pocos candidatos, pruébalos todos con los mismos casos reales y compara calidad, coste por tarea y tiempo de respuesta en una tabla de puntuación. La mejor opción es el modelo más barato y rápido que cumpla de forma fiable tu nivel de calidad, con condiciones que puedas aceptar. Como los modelos y los precios cambian a menudo, guarda tu conjunto de prueba y vuelve a ejecutarlo cuando se mueva el mercado.

Esta guía te da un proceso repetible. A propósito no clasifica modelos concretos: cualquier lista así se quedaría anticuada enseguida. Consulta directamente con los proveedores las gamas, capacidades y precios actuales.

Paso 1: define la tarea con precisión

«Necesitamos IA» no es un requisito. Anota:

• La tarea: por ejemplo, «redactar respuestas a correos de clientes sobre pedidos y devoluciones» o «extraer campos de facturas de proveedores».
• Entradas: qué recibe el modelo (mensajes cortos, documentos largos, imágenes, tablas).
• Salidas: texto libre, datos estructurados, código, decisiones.
• Idiomas: en qué idiomas están las entradas y salidas.
• Volumen: solicitudes al día o al mes, y picos.
• Quién ve el resultado: personal interno, clientes, el público.
• Riesgo: qué pasa si el resultado es incorrecto.

Cada tarea favorece modelos distintos. Un paso de clasificación con mucho volumen necesita un modelo rápido y barato. Analizar contratos largos requiere una ventana de contexto grande y buen razonamiento. Muchas aplicaciones usan varios modelos para distintos pasos.

Paso 2: fija tus criterios

Criterio	Preguntas que hacer
Calidad	¿Alcanza el nivel en nuestros casos de prueba? ¿Cómo maneja los casos difíciles e inusuales?
Seguimiento de instrucciones	¿Cumple de forma fiable las reglas de formato y las restricciones?
Fidelidad a las fuentes	¿Se ciñe a las fuentes facilitadas y reconoce cuando falta información?
Ventana de contexto	¿Admite nuestras entradas más largas con espacio para instrucciones y salida?
Idiomas	¿Qué tal funciona en cada idioma que necesitamos?
Modalidades	¿Necesitamos imágenes, documentos, audio?
Salida estructurada	¿Admite esquemas o JSON fiable?
Uso de herramientas	¿Puede llamar a funciones o herramientas si lo necesitamos?
Velocidad	Tiempo hasta el primer token y tiempo total de respuesta con nuestros tamaños de entrada
Coste	Coste por tarea con nuestros volúmenes de tokens, incluidas opciones de caché y por lotes
Condiciones de datos	Conservación, uso de las entradas para entrenar, ubicación de los datos, certificaciones, condiciones contractuales
Disponibilidad	Límites de uso, compromisos de disponibilidad, disponibilidad regional
Ecosistema	SDK, documentación, integración con nuestras plataformas
Continuidad	Con qué frecuencia se retiran modelos y con cuánta antelación se avisa

Pondera los criterios según tu tarea. En una herramienta interna de resúmenes pueden pesar más la calidad y el coste. En un asistente para clientes que trata datos personales, las condiciones de datos y la fidelidad a las fuentes pueden ser decisivas.

Paso 3: decide el modelo de despliegue

Opción	Qué significa	Ventajas	Inconvenientes
Modelo propietario vía API del proveedor	Modelo alojado por quien lo desarrolla	Arranque rápido, grandes capacidades, sin infraestructura	Dependencia de un proveedor; los datos salen de tu entorno según sus condiciones
Modelo propietario vía plataforma cloud	Modelos iguales o similares ofrecidos por un gran proveedor cloud	Encaja con contratos cloud existentes, opciones de alojamiento regional	La disponibilidad y las funciones pueden variar
Modelo de pesos abiertos alojado por terceros	Modelo de libre acceso ejecutado por un proveedor de alojamiento	Más opciones y portabilidad	Calidad del alojamiento y condiciones variables
Modelo de pesos abiertos autoalojado	Ejecutas el modelo en tu propia infraestructura	Máximo control sobre datos y personalización	Requiere hardware, conocimientos, mantenimiento y seguridad

Para la mayoría de pymes, empezar con una API es lo más pragmático. Vuelve a plantearte el autoalojamiento si los requisitos de datos, el volumen o la personalización justifican el esfuerzo.

Paso 4: crea un conjunto de prueba

El conjunto de prueba es el activo más valioso al elegir modelo. Permite comparar candidatos con justicia y reevaluar rápido más adelante.

• Reúne de 30 a 100 casos reales, anonimizados si hace falta.
• Refleja la distribución esperada: sobre todo casos típicos, más casos difíciles, casos límite y casos que deberían rechazarse o escalarse.
• Anota el resultado esperado o los criterios que debe cumplir una buena respuesta.
• Define la puntuación: por ejemplo, aprobado/suspenso por criterio, o una escala de 1 a 5 con descripciones claras.
• Mantenlo privado y estable, para que los resultados sean comparables con el tiempo.

En tareas con una única respuesta correcta, como extracción o clasificación, la puntuación puede automatizarse. En tareas de redacción, usa una rúbrica y haz que personas puntúen una muestra, idealmente sin saber qué modelo generó cada respuesta.

Paso 5: preselecciona y prueba

Elige de tres a cinco candidatos de distintos niveles de precio: al menos un modelo pequeño y barato, uno de gama media y uno de gama alta. Después:

1. Usa la misma estructura de prompt con todos y adáptala solo donde la documentación de un proveedor recomiende un formato concreto. Un prompt de sistema bien diseñado hace la comparación más justa.
2. Ejecuta el conjunto de prueba completo con cada uno.
3. Registra las puntuaciones de calidad, el consumo de tokens y los tiempos de respuesta.
4. Lee los fallos. Dos modelos con la misma media pueden fallar de formas muy distintas, y un tipo de fallo puede ser inaceptable para ti.

No elijas solo por los benchmarks públicos. Miden capacidades generales en tareas estándar, no tu tarea con tus datos y tu prompt.

Paso 6: calcula el coste por tarea

El precio por millón de tokens no es lo mismo que el coste por tarea. Un modelo más barato que necesita prompts más largos, más reintentos o más corrección humana puede salir más caro en total.

Para cada candidato, calcula:

• la media de tokens de entrada y salida por tarea según tus pruebas,
• el coste por tarea a precios actuales,
• el coste mensual con tu volumen previsto,
• el esfuerzo de revisión humana que implica su tasa de error.

La calculadora de coste de API de LLM compara tres escenarios de precio a la vez, y el artículo sobre los precios de las API de LLM explica los factores que cambian el cálculo, como la caché y los descuentos por lotes. Para el caso de negocio completo, con el tiempo de revisión, usa la calculadora de ROI de la automatización con IA.

Paso 7: revisa las condiciones legales y de datos

Antes de decidir, revisa con cada proveedor:

• si se conservan las entradas y salidas, durante cuánto tiempo y con qué fin,
• si tus datos pueden usarse para entrenar modelos y cómo oponerte si procede,
• dónde se procesan y almacenan los datos,
• los acuerdos de encargo de tratamiento y las certificaciones de seguridad,
• las condiciones sobre la titularidad y el uso de los resultados,
• las restricciones de uso que puedan afectar a tu caso.

Si operas en la UE y el caso de uso podría entrar en una categoría regulada por la Ley de IA, tenlo en cuenta pronto. El artículo sobre los niveles de riesgo de la Ley de IA explica cada nivel. Implica a tu delegado de protección de datos o a tu asesor jurídico en todo lo que afecte a datos personales.

Paso 8: decide con una tabla de puntuación

Una tabla ponderada sencilla hace transparente la decisión:

Criterio	Peso	Modelo A	Modelo B	Modelo C
Calidad en el conjunto de prueba	35 %	4	5	3
Coste por tarea	25 %	4	2	5
Velocidad	10 %	4	3	5
Condiciones de datos	20 %	4	4	3
Integración y ecosistema	10 %	3	4	4
Puntuación ponderada		3,9	3,75	3,8

Las cifras son ilustrativas. En este ejemplo las puntuaciones están muy cerca, algo habitual. Cuando ocurre, mira el análisis de fallos y los criterios eliminatorios para ti, y plantéate un enrutado: el modelo más barato para la mayoría de casos y el más potente para los difíciles.

Evitar la dependencia

• Encapsula la llamada al modelo en tu código para poder cambiar de proveedor con poco esfuerzo.
• Mantén prompts y conjuntos de prueba portables, sin atarlos a funciones propietarias de una plataforma salvo que el beneficio sea claro.
• Registra entradas, salidas y recuentos de tokens en tus propios sistemas, dentro de tus reglas de datos.
• Vigila los avisos de retirada. Los proveedores retiran versiones de modelos; planifica migraciones y vuelve a probar.

Errores habituales

• Elegir por defecto el modelo más famoso. Puede ser más potente y caro de lo que necesita tu tarea.
• Probar con unos pocos ejemplos elegidos a mano. Los resultados no reflejarán el uso real.
• Comparar el precio por token en lugar del coste por tarea.
• Ignorar las condiciones de datos hasta después de construir.
• Cambiar prompts y modelos a la vez, sin poder saber qué cambio importó.
• No volver a evaluar nunca. El mercado se mueve rápido; tu conjunto de prueba te permite aprovecharlo.

Resumen

Define la tarea, fija criterios ponderados, crea un conjunto de prueba realista, prueba unos pocos candidatos, compara el coste por tarea y las condiciones de datos y decide con una tabla de puntuación. Guarda el conjunto de prueba y vuelve a ejecutarlo cuando aparezcan modelos o precios nuevos. Si el coste pesa mucho, sigue con cómo reducir los costes de API de LLM, y si estás decidiendo cómo dar al modelo el conocimiento de tu empresa, lee RAG o fine-tuning.