--- title: "AI adoption in a telco: the network is easy, the commercial side isn't" url: https://zerofive.ai/en/blog/strategy/ai-adoption-telecom-network-commercial canonical: https://zerofive.ai/en/blog/strategy/ai-adoption-telecom-network-commercial language: en published: 2026-07-30 updated: 2026-09-23 author: "ZeroFive.AI" tags: AI adoption, telco, NIS2, network, churn abstract: "The highest-value area carries the least friction. NIS2 coordination, the hidden credit assessment, and pilots at large volumes." --- # AI adoption in a telco: the network is easy, the commercial side isn't **In short.** Telecom operators enjoy a rare condition: the area with the most value, network optimisation, is also the one with the least regulatory friction, because it stays minimal risk under the AI Act. That is the opposite of banking and insurance. The constraint here concerns the overlap with NIS2, which needs coordinating rather than duplicating, more than the rules themselves. The use case to treat with most care is the commercial one, where a credit assessment hides. In operators, technical maturity is high, and the question concerns impact rather than feasibility. That shifts the problem onto different ground from other sectors, where the discussion stops earlier, at what can be built with the available data. ## Two areas, two logics On the network, value is measured in operating costs, faults avoided and capacity recovered. These are numbers the operator already collects daily for its own reasons, which makes the business case verifiable in months rather than years and removes the argument about how to measure. That matters. On the commercial side, value is measured in churn avoided, conversion and margin per customer. Those numbers are available too, with one complication: attributing a churn change to a model requires a control group, and in a telco keeping one means declining to treat part of the customer base. The practical difference is that on the network you can start without regulatory discussion, while on the commercial side you first need to know which risk class you are working in. ## The map of candidate use cases | Use case | Value | Regulatory friction | Suitable as first | |---|---|---|---| | Predictive maintenance on the network | High and measurable | Low, NIS2 obligations remain | Yes | | Capacity optimisation | High | Low | Yes | | Customer service assistance | Medium-high, at volume | Low, Article 50 | Yes | | Churn and propensity models | High | Medium, GDPR profiling | As a second step | | Traffic fraud detection | High | Medium, depends on customer impact | As a second step | | Credit assessment for instalment plans | High | High, Annex III | No, not as a first | The last row stays invisible longest in operators, because that process originates in the commercial function and gets treated as a sales rule rather than a scoring system. ## Coordinating with NIS2 instead of duplicating A telecom operator already produces documentation on risk management, resilience and critical suppliers. Many of the requirements the AI Act sets for relevant systems overlap with that work. Building a second separate framework means paying twice for the same system, with the result that the two sets of documentation diverge over time and neither is reliable. Coordination is a requirements mapping exercise rather than a rewrite: you establish which evidence satisfies both sets of rules, which serves only one, and who maintains it. It is also how to avoid loading everything onto the security function, which in many operators is already the bottleneck. ## The pilot when volumes are enormous The recurring temptation is to skip the pilot, because volumes are such that a test on a narrow perimeter looks insignificant, and the pressure to scale immediately is strong. It's worth resisting for a practical reason: at large volumes a systematic error causes damage for weeks before anyone notices, and the cost of recovery exceeds that of the test avoided. The right perimeter for a telco pilot is a region, a customer segment or a type of installation, with a baseline measured on that same perimeter and acceptance criteria set beforehand. The exit plan here mostly concerns integration with billing and network management systems, the part that stretches timelines more than any modelling question. ## When the model comes from the vendor Most AI systems in a telco arrive inside vendor platforms rather than being developed in house. That changes the question: it isn't what we want to build, it's what we are already using and who answers for what. Defining the contractual role has to happen system by system, before extending usage rather than after, because the choice between provider and deployer determines which obligations fall on the operator and which stay with the supplier that built the model. This isn't a formality. An operator switching on an AI feature inside an existing platform takes on obligations nobody assessed at activation. ## Where to start The sequence begins with the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), which in a telco must also cover features switched on inside vendor platforms. The general selection criteria are in [AI adoption: how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case), and the cost model in [AI project budgeting](/en/blog/strategy/ai-project-budget-pilot-production). The sector's regulatory picture is on the [AI governance for telecom operators](/en/sectors/telco) page. To assess which use cases make sense for your operator, you can [book a meeting](https://calendly.com/fabiolalli/zerofive).