Why Data Alone Cannot Make Infrastructure AI Reliable
/ Reading time: about 6 minutes
By Daria Batrakova, Director Telecom Solutions
In our last blog, we explored why a reliable data foundation is essential for trustworthy autonomous infrastructure operations. But reliable AI does not come from data quality alone. It also depends on where that data lives, how it is structured, and whether it carries enough operational meaning for AI agents to act on it correctly.
In this second blog, we look at a common assumption in enterprise AI programs: that a centralized data lake or warehouse already contains “everything” and is therefore the natural place to ground operational AI. For autonomous operations across IT, network, data center, and OT environments, that assumption is often backwards.
Operational AI does not need the largest possible pool of data. In fact, it needs the exact opposite. The smallest set of data that is authoritative, current, and rich in operational meaning is best. The real question is not “where is the most data?” It’s “where is the ground truth?” For infrastructure, ground truth does not live in a lake. It lives in a maintained infrastructure digital twin. The difference between these two decides whether an agent is reliable or merely confident.
A Data Lake Captures and Stores Data, but Doesn’t Give Business Meaning or Structure
The appeal of modern data storage and management technologies like data lakes is that they accept raw data at scale. That is also precisely why they struggle as a runtime grounding source. As explained by AWS, raw data sits in a lake with no oversight of its contents, unless cataloging and governance are added on top. If AI has to fix messy records and resolve data conflicts while generating an answer, it is forced to do heavy data engineering in real time. This makes the AI incredibly slow, prone to mistakes, and massively expensive to run.
Suitable Product:
Five Places Where a Data Platform Falls Short for Infrastructure AI
FNT’s “Confident but Wrong” white paper compares an infrastructure digital twin, which is an analytical platform that sits on top of a data platform to process, visualize, and generate business insights, across five dimensions. The contrast is what makes the case concrete for teams that already run a lake or warehouse:
|
Dimension |
Data lake / warehouse |
Infrastructure digital twin |
|
Data model |
Tabular and columnar, tuned for aggregation |
A graph of relationships; a mesh of assets, connections, and dependencies |
|
Validation |
Tracks provenance (where data came from) |
Validates against business rules and physical reality |
|
Freshness |
Refreshed in batch cycles, inherently lags reality |
Continuously reconciled, often in real-time to reflect current state |
|
Dependencies |
Relationships rebuilt at query time through joins |
Relationships modelled natively and traversed directly |
|
Ontology |
Meaning must be inferred from schema and content |
Meaning encoded deliberately, the model already knows what an asset like device, port, circuit, or service is |
The last row is the most impactful one. A lake can ingest infrastructure data, but it cannot ingest the meaning of it. The knowledge that a particular record is a patch panel, that a containment relationship implies a physical dependency, or that a logical circuit rides a specific fiber path is not something an analytical store derives on its own. It has to be modelled. This is the ontology problem, and it is why a maintained twin is not just cleaner data, but is structurally different data.
The Grounding Source Is Where Operational Meaning Lives
Operational AI, capable of supporting capacity planning, change impact analysis, incident diagnosis, compliance verification, and automated remediation, needs semantics. Volume alone is insufficient. It needs to know what is authoritative, what the relationships are, and how intended state differs from observed state.
Agents should ingest desired state data, not just observed data, so they never have to infer which state is normative. Those questions should be resolved before the data ever reaches the prompt – and this is where “system of record” like infrastructure digital twin can help.
Flat data also flattens time. Capacity decisions and change planning depend on knowing the past, the present, and the intended future state of an asset. A monitoring feed shows only the present; a data lake preserves history but loses the planned-versus-implemented distinction. Only a maintained twin holds all three at once.
Bigger LLM Context Windows Do Not Fix This
The predictable argument against separate system of records is that LLM’s context windows are expanding fast, with some models now exceeding a million tokens, so the retrieval problem will simply disappear. The evidence does not support that.
Research by AC Anthology on long-context behavior found that model performance degrades when the relevant information is buried in the middle of a long input, even in models built for long-context reasoning. Attention is not distributed evenly across a large prompt, and facts placed away from the beginning or end are not reliably surfaced. Open AI makes the same point, but from the opposite direction, claiming that too much irrelevant context drowns out the information that matters. More context relaxes some constraints, but it does not remove the need for precise retrieval and authoritative source selection. Hand a capable model a large, poorly structured context and you get more preprocessing and less reliable output. The engineering problem is not capacity. It is precision.
The Right Architecture: Data Platform Plus Digital Twin
None of this is an argument against modern data platforms like data lakes or warehouses, but against their misapplication. When an authoritative, API-accessible digital twin already exists as the system of record, it should serve as the primary grounding source for operational AI at runtime.
The reliable pattern is federated retrieval with strict source ranking. This means that when an AI Agent needs to answer a question, it shouldn't pull from a single source. It should query multiple sources in parallel (federated retrieval) but treat them with a clear hierarchy: the most authoritative source wins. If the digital twin has the answer, it takes precedence over the data warehouse, which takes precedence over a document store, and so on.
This is why the answer is “data platform plus digital twin,” not “either/or.” FNT Command is an API-first infrastructure digital twin spanning physical assets, logical services, and virtual resources across data centers, enterprise IT, and telecommunications networks. It’s designed to be the authoritative grounding layer an AI agent reasons over, kept aligned with the infrastructure it represents.
Conclusion
As IT and network operations become more autonomous, the value of authoritative infrastructure data goes up, not down. A modern technology like data lake makes everything available but only a maintained infrastructure twin makes the right piece of knowledge reliable. The organizations that get this right will treat their analytical estate and their digital twin as complementary and point their AI agents at ground truth first.
The full architecture, including the five-dimension comparison and a source-selection hierarchy for grounding infrastructure AI, is set out in the FNT white paper Confident but Wrong: Why Agentic AI for Digital Infrastructure Depends on Authoritative Knowledge and Data.