Portabilidad de datos en software con IA: guía para evaluar el riesgo de dependencia

La portabilidad en una aplicación con funciones de inteligencia artificial no se limita a descargar un archivo. Implica poder recuperar datos, entender qué información acompaña a esos datos y comprobar qué partes del trabajo pueden seguir utilizándose fuera del servicio. Si una herramienta genera informes, clasifica documentos o automatiza tareas, la pregunta práctica es si una empresa puede llevarse los insumos y resultados que necesita para continuar su actividad. La posibilidad de exportar no garantiza, por sí sola, que el resultado sea reutilizable.

Conviene distinguir entre los datos que aporta el cliente, los resultados que genera la aplicación y los elementos que pertenecen al proveedor o dependen de su infraestructura. Esa distinción importa porque la documentación puede definir categorías de exportación y exclusiones de forma diferente. No hay que suponer que el historial, las instrucciones, las configuraciones o las conexiones con otros sistemas se incluyen automáticamente en una descarga. Cada elemento debe verificarse por separado.

La portabilidad también tiene una dimensión operativa: un archivo exportado puede estar completo, pero necesitar un formato, una herramienta o un proceso específico para volver a incorporarlo a otro sistema. Por eso, una evaluación útil no se queda en «¿puedo descargar mis datos?». Pregunta qué categorías abarca la exportación, cómo se entregan y qué dependencias podrían impedir su uso posterior. En esta guía, los ejemplos documentados sirven para mostrar qué comprobar, no para comparar proveedores ni dar por hecho que sus políticas sean equivalentes.

La documentación oficial de Microsoft explica que sus clientes pueden exportar determinados datos, entre ellos archivos de texto, sonido, imagen y vídeo, así como contenido de bases de datos. También identifica exclusiones: la información utilizada para configurar recursos —por ejemplo, ciertos ajustes técnicos y nombres de recursos— y datos propietarios protegidos como secretos comerciales no se consideran datos del cliente exportables. La lista de exclusiones es tan importante como la promesa de exportación.

Este ejemplo permite plantear una comprobación concreta: buscar la definición de los datos exportables y leer las excepciones, en lugar de fiarse de una frase general sobre portabilidad. La documentación consultada describe categorías de contenido y límites, pero no sirve para afirmar que todas las plataformas ofrecen las mismas opciones ni que cualquier dato producido por una función de IA esté incluido. La política debe revisarse para el producto, servicio y tipo de información que la empresa vaya a utilizar.

También hay que comprobar los formatos disponibles y si existe documentación que explique su estructura. Un formato conocido puede facilitar el procesamiento en otras herramientas, pero no basta con que el nombre del formato aparezca en una página comercial: importa si la exportación contiene los campos necesarios, conserva relaciones relevantes y puede repetirse con un volumen de datos suficiente. Formato, contenido y procedimiento son tres comprobaciones distintas.

Si la documentación no aclara un punto, debe registrarse como una pregunta pendiente, no resolverse mediante una suposición. Antes de contratar, conviene solicitar una respuesta precisa sobre si el proveedor permite exportar los datos concretos que la empresa generará, con qué formato y mediante qué proceso. Si esa respuesta afecta a la continuidad operativa, se debe pedir que quede reflejada en los compromisos contractuales aplicables.

La retención responde a una pregunta distinta de la portabilidad: durante cuánto tiempo conserva el servicio ciertos datos y qué ocurre después. En Amazon Location Service, la documentación indica que las ubicaciones de dispositivos se almacenan durante 30 días antes de eliminarse automáticamente. En cambio, las geometrías de geocercas que proporciona el usuario deben eliminarse explícitamente. Un mismo servicio puede aplicar reglas distintas según el tipo de dato.

Este ejemplo no debe generalizarse a otros productos de AWS ni a otros proveedores. Su utilidad consiste en mostrar por qué hay que revisar cada categoría y cada operación por separado: conservación, eliminación automática y eliminación que requiere una acción del cliente no son lo mismo. En un proceso de evaluación, conviene identificar qué datos se guardan, durante cuánto tiempo, qué activa su borrado y si la documentación indica excepciones o pasos adicionales.

Para una empresa, el plazo de retención puede afectar al momento en que conviene exportar información y a la planificación de una migración. La política de eliminación también puede ser relevante para la gestión interna y para obligaciones que la organización deba cumplir. Sin embargo, una página técnica de un servicio concreto no permite concluir qué obligaciones legales se aplican a una empresa determinada ni qué ocurre con todas las copias o sistemas asociados: eso requiere revisar los documentos aplicables al servicio y, cuando corresponda, asesoramiento contractual o jurídico.

Antes de adoptar una herramienta, merece la pena dejar por escrito las preguntas que la documentación pública no contesta: qué sucede al cerrar una cuenta, si hay un periodo para recuperar información, cómo se solicita la eliminación y qué alcance tiene. No conviene dar por supuesto un plazo de gracia ni una eliminación inmediata. La falta de una respuesta pública es un límite de información, que debe elevarse al proveedor antes de depender del sistema.

