Dependencia de un proveedor de IA: cómo evaluar el lock-in con Claude, OpenAI o Copilot (2026)

Dependencia de un proveedor de IA: cómo evaluar el lock-in con Claude, OpenAI o Copilot (2026)

La dependencia de un proveedor de IA se evalúa con 3 comprobaciones separadas y una prueba práctica (octubre de 2026): propiedad (el código y los datos son de tu empresa), acceso (cuentas de Claude, OpenAI o Azure, repositorios, API keys y facturación a vuestro nombre) y autonomía operativa (otra persona puede operarlo y recuperarlo mañana con lo entregado). La prueba es que alguien distinto complete una tarea real usando solo esa documentación. Antes de firmar, repasa las 14 comprobaciones de la checklist de este post; que el contrato diga "el código es tuyo" no basta.

Te pongo un ejemplo ficticio, pero muy parecido a lo que oigo en reuniones. Una distribuidora de 25 personas tiene un asistente que lee pedidos y los mete en el ERP. Funciona bien. Un lunes deja de responder. El consultor que lo montó está de vacaciones. La empresa descubre entonces que la cuenta de OpenAI está a nombre del consultor, que el servidor lo paga él y que nadie dentro sabe dónde está el código. El contrato decía, con letra clara, que todo era propiedad del cliente. Era verdad, y no les servía de nada ese lunes.

Este post es la versión a fondo de una de las preguntas de las 12 preguntas antes de contratar una implantación de IA: qué ocurre si el proveedor no está disponible. Aquí la desmonto en piezas que puedes comprobar antes de firmar.

¿Qué significa depender de un proveedor de IA? Propiedad, acceso y autonomía (octubre 2026)#

En las conversaciones comerciales de este año, las empresas me han planteado la dependencia de formas muy distintas: pedir que todo esté en repositorios suyos, preguntar qué grado de autonomía les queda, preocuparse por pasar 72 horas sin acceso al sistema, o temer quedarse atadas a una nube concreta. Parecen preocupaciones diferentes. Son el mismo problema visto desde tres ángulos, y cada uno se comprueba de una manera:

La propiedad es lo que más se negocia y lo que menos protege por sí sola: puedes ser dueño de un repositorio que no sabes desplegar. El acceso se descuida porque al principio es cómodo que el proveedor lo gestione todo. Y la autonomía es lo único que responde a la pregunta "¿podemos seguir trabajando si esta persona desaparece?".

¿Cuál es la mejor forma de evitar el lock-in con un proveedor de IA en España en 2026?#

La mejor forma de evitar el lock-in es exigir, desde la propuesta, que todas las cuentas (modelo, repositorio, hosting y dominio) estén a nombre de tu empresa y que el proyecto se cierre con una prueba de salida hecha por un tercero; en una implantación de 5.000-20.000 € para una pyme española (octubre de 2026) eso se pide por escrito antes de firmar, no se negocia después. El resto de medidas suman, pero ninguna compensa que la cuenta del modelo sea de otro.

Los esfuerzos son mi estimación para un proyecto de pyme, no una tarifa: sirven para que veas que ninguna de estas medidas encarece mucho un proyecto si se pide al principio.

¿A nombre de quién debe estar la API key de Claude u OpenAI?#

A nombre de tu empresa. Es la comprobación más barata y la que más cambia el riesgo.

Un proyecto de IA a medida suele llamar a un modelo (Claude, GPT, Gemini) a través de una API. Esa llamada usa una clave asociada a una cuenta, y quien controla la cuenta controla el servicio: puede revocarla, cambiar el plan, ver el consumo y, si deja de pagar, cortarlo. Hay tres configuraciones habituales:

Sobre la propiedad de lo que genera el modelo, conviene leer los términos del fabricante que vayas a usar. Por ejemplo, los Commercial Terms de Anthropic (versión vigente desde el 17 de junio de 2025, consultada el 8 de octubre de 2026) dicen que el cliente conserva los derechos sobre sus entradas, que es propietario de las salidas y que Anthropic no puede entrenar modelos con el contenido del cliente de esos servicios. Esos términos se aplican a quien firma la cuenta. Si la cuenta es de tu consultor, el cliente contractual de Anthropic es él, no tú. Con OpenAI, Microsoft o Google haz la misma comprobación en sus condiciones de empresa antes de firmar, y fíjate en el plan concreto: las condiciones de un plan de consumidor y las de un plan de empresa no son iguales.

