A manufacturer considering a change of AI supplier needs to preserve more than access to a language model. The real question is whether the maintenance assistant, production-support service or operational search tool can remain useful when its provider changes terms, withdraws a service or takes the product in another direction.
That makes industrial AI vendor lock-in a continuity question. Can you retain the operational knowledge, system connections and decision rules that make the service valuable, then establish that a replacement handles the work acceptably?
The digital-sovereignty webinar frames the objective as consciously managing dependencies rather than being controlled by them. For an existing AI service, that means having a practical alternative, not eliminating every dependency.
Preserve the service, not just the model connection
Consider a maintenance assistant that answers questions using approved manuals, checks equipment records and prepares a maintenance request for review. Replacing its model connection would address only part of that service. You would still need the applicable documents, equipment identifiers, access rules, instructions governing the assistant and the connection to the maintenance system.
Separate portability into distinct questions:
- Data export: can you obtain and reuse the information and configuration needed to reconstruct the service?
- Technical connectivity: can the replacement application reach the required systems under the right permissions?
- Behavioral equivalence: does the replacement retrieve appropriate evidence, answer within its remit and use business-system tools correctly?
Success at one does not establish the others. An exported document collection is not a functioning assistant. An accepted request is not evidence of an acceptable answer. Treat behavioral equivalence as meeting the same operational requirements, not reproducing identical wording.
The agent-and-ERP discussion raises a useful selection criterion: how proprietary a solution is to a particular language model, how open it is and how well it represents business logic. Apply that distinction to continuity: keep business requirements explicit enough that you can assess another implementation against them.
Retain the assets needed to rebuild
Do not let “you own your data” stand in for a detailed exit agreement. Ask separately what you may retrieve, in what form, under what conditions and with what rights to reuse it. Manufacturing AI data ownership and practical recoverability should be examined asset by asset.
For the maintenance assistant, retain or secure access to:
- Operational source records. Identify the documents, equipment histories and business-system records the service needs. Establish rights to use them with a replacement supplier, including any restrictions attached to third-party manuals.
- Reusable retrieval context. Request document revisions, equipment mappings, access metadata, document segments and retrieval configuration. Address embeddings, the numerical representations used for similarity search, and indexes explicitly. Ask which assets can be exported and what must be rebuilt from source material.
- Application instructions and workflow logic. Preserve prompts, tool descriptions, routing rules, approval boundaries and exception handling in a form your team can inspect and maintain.
- Evaluation examples. Keep representative questions, expected supporting sources, acceptable actions, prohibited actions and reviewer judgments outside a supplier-only workspace.
- Conversation and operational records. Specify access to relevant messages, retrieved passages, tool requests, responses, errors and configuration versions, subject to retention and access controls.
The purpose is not to demand every internal component of a supplier’s product. It is to distinguish what your organization must retain from what it is prepared to recreate. If a retrieval index is not exportable, for example, identify the source material and configuration needed to rebuild retrieval, then evaluate the rebuilt result.
Operational records deserve particular attention. Require enough detail to investigate how an answer or action arose: what the user asked, which evidence was available, which tool was called and what happened next. Preserve that inspection capability across the change, rather than accepting a downloadable transcript as the entire service history.
Separate industrial context from supplier-specific connections
A model-independent AI architecture should give industrial context and business rules a clear home outside any single model connection. ARC Advisory Group describes an approach in which an organization exposes selected tools and telemetry without handing over its raw database or source code. That is a useful separation between controlled access to industrial knowledge and possession of the underlying systems.
For the maintenance assistant, define a business operation such as “retrieve this equipment’s maintenance history” independently of the model supplier’s request format. Document the equipment identifier, permitted records, result fields and error handling. Put supplier-specific translation at the boundary, rather than making it the only description of what the operation means.
Apply the same discipline to actions. “Prepare a maintenance request” should specify whether the result is a draft, who reviews it and what happens after a timeout or repeated request. A replacement needs those rules, not merely a connection address.
An open protocol alone is not an adequate acceptance criterion. Ask which authentication arrangements, permissions, tool meanings and execution rules remain to be configured. Require the replacement to demonstrate the required operations with your access boundaries intact. A shared interface label should not substitute for that evidence.
If the broader decision is whether to change the ERP platform itself, assess whether the AI workflow justifies an ERP upgrade separately. Preserving an existing AI service need not become an argument for replacing its system of record.
Establish acceptable behavior before switching
Return to the maintenance assistant. Give the replacement the same technician question, equipment context and authorized document collection. Ask it to identify the applicable procedure and prepare the permitted draft request. The test is not whether its interface accepts the input. It is whether the resulting evidence, answer and action meet the service’s requirements.
Evaluate retrieval and tool use separately. Check whether the applicable passage was found, whether the answer stayed within that evidence and whether the tool received the correct equipment identifier and request details. Include cases where the assistant must ask for clarification or stop. The question of whether a maintenance manual applies to the equipment remains important regardless of which supplier generates the answer.
Keep the current service’s evaluation examples and reviewer decisions available for this comparison. Require a reviewer to resolve material differences, rather than using fluent wording or successful connectivity as the switching criterion. Define a fallback for work the replacement has not yet passed.
Tight integration can still be a reasonable choice. Assess the value of a coherent workflow, coordinated support and fewer components for your team to assemble against the assets and controls you would have to recreate on exit. Equally, assess who will maintain the connections, permissions and evaluation process in a more modular design. Prefer the dependency you understand and can manage, not openness as a label.
The useful outcome is a service you can continue deliberately: retain what matters, reconnect it under controlled access and establish acceptable behavior before transferring responsibility. If you need help examining those boundaries, explore Data & AI services around the service you need to preserve.