Telco executives are leaning hard into AI. Every board deck includes “AI-driven transformation”. Every CIO has a dozen proofs of concept running. Every vendor is promising copilots, autonomous agents, smarter recommendations, and lower operating costs.
Yet the results tell a different story. AI is not scaling. Pilots stay pilots, gains are incremental at best, and costs do not actually go down. The big prize, the one every operator wants, remains out of reach: AI that works reliably across the business to shrink cycle times, eliminate errors, reduce integration debt, speed up monetization, and automate decisions.
This failure is not because AI is overhyped or immature. A marginally stronger model will not move the needle anymore. It is also not because telcos are lacking data. They have massive data sets, modern cloud platforms, analytics teams, and more dashboards than anyone needs. It is because telcos are trying to deploy AI inside one of the most semantically fragmented environments in any industry.
And no amount of model tuning, data engineering, or prompt engineering will solve a semantic problem.
The uncomfortable truth: AI without context is where AI starts hallucinating
Generative AI can write an email, generate a summary, write code, or provide a highly detailed answer to a very difficult question. But what it cannot do on its own is understand the deep structures that govern a telecom business. It does not inherently know what a subscriber is versus an account, why a billing account may differ from a CRM account, how a product catalog drives eligibility, or what rules tie together a bundle, its charges, its mediated events, and its billing cycles. LLMs were never trained on the private, messy, proprietary operational reality of a telco.
Telco BSS is full of such nuances. These are not cosmetic differences. They are the source of quote fallouts, billing errors, revenue leakage, compliance failures, and months-long integration cycles.
When AI lacks this understanding, it becomes a sophisticated auto complete engine, not an intelligent operator. It cannot reconcile conflicting customer identifiers across CRM, billing, and charging. It cannot reason across a CPQ flow that uses a different product hierarchy from the catalog. It cannot validate an order if eligibility rules are scattered across three systems. AI simply cannot reason, and it cannot act, and in worse cases – it just starts hallucinating
This is why telcos see AI hype collide with reality the moment they step outside the demo and into production.
The real barrier is semantic chaos, not model capability
Telecom BSS is an ecosystem of systems built over years or decades. CRM, CPQ, catalog, ordering, activation, mediation, charging, billing, dunning, partner management, self service portals, and analytical platforms. Each came from a different vendor or era. Each uses its own definitions. Each captures its own version of the truth.
Tommy Björkberg, VP Network & Cloud at KPN, referred to this in a recent LinkedIn post as the “Garbage In, Gospel Out” problem. Telecom data is not “ready-made AI fuel”. It is fragmented, inconsistent, duplicated, and full of conflicting definitions. You can pump this into an AI model, but the result is exactly what you would expect. The AI becomes a mirror of your fragmentation. It inherits your inconsistencies. It faithfully replicates your semantic drift.
Which is why telcos end up with:
- copilots that hallucinate catalog structures
- chatbots that give the wrong account information
- AI agents that cannot generate a valid order
- predictive models that fail because the underlying entities are not aligned
This is not a data volume problem. Telcos have oceans of data. This is not an LLM quality problem. The best models on the planet will still fail. This is a semantic problem.
AI cannot fix a world where meaning is broken.
Inside a telco stack: what semantic chaos looks like
To explain semantic chaos, let us examine a common telco consumer scenario.
A customer buys a new roaming bundle that includes data, voice, and SMS. They tap “Buy” in the self service app or say “Yes” to an agent in a retail store. From that moment until the bundle is fully consumed, a lot happens behind the scenes. Here is a simplified view of what needs to line up:
- The intent is captured.
The self service app or CRM front end creates an order. It uses its own representation of the customer, the subscription, and the bundle. Often it has its own product catalog or a cached version of the central one. - Product is configured and validated.
A CPQ or order management system checks which variants of the roaming bundle exist, validates eligibility rules, checks for incompatibilities with current services, and configures the service on the subscription. These rules sit across catalog, charging, CRM, CPQ, and sometimes custom rules engines. - The order is decomposed.
The roaming bundle that looks like a single offer to the customer must be broken into several technical components. For example:- a charging configuration for the bundle
- rating rules for different zones
- subscriber wallets (allowances) for data, voice minutes, and SMS
- validity windows for renewals, fees, and more
- Order management translates the commercial order into multiple technical orders, each targeting a different downstream system.
- Provisioning is executed.
Activation happens in the online charging system, billing, invoicing, policy control, and sometimes even network-side systems. Each one has its own data model and its own view of what the roaming bundle looks like. - Usage is collected and rated.
As the customer travels, network events are mediated and handed over to charging and billing. There is another layer of mapping between network event formats, partner records, and your rating logic. - Billing and customer view are updated.
The bill needs to reflect the bundle in a way customers understand. The self service app needs to show remaining allowances. Care agents need a consolidated view of what is active and what was consumed.
Across this journey, we have:
- Multiple “customer” identifiers
- Several definitions of “product” and “offer”
- Different representations of the same roaming bundle in catalog, charging, and billing
- Different clocks and lifecycle states for the same subscription
- Eligibility and pricing rules, and many other entities and actions, scattered across systems
- Dozens of systems that need to interact, read from, and write to each other in order to fulfil the service the customer bought
Now, layer AI on top and ask something simple like:
- “Show me customers who bought the roaming bundle, never used it, and called to complain about bill shock”
- or “Fix roaming bundles that are active in catalog but not yet correctly provisioned in charging”
To answer or act on this, an AI system has to understand all the mappings across CRM, catalog, CPQ, ordering, charging, mediation, billing, care, and analytics. It must interpret what “roaming bundle” means in each system, how identifiers relate, which state transitions matter, and what is considered “correct”.
This is what we mean by “the lines, not the boxes”. A telco product or service is not owned by one application. It is the sum of processes that span many boxes, connected by many lines, each carrying a slightly different view of reality.
And telcos have lots of boxes. Hundreds of them. Each box interconnected with another. That is the n-squared problem. Even if not all boxes are interconnected, many of them are, which means there are far more lines than boxes.
Now imagine you need to swap one of these boxes for a newer, fancier one. How many lines will you need to redraw? How many others will you need to ‘fix’?
This is semantic chaos in practice.
The boxes are fine. The lines are the problem.
Once you see the roaming bundle journey end to end, the AI problem looks very different.
The issue is not whether a model can classify text, write Python, or summarize a document. The issue is that an AI agent trying to help you with roaming bundles, RAN failure prediction, or quote to order has to move through a landscape where:
- “Customer” means one thing in billing, another in CRM, and something else in analytics
- The same bundle is represented as different SKUs with different attributes in catalog, CPQ, and charging
- Order states are encoded differently in each system
- Event IDs and subscription IDs do not align cleanly
- Business rules live partly in code, partly in config, partly in spreadsheets, and partly in people’s heads
Retrieval augmented generation (RAG) does not fix that. It can fetch you the catalog PDF and the billing guide. It cannot turn them into an operational graph that says:
- this roaming bundle consists of these technical components
- they must be activated in this sequence
- these downstream systems must be updated
- these fields correspond to each other
- these constraints must be checked before and after each step
Without that graph, AI behaves like a smart intern who has read all the manuals but still needs a senior architect to interpret every detail.
That is why AI pilots look great in a controlled sandbox, but fall apart once they face the real BSS stack. The models are strong enough. The semantics are not.
How a Telco Ontology fixes the lines
This is exactly the problem BSS Magic was built to solve. Instead of teaching every AI application or agent to understand every system directly, BSS Magic’s Telco Ontology serves as a shared semantic layer on top of the existing stack.
BSS Magic has three layers:
- Data layer Vendor-agnostic connectivity that pulls data from CRM, billing, charging, catalog, ordering, care, data lakes, and even network systems. It does not try to standardize systems. It connects to them to provide the ontology with what it requires in order to build the machine-readable, digital representation of the telco’s world: the data, the logic, and the actions that comprise a telco.
- Ontology layer The telco ontology is, in essence, a machine-readable representation of how the telco works in the real world. It covers the nouns and verbs, the entities, the logic, and the actions that make up the telco. It is the digital twin of the telco. It represents entities such as customer, account, subscription, store, handset, balance, and cell site, the actions such as provision, update, charge, delete, ship, and write, and the business logic such as the sequence of actions, who is churning, or the impact of a power outage on cell availability. It is a telco knowledge base grounded in TM Forum SID, ODA, eTOM, and 3GPP, extended with each operator’s specifics. This is where customer, subscription, offer, service, resource, order, charge, and balance are defined once, with relationships, constraints, and lifecycle states. It is where roaming bundles are expressed as structured combinations of services, prices, allowances, and provisioning flows, independent of any single vendor’s jargon, taxonomy, or schema.
- AI layer Ontology-aware AI that generates production grade code, queries, and workflows. These are your agents, copilots, automation flows or any AI output. They do not speak directly to fifty systems. They speak to the ontology, which already knows how to read and write to those systems.
The ontology sits in the middle and changes the integration topology. Instead of every system integrating with many others directly, each system integrates once to the ontology. The ontology handles semantic translation, so complexity grows linearly instead of exploding. It knows which systems to query, how to resolve IDs, how to interpret results, and which actions are valid. The ontology fixes the lines.
What this unlocks in BSS: from insight to execution
Once semantics are solved, AI stops being a lab experiment and becomes operational. Any AI application can stand on top of a digital twin of the telco business, not a pile of disconnected logs and tables, and can now understand, reason, and drive actions with confidence.
The applications are vast, from observability and insights through migrations to full creation of applications, services, and capabilities that elevate customer experience, increase revenue, and cut costs. We will dive deeper into those in our next posts.
FAQs
Most telcos cannot operationalize AI because their data landscape is semantically chaotic. CRM, billing, charging, catalog, CPQ, mediation, and ordering systems all define core concepts differently-subscriber IDs, account structures, product definitions, eligibility rules, and usage records often contradict one another. As the blog highlights, LLMs and ML models cannot reason across inconsistent or conflicting semantics. They inherit the fragmentation and hallucinate when domain meaning is unclear . The real blocker isn’t model quality or lack of data-it’s the absence of a unified semantic layer. Without shared meaning, AI cannot scale across workflows, automate decisions, or act reliably.
Semantic chaos describes the inconsistent, duplicated, vendor-specific definitions telcos accumulate across decades of siloed systems. One “subscriber” might represent a billing account in one system, a CRM profile in another, and a network identifier in a third. Product catalogs differ between CPQ and charging. Eligibility rules appear in multiple systems with no single source of truth. This fragmentation forces costly manual reconciliation and leads to billing errors, failed orders, revenue leakage, and poor AI accuracy. As the blog explains, telcos experience “Garbage In, Gospel Out”-AI faithfully reproduces the inconsistencies of the underlying stack rather than fixing them.
Because no AI model-regardless of size-can correctly infer proprietary, inconsistent, or conflicting telecom semantics on its own. LLMs excel at pattern recognition but lack structural understanding of domain-specific relationships such as subscriber hierarchy, rating logic, or cross-system identity resolution. The blog notes that “a marginally stronger model will not move the needle” because the problem is not computational-it’s contextual . Without unified meaning across BSS components, AI agents hallucinate catalog structures, produce invalid orders, and misinterpret account data. Domain intelligence must be explicitly encoded through a telco ontology.
AI agents require reliable, consistent definitions to act autonomously. But in telcos, the same entity behaves differently across systems. So agents:
* Generate invalid orders because they follow mismatched product hierarchies
* Pull conflicting account information from CRM vs billing
* Misinterpret rating rules
* Cannot execute workflows end-to-end
* Fail validation because eligibility logic lives in separate systems
These aren’t algorithmic failures-they stem from missing semantic alignment. AI agents behave like “a sophisticated autocomplete engine” instead of an intelligent operator when meaning is broken.
A telco ontology is a machine-readable semantic model that defines the core entities, relationships, actions, and business logic that govern telecommunications operations. It unifies how subscribers, accounts, services, products, charges, events, and orders are defined across all BSS/OSS systems. As described in the blog, this ontology becomes the foundation for AI to reason correctly about the telco business and align conflicting data sources. It is the missing layer enabling reliable AI automation, BSS interoperability, and cross-stack workflows that previously required manual intervention.
Instead of pushing raw, fragmented, conflicting data into AI systems, the ontology aligns all meanings before the AI ever sees them. It resolves entity mismatches, standardizes definitions, and establishes relationships across the stack. The blog stresses that AI cannot fix broken meaning-but ontology can. When the ontology sits between the BSS components and AI models, all systems speak a consistent semantic language. As a result, AI outputs become trustworthy, explainable, and operationally valid.
Telcos already have massive data sets-usage events, CDRs, CRM profiles, billing histories, product records. The issue is not quantity but coherence. More data simply amplifies inconsistencies. Without unified semantics, large datasets produce hallucinations, invalid predictions, and unreliable AI actions. As the blog notes, “AI becomes a mirror of your fragmentation,” inheriting every inconsistency built into the legacy stack. Semantic alignment unlocks the real value of telco datasets by making them AI-ready.
Because they lack internal domain understanding of how telco systems relate. A chatbot that queries CRM for a “billing account” may return the wrong identifier because billing and CRM define accounts differently. A copilot referencing the product catalog may hallucinate nested structures that exist in CPQ but not in charging. The blog provides examples such as copilots hallucinating catalog structures and chatbots giving incorrect account information due to fragmented semantics. These hallucinations disappear when AI is grounded in a telco ontology.
Because each integration requires teams to map abstractly similar but structurally incompatible entities. When every vendor defines subscribers, offers, and events differently, point-to-point integrations multiply (the n² problem). This leads to:
* Multi-year transformation timelines
* Expensive middleware layers
* Endless reconciliation logic
* Growing technical debt
As the blog describes, fragmented semantics create “months-long integration cycles” that block modernization and AI adoption .
Telecom stacks evolved over decades, with each new system added as a standalone product from a different vendor, built in a different era, with its own terminology and data model. Unlike other industries, telcos rely on dozens of specialized systems-CPQ, catalog, CRM, mediation, charging, billing, dunning, analytics-each essential and each semantically unique. The blog highlights that telecom BSS is “an ecosystem of systems built over years or decades,” creating extreme fragmentation not seen in most other enterprises.
Vendors built their systems independently without shared standards, and many resisted adopting TM Forum ODA or SID because proprietary semantics generate lock-in. Each system embeds its own interpretation of subscribers, products, balances, and events. Over time, operators customize these systems further, extending the semantic drift. The blog emphasizes that “each uses its own definitions” and vendors frequently extend standards with proprietary variations, compounding inconsistency.
By abstracting the vendor-specific semantics into a unified model, the ontology acts as a translation and normalization layer. Systems no longer integrate point-to-point-instead, each integrates once with the ontology. This reduces integration complexity, eliminates reconciliation logic, and establishes a universal semantic language across the stack. While the blog focuses on the semantic problem, this is the foundation of Totogi’s BSS Magic-AI-generated ontology-driven interoperability.
AI agents must understand entities, relationships, and constraints to act autonomously. Without semantic grounding, an agent cannot ensure its actions are valid-whether creating a plan, provisioning a service, or generating an order. As the blog states, AI “cannot reason, and it cannot act” when meaning is fragmented, and in worse cases “just starts hallucinating”. Ontology provides the reasoning foundation required for safe, accurate, compliant AI actions.