Configuración recomendada: dónde vive cada API key y cada cuenta (octubre 2026)#

Esta es la configuración que dejo en todos los proyectos y la que te recomiendo pedir a cualquier proveedor. La regla es sencilla: titular, tu empresa; invitado, el proveedor.

Si alguna fila no está a tu nombre, no tiene por qué ser grave hoy. Apúntala y pon fecha para cambiarla.

Tienes el detalle de qué hace cada herramienta con tus datos en a dónde van tus datos en ChatGPT, Claude, Copilot y otros.

¿Qué pasa si mañana quiero cambiar de Claude a GPT o a Gemini?#

Esta es la otra cara del lock-in, la tecnológica. Los modelos cambian de precio, de calidad y de condiciones cada pocos meses. Un sistema construido para un único modelo, con las instrucciones y el formato de respuesta pegados a él, convierte cada cambio en un proyecto.

La pregunta útil para el proveedor es: "si mañana quiero pasar este proceso de Claude a GPT, ¿qué hay que tocar y cuánto cuesta?". Una buena respuesta separa dos capas:

• Capa de integración: conexiones al ERP, al CRM, al correo, al Drive; permisos; registro de lo que pasa. Esta capa no debería cambiar al cambiar de modelo.
• Capa de modelo: qué modelo se llama, con qué instrucciones y con qué pruebas se valida el resultado. Esta sí cambia, y lo que la hace barata es tener un conjunto de pruebas con casos reales para comparar el modelo nuevo contra el antiguo antes de cambiar.

Si el proveedor no tiene ese conjunto de pruebas, cambiar de modelo será probar a ojo en producción. Si lo tiene, es una tarde de trabajo y una decisión con datos. Hay opciones intermedias, como pasarelas que dan acceso a muchos modelos con una sola clave (OpenRouter, por ejemplo), que reducen la fricción técnica pero añaden un intermediario más cuyas condiciones también hay que leer. Expliqué por qué no conviene casarse con un único fabricante en IA multimodelo en la empresa, y cómo repartir tareas entre modelos para controlar la factura en controlar el coste de un chat de IA multimodelo.

Copilot vs ChatGPT Enterprise vs plataforma propia multimodelo: ¿cuál te ata más? (2026)#

Son las tres opciones que más veo encima de la mesa en pymes que ya usan IA. Ninguna es "sin dependencia": cambia de quién dependes y cuánto cuesta salir. En la tabla solo pongo como hecho lo que he verificado en la documentación oficial el 8 de octubre de 2026; lo demás está planteado como lo que tienes que comprobar.

La fuente de las filas de Copilot es la página de Microsoft Data, Privacy, and Security for Microsoft Copilot (revisión del 9 de julio de 2026, consultada el 8 de octubre de 2026). Dice también que las peticiones, las respuestas y los datos de Microsoft Graph no se usan para entrenar los modelos base, y que Microsoft no reclama la propiedad de lo que genera el servicio. Las páginas de OpenAI sobre privacidad de empresa y residencia de datos no se dejaron consultar desde mi entorno ese día (error 403), así que no afirmo sus condiciones: pídelas en la propuesta y guárdalas con fecha.

Mi lectura para una pyme de 10-50 personas: si toda la empresa vive en Microsoft 365 y el uso es redactar, resumir y buscar en vuestros documentos, Copilot ata menos de lo que parece, porque los datos ya estaban ahí. Si lo que quieres es automatizar procesos que tocan el ERP o el CRM y elegir el modelo de cada tarea, una plataforma propia con las cuentas a tu nombre es la que deja la salida más barata. Lo comparo con más detalle, incluidos precios, en ChatGPT Enterprise, Copilot o una plataforma propia y en alternativas a ChatGPT Enterprise sin OpenAI ni Microsoft.

