Imagine changing your AI provider and discovering that your organization must rebuild what it knows about its own infrastructure.
The asset files are available. The inspection reports are downloadable. The sensor readings remain in a database.
But the relationships that made those records useful are scattered across prompts, assistant configurations, proprietary indexes and conversation histories.
Which pump serves which zone? Which inspection supersedes an earlier finding? Who approved the operating limit? What evidence confirmed that a repair worked?
You can export the documents. Can you preserve the understanding?
For infrastructure owners adopting GeoAI and digital twins, that question deserves a place beside model accuracy, security and cost.
The knowledge is in the connections
An LLM can help people ask questions across complex information. That is valuable when teams have spent years navigating disconnected GIS, BIM, maintenance and operational systems.
However, a fluent answer can conceal how much work sits underneath it.
Consider an illustrative water-network question:
“If this pumping station becomes unavailable, which facilities could lose service first?”
A useful response needs more than a station name and a nearby-hospitals layer.
It needs network connectivity, valve states, pressure zones, available storage, current demand and an appropriate hydraulic assessment. It also needs to distinguish confirmed conditions from assumptions.
A hospital may be geographically close while receiving water through another supply path. A more distant facility may depend directly on the affected station.
The organization’s operational knowledge lies in those dependencies, their supporting evidence and the rules for interpreting them.
That knowledge should remain usable when the conversational model changes.
Ownership needs a practical definition
The title is an architectural principle. It is not a claim that every LLM provider legally owns customer data.
Contractual ownership, permitted data use, retention and practical portability are separate questions. Buyers need to examine each one.
An organization can retain ownership of its documents while becoming dependent on a particular system to retrieve, connect and interpret them.
The same risk can arise with a digital-twin platform, systems integrator or internally developed application. Moving the dependency away from an LLM vendor does not automatically solve it.
My position is that customer-specific asset knowledge should remain under customer-governed control, with usable access and export rights. A supplier can retain its platform intellectual property while allowing customers to preserve their own operational records and relationships.
The procurement question becomes concrete: what can we take with us, and what will still work?
Separate three layers
A practical starting point is to separate physical context, model reasoning and execution location.
Physical context contains stable asset identities, geometry, relationships, observations, evidence, approved constraints and decision history. It needs governed records, whether implemented through linked databases, a knowledge graph or a combination.
Model reasoning helps interpret requests, select tools and explain results. Models should access approved context through controlled interfaces. Their suggested relationships should remain distinguishable from verified records.
Execution location determines where retrieval, inference and specialist analysis run: cloud, private infrastructure, on premises or edge. Different workloads may need different arrangements.
These layers will still have dependencies. Separating them makes those dependencies visible and easier to manage.
An organization should be able to improve its conversational interface without renegotiating the meaning of every asset.
Open connections help, but meaning must survive
There are useful standards to build upon.
OGC GeoSPARQL supports representing and querying geospatial information in RDF. It provides a foundation for expressing spatial knowledge through shared structures.
The Model Context Protocol provides a standard way to connect AI applications with external tools and data sources.
Neither automatically makes an infrastructure knowledge system portable.
A working connection does not prove that two systems interpret “feeds,” “isolates,” “supersedes” or “verified” consistently. A spatial query standard does not supply an organization’s maintenance rules.
Teams still need agreed definitions, stable identifiers, version history and clear responsibility for updates.
Portability also needs to include retrieval configuration, access policies and evaluation cases. Embeddings may need regeneration when the embedding model changes. A replacement LLM may use tools differently or produce weaker explanations.
Changing models is an engineering exercise that requires validation.
Test the exit before you need it
I would make a small portability exercise part of an infrastructure AI pilot.
Choose one bounded workflow, such as reviewing a suspected network fault. Record the evidence, expected tool outputs, permissions and acceptable response behavior.
Then run it through a second model using the same governed context.
Evaluate more than whether the answers sound similar:
- Does each answer identify the correct assets and dependencies?
- Can it cite the evidence and recognize stale observations?
- Does it preserve uncertainty and escalate unresolved conflicts?
- Are restricted records and actions still blocked?
- Can a reviewer reconstruct how the recommendation was reached?
Keep spatial calculations, engineering simulations and action permissions in appropriate services with explicit controls. An LLM's recommendation should not itself grant authority to operate an asset.
This exercise reveals which parts of the system are portable and which need further work.
Measure the cost of keeping your knowledge usable
The business case extends beyond avoiding supplier dependence.
A governed context layer can support successive assistants, engineering applications and operational workflows. Its value grows when teams can reuse verified relationships instead of repeatedly reconstructing them.
Useful measures include the time required to validate a replacement model, the effort spent rebuilding integrations, the share of recommendations traceable to evidence and the time needed to bring a new team into an established workflow.
There is a cost to maintaining this foundation. Asset relationships change. Evidence expires. Permissions evolve. Someone must own that work.
For me, that is where the lasting infrastructure AI investment sits: maintaining knowledge that the organization can inspect, correct and carry forward.
The next model may offer better reasoning or lower cost. Enterprises should be able to consider it without putting years of operational understanding at risk.
Before approving the next AI pilot, ask the team to demonstrate what survives when the model is replaced.
