La competencia entre OpenAI y Anthropic muestra que los proveedores de modelos de IA ya no se eligen solamente por la calidad técnica de sus modelos. El precio, los descuentos, las condiciones comerciales y la posibilidad de cambiar de proveedor también pueden modificar la economía de un producto digital.

El caso de Replit, que según un informe de The Information habría trasladado la mayor parte de su gasto hacia OpenAI mediante un contrato superior a US$100 millones anuales, vuelve visible una decisión que muchas empresas deberán enfrentar a menor escala: ¿conviene construir toda una operación alrededor de un único proveedor o diseñar una arquitectura capaz de combinar alternativas?

La respuesta no es igual para todos los negocios. Depende de los procesos, el volumen de uso, la criticidad de las respuestas y el nivel de flexibilidad que la empresa necesita conservar.

Qué está cambiando entre los proveedores de modelos de IA

Hasta hace poco, una decisión habitual consistía en comparar modelos por sus capacidades: comprensión de instrucciones, generación de código, análisis de documentos o calidad de las respuestas. Esos criterios siguen siendo importantes, pero ya no alcanzan para evaluar el costo total de una implementación.

El documento fuente describe una competencia en la que OpenAI estaría utilizando descuentos para captar clientes empresariales. En el caso de Replit, el descuento informado habría superado el 30%. También se menciona una oferta de 40% para DataCamp, condicionada al uso de Codex. Se trata de condiciones reportadas por fuentes periodísticas y por ejecutivos de las empresas, no de una tarifa general aplicable a cualquier cliente.

La situación permite extraer una conclusión más amplia: el precio de acceso a un modelo puede cambiar de manera significativa según el volumen, la negociación y el compromiso comercial. Por eso, una evaluación seria debe considerar tanto la calidad del modelo como las condiciones concretas de uso.

No existe un modelo ideal para todas las tareas

Una empresa puede necesitar inteligencia artificial para resolver problemas muy distintos:

  • Responder consultas frecuentes de clientes.
  • Recomendar productos según el catálogo y las reglas comerciales.
  • Analizar documentos y detectar información faltante.
  • Clasificar oportunidades comerciales.
  • Escribir o revisar código.
  • Resumir conversaciones y actualizar sistemas internos.
  • Ejecutar acciones dentro de un flujo operativo.

Es posible que un proveedor funcione muy bien para una tarea y no sea la alternativa más conveniente para otra. Una respuesta simple y repetitiva puede resolverse con un modelo menos costoso, mientras que una tarea compleja puede justificar el uso de una opción más capaz.

Esto no implica que haya que cambiar de modelo en cada consulta. Significa que la arquitectura debería permitir tomar esa decisión de manera explícita, según la complejidad, el riesgo, la velocidad y el costo de cada proceso.

El caso de Rippling citado en el documento ilustra cómo puede cambiar el uso real dentro de una compañía. Según declaraciones de su CEO, en mayo de 2026 los modelos de Anthropic representaban el 57% del trabajo de programación medido, frente al 16% de OpenAI. En octubre, esas proporciones reportadas se habían invertido: 52% para OpenAI y 18% para Anthropic. Es un caso empresarial particular, no una medición de todo el mercado, pero muestra que las preferencias pueden modificarse en pocos meses.

Qué evaluar antes de elegir un proveedor

Una comparación útil no debería limitarse a una tabla de precios. Conviene analizar el impacto del proveedor dentro de todo el proceso.

1. Costo por tarea, no solo por token

El precio unitario es un dato importante, pero no representa por sí solo el costo final. También hay que observar cuántas veces se consulta el modelo, qué cantidad de información recibe, cuánto contexto necesita y qué proporción de respuestas requiere revisión humana.

Una alternativa aparentemente más barata puede generar más costo si produce errores, necesita reintentos frecuentes o exige controles adicionales. La comparación debe hacerse sobre tareas reales y con volúmenes representativos.

2. Calidad según el caso de uso

No alcanza con preguntar cuál es el modelo más potente. La pregunta correcta es cuál responde mejor al problema específico de la empresa.

Para evaluarlo, se puede armar un conjunto de casos reales y medir criterios como:

  • Exactitud de la respuesta.
  • Capacidad para respetar reglas y formatos.
  • Manejo de información incompleta.
  • Calidad de las derivaciones a una persona.
  • Tiempo de respuesta.
  • Frecuencia de errores o respuestas que requieren corrección.

La prueba debería incluir situaciones normales y excepciones. Un sistema puede funcionar bien en consultas simples y fallar cuando el usuario plantea una condición poco habitual.

3. Facilidad de integración y reemplazo