Dónde se alojan los datos en cada opción#

Si tratáis datos personales, este cuadro condiciona qué opción es viable antes que el precio. Tienes el detalle en IA privada para empresas con datos en Europa.

Qué dicen los usuarios#

He intentado consultar las reseñas públicas de Microsoft Copilot y de ChatGPT Enterprise en G2, Capterra y TrustRadius el 8 de octubre de 2026 y ninguna de las tres páginas se dejó leer desde mi entorno, así que no voy a resumir valoraciones que no he podido verificar. Si las consultas tú, filtra por empresas de 11-50 empleados y busca dos palabras: "export" y "admin". Son las que dicen si alguien pudo llevarse su trabajo al cambiar de herramienta.

Lo que sí puedo contar es lo que me preguntan las propias empresas en las reuniones de este año: casi nunca empiezan por el modelo; empiezan por si el sistema se puede parar y por si de verdad es suyo. Es la misma preocupación de este post, vista desde el lado del comprador.

Dos niveles de lock-in: el proveedor tecnológico y el proveedor humano#

Cuando una pyme pregunta por dependencia, suele mezclar dos riesgos que se mitigan de forma distinta:

Sobre Copilot conviene matizar: Microsoft no va a desaparecer un lunes, pero si construyes procesos que solo existen dentro de su ecosistema, cambiar más adelante significa reconstruirlos. Puede ser razonable si toda la empresa vive en Microsoft 365, siempre que se decida sabiendo el coste de salida. Tienes la comparación en ChatGPT Enterprise, Copilot o una plataforma propia.

¿Es arriesgado contratar IA a un consultor que trabaja solo?#

Sí, tiene un riesgo específico, y prefiero decirlo yo antes que dejar que lo descubras. Trabajo solo. Si mañana me pasa algo, no hay un compañero de guardia que conozca tu sistema. Una consultora grande tiene más personas; también tiene más rotación, y el que te vendió el proyecto rara vez es el que lo construye.

Lo que no vale es resolver ese riesgo con confianza personal ("tranquilo, yo siempre contesto"). La continuidad tiene que funcionar aunque yo no conteste. Los mecanismos que la sostienen son verificables:

1. Todo a nombre del cliente desde el primer día: repositorio en tu organización de GitHub o GitLab, cuentas del modelo, hosting y dominio con tu empresa como titular. Yo entro como invitado y me puedes sacar.
2. Documento de operación escrito para alguien que no soy yo: cómo se arranca, dónde están los registros, qué hacer ante los tres fallos más probables, cómo se cambia una clave.
3. Restauración ensayada: no "hay copias", sino "hemos borrado el entorno de pruebas y lo hemos levantado desde la copia, y tardó tanto".
4. Prueba de salida antes de cerrar el proyecto (la explico abajo).
5. Soporte escrito o explícitamente no contratado. Si hay soporte, con tiempos de respuesta por escrito. Si no lo hay, que la propuesta diga que no lo hay.

Un proveedor individual que cumple esos cinco puntos te deja menos expuesto que una empresa grande que no los cumple. Y al revés: el tamaño del proveedor no sustituye a ninguno de ellos.

La prueba de salida paso a paso: alguien distinto completa una tarea con lo entregado#

Es la comprobación que más recomiendo y la que casi nadie pide. Consiste en esto:

1. Elige a una persona que no haya construido el sistema. Puede ser alguien técnico de tu equipo, un freelance al que pagas unas horas o el proveedor de informática que ya tenéis.
2. Dale solo lo entregado: acceso al repositorio, a las cuentas y al documento de operación. Nada de llamadas al autor.
3. Pídele una tarea concreta y realista. Por ejemplo: cambiar la API key por una nueva, desplegar el sistema en un entorno limpio, restaurar la copia de ayer o cambiar el modelo de un paso y comprobar que las pruebas siguen pasando.
4. Anota dónde se atasca. Cada atasco es un hueco de documentación o un acceso que falta.

