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:
| Dimensión (octubre 2026) | Qué preguntar | Qué prueba pedir | Señal de alarma |
|---|---|---|---|
| Propiedad | ¿De quién son el código, los prompts, la configuración y los datos generados? ¿Puedo modificarlos y dárselos a otro proveedor? | Cláusula de cesión de derechos y licencia de uso de componentes previos del proveedor; copia del repositorio en tu organización | “El código es tuyo” pero el sistema solo funciona sobre una plataforma del proveedor que no se entrega |
| Acceso | ¿A nombre de quién están la cuenta del modelo (Anthropic, OpenAI, Azure), el repositorio, el hosting, el dominio y la facturación? | Que te enseñe la consola de cada servicio con tu empresa como titular y tu tarjeta como medio de pago | La API key vive en la cuenta del proveedor y te refactura el consumo |
| Autonomía operativa | ¿Podría otra persona, sin hablar con el autor, arrancarlo, diagnosticar un fallo y restaurarlo? | Documento de operación + restauración ensayada + prueba de salida con un tercero | “Si pasa algo, me llamas” es todo el plan de continuidad |
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.
| Medida (octubre 2026) | Qué riesgo reduce | Esfuerzo orientativo | Cuándo pedirla |
|---|---|---|---|
| Cuentas del modelo, repositorio y hosting a nombre del cliente | Corte del servicio si el proveedor desaparece o deja de pagar | Unas horas de alta al arrancar | En la propuesta, antes del primer día |
| Capa de modelo separada de la capa de integración | Cambio de precio o retirada de un modelo | Decisión de diseño, sin coste extra si se toma al principio | En la reunión técnica de arranque |
| Conjunto de pruebas con 30-50 casos reales | Cambiar de modelo a ciegas | 1-2 días de trabajo conjunto con quien conoce el proceso | Durante la construcción |
| Documento de operación para un tercero | Que solo el autor sepa arrancarlo | 1 día al cierre del proyecto | Como entregable con nombre en el contrato |
| Restauración ensayada | Copias que nadie ha probado | Medio día | Antes de la aceptación final |
| Prueba de salida con otra persona | Dependencia que no se ve hasta que falla | 2-4 horas de esa persona | Como criterio de cierre del proyecto |
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:
| Dónde vive la API key (octubre 2026) | Quién paga el consumo | Qué pasa si el proveedor desaparece | Mi valoración |
|---|---|---|---|
| Cuenta del proveedor que te refactura | El proveedor, y te lo repercute | El sistema deja de funcionar cuando la cuenta se cierra o se impaga | Solo aceptable en una prueba de concepto corta y pactada |
| Cuenta de tu empresa, el proveedor tiene acceso como miembro | Tu empresa, directamente al fabricante | Le retiras el acceso y el sistema sigue igual | La opción por defecto |
| Plataforma SaaS de terceros que incluye el modelo | Tu empresa, a la plataforma | Depende de las condiciones de exportación de esa plataforma | Válida si la salida está probada |
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.
| Pieza | Titular recomendado | Quién más accede | Cómo lo compruebas |
|---|---|---|---|
| Cuenta de API de Anthropic (Claude) | Tu empresa, con tu tarjeta | El proveedor como miembro de la organización | Consola de Anthropic: razón social y método de pago |
| Cuenta de API de OpenAI o Azure OpenAI | Tu empresa (en Azure, dentro de tu suscripción) | El proveedor con un rol limitado | Facturas a tu nombre; en Azure, el recurso cuelga de tu suscripción |
| Cuenta de Google (Gemini) | Tu empresa, en tu proyecto de Google Cloud | El proveedor con un rol limitado | Proyecto y facturación de Google Cloud a tu nombre |
| Licencias de Copilot o ChatGPT Enterprise | Tu tenant de Microsoft 365 o tu espacio de trabajo | Administradores que tú designes | Panel de administración con tus administradores |
| Repositorio de código | Organización de tu empresa en GitHub o GitLab | El proveedor como colaborador | Ves el historial completo sin pedir permiso |
| Servidor o hosting | Cuenta del proveedor cloud a tu nombre | El proveedor con usuario propio, revocable | Facturas emitidas a tu empresa |
| Dominio y DNS | Tu registrador habitual | Nadie más, o el proveedor con acceso temporal | Whois y panel del registrador |
| Claves y contraseñas | Gestor de secretos de tu empresa | Acceso compartido y registrado | Ninguna clave vive solo en el portátil del proveedor |
| Copias de seguridad | Almacenamiento a tu nombre, en la UE si tratas datos personales | Proceso automático + tu responsable técnico | Fecha de la última restauración ensayada |
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.
| Opción (oct 2026) | Quién guarda los datos | ¿Puedes cambiar de modelo? | Coste de salida | Dónde se alojan los datos |
|---|---|---|---|---|
| Microsoft Copilot (antes Microsoft 365 Copilot) | Microsoft, dentro de tu tenant de Microsoft 365 y con sus mismos compromisos contractuales | Elige Microsoft; el administrador puede habilitar modelos de OpenAI y de Anthropic como subencargados | Medio-alto si los procesos solo existen dentro de Microsoft 365; tus documentos siguen en SharePoint y OneDrive | Para clientes de la UE es un servicio del EU Data Boundary, salvo los modelos de Anthropic, que hoy están excluidos |
| ChatGPT Enterprise | OpenAI, en el espacio de trabajo de tu empresa | Modelos de OpenAI | Comprueba qué exporta el administrador (conversaciones, GPTs personalizados, configuración) y en qué formato | Pregunta por escrito qué opciones de residencia de datos en Europa aplican a tu plan |
| Plataforma propia multimodelo | Tu empresa, en una cuenta cloud o un servidor a tu nombre | Sí: cualquier modelo con API (Claude, GPT, Gemini, modelos abiertos) | Bajo si las cuentas y el código son tuyos; alto si la plataforma es del proveedor | Donde decidas: región de la UE, tu propio servidor o un modelo local para lo más sensible |
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#
| Opción (oct 2026) | UE | EE. UU. | On-premise |
|---|---|---|---|
| Microsoft Copilot | Sí para clientes de la UE (EU Data Boundary), con la excepción de los modelos de Anthropic | Posible para modelos excluidos del EU Data Boundary y para clientes fuera de la UE | No |
| ChatGPT Enterprise | Comprobar con OpenAI qué ofrece para tu plan | Comprobar con OpenAI | No |
| Plataforma propia multimodelo | Sí, si eliges región europea en tu cuenta cloud y modelos con procesamiento en la UE | Depende del modelo que llames: compruébalo modelo a modelo | Sí, con modelos abiertos en un servidor propio |
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:
| Tipo de dependencia (octubre 2026) | Ejemplo | Riesgo real | Cómo se mitiga |
|---|---|---|---|
| Tecnológica: un único modelo | Todo el sistema depende de un modelo concreto de un fabricante | Subida de precio, retirada del modelo, cambio de condiciones | Capa de modelo separada + conjunto de pruebas + cuenta propia con al menos dos fabricantes |
| Tecnológica: plataforma SaaS cerrada | Copilot dentro de Microsoft 365, un chatbot de un SaaS vertical, un constructor de agentes de pago | No poder exportar flujos, historial o configuración; precio por usuario que crece con la plantilla | Comprobar qué se puede exportar y en qué formato antes de construir encima; mantener tus datos fuera de la plataforma |
| Humana: proveedor unipersonal | Un consultor que lo diseñó, lo construyó y es el único que lo entiende | Vacaciones, enfermedad, cambio de actividad, desacuerdo comercial | Cuentas a nombre del cliente, documentación de operación, restauración ensayada, prueba de salida, soporte con tiempos escritos |
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:
- 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.
- 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.
- Restauración ensayada: no “hay copias”, sino “hemos borrado el entorno de pruebas y lo hemos levantado desde la copia, y tardó tanto”.
- Prueba de salida antes de cerrar el proyecto (la explico abajo).
- 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:
- 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.
- Dale solo lo entregado: acceso al repositorio, a las cuentas y al documento de operación. Nada de llamadas al autor.
- 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.
- 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)#
| # | Comprobación | Cómo la verificas |
|---|---|---|
| 1 | Repositorio de código en la organización de tu empresa | Lo ves en tu cuenta de GitHub/GitLab, con historial |
| 2 | Cuenta del modelo (Anthropic, OpenAI, Azure, Google) a nombre de tu empresa | Consola con tu razón social y tu medio de pago |
| 3 | Hosting, dominio y base de datos a tu nombre | Facturas emitidas a tu empresa |
| 4 | Ninguna clave o contraseña solo en el portátil del proveedor | Gestor de secretos o bóveda compartida con tu empresa como titular |
| 5 | Exportación de datos en formato abierto | Una exportación real (CSV, JSON) hecha durante el proyecto |
| 6 | Restauración ensayada | Acta con fecha y tiempo que tardó |
| 7 | Documento de operación para un tercero | Lo lee alguien que no es el autor y entiende qué hacer |
| 8 | Plan para cambiar de modelo | Respuesta escrita: qué se toca, cuánto cuesta, qué pruebas se usan |
| 9 | Conjunto de pruebas con casos reales | Lo puedes ejecutar tú y ver el resultado |
| 10 | Componentes del proveedor que no se ceden | Lista explícita y licencia de uso indefinida para tu empresa |
| 11 | Coste de salida | Qué pagarías y cuánto tardarías en pasar el sistema a otro proveedor |
| 12 | Soporte acordado frente a no contratado | Por escrito: qué cubre, qué no, horario |
| 13 | Tiempo de respuesta real ante una caída | Cifra concreta (horas) y canal; si no se contrata, que conste |
| 14 | Prueba de salida como criterio de cierre | Fecha, persona que la hace y tarea a completar |
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.
| Error común (oct 2026) | Por qué sale caro | Qué hacer en su lugar |
|---|---|---|
| Darlo por resuelto porque el contrato dice “el código es tuyo” | Puedes ser dueño de un repositorio que nadie de tu lado sabe desplegar | Pedir también acceso y autonomía: cuentas a tu nombre y prueba de salida |
| Aceptar que el proveedor refacture el consumo de la API | Si su cuenta se cierra o se impaga, tu sistema se para con ella | Cuenta del modelo a nombre de tu empresa desde el primer día |
| Confiar en “hay copias de seguridad” | Una copia que nunca se ha restaurado no sabes si sirve | Pedir el acta de una restauración ensayada, con fecha y duración |
| Construir todo sobre un único modelo sin pruebas | Cada cambio de precio o de versión obliga a rehacer y probar a ojo | Separar la capa de modelo y mantener un conjunto de 30-50 casos reales |
| Confundir soporte con “si pasa algo, me llamas” | No hay tiempos de respuesta exigibles cuando de verdad falla | Soporte con alcance y horas por escrito, o constancia de que no está contratado |
| Pedir independencia y, a la vez, que el equipo no dedique ni una hora | Nadie dentro sabe dónde está nada y la documentación no se lee hasta el día del fallo | Una persona interna que reciba la entrega y haga o supervise la prueba de salida |
| Reconstruir el ERP o el CRM “para no depender de nadie” | Creas una dependencia nueva con quien mantiene ese software casero | Mantener los sistemas establecidos y construir encima una capa pequeña y documentada |
| Elegir proveedor solo por su tamaño | Una consultora grande también rota personas y puede no documentar | Evaluar los mecanismos de continuidad, no el número de empleados |
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:
- 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.
- 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.
- 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.
- Prueba de salida: criterio de aceptación final del proyecto, con la tarea y la persona definidas.
- 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.