Una empresa manufacturera que se plantea cambiar de proveedor de IA necesita conservar algo más que el acceso a un modelo de lenguaje. La cuestión es si el asistente de mantenimiento, el servicio de apoyo a producción o la herramienta de búsqueda operativa pueden seguir siendo útiles cuando su proveedor cambia las condiciones, retira un servicio o lleva el producto en otra dirección.
Por eso, la dependencia de un proveedor de IA industrial es una cuestión de continuidad. ¿Puedes conservar el conocimiento operativo, las conexiones con otros sistemas y las reglas de decisión que dan valor al servicio, y después comprobar que una alternativa realiza el trabajo de forma aceptable?
El webinario sobre soberanía digital plantea el objetivo como una gestión consciente de las dependencias, en lugar de dejarse controlar por ellas. Para un servicio de IA ya implantado, eso significa disponer de una alternativa práctica, no eliminar todas las dependencias.
Conserva el servicio, no solo la conexión con el modelo
Piensa en un asistente de mantenimiento que responde preguntas utilizando manuales aprobados, consulta los registros de los equipos y prepara una solicitud de mantenimiento para su revisión. Sustituir la conexión con el modelo solo resolvería una parte de ese servicio. Seguirías necesitando los documentos aplicables, los identificadores de los equipos, las reglas de acceso, las instrucciones que rigen al asistente y la conexión con el sistema de mantenimiento.
Separa la portabilidad en cuestiones distintas:
- Exportación de datos: ¿puedes obtener y reutilizar la información y la configuración necesarias para reconstruir el servicio?
- Conectividad técnica: ¿puede la aplicación sustituta acceder a los sistemas necesarios con los permisos adecuados?
- Equivalencia de comportamiento: ¿recupera la alternativa las fuentes adecuadas, responde dentro de su ámbito de actuación y utiliza correctamente las herramientas de los sistemas de negocio?
Resolver una cuestión no demuestra que las demás estén resueltas. Una colección de documentos exportada no es un asistente operativo. Que una petición sea aceptada no demuestra que la respuesta sea aceptable. Entiende la equivalencia de comportamiento como el cumplimiento de los mismos requisitos operativos, no como la reproducción de una redacción idéntica.
La conversación sobre agentes y ERP plantea un criterio de selección útil: hasta qué punto una solución depende de un modelo de lenguaje concreto, cuán abierta es y en qué medida representa la lógica del negocio. Aplica esa distinción a la continuidad: mantén los requisitos de negocio lo bastante explícitos como para evaluar otra implementación frente a ellos.
Conserva los activos necesarios para reconstruir el servicio
No permitas que «los datos son tuyos» sustituya a un acuerdo de salida detallado. Pregunta por separado qué puedes recuperar, en qué formato, bajo qué condiciones y con qué derechos de reutilización. La propiedad de los datos de IA en fabricación y la posibilidad real de recuperarlos deben examinarse activo por activo.
Para el asistente de mantenimiento, conserva o garantiza el acceso a:
- Registros operativos de origen. Identifica los documentos, los historiales de los equipos y los registros de los sistemas de negocio que necesita el servicio. Establece los derechos para utilizarlos con otro proveedor, incluidas las restricciones asociadas a manuales de terceros.
- Contexto reutilizable para la recuperación de información. Solicita las revisiones de los documentos, las correspondencias con los equipos, los metadatos de acceso, los fragmentos documentales y la configuración de recuperación. Trata expresamente los embeddings, las representaciones numéricas utilizadas para buscar por similitud, y los índices. Pregunta qué activos se pueden exportar y cuáles deben reconstruirse a partir del material de origen.
- Instrucciones de la aplicación y lógica de los flujos de trabajo. Conserva los prompts, las descripciones de las herramientas, las reglas de enrutamiento, los límites de aprobación y la gestión de excepciones en un formato que tu equipo pueda inspeccionar y mantener.
- Ejemplos de evaluación. Mantén las preguntas representativas, las fuentes de respaldo esperadas, las acciones aceptables, las acciones prohibidas y las valoraciones de los revisores fuera de un espacio de trabajo exclusivo del proveedor.
- Registros de conversaciones y de funcionamiento. Especifica el acceso a los mensajes pertinentes, los fragmentos recuperados, las peticiones a herramientas, las respuestas, los errores y las versiones de configuración, sujeto a los controles de conservación y acceso.
El objetivo no es exigir todos los componentes internos del producto de un proveedor. Es distinguir lo que tu organización debe conservar de lo que está dispuesta a recrear. Si, por ejemplo, un índice de recuperación no se puede exportar, identifica el material de origen y la configuración necesarios para reconstruir la recuperación de información y, después, evalúa el resultado reconstruido.
Los registros de funcionamiento merecen especial atención. Exige suficiente detalle para investigar cómo se llegó a una respuesta o acción: qué preguntó el usuario, qué fuentes estaban disponibles, qué herramienta se invocó y qué ocurrió después. Conserva esa capacidad de inspección durante el cambio, en lugar de aceptar una transcripción descargable como si fuera todo el historial del servicio.
Separa el contexto industrial de las conexiones específicas del proveedor
Una arquitectura de IA independiente del modelo debería dar al contexto industrial y a las reglas de negocio un lugar claramente definido fuera de la conexión con cualquier modelo concreto. ARC Advisory Group describe un enfoque en el que una organización expone herramientas y telemetría seleccionadas sin entregar su base de datos en bruto ni su código fuente. Es una separación útil entre el acceso controlado al conocimiento industrial y la posesión de los sistemas subyacentes.
Para el asistente de mantenimiento, define una operación de negocio como «recuperar el historial de mantenimiento de este equipo» con independencia del formato de petición del proveedor del modelo. Documenta el identificador del equipo, los registros permitidos, los campos del resultado y la gestión de errores. Sitúa la adaptación específica del proveedor en el punto de conexión, en lugar de convertirla en la única descripción de lo que significa la operación.
Aplica la misma disciplina a las acciones. «Preparar una solicitud de mantenimiento» debería especificar si el resultado es un borrador, quién lo revisa y qué ocurre tras agotar el tiempo de espera o recibir una petición repetida. La alternativa necesita esas reglas, no solo una dirección de conexión.
Un protocolo abierto, por sí solo, no es un criterio de aceptación suficiente. Pregunta qué mecanismos de autenticación, permisos, significados de las herramientas y reglas de ejecución quedan por configurar. Exige que la alternativa demuestre las operaciones necesarias respetando tus límites de acceso. Una denominación de interfaz compartida no debe sustituir a esa evidencia.
Si la decisión más amplia consiste en cambiar la propia plataforma ERP, evalúa por separado si el flujo de trabajo con IA justifica una actualización del ERP. Conservar un servicio de IA existente no tiene por qué convertirse en un argumento para sustituir el sistema que mantiene los registros oficiales del negocio.
Comprueba que el comportamiento sea aceptable antes del cambio
Volvamos al asistente de mantenimiento. Proporciona a la alternativa la misma pregunta del técnico, el mismo contexto del equipo y la misma colección de documentos autorizados. Pídele que identifique el procedimiento aplicable y prepare el borrador de solicitud permitido. La prueba no consiste en comprobar si su interfaz acepta la entrada. Consiste en determinar si las fuentes utilizadas, la respuesta y la acción resultantes cumplen los requisitos del servicio.
Evalúa por separado la recuperación de información y el uso de herramientas. Comprueba si se encontró el fragmento aplicable, si la respuesta se mantuvo dentro de lo que respaldaba esa fuente y si la herramienta recibió el identificador correcto del equipo y los detalles adecuados de la solicitud. Incluye casos en los que el asistente deba pedir aclaraciones o detenerse. Determinar si un manual de mantenimiento es aplicable al equipo sigue siendo importante con independencia del proveedor que genere la respuesta.
Mantén disponibles los ejemplos de evaluación del servicio actual y las decisiones de los revisores para realizar esta comparación. Exige que un revisor resuelva las diferencias relevantes, en lugar de utilizar una redacción fluida o una conexión correcta como criterio para el cambio. Define una alternativa de respaldo para las tareas cuya evaluación aún no haya superado la solución sustituta.
Una integración estrecha puede seguir siendo una elección razonable. Sopesa el valor de un flujo de trabajo coherente, un soporte coordinado y menos componentes que tu equipo deba ensamblar frente a los activos y controles que tendrías que recrear al salir. Del mismo modo, evalúa quién mantendrá las conexiones, los permisos y el proceso de evaluación en un diseño más modular. Elige la dependencia que entiendas y puedas gestionar, no la apertura como etiqueta.
El resultado útil es un servicio cuya continuidad puedas gestionar de forma deliberada: conserva lo importante, vuelve a conectarlo con acceso controlado y comprueba que su comportamiento sea aceptable antes de transferir la responsabilidad. Si necesitas ayuda para examinar esos límites, explora los servicios de Data & AI en torno al servicio que necesitas preservar.