Si esa persona necesita llamar al autor en cada paso, todavía hay dependencia, diga lo que diga el contrato. Si completa la tarea, la autonomía está demostrada y no solo prometida. Conviene pactarla en la propuesta como criterio de cierre del proyecto, con fecha y con quién la hace.

Mejores prácticas antes de firmar: 14 comprobaciones con un proveedor de IA (octubre 2026)#

No hace falta que todas salgan perfectas para firmar. Hace falta que sepas cuáles no salen y lo aceptes con conocimiento.

Errores comunes al evaluar la dependencia de un proveedor de IA#

Estos son los fallos que más veo al revisar propuestas y contratos de implantación de IA en 2026. Casi todos se corrigen con una frase en la propuesta si se detectan antes de firmar.

Quiero autonomía, pero no quiero programar: ¿es contradictorio?#

No, y es una de las confusiones más frecuentes. Muchas empresas quieren que el sistema sea suyo y poder cambiar de proveedor, pero no quieren montar un equipo técnico ni aprender a programar. Es una postura perfectamente coherente, porque son dos cosas distintas:

• Independencia contractual y operativa: las cuentas son tuyas, la documentación existe y cualquier profesional competente puede hacerse cargo. Esto lo puede tener cualquier cliente de un proyecto llave en mano, sin escribir una línea de código.
• Capacitación: que tu equipo sepa modificar y ampliar el sistema. Esto exige tiempo, práctica y una modalidad de trabajo distinta (construcción conjunta o tutoría).

Un buen proveedor no te promete la misma transferencia a todos. Si contratas llave en mano, lo justo es exigir independencia operativa, no que tu equipo salga sabiendo ampliarlo. Si quieres lo segundo, se contrata otra cosa y se presupuesta distinto. Lo detallo en llave en mano, construcción conjunta o tutoría.

¿Soberanía significa desarrollarlo todo a medida?#

Tampoco. Algunos directores me dicen que huyen de las soluciones totalmente a medida, y tienen razón: cada pieza propia es algo más que mantener. Reconstruir el ERP o el CRM para "no depender de nadie" crea más dependencia, no menos, porque ahora dependes de quien escribió ese ERP casero.

El planteamiento que funciona es otro: mantener los sistemas establecidos (vuestro ERP, vuestro CRM, Microsoft 365 o Google Workspace) y construir encima una capa de valor específica, pequeña y bien documentada, que conecta esas piezas con los modelos de IA. Esa capa es lo único realmente a medida, y es lo que debe estar en tu repositorio con tu documentación. Si un día cambias de modelo, cambias esa capa; si cambias de ERP, cambias un conector. La soberanía consiste en controlar las piezas críticas, no en fabricarlas todas.

Como director de una pyme de 10-50 personas, ¿qué tengo que exigir por contrato?#

Si solo vas a negociar cinco cláusulas, que sean estas:

1. Titularidad de cuentas: todas las cuentas de servicios necesarias para operar el sistema (modelo, hosting, repositorio, dominio) se crean a nombre del cliente; el proveedor accede como usuario invitado.
2. Cesión y licencia: cesión del código desarrollado para el proyecto y licencia perpetua, sin coste adicional, de cualquier componente previo del proveedor que el sistema necesite para funcionar.
3. Entregables de continuidad: documento de operación, procedimiento de restauración ensayado y conjunto de pruebas, como entregables con nombre en el contrato, no como "documentación técnica" genérica.
4. Prueba de salida: criterio de aceptación final del proyecto, con la tarea y la persona definidas.
5. Soporte: alcance, horario y tiempo de respuesta por escrito, o declaración expresa de que no está contratado. Y qué pasa con los accesos del proveedor al terminar la relación.

Esto no es asesoramiento jurídico; tu abogado adaptará la redacción. Pero si una propuesta no puede asumir estos cinco puntos, ya sabes cuánta dependencia estás comprando.

¿Para quién NO es este nivel de exigencia?#

