OSS Data Quality Requirements for AI-Driven Operations

When an AI agent misconfigures a service order or fails to flag a degraded fiber path, the reflex is to blame the model. Swap in a better one, tune the prompt, add another training pass. That reflex is wrong more often than it's right. Most failures in AI-driven OSS operations trace back to what the agent was reading at the moment it acted, not how it reasoned once it had the data in hand.

An AI agent operating in an operational support system reads inventory records, reasons over topology, and takes action inside a live network. If the record it reads is missing a field, out of date, or contradicted by a second system holding a different version of the truth, the agent's output carries that flaw forward no matter how sophisticated the underlying model is. A frontier model handed a stale circuit ID will produce a confident, well-structured, completely wrong answer, because the model's job was never to notice the data was bad. That job belongs to the layer beneath it.

This is where the hallucination conversation changes shape once you leave chat interfaces and enter live networks. A customer-facing chatbot that invents a wrong answer is an embarrassment, usually caught and corrected within a single session. An AI agent that misconfigures a provisioning workflow or misreads inventory state and commits a service order produces an operational event, not a wrong answer for someone to catch. It's producing an operational event: a truck roll, a service outage, a billing error that propagates downstream before anyone notices. The distinction matters because it changes what "acceptable error rate" means. A chatbot can be wrong sometimes. An agent acting on live network state needs to be right, or it needs to know when to stop and ask.

Data quality when the consumer is an AI agent instead of a human analyst

A human network engineer looking at an incomplete circuit record fills the gap. Years of pattern recognition let a person infer that a blank field probably means "default configuration" or pick up the phone and ask someone in provisioning. An AI agent doesn't do that. It acts on what's in front of it, and it treats absence not as an invitation to guess but as a signal, one it may or may not be built to handle gracefully. That difference is the entire reason "data quality" needs a stricter definition once the consumer of that data stops being a person.

Four dimensions do the real work here, and each one shows up again later in this piece applied to a specific part of the OSS stack.

Completeness means every field an agent needs to make a decision is actually populated. A missing circuit ID, an unresolved gap in topology, a blank service attribute: any of these forces the agent into one of two bad choices, halt the workflow or guess. Neither is acceptable at scale.

Consistency means the same network element, service, or customer record resolves to the same state everywhere the agent looks. Inventory, GIS, provisioning, and assurance systems all need to agree. When they don't, the agent isn't choosing between conflicting sources; it is often unaware a conflict exists.

Lineage means the agent, and any human reviewing the agent's decision afterward, can trace where a piece of data came from, when it was last verified, and what it passed through before it reached the point of use. Lineage is what turns "the agent did this" into "the agent did this because the record said X, verified at time Y, sourced from system Z."

Real-time accuracy means the data reflects the network as it exists right now, not as it existed at the last batch sync. An agent acting on a snapshot from four hours ago is making a decision about a network that has already moved on.

77% of organizations cannot trace where their training data actually came from, which stands as one of the more widespread compliance gaps across the current AI regulatory landscape. In an OSS context, that same gap doesn't just create legal exposure. It strips any AI-driven operational decision of its defensibility the moment someone asks "why did the agent do that."

Fragmented OSS data estates create the conditions for agent failure

Legacy OSS architecture was built for a human sitting at a terminal, clicking between three or four systems to piece together a picture of the network. It was never built for an agent that needs a single, resolved, consistent state across every domain in the time it takes to execute a function call. That mismatch is the starting condition most operators are working from.

Network data, billing data, and customer data sit in separate silos and don't move cleanly between them. That's the baseline: network data, billing data, and customer data sit in separate silos and don't move cleanly between them. A pulse-check of European telco CEOs at an industry conference found data readiness cited as a key constraint on getting automation initiatives out of the pilot stage. Several operators pointed to legacy IT as the reason a new product launch takes ten to twelve months from concept to market, a timeline those operators attributed to the constraints of legacy IT.