La dependencia no surge únicamente del contrato comercial. También aparece cuando el código, los flujos y las instrucciones quedan atados a las particularidades de un solo proveedor.

Para reducir ese riesgo, conviene separar la lógica de negocio de la conexión con el modelo. Las reglas de la empresa, los criterios de derivación, los permisos y las validaciones no deberían quedar mezclados sin necesidad con una única interfaz de proveedor.

Esto permite probar otra alternativa sin reconstruir todo el sistema. No garantiza una migración inmediata: los tiempos dependen de las integraciones, las funciones utilizadas y las evaluaciones de calidad. Pero sí puede disminuir el costo de adaptación.

4. Condiciones comerciales y previsibilidad

Los descuentos pueden ser atractivos, pero una decisión de largo plazo no debería basarse solamente en una oferta inicial. Es necesario entender qué compromisos de volumen existen, cuánto dura la condición acordada y qué ocurre si cambia el consumo o termina el beneficio.

También conviene analizar la capacidad de negociar, la estabilidad de las tarifas y el impacto que tendría una modificación de precios en el margen del producto o servicio.

5. Observabilidad y control

Una operación con inteligencia artificial necesita registrar qué modelo se utilizó, para qué tarea, con qué resultado y a qué costo. Sin esa información, la empresa no puede saber si una alternativa más barata mantiene la calidad ni detectar dónde se concentra el gasto.

La observabilidad también ayuda a identificar cuándo una tarea debería cambiar de modelo, cuándo conviene pedir intervención humana o cuándo una respuesta no cumple las reglas definidas.

Cuándo conviene una arquitectura con varios modelos

El uso de varios proveedores puede ser conveniente cuando una empresa tiene tareas heterogéneas, un volumen elevado de consultas o una dependencia significativa de los costos de inferencia. También puede resultar útil cuando el producto necesita continuar operando aunque una alternativa cambie sus precios, sus límites o sus condiciones de acceso.

Sin embargo, sumar proveedores no es un objetivo en sí mismo. Cada conexión adicional agrega trabajo de evaluación, monitoreo y mantenimiento. Una arquitectura flexible tiene sentido si responde a una necesidad concreta y si la empresa cuenta con criterios claros para decidir qué modelo usar en cada situación.

Una estrategia práctica puede comenzar con un solo caso de uso. Primero se define la métrica, se documentan los errores y se prueba la calidad con datos reales. Después se compara una segunda alternativa en las tareas donde el costo o el rendimiento representan una limitación. Recién entonces se decide si la complejidad adicional se justifica.

Cómo evitar que el precio sea el único criterio

Los descuentos pueden acelerar una decisión, pero también pueden ocultar costos operativos. Antes de cambiar de proveedor, una empresa debería responder estas preguntas:

  1. ¿Qué tareas generan la mayor parte del gasto?
  2. ¿Qué nivel de error es aceptable en cada proceso?
  3. ¿Qué información debe permanecer bajo control de la organización?
  4. ¿Qué partes del sistema dependen de una interfaz específica?
  5. ¿Cuánto costaría validar una alternativa?
  6. ¿Qué ocurre si el proveedor aumenta precios o modifica sus condiciones?
  7. ¿En qué casos debe intervenir una persona?

Estas respuestas permiten distinguir una decisión técnica de una decisión de negocio. El proveedor más barato no siempre es el más conveniente, del mismo modo que el modelo más avanzado no necesariamente produce el mejor resultado económico.

El aprendizaje para líderes y equipos de negocio

La principal lección de la disputa entre OpenAI y Anthropic no es que una compañía haya ganado definitivamente. El propio documento señala que la competencia continúa y que el liderazgo puede cambiar con nuevas versiones, mejores precios o acuerdos comerciales distintos.

Para los líderes, el punto central es diseñar sistemas que puedan medirse y adaptarse. Antes de contratar o desarrollar una solución, conviene identificar el problema específico, definir cómo se evaluará el resultado y entender qué parte de la operación quedará expuesta a la decisión de un proveedor.

Cuando el desafío combina procesos propios, reglas internas, integraciones y necesidad de flexibilidad, Soluciones a medida UAMI puede ayudar a diseñar una implementación funcional sobre la operación real, medir su valor y definir el alcance antes de escalar. La decisión sobre los modelos debería quedar subordinada al problema de negocio, no al revés.

Como próximo paso, elegí un proceso concreto, reuní ejemplos reales y compará alternativas con una métrica común de costo y calidad. Esa prueba acotada permite tomar una decisión más informada y evitar comprometer toda la operación con una tecnología que todavía no fue validada en contexto.