• Si vas a probar una herramienta durante dos semanas para ver si sirve, basta con no meter datos sensibles y no construir procesos encima.
• Si el uso es individual (una persona con su licencia de Claude o ChatGPT para redactar), el lock-in relevante es el de la licencia, no el de un proveedor de implantación.
• Si tu empresa ha decidido conscientemente vivir dentro de un ecosistema (todo Microsoft, por ejemplo) y asume el coste de salida, no necesitas multimodelo: necesitas que tus datos sigan siendo exportables.

¿Quién hace esto en España?#

Soy Javier Santos Criado, consultor IA en Javadex, y monto sistemas de IA para pymes con la continuidad como requisito de entrega, no como promesa. Todo se crea a nombre de tu empresa desde el primer día, el proyecto se cierra con la prueba de salida y el soporte, si lo hay, está escrito con tiempos concretos.

Cuando el objetivo es un ChatGPT corporativo propio, lo monto sobre Cortex, la plataforma de IA privada: multimodelo (Claude, GPT, Gemini y otros, eligiendo el adecuado para cada tarea), conectada a vuestras herramientas, con tu marca, datos en Europa y sin lock-in, porque las cuentas y la configuración son de tu empresa. Desde 5.000 € y funcionando en un mes. Si quieres ver cómo trabajo un proyecto de principio a fin, lo cuento en cómo trabajo yo.

→ Cuéntame qué sistema quieres montar y cómo lo usáis hoy. Respondo por email en menos de 24 horas con una primera valoración y con lo que quedaría a nombre de tu empresa.

Preguntas frecuentes#

¿Cómo evaluar la dependencia de un proveedor de IA?#

Comprobando tres cosas por separado: propiedad (el código, la configuración y los datos son tuyos y puedes llevártelos), acceso (cuentas del modelo, repositorio, hosting, API keys y facturación a nombre de tu empresa) y autonomía operativa (otra persona puede operar y restaurar el sistema con lo entregado). La prueba definitiva es que alguien distinto complete una tarea real usando solo la documentación.

¿Cómo evaluar el lock-in de un proveedor de IA en 2026?#

En octubre de 2026 la forma práctica es una checklist de 14 comprobaciones antes de firmar (cuentas a tu nombre, exportación, restauración ensayada, documento de operación, plan para cambiar de modelo, coste de salida y soporte escrito) y una prueba de salida como criterio de cierre del proyecto.

¿A nombre de quién debe estar la API key de Claude u OpenAI?#

A nombre de tu empresa, con tu medio de pago. El proveedor puede tener acceso como miembro invitado. Si la cuenta es suya, el cliente contractual del fabricante es él y el sistema deja de funcionar si la cuenta se cierra o se impaga.

¿Puedo cambiar de Claude a GPT sin rehacer el proyecto?#

Sí, si el sistema separa la capa de integración (conexiones, permisos, registros) de la capa de modelo y existe un conjunto de pruebas con casos reales para comparar el modelo nuevo con el antiguo. Sin esas pruebas, cambiar de modelo es probar a ojo en producción.

¿Copilot genera dependencia de Microsoft?#

Depende del uso. Si los procesos solo existen dentro de Microsoft 365, salir cuesta reconstruirlos, pero tus documentos siguen en SharePoint y OneDrive. Según la documentación de Microsoft consultada el 8 de octubre de 2026, para clientes de la UE Copilot es un servicio del EU Data Boundary, con los modelos de Anthropic hoy excluidos, y Microsoft no reclama la propiedad de lo que genera.

¿Es arriesgado contratar IA a un consultor que trabaja solo?#

Tiene un riesgo específico: si esa persona no está, nadie más conoce el sistema. Se mitiga con cuentas a nombre del cliente, documento de operación, restauración ensayada, prueba de salida y soporte con tiempos por escrito. Esos mecanismos protegen más que el tamaño del proveedor.

¿Soberanía en IA significa desarrollarlo todo a medida?#

No. Lo razonable es mantener el ERP, el CRM y las herramientas que ya funcionan y construir encima una capa específica, pequeña y documentada que las conecta con los modelos de IA. Rehacer sistemas establecidos para no depender de nadie crea una dependencia nueva.