Fragmentation doesn't degrade one quality dimension at a time. It hits completeness, consistency, lineage, and real-time accuracy all at once. Completeness fails when a provisioning agent can't see the inventory record another team owns in a separate system. Consistency fails when the GIS platform shows a fiber route as active while the fault management system has already flagged it degraded. Lineage fails the moment data gets copied, reshaped, or manually corrected without leaving a trace of what changed and why. Real-time accuracy fails wherever batch-sync jobs are still the mechanism connecting systems, because a batch job by definition means the agent's view of the network is however old the last sync cycle was.

Effects of a unified data model on AI agents across qualification, design, provisioning, and activation

Agents don't stay inside one workflow stage. A provisioning agent has to read qualification records, design decisions, and current inventory state before it commits to an action, and if those three inputs came from three different systems with three different schemas and three different update cadences, the agent is synthesizing a decision from a base that was never internally consistent to begin with. That's not a hypothetical risk; it's the default condition in most fragmented OSS estates.

A unified data model changes what's structurally possible at each of the four dimensions. Completeness stops being something discovered missing when the agent goes looking for it, because a single schema enforces that required attributes get populated at the point a record is created. Consistency stops being a reconciliation problem, because qualification, design, provisioning, and activation are all reading and writing the same record rather than four separate copies of one. Lineage stays intact because provenance travels with the field inside one system, instead of getting lost in translation every time data crosses a system boundary. Real-time accuracy becomes achievable because updates propagate through an event-driven model the moment they happen, rather than waiting on the next scheduled batch job.

For fiber operators specifically, this appears most concretely in how GIS integration links every physical asset (cables, ducts, nodes, customer endpoints) to its exact location, combined with inventory and reconciliation running as one system rather than two adjacent ones. That combination is what turns an OSS into a live model of the network instead of a historical snapshot someone updates when they remember to. An agent qualifying and designing a service against a live model is working from verified data. An agent working from outdated drawings and a spreadsheet someone updated last quarter is not, no matter how good its reasoning is.

PwC's composable BSS/OSS framework describes this as governed data domains: customer, product, order, usage, and financial data treated as assets with defined quality standards, defined lineage, and defined access controls, connected through defined integration points. That framing matters because it gives agents something specific to act through, trusted actuators operating within policy, rather than open access to a data layer with no boundaries.

Real-time accuracy is the hardest quality dimension to sustain in a live network

Completeness, consistency, and lineage are, at bottom, schema and governance problems. Define the required fields, enforce a single source of truth, build provenance tracking into the record structure, and those three dimensions become achievable through design decisions made once. Real-time accuracy is different. It requires continuous, event-driven data flow sustained indefinitely, and most legacy OSS architectures were never built to carry that load.

Batch synchronization is the direct enemy of real-time accuracy. An agent reading a provisioning record that was last synced four hours ago isn't reading an old copy of the truth, it's reading a description of a network that has since changed shape.

For fiber and Carrier Ethernet operators, the failure mode is specific and expensive. A qualification agent reads an inventory record showing available fiber capacity. That capacity was actually consumed by an activation that completed twenty minutes ago, but the record hasn't caught up yet. The agent commits a service order against capacity that no longer exists. Nothing about the model failed here. The reasoning was sound given the data it had. The failure is entirely one of latency, the gap between what the record says and what the network actually looks like at the moment of the decision.

Zero-touch provisioning makes the dependency unavoidable to see. Platforms that sync from existing OSS and BSS tools and activate ONTs or CPE without a human touching a configuration screen are built on the assumption that the data feeding them reflects actual network state at the moment of activation. When that assumption breaks, zero-touch provisioning doesn't fail quietly one order at a time. It fails at scale, because the entire point of the architecture is removing the human checkpoint that would otherwise catch the error.

Data lineage functions as operational governance, not just compliance paperwork

The compliance clock on this is already running. The EU AI Act reached broad enforcement on August 2, 2026, covering transparency obligations and general-purpose AI systems, while the requirements specific to high-risk AI systems were pushed to December 2, 2027 under the Digital Omnibus. Those high-risk requirements include operational human oversight mechanisms and technical documentation, with penalties for violations scaling up to €15 million or 3% of global annual turnover. (The larger €35 million or 7% ceiling applies only to prohibited practices under Article 5, a narrower category.) Telecom's role in critical infrastructure and essential services places it close to the categories the Act targets.

