Usar varios modelos de IA en una empresa o estandarizar en uno

Cada área eligió su modelo de IA por su cuenta, y ahora nadie explica por qué

A fin de mes llegan dos facturas de proveedores de IA distintos: marketing usa un modelo para redactar campañas, soporte usa otro para responder tickets, y cada equipo decidió por su cuenta, sin que nadie mirara el conjunto. Es el patrón más común que encuentro al entrar a una empresa mediana: no hay una decisión de arquitectura, hay una colección de decisiones sueltas que un día se sumaron sin que nadie las planeara juntas.

El problema no es tener dos modelos. El problema es no saber por qué se tiene dos. Nadie se sentó a decidir “este modelo para esto, aquel modelo para aquello”. Cada área resolvió su dolor inmediato con la herramienta que tenía a mano, y la suma de esas decisiones parciales terminó pareciendo una estrategia sin serlo. Cuando llega la auditoría de gasto o la revisión de seguridad, nadie puede explicar el criterio, porque no hubo criterio: hubo urgencia.

Esa es la pregunta real detrás de “¿debería estandarizar en un solo modelo de IA?”: no es cuál modelo es mejor, es si la empresa tiene un criterio o si está improvisando. Cambiar de proveedor más adelante es mucho más simple cuando ese criterio existió desde el inicio, algo que se nota justamente al cambiar de modelo de IA sin perder lo construido; cuando no existió, cada cambio de proveedor es una reconstrucción completa.

Qué se gana de verdad al estandarizar en un solo modelo de IA

Estandarizar tiene ventajas reales, y conviene nombrarlas antes de discutir lo demás, porque buena parte del ruido en esta discusión viene de tratar la estandarización como si fuera solo burocracia. No lo es.

• Un solo contrato y una sola política de datos: legal y seguridad revisan un proveedor, no tres, y las cláusulas de privacidad y retención se auditan una vez, no varias.
• Un equipo que se vuelve experto en una sola herramienta: el prompt que funciona para un caso se reutiliza en otro, y la curva de aprendizaje no se repite área por área.
• Gobierno de datos más simple: existe una sola bitácora de qué información sale de la empresa hacia un proveedor externo, no varias que hay que cruzar a mano.
• Menos superficie de riesgo: cada integración nueva es una puerta de entrada distinta para un incidente de seguridad; una puerta es más fácil de vigilar que tres.

La simplicidad de gestionar un solo proveedor tiene un costo directo: se deja de aprovechar que existen tareas donde un modelo mucho más económico entrega exactamente el mismo resultado. Eso es lo que se pierde al estandarizar sin mirar la tarea, y es el punto que sigue.

Dónde el modelo barato hace exactamente el mismo trabajo

No todas las tareas necesitan el modelo más capaz del mercado. Clasificar un ticket como urgente o no urgente, extraer un dato de un documento con formato conocido, resumir una transcripción, responder una pregunta frecuente con la información ya disponible en la base de conocimiento: son tareas de alto volumen y bajo riesgo de juicio, y ahí un modelo económico entrega el mismo resultado que uno costoso, porque el problema no exige razonamiento profundo, exige velocidad y repetición.

El error que veo seguido es usar el modelo más caro disponible para toda la operación “por si acaso”, sin medir si la tarea lo necesita. Es pagar un especialista para llenar un formulario. La capacidad sobra, y esa capacidad sobrante se paga, no se regala. La forma correcta de mirarlo no es “qué modelo es mejor” sino “qué tan compleja es esta tarea específica y qué tan cara sale equivocarse en ella”.

Esto conecta directo con qué LLM elegir para una empresa: el criterio no es la marca, es el par tarea-riesgo. Una empresa que ya hizo ese ejercicio para elegir su primer modelo tiene, sin saberlo, la mitad del trabajo hecho para decidir después si le conviene sumar un segundo.

El costo real de gestionar más de un proveedor de IA

Usar dos modelos abarata el consumo, pero administrarlo no es gratis, y esa parte casi nunca entra en la cuenta inicial. Dos proveedores significan dos contratos que revisar, dos políticas de privacidad que cumplir, dos integraciones técnicas que mantener cuando alguno cambia su interfaz, y dos curvas de aprendizaje para el equipo que escribe y ajusta los prompts.

• Doble superficie de auditoría: seguridad y cumplimiento tienen que revisar dos proveedores, no uno, cada vez que cambia una normativa o una política interna.
• Doble mantenimiento técnico: cada proveedor actualiza su interfaz en su propio calendario, y alguien del equipo tiene que seguir a ambos al mismo tiempo.
• Doble criterio de calidad: hay que evaluar y monitorear el desempeño de cada modelo por separado, porque uno puede degradarse sin que el otro lo haga.
• Más reglas de enrutamiento que mantener: alguien tiene que revisar, con el tiempo, si la regla “esta tarea va al modelo barato” sigue siendo cierta.

Esa gestión adicional consume horas de un equipo que probablemente ya está corto de tiempo. Por eso la pregunta no es solo cuánto cuesta usar un LLM en una empresa en el papel, es si ese ahorro compensa el trabajo de sostener dos proveedores en paralelo. Con poco volumen, casi nunca compensa.