Las interfaces de programación y las integraciones pueden facilitar el intercambio de información entre sistemas, pero su mera existencia no demuestra que una solución sea fácil de reemplazar. Para evaluarlas, hay que revisar qué operaciones permiten, qué datos exponen y qué limitaciones documenta el proveedor. También conviene comprobar si una integración cubre el flujo de trabajo que realmente utiliza la empresa, en vez de asumir que una conexión genérica resolverá la migración. Una interfaz documentada es evidencia de una capacidad concreta, no una garantía de salida completa.

La información disponible para esta pieza no incluye documentación de APIs de un producto de software con IA ni permite comparar endpoints, límites de uso o compatibilidad entre proveedores. Por eso, no es posible sostener aquí que una API determinada reduzca el acoplamiento, ni que las funciones de IA de un servicio dependan de un modelo propietario o de código abierto. Esas cuestiones deben contrastarse con la documentación técnica específica del producto que se esté evaluando.

En la práctica, la revisión puede organizarse alrededor de preguntas verificables: ¿hay una referencia oficial de la interfaz?, ¿se describen los datos que pueden leerse o modificarse?, ¿se publican límites o condiciones de acceso?, ¿se documentan cambios y versiones? Si la empresa necesita conservar una integración para operar, debe comprobar además quién la mantiene y qué compromisos existen si cambia el servicio. La respuesta puede variar entre productos y planes, así que no se debe trasladar una conclusión de una plataforma a otra.

En el caso de funciones basadas en IA, hay otra cautela: una interfaz puede permitir utilizar una función sin proporcionar acceso al modelo subyacente, a sus parámetros o a una alternativa compatible. La investigación disponible no permite afirmar qué condiciones aplican a productos concretos. El acceso a una función no equivale al control de su tecnología subyacente. Si ese control es necesario, debe confirmarse en documentación o contrato, no inferirse de la presencia de una API.

Una matriz sencilla ayuda a separar lo que está documentado, lo que se deduce y lo que sigue pendiente. Para cada dato o función crítica, se puede anotar la fuente oficial, la capacidad que describe, sus límites y la pregunta que queda sin resolver. Esta práctica hace visible la diferencia entre una promesa general y una instrucción operativa concreta, y evita que una expectativa comercial se convierta en un requisito asumido sin evidencia. La matriz ordena la revisión; no sustituye una garantía contractual.

La tabla es un instrumento de análisis, no una clasificación de proveedores. Por ejemplo, Microsoft documenta categorías exportables y exclusiones, mientras que la página de Amazon Location Service especifica plazos y una diferencia entre eliminación automática y explícita para ciertos datos. Son evidencias de alcance distinto: no permiten comparar la calidad general de ambos servicios ni afirmar que uno sea más portable que el otro.

Los puntos que afectan a la continuidad del negocio pueden requerir compromisos expresos: qué datos se entregan, en qué plazo, en qué formato y cuánto tiempo se mantiene el acceso al finalizar la relación. También puede ser necesario aclarar quién responde a una solicitud de exportación y qué asistencia está incluida. La documentación técnica permite formular preguntas mejor delimitadas; las condiciones contractuales determinan qué obligaciones se han aceptado. No conviertas una expectativa en un compromiso sin confirmación escrita.

Una lista mínima antes de decidir puede ser útil:

• Identificar los datos y resultados que serían difíciles de reconstruir.
• Localizar la documentación oficial que describe exportación, retención y eliminación.
• Confirmar formatos, límites y pasos mediante una respuesta aplicable al producto y plan concretos.
• Resolver por contrato las condiciones esenciales que no estén documentadas públicamente.
• Guardar la versión y fecha de los documentos revisados para poder detectar cambios posteriores.

Este proceso no elimina el riesgo de dependencia, pero ayuda a reconocerlo antes de que la empresa haya acumulado información o procesos difíciles de trasladar.

La evidencia examinada permite sostener conclusiones acotadas: Microsoft declara opciones de exportación para determinadas categorías y especifica exclusiones; Amazon Location Service documenta un periodo de conservación de 30 días para ubicaciones de dispositivos y exige borrar explícitamente las geometrías de geocercas. Son ejemplos útiles de qué detalles buscar, no una evaluación comparativa de programas con IA ni una recomendación sobre un proveedor.

La documentación disponible no ofrece una base suficiente para comparar formatos de exportación entre herramientas de IA, verificar la portabilidad del historial de interacciones o determinar qué proveedores permiten migrar configuraciones, instrucciones o resultados generados. Tampoco acredita condiciones generales sobre APIs, modelos subyacentes, continuidad del servicio, cambios de precio o compromisos en caso de cierre del proveedor. Esos elementos no deben presentarse como hechos establecidos sin una fuente específica.

Por tanto, para una pyme que evalúa una herramienta, la decisión práctica es tratar la portabilidad como una lista de requisitos verificables: qué se necesita recuperar, qué está documentado, qué no se ha confirmado y qué debe quedar en el contrato. No hace falta asumir que toda función de IA es intrínsecamente difícil de reemplazar, ni que una exportación anunciada resuelve la salida. La conclusión prudente depende del producto, el tipo de dato y las condiciones aplicables.

La pieza no ofrece asesoramiento legal ni una auditoría técnica de servicios concretos. La documentación puede cambiar y las condiciones pueden depender del producto, plan, región o contrato. Antes de tomar una decisión, hay que consultar las fuentes oficiales vigentes para el servicio exacto y conservar constancia de las respuestas a las preguntas esenciales.