When an agent makes a wrong provisioning decision, the legal exposure matters less than the operational disruption an operator faces day to day. The operational argument is simpler and more immediate. When an agent makes a wrong provisioning decision, the first question anyone asks is what data it read and whether that data was correct. Without lineage, that question has no answer. And without an answer, there's no way to tell whether the failure was the model's reasoning, a data quality gap, or a data freshness problem, so there's no way to know what to fix. Lineage is also the mechanism that makes an AI decision reversible: if you can reconstruct what state the agent saw when it acted, you can reconstruct the state before it acted and roll back cleanly. Without that trace, a rollback is a guess.

Observability is lineage applied continuously rather than after the fact, and it's what makes debugging, cost tracking, and reliability assessment possible in something closer to real time. It's also what lets an operator evaluate agent outputs for hallucination risk, confidence, and relevance before those outputs turn into actions, and it reinforces governance by giving the system a mechanism to block an unsafe or unauthorized action before it executes rather than explain it afterward.

NIST's AI Risk Management Framework, under its GOVERN function, requires accountability structures, defined risk tolerance thresholds, and explicit accountability for AI-driven decisions. The 2024 Generative AI Profile built on that framework didn't extend coverage to agentic systems specifically, a gap NIST has since moved to address. Even where NIST's framework carries no independent legal penalty attached to it, it's increasingly the standard enterprise procurement teams check against before they'll sign off on deploying an agent into live operations.

The governed AI requirement: agents operating within the same permission structures as human operators

There's a real difference between bolting AI onto existing workflows and building AI-native governance from the ground up, and that difference is visible exactly at the permissions layer. AI-augmented systems tend to add an agent on top of workflows that already exist, with its own logging and its own permission model running alongside the human one. The agent is taking real actions inside the network, but those actions don't appear in the same audit trail as everything a human operator does, producing shadow automation.

Ericsson's framing of agentic AI in telecom draws a useful line here. Impactful actions, changing live radio parameters or touching billing-sensitive operations, still require human approval even in the more advanced deployments being discussed. It's a deliberate calibration of risk that the industry has built in, not a limitation it is working around, and it's the right one. It's a deliberate calibration of risk, and it's the right one.

Structurally, governed AI means three things hold true. Agents use the same APIs human operators use, going through the same access controls everyone else has to go through. Agent actions land in the same audit log as human actions, as part of the operational record. And agent permissions are scoped the same way human permissions are scoped: role-based, specific to service type, and revocable the same way an employee's access gets revoked.

This is the architecture that actually protects data quality over time, not just at deployment. An agent that can write to the data model through an ungoverned pathway can quietly degrade the very data the whole system depends on, and it can do it faster than any single human error would, simply because it's running continuously.

A practical framework for assessing OSS data quality readiness before deploying AI agents

Before deploying an agent into live operations, the assessment that matters is an audit of the data estate against the four dimensions laid out above. It's an audit of the data estate against the four dimensions laid out above, and it needs to happen before the agent goes live, not after the first incident.

Completeness audit: map every decision point in the target workflow and list the exact data fields the agent needs at each step. Measure current population rates for those fields across every source system involved, including systems beyond the primary one. Gaps found here are blocking issues, not items for a backlog. Separately, identify which fields get populated manually versus automatically, because manual population is a standing risk to real-time accuracy no matter how complete the field looks today.

Consistency check: select a sample of network elements and trace how each one is represented across every system the agent will query: inventory, GIS, provisioning, fault management. Any divergence in state, identifier, or attribute value across those systems is a consistency failure the agent will run into sooner or later. Then check whether reconciliation between those systems runs on a batch schedule or an event-driven one. Batch reconciliation guarantees a consistency gap; it's a question of how wide, not whether one exists.

Lineage assessment: for any record the agent is going to act on, ask whether its origin, its transformation history, and its last verification timestamp can all be traced. If answering that requires manual digging across multiple systems, lineage isn't operationally viable for AI governance yet, regardless of what the compliance paperwork says. The sharper test: could a complete record of what data the agent acted on, and when, be produced on demand, to the standard EU AI Act enforcement expects? If the answer takes days and a spreadsheet, the data estate isn't ready. If it takes minutes and a query, it is.