Cómo se enruta por tarea en la práctica

Cuando el volumen ya justifica usar más de un modelo, el trabajo técnico se llama enrutamiento: definir qué tarea va a qué modelo antes de que la tarea llegue. No es una decisión que tome el modelo, es una decisión que toma la empresa y que queda escrita en la arquitectura del sistema, no en la memoria de un desarrollador.

El punto de partida es catalogar las tareas, no los modelos. Para cada tarea repetida se responden dos preguntas: qué tan alto es el volumen y qué tan cara sale una respuesta equivocada. Con esas dos variables se arma la regla de enrutamiento.

• Alto volumen, bajo riesgo de error: clasificación, extracción de datos estructurados, respuestas de primer nivel. Va al modelo económico, y el ahorro se multiplica por el volumen.
• Bajo volumen, alto riesgo de error: redacción legal, análisis financiero, cualquier salida que un cliente o un regulador vaya a leer con lupa. Va al modelo de mayor capacidad, porque el costo de un error supera cualquier ahorro posible.
• Tareas mixtas: un primer filtro económico que resuelve el caso simple, y una escalada al modelo más capaz solo cuando el caso no se resuelve en ese primer paso. Es el patrón que más ahorra en la práctica, porque la mayoría de los casos reales son simples.

Esta lógica de enrutamiento es la misma que sostiene a los agentes de IA empresariales bien diseñados: no es un solo modelo haciendo todo, es un sistema que decide qué recurso usar según la tarea, con reglas explícitas y auditables, no según qué proveedor tuvo mejor marketing ese trimestre.

A partir de qué volumen se justifica complicarse con dos modelos

No hay un número universal, y cualquiera que dé uno sin conocer tu operación está inventando. Lo que sí hay es un criterio: se justifica usar más de un modelo cuando el ahorro que genera enrutar una tarea de alto volumen al modelo económico supera, con margen claro, el costo de mantener esa segunda integración funcionando.

En la práctica, esto casi nunca aparece al principio. Una empresa que recién está probando IA en un par de procesos gana más simplificando: un modelo, un proveedor, un equipo aprendiendo a usarlo bien. La complejidad de un segundo modelo empieza a tener sentido cuando ya existe una tarea con volumen alto, estable y medido (miles de ejecuciones al mes, no un piloto de dos semanas) y ese volumen por sí solo mueve la aguja del gasto.

Es la misma lógica que separa una automatización aislada de una transformación real: montar un segundo modelo porque “es más barato” sin medir el volumen que de verdad pasa por esa tarea no ahorra nada, solo agrega una pieza más que mantener. El ahorro se demuestra con el uso real, no con la lista de precios del proveedor.

El efecto real en el bloqueo de proveedor

Estandarizar en un solo modelo, sin ninguna otra medida, aumenta el bloqueo de proveedor: con el tiempo, los prompts, las integraciones y hasta el criterio del equipo terminan escritos a la medida de un proveedor específico, y salir de ahí se vuelve caro. No porque el contrato lo impida, sino porque reconstruir todo ese trabajo interno cuesta tiempo y dinero real.

Usar más de un modelo, aunque parezca contradictorio, reduce ese riesgo, pero no por el simple hecho de tener dos proveedores activos. Lo reduce porque obliga a construir una capa propia entre la empresa y los modelos: prompts documentados fuera de la interfaz de un proveedor, evaluaciones que miden calidad de forma independiente del modelo que las procesó, datos organizados según el proceso de negocio y no según el formato que exige un proveedor en particular. Esa capa es la que de verdad protege contra el bloqueo, tengas uno o dos modelos activos.

Por eso una empresa puede estandarizar en un solo modelo hoy y no estar bloqueada, si construyó esa capa propia desde el inicio, y otra puede usar tres modelos y estar completamente atrapada, si cada integración se hizo pegada al detalle específico de cada proveedor. El número de modelos no determina el bloqueo; lo determina si existe algo propio entre la empresa y el proveedor, o si el proveedor es la arquitectura completa.

Mi criterio sobre cuándo vale la pena complicarse

La pregunta no es cuántos modelos usar, sino si conoces tu volumen

Vale la pena volver a la pregunta inicial (“¿un modelo o varios?”) con el marco correcto: no es una pregunta de preferencia ni de qué proveedor convenció mejor al equipo de compras, es una pregunta de volumen y de tarea. Estandarizar simplifica la gestión y sube el costo por operación. Diversificar abarata el costo por operación y sube el costo de gestión. Ninguna de las dos es la respuesta correcta en abstracto.

Lo que sí es un error, en cualquiera de los dos caminos, es decidir sin haber medido antes qué tareas mueve la empresa, con qué volumen y con qué riesgo cada una. La arquitectura de IA de una empresa no se copia de otra ni se elige por la conversación de moda: se arma mirando el proceso propio, del mismo modo en que se diagnostica cualquier otro proceso antes de automatizarlo en una empresa AI Native. Ese diagnóstico, y no el modelo que se elija al final, es lo que separa una decisión de arquitectura de una improvisación que un día se volvió costumbre.