Una puerta que abre hacia el mismo proveedor
Imaginemos una oficina pública que utiliza un sistema de inteligencia artificial para ordenar solicitudes de un beneficio. El contrato permite terminar el servicio y el panel incluye una opción para detenerlo. En el papel, la institución conserva dos poderes: puede apagar el sistema y puede poner fin al contrato. Pero sus funcionarios ya han adaptado el procedimiento a las categorías del proveedor; los expedientes se guardan en formatos que el sistema entiende mejor que cualquier alternativa; la experiencia de uso se ha acumulado alrededor de esa plataforma, y la oficina redujo el personal capaz de realizar manualmente la tarea. El día que decide marcharse, el servicio que debe proteger a los solicitantes también puede quedar interrumpido.
El ejemplo es hipotético. Su mecanismo aparece en un problema documentado de la contratación pública de inteligencia artificial: el bloqueo tecnológico del proveedor. La OCDE advierte que las administraciones pueden quedar muy dependientes de tecnologías propietarias y formatos de datos del contratista; también describe sistemas ya incorporados en la administración que pueden carecer de capacidad propia para mantenerlos o supervisarlos de manera independiente. Lo decisivo es que la institución pueda detener el sistema sin abandonar, junto con él, la función pública que había delegado.[1]
Conviene distinguir tres capacidades que el lenguaje contractual suele comprimir en una sola. Detener es interrumpir una operación. Salir es poner término a una relación con el proveedor y recuperar los medios necesarios para no depender de ella. Continuar es mantener la función —con otro proveedor, otro sistema o un procedimiento distinto— durante y después de esa salida. Un organismo puede tener la primera capacidad y carecer de las otras dos. Puede tener derecho jurídico a terminar el contrato y descubrir que hacerlo equivale, en la práctica, a dejar de prestar el servicio.
La diferencia importa porque una autorización formal y una capacidad efectiva no son lo mismo. En el análisis de la autoridad dentro de las organizaciones, una persona puede tener la facultad escrita para decidir y, sin embargo, no controlar las condiciones que hacen viable su decisión. En la contratación de IA, la cláusula de terminación pertenece al primer plano. Los datos que pueden recuperarse, la documentación disponible, el conocimiento retenido por el organismo y la existencia de una ruta de transición pertenecen al segundo.[4] Sin estos elementos, la libertad contractual corre el riesgo de parecerse a una salida de emergencia que termina en la misma sala.
Cómo se construye el costo de marcharse
La dependencia no suele aparecer completa el día de la firma. Se forma mientras el sistema se convierte en parte de la organización. Los equipos conectan bases de datos, trasladan tareas a una interfaz, capacitan a los funcionarios en un flujo específico y ajustan sus criterios de trabajo a las opciones que el producto ofrece. Cada adaptación puede ser razonable por separado. Juntas hacen que abandonar el sistema exija recuperar información, reconstruir procedimientos, transferir conocimientos y mantener la atención de los casos abiertos. Lo que al principio fue una compra se vuelve una infraestructura de trabajo.
La dependencia puede ser técnica, pero también organizativa. Un archivo exportable sirve de poco si nadie conserva la documentación que explica sus campos. Un manual no permite migrar un servicio si los equipos que conocen sus integraciones ya no están. La formación de funcionarios tampoco resuelve el problema si su competencia solo alcanza para operar una plataforma y no para detectar cambios relevantes, revisar resultados o activar otro procedimiento. El proveedor puede conocer detalles que no constan en el expediente; la institución puede retener las obligaciones públicas sin retener las capacidades para cumplirlas.
Por eso el costo de salida no se mide únicamente en la tarifa de terminación, los cargos por descargar datos o las horas necesarias para instalar otro software. Incluye la pérdida de inversiones internas y el riesgo de que la función se deteriore mientras se transfiere. Si los usuarios de un sistema público no pueden esperar a que se complete una migración, una administración puede permanecer con un proveedor incluso cuando detecta fallos que justificarían el cambio. La amenaza de salida deja entonces de ordenar la relación: el contratista sabe, o puede prever, que la opción escrita resulta demasiado costosa de ejercer.
Una cláusula conserva valor cuando modifica las opciones reales de ambas partes. Si el organismo puede trasladar los datos, reconstruir el proceso y sostener la atención durante una transición, el proveedor tiene razones para competir por la continuidad del contrato. No es necesario que la institución cambie efectivamente de empresa. El valor disciplinario de una alternativa consiste en que pueda ser utilizada si la relación deja de servir al interés público. Cuando se vuelve impracticable, todavía se puede invocar en una negociación, pero ya no funciona como una alternativa creíble.
La dependencia varía según la tarea, la arquitectura, los datos, la duración del contrato y la capacidad de la administración. El diseño institucional debe identificar qué conocimientos y medios públicos son necesarios para que una decisión futura de detener, sustituir o rediseñar el sistema siga siendo practicable. La interoperabilidad ayuda cuando permite esa transición; su alcance depende de que los datos, el proceso y el servicio puedan transferirse de manera útil.
El cambio de proveedor también es una capacidad pública
La OCDE sitúa el bloqueo del proveedor entre los desafíos de implementar IA mediante compras públicas.[1] Esa dependencia señala cuándo debe actuar la administración: antes de adjudicar, todavía puede comparar formatos, exigir documentación, discutir asistencia de transición y valorar cuánta pericia debe mantener. Una vez que el servicio se integra en procedimientos cotidianos, los costos de corregir una omisión aumentan y la negociación se produce desde una posición distinta.
El debate jurídico europeo ofrece una comparación acotada. El capítulo VI de la Ley de Datos de la Unión Europea establece obligaciones para facilitar el cambio entre proveedores de servicios de tratamiento de datos, incluidos servicios cloud y edge. La Comisión Europea explica que esos requisitos contemplan la exportación de datos en formatos comúnmente utilizados y legibles por máquinas, interfaces abiertas para ciertos servicios y medidas para reducir obstáculos al cambio. La regulación comenzó a aplicarse el 12 de septiembre de 2025; la eliminación completa de cargos por cambio está prevista desde el 12 de enero de 2027.[2][3] Estas reglas alcanzan a los servicios de tratamiento de datos incluidos en su ámbito. No deben presentarse como un derecho general a trasladar cualquier modelo, configuración, sistema de IA o contrato de una administración.
La comparación muestra algo más modesto y más útil que una promesa universal: la posibilidad de cambiar de proveedor puede convertirse en una obligación de diseño contractual y técnico. También deja visible lo que una regla de portabilidad no decide automáticamente. Exportar datos no garantiza que el nuevo sistema conserve el desempeño necesario; una interfaz abierta no transfiere conocimiento institucional; la equivalencia funcional en un servicio cloud no resuelve quién revisará las decisiones sustantivas de un sistema de IA. La salida debe diseñarse alrededor de la función que debe continuar, no de una casilla que diga «descarga disponible».
Para un organismo público, eso comienza por inventariar qué se está delegando. Puede ser una recomendación que un funcionario aún contrasta, una clasificación que define prioridades o un paso que desencadena una decisión con consecuencias para una persona. Cuanto más depende un servicio de una plataforma, mayor es la importancia de conservar registros utilizables, descripciones comprensibles de datos y versiones, documentación de las integraciones y capacidad para reconstruir el flujo de trabajo. No todos los contratos requieren la misma solución. El diseño debe responder a la función, a la gravedad de una interrupción y al tiempo que la institución tendría para reemplazar el sistema.
Un contrato sólido puede establecer formatos de exportación, acceso a registros, asistencia de migración, aviso sobre cambios relevantes, períodos de transición y pruebas de continuidad. También puede exigir que las partes ensayen una salida antes de que una crisis obligue a improvisarla. La prueba no debería limitarse a verificar que un archivo se descarga: debe comprobar que el organismo puede usarlo, que entiende qué información falta, que existe personal capaz de reconstruir el proceso y que la atención no desaparece durante el traslado. Cuando la función no admite una interrupción sencilla, puede ser necesario prever un procedimiento alternativo con recursos y responsables identificados.
La administración conserva las capacidades que necesita para cumplir las obligaciones que justificaron contratar el sistema. Una documentación suficiente, personal preparado para revisar y migrar, acceso conforme a la ley a los registros pertinentes y condiciones contractuales de transición pueden ofrecer más control que una copia de código que nadie está en condiciones de ejecutar. El grado de exigencia debe corresponder a la criticidad del servicio y al costo de quedar sin alternativa; en unos casos bastará una transición probada y en otros será necesario mantener un procedimiento alternativo con recursos asignados.
La reversibilidad antes de que haya una crisis
La dependencia también se mueve con el tiempo. Un sistema puede cambiar de versión, recibir datos nuevos, incorporar una función o pasar a atender más decisiones de las previstas al contratarlo. El personal que conocía la configuración puede salir de la institución; el proveedor puede modificar una interfaz, una condición de servicio o una política de precios. La capacidad de salida que parecía suficiente al comienzo quizá ya no lo sea. Por eso una cláusula inicial no reemplaza la supervisión del contrato: la administración tiene que revisar si siguen existiendo las condiciones que vuelven ejecutable esa salida.
Una prueba periódica puede hacer visible una dependencia que el contrato no revela: quién tiene credenciales, qué sistema contiene la versión utilizable de los expedientes, qué procedimiento permite continuar si la herramienta se detiene y cuánto tarda una transferencia realista. Este ejercicio no predice la próxima falla. Permite saber qué decisión sería posible cuando llegue el momento y qué inversiones deben hacerse antes para que no sea demasiado tarde. En una institución que procesa solicitudes, el retraso de semanas puede afectar a personas; en otras tareas, el daño será distinto. El plan de continuidad debe explicarlo desde la función pública concreta.
La cuestión enlaza con una preocupación más amplia sobre la autoridad delegada. Una capacidad técnica superior puede hacer razonable confiar una tarea a un sistema; no convierte automáticamente a la organización usuaria en dueña de las condiciones para abandonarlo. La autoridad sobre la función incluye conservar la facultad práctica de revisar el arreglo, cambiarlo y responder por sus consecuencias. Si solo el proveedor puede interpretar el funcionamiento, restaurar el servicio o hacer viable la transición, la institución conserva el deber público, pero ha cedido parte de los medios necesarios para ejercerlo.
Una herramienta puede mejorar una función y reducir costos; la administración tiene razones para adoptarla cuando el beneficio sirve a su cometido público. Al contratarla, debe decidir qué capacidad conservará para examinar su desempeño, sustituirla y mantener el servicio. Esa previsión permite aprovechar la automatización y, a la vez, seguir aprendiendo de su uso. La continuidad queda entonces organizada por la institución, en lugar de depender de la buena voluntad de quien suministra la herramienta.
El botón de apagado sigue siendo útil. Impide que una operación continúe cuando debe detenerse. Pero el poder de detener no completa el poder de gobernar si, al pulsarlo, la institución no sabe cómo atenderá mañana a quienes dependían de ese servicio. El Estado demuestra que conserva autoridad cuando puede detener un sistema y también sostener la tarea, cambiar de proveedor o reconstruir el procedimiento. Una salida no empieza con la firma de una cláusula; empieza mucho antes, cuando se decide qué capacidades no se delegarán junto con el trabajo.