Microsoft argues for telecom ontology layer as AI workloads strain data models

Microsoft used a June 10 Community Hub post to make a direct case for an ontology layer in telecom: operators need a shared business vocabulary across OSS, BSS, network and customer systems before they can scale AI agents.

The post centers on Microsoft Fabric IQ ontology preview, which lets teams define concepts, properties and relationships, then bind those definitions to OneLake data sources. Microsoft frames the ontology as a business context layer for people, analytics systems and AI agents.

Change

Telecom teams have spent years moving data into lakes, warehouses and real-time platforms. That solved access in many cases. It left a harder problem in place: a customer can appear as an account in sales, a consumer in digital channels and a subscriber in network systems.

An AI agent that analyzes a service complaint needs the link between the subscriber, the service plan, the cell site, the slice, the device and the recent fault record. A table schema can name columns. An ontology can define the business object and the relationships that make the answer usable.

Microsoft says Fabric IQ ontology items define business terms above table schemas. Teams model entity types such as Customer, Service, Device, Site and Network Slice, then bind those entities to lakehouse tables, eventhouse streams and Power BI semantic models. Fabric can also represent those links as a graph, which helps agents traverse relationships across domains.

For telecom operators, the practical use cases include RAN congestion analysis, customer 360, fraud detection, field operations, service assurance and SLA monitoring. A service agent can treat prb_util_pct above 80 as a RAN congestion signal because engineers encoded that meaning in the model. A customer agent can connect a dropped quality-of-service KPI to affected subscribers because the ontology defines the path from network resource to customer service.

Provider comparison

Microsoft has the strongest pitch for operators that already use Fabric, Power BI, Azure Data Lake Storage, Microsoft Purview and Microsoft 365. Microsoft Fabric gives those teams one SaaS data platform, OneLake storage and Fabric IQ preview in the same environment. The trade-off sits in platform commitment. Operators that choose Fabric IQ will map key telecom concepts into Microsoft’s semantic and graph model.

AWS approaches the same problem from a catalog and governance base. AWS Glue Data Catalog centralizes technical metadata for S3, Redshift and third-party data sources, and AWS Lake Formation adds permissions. AWS gives strong fit to operators with large S3 estates and existing Athena, Redshift, EMR and SageMaker Lakehouse usage. Teams need extra domain modeling work if they want a telecom business ontology rather than a catalog of tables, partitions and schemas.

Google Cloud brings Dataplex Universal Catalog and Knowledge Catalog into the comparison. Google fits operators that use BigQuery, Vertex AI and Google Cloud governance services. Its metadata model, lineage and quality features help teams govern analytical estates. Operators still need to define telecom concepts and relationships with enough rigor for agents that cross network, service and customer domains.

Databricks competes through Unity Catalog, which covers governance for data, models, apps and AI agents across clouds. Databricks suits operators that build lakehouse programs around Delta, Iceberg, Parquet, notebooks and machine learning workflows. Unity Catalog gives strong lineage and access control. Telecom teams need to design the semantic layer that maps engineering terms to commercial and service concepts.

Snowflake brings Horizon Catalog into governed discovery, lineage and policy management across Snowflake estates. It fits operators that concentrate data in Snowflake and want catalog governance close to analytics workloads. As with AWS, Google and Databricks, the operator must decide where the telecom ontology lives and how agents use it.

Pricing and migration

Pricing will shape architecture. Microsoft sells Fabric through capacity units under Fabric pricing, with pay-as-you-go and reserved capacity options. That model can help operators pool spend across BI, engineering, warehousing, real-time analytics and AI workloads. It can also hide cost drivers unless teams tag workspaces, monitor capacity use and separate experimental agents from production service operations.

AWS prices Glue Data Catalog metadata with a free first tier, then charges for objects and requests above that level under AWS Glue pricing. Glue crawlers, ETL jobs, table optimization and statistics add usage charges. The model rewards teams that keep metadata design disciplined and avoid catalog sprawl.

Google charges Knowledge Catalog metadata storage by GiB-hour under Dataplex pricing. Google does not charge for some catalog API interactions listed on its pricing page, though related data quality, profiling, lineage and processing features can add costs. Operators should model metadata volume, scan frequency and lineage depth before migration.

Migration should start with one high-value domain, not an enterprise modeling program. Service assurance gives a strong first target because teams can connect network telemetry, trouble tickets, customer impact and field actions. A second strong target uses customer 360, where teams connect subscriber identity, products, devices, interactions and consent rules.

A telecom ontology program needs business owners and engineers in the same design room. Network teams define topology, fault and performance terms. Product teams define offers, bundles and SLA commitments. Security and compliance teams define access rules for personal data, lawful intercept constraints and regional data handling. Data platform teams bind those definitions to source systems.

Teams should track four migration tasks. First, choose canonical names for concepts that cross domains. Second, map each concept to source data and declare identity keys. Third, encode relationships such as subscriber to service, service to network resource and site to cell. Fourth, test agent answers against known incidents, customer records and SLA reports.

Business impact

Telecom executives should treat ontology work as AI infrastructure. Agents need shared meaning before they can plan actions across departments. A network anomaly agent that reads cell congestion, ticket history and affected enterprise customers can rank incidents with more context than a rules engine that sees counters alone.

The payoff comes from fewer bespoke data pipelines, faster use-case onboarding and stronger governance. Teams can reuse the same definitions across service assurance, churn models, network planning and contact center copilots. Compliance teams can attach rules to concepts rather than chase copies of sensitive columns across projects.

The risk comes from weak ownership. A telecom ontology fails when teams treat it as a diagram or a catalog cleanup task. Operators need named owners for subscriber, service, product, network resource and location concepts. They also need release control, test cases and change review, because an ontology change can alter agent answers across business processes.

Microsoft’s telecom argument lands with force for operators that already depend on Fabric. Fabric IQ gives those operators a near-path route from semantic models and OneLake sources into agent grounding. Operators on AWS, Google Cloud, Databricks or Snowflake can pursue the same outcome, but they must assemble more of the telecom ontology and agent context layer themselves.

The strategic choice comes down to control plane design. Pick one place where teams define telecom meaning, govern it and expose it to agents. Then force each AI use case to use that shared model. Telecom operators that skip that step will keep paying data engineers to rebuild context one project at a time.