Su demostración funciona, los primeros clientes firman y el uso despega. Entonces llega un correo electrónico: el modelo que hace funcionar su producto será sustituido, su tarifa cambia o determinados usos pasarán a regirse por otras condiciones. Para una start-up, ese mensaje puede convertir una semana comercial prometedora en un trabajo de emergencia. La dependencia de las plataformas de IA no es solo una cuestión de infraestructura: afecta al margen, a la promesa al cliente y a la libertad estratégica. Con la vista puesta en septiembre de 2026, los cambios ya observados permiten identificar los riesgos, sin pretender conocer las próximas decisiones de los proveedores.
Una dependencia más profunda que una simple API
El fenómeno no es nuevo. Los emprendedores conocen los cambios de algoritmo de las redes sociales, las comisiones de las tiendas de aplicaciones y las facturas de la nube. Pero la IA generativa añade una dificultad: el servicio contratado no tiene un comportamiento perfectamente estable. Dos modelos capaces de responder a la misma consulta pueden producir resultados muy distintos en un proceso de negocio.
Por tanto, cambiar de proveedor no consiste únicamente en modificar una dirección en el código. Hay que comprobar las respuestas, los rechazos, los formatos, las llamadas a herramientas y el rendimiento en los idiomas utilizados. Una instrucción cuidadosamente optimizada para un modelo puede funcionar de forma mediocre en otro. La verdadera dependencia suele residir en las pruebas que faltan y los ajustes acumulados.
Las señales ya son tangibles. Las sucesivas declaraciones de obsolescencia de versiones de API en OpenAI han incorporado la migración al día a día de los desarrolladores. La importante caída de sus servicios en noviembre de 2023 recordó el riesgo de concentración. La llegada de Claude 3 y, después, de GPT-4o en 2024 ilustró, por su parte, la velocidad de renovación. Estos acontecimientos no predicen ninguna retirada concreta en 2026; justifican prepararse para la siguiente.
La tarifa anunciada no es su coste real
Para un fundador, el precio por millón de tokens constituye una referencia cómoda, pero incompleta. Una funcionalidad puede requerir varias llamadas, un historial extenso, documentos, reintentos tras un error y un modelo adicional encargado de verificar la respuesta. A ello pueden sumarse la búsqueda documental, el almacenamiento y las intervenciones humanas.
Tomemos un asistente que prepara respuestas para un servicio de atención al cliente. Si una nueva versión exige más contexto o genera más respuestas que hay que corregir, su coste real puede aumentar pese a una tarifa unitaria inferior. Por el contrario, un modelo más caro puede resultar rentable si evita varios intentos. La unidad económica adecuada es la tarea completada con éxito, no el token consumido.
Desde los primeros contratos, el equipo debe hacer un seguimiento del coste por operación útil y por cliente, y después simular varios escenarios de tensión: subida de tarifas, desaparición de un descuento, uso más intensivo o cambio a un modelo de respaldo. Una suscripción «ilimitada» vendida antes de este análisis puede convertirse en un compromiso imposible de cumplir. Es preferible prever volúmenes incluidos, alertas y reglas claras para los excesos de consumo.
Preparar una salida sin crear una complejidad innecesaria
La portabilidad no significa mantener cinco proveedores de forma permanente. Una empresa joven debe, ante todo, ofrecer un producto útil. Sin embargo, algunas decisiones tempranas evitan convertir cada cambio en una reescritura completa.
Separar la lógica de negocio del proveedor
Las reglas de negocio, los permisos de acceso y los datos de los clientes no deberían quedar ocultos dentro de una integración propietaria. Una capa interna puede centralizar las llamadas, los tiempos de espera, los reintentos y la medición de costes. También debe hacer visibles las diferencias entre proveedores: una interfaz común no garantiza capacidades idénticas.
Las instrucciones, los esquemas de salida y las configuraciones deben mantenerse bajo control de versiones fuera de las consolas del proveedor. Cuando el producto utiliza búsqueda documental, conservar los documentos originales y sus metadatos facilita la reconstrucción del índice. Cambiar de modelo de embeddings puede obligar a recalcular las representaciones vectoriales: esta operación requiere tiempo y merece una partida presupuestaria.
Probar una alternativa real de respaldo
Una segunda clave API guardada en una caja fuerte no constituye un plan de continuidad. El modelo alternativo debe evaluarse en situaciones representativas: casos difíciles, francés imperfecto, documentos largos, intentos de manipulación y salidas estructuradas. Los datos de prueba deben estar anonimizados o utilizarse dentro de un marco autorizado.
- Calidad: ¿la respuesta sigue siendo aprovechable para la actividad?
- Fiabilidad: ¿se mantienen los formatos esperados y las salvaguardas?
- Operación: ¿los tiempos de respuesta, las cuotas y los costes siguen siendo aceptables?
- Cumplimiento normativo: ¿el tratamiento respeta los compromisos adquiridos con el cliente?
Esta evaluación debe desembocar en una decisión sencilla: ¿qué funciones pueden pasar al modelo alternativo, cuáles entran en modo degradado y cuáles deben detenerse? Para una operación sensible, es preferible suspender una respuesta antes que ofrecer silenciosamente un resultado menos seguro.
El contrato es un componente del producto
En sus inicios, muchas start-ups aceptan condiciones estándar con una tarjeta bancaria. Es rápido, pero ese marco no ofrece necesariamente las garantías que esperan sus propios clientes. Antes de prometer una alta disponibilidad o una ubicación estricta de los datos, hay que comprobar qué garantiza realmente el proveedor para la modalidad efectivamente contratada.
La negociación debe centrarse en los puntos que pueden interrumpir la actividad: preaviso de retirada de un modelo, notificación de cambios de tarifas, cuotas, asistencia y condiciones de suspensión. Un compromiso de disponibilidad puede prever abonos en lugar de una indemnización por pérdidas comerciales. Por tanto, hay que leer las exclusiones, los límites de responsabilidad y las vías de reclamación, no solo el porcentaje destacado.
En materia de datos, las preguntas son igual de concretas: ¿se utilizan las entradas y las salidas para el entrenamiento? ¿Durante cuánto tiempo se conservan? ¿Qué subencargados intervienen, en qué regiones y cómo se puede obtener su supresión? Una opción comercial de confidencialidad no sustituye el examen del contrato de tratamiento de datos. En un contexto europeo, los compromisos deben ser coherentes, en particular, con las obligaciones aplicables en virtud del RGPD.
Por último, el contrato con el cliente debe reflejar esta realidad. Puede regular el recurso a subencargados y su sustitución, precisar las funciones disponibles en modo degradado y establecer cómo se informará al cliente. Conviene no prometer una sustitución automática si modifica los lugares de tratamiento o las garantías acordadas.
Convertir la reversibilidad en un ejercicio periódico
El mejor indicador no es el número de proveedores integrados, sino el tiempo necesario para recuperar un servicio aceptable. Un ejercicio de cambio de proveedor en un ámbito limitado revela las dependencias ocultas: cuotas insuficientes, funcionalidades propietarias y costes inesperados. También puede estudiarse el alojamiento de un modelo de pesos abiertos, sin presentarlo como una independencia gratuita: la capacidad de cómputo, el mantenimiento y los conocimientos técnicos siguen necesitando financiación.
¿Y ahora qué? Si el mercado mantiene su rápida renovación, las start-ups capaces de comparar y cambiar sus componentes deberían absorber mejor las disrupciones. El objetivo no es abandonar al proveedor preferido, sino poder quedarse por elección. Desde los primeros clientes, una base de pruebas, un plan de respaldo y unos compromisos contractuales realistas constituyen un seguro estratégico mucho más creíble que una promesa de migración «en pocos días».