Articles
From recommending to acting: What changes when AI owns the journey
For a decade, AI-driven personalisation in the telecommunications sector has been in a comfortable state: the model makes a suggestion, a person or a rules engine then decides, and responsibility rests with the individual who approved the action. That situation is now coming to an end. When operators begin to use agentic AI in the telecom industry, the system no longer just proposes the best offer; it sends the offer, applies the discount, changes the customer plan and concludes the interaction. The model itself may be the same, but the governance issues are now completely different. The following article outlines the changes that occur when AI moves from a recommendation role to an acting one, explains why consent, data residency, and the ability to audit decisions have to become hard requirements rather than merely compliance footnotes, and states what regulated operators need to have in place before they hand over a customer journey to an autonomous system.
What changes when AI moves from recommending to acting in telecom?
In the case of AI making recommendations, a human has to make the final decision between the suggestion from the model and the customer, and that person is the one who exercises control. They are in a position to spot a bad offer, identify a vulnerable customer, or choose not to send something that appears to be wrong. However, when AI takes action, that control is lost unless it is intentionally incorporated into the system.
Three changes occur simultaneously. The first is that accountability moves from an individual to a system, which means that the operator has to be able to explain after the fact why a particular action was taken with respect to a specific customer. The second is that the blast radius increases: while a defective recommendation affects only one reviewer, a flawed autonomous action can affect all the customers who match a given pattern before any detection takes place. The third point is that permissions are important in a manner that was never the case with a suggestion engine, since the acting system needs write access to the billing, plan, and consent records, and each of those access routes is a possible point of failure or an attack surface.
That is the reason why governance must not be delayed until after deployment; operators who regard the transition from suggesting to carrying out as being merely an upgrade of the model will find that it is in fact a change to the operating model.
From next best offer to next best action
The change is most easily seen in a simple example. A recommendation engine identifies a customer who is nearing a contract to end as likely to churn and recommends a retention offer to an agent. An agentic system would sense the same signal, choose the offer, check eligibility, apply the discount, send the confirmation and log the outcome, with no human in the loop. In the old days, a human would ingest each step: check consent, sanity-check the discount, notice context. Now each step must be an explicit, testable control in the system.
Why Human-in-the-Loop is a design choice, not a default
Many operators expect a human to be in the loop. In practice, the economics of automation drive toward eliminating that step for low-risk actions. So, the question of governance is what actions require a human checkpoint and what can run autonomously, and that decision should be made deliberately by impact rather than inherited by accident.
How does AI personalization change the telecom customer journey?
Telecom customer journey orchestration used to mean sequencing predefined steps: a welcome series, a renewal reminder, a retention call triggered by a churn score. AI-owned journeys are different because the sequence itself is decided in real time. The system chooses the channel, timing, offer, and next action based on the customer's current context, then adapts as the customer responds.
For telecom customer experience AI to work at this level, three capabilities must exist underneath. The system needs a unified, current view of the customer across mobile, broadband, and TV, because personalization built on a partial record produces confidently wrong actions. It needs a reliable way to execute decisions through governed APIs rather than bespoke scripts. And it needs a record of every decision detailed enough to reconstruct later. The first two are integration problems, and the third is a governance problem, and an operator that solves only the model layer will find the other two blocking production.
Why is telecom customer data consent to the first gate for autonomous AI?
Telecom customer data consent represents the first limit to autonomous personalization. Consent gathered for one function, like billing or service delivery, does not transfer automatically to another, such as cross-sell using AI across mobile, broadband, and TV. In the case of a human marketer, checking the consent was part of the process. With the AI solution, consent needs to be checked for every action based on the current preference state of the customer.
In other words, consent should be a dynamic property of the customer that can be queried, not an exportable flag delivered to the marketing platform on a daily basis. If the customer opts out of marketing consent at 9:00, the autonomous customer journey should not attempt to deliver an offer at 9:05, because the overnight synchronization has not occurred yet.
Three kinds of consent an acting system touches
Operators should separate the issues raised by an autonomous journey. There are three different things: permission to contact a customer, permission to use their data for profiling, and permission for the system to act on their account without a human confirming it. Mature journey design asks, each explicitly, before executing. Regulated operators should seek legal advice on the application of the UK GDPR, PECR and sector rules to their specific use cases, particularly where decisions are taken entirely by automated means.
Consent needs real-time synchronization
For AI-owned journeys, real-time propagation of consent changes to every system that can act on a customer is not an option. This is one of the best arguments for a single customer record – one authoritative source of truth that all channels and all agents read from, so a withdrawal is effective everyplace at once.
What does telecom data residency mean for AI-driven personalization?
Telecom service operators have data residency policies detailing where customer data must be stored and processed. While this may seem straightforward, the use of AI complicates matters because inference is categorized as processing. When customer usage, location, and account data are sent to a model in another jurisdiction, it may conflict with data residency laws, even though the information is never stored there. For companies using machine learning applications, any data run through a predictive model may be seen as transferring data across borders.
The emergence of sovereign AI technology, moving from discussions to reality, is demonstrated by BT and Nscale’s announcement in April 2023 that they will establish sovereign AI data centers in the UK, leveraging NVIDIA’s full stack AI infrastructure. This development will boost BT Business’ capabilities regarding sovereign technology. The goal is to create the ability for organizations to perform AI inference on UK land, satisfying in terms of regulations and data residency policies. Besides, BT Business states it is the first company in the UK to provide a comprehensive range of products, including telecom, cloud, and AI solutions.
The implications for personalization are simple. The largest UK operator investment in keeping AI workloads within UK-controlled infrastructure signals where regulated customers, and the regulators watching them, expect customer data to be processed by AI. Operators designing AI-owned journeys should assume residency will be examined, and should make where a model runs a configurable, auditable property rather than an accident of vendor choice.
Residency controls worth designing in
Companies should be able to identify the specific types of models that process different categories of consumer data within various jurisdictions and describe the contractual terms under which these models operate. Proof of this must be supported by logs. Anything that merely exists on paper without being represented in gateway systems is not going to stand up to scrutiny.
What is an AI audit trail, and why do regulated operators need one?
AI audit trail indicates that everything done by AI system will be kept in a clear and constant record of what AI has done, when, and for what reason. In the case of a recommendation engine, logging a recommendation that was made would usually be sufficient. Whereas for the acting system, everything has to be captured in logs, starting from the customer situation to the consent state, and ending with the action done, API calls taken, and results obtained along the way.
What does AI decision auditability require in practice?
AI decision auditability is the ability to answer a specific question from a regulator, an ombudsman, or an unhappy customer: why did your system do this to this person on this date? Answering it requires four things to be true at once:
- Every autonomous action is tied to an identifiable agent's identity, not a shared service account.
- The inputs to the decision, including customer attributes and consent state, are preserved as they were at decision time, not as they are now.
- The model version and configuration in force are recorded, because the same prompt on a different version can produce a different action.
- The API calls the agent made are logged and attributable, so the executed action can be reconciled against the intended one.
Without these, an operator can say what happened but not why, and "the model decided" is not an answer a regulated business can give.
Why reconstructing a decision is harder than logging it
Tracing back an output is straightforward. The challenge is that context changes: client documents are modified, agreements change, models trained again. A trail which only holds the final action cannot be used for replay. The principle is to take the snapshot of the decision context at the time of action, so that months later the operator can demonstrate what the system knew and was allowed to do.
How does AI identity and access management change for autonomous agents?
AI identity and access management entails the application of techniques already practiced by IT teams in granting access to users and entities to a new type of actor. An autonomous agent must be given a personal identity, define its permissions, and manage its lifecycle. In the case that agents are run under a wide-ranging shared service account, their actions would not be distinguishable in logs, and all breaches would potentially have major repercussions.
One of the principles involved in AI identity and access management is the application of the principle of least privilege at the stake of individual action. For example, the agent that generates personalized offers should be entitled to read plan and usage history data to prepare an offer for pending approval or apply for a discount. However, it should not be able to alter the provision of terms of the contract or close the account. Additionally, the permissions of the agent must be divided so that acting autonomously and acting on the instruction of a customer are taken into consideration since their risk profiles are different.
Here, we observe that management of the API infrastructure becomes intertwined with AI governance. An agent can only implement the procedures permitted by the APIs connected to it. If the infrastructure restricts access and either allows no access at all or fully implements it, no policy can protect the agent.
Wondering whether your customer records and API layer can support governed, auditable AI-driven journeys?
BT-EE unified customer record and CSAT resultsWhat does AI governance in telecom look like day to day?
While there are various dimensions to AI governance in telecom, in practice it boils down to a limited number of controls that can be implemented on a use-case basis at different stages of implementation. At design time, every autonomous use case (function) is classified according to potential impact on the customer, which informs whether and how permissions, human checks, or both, are built into the design. In operations, monitoring key performance indicators (offer acceptance rate, complaint rate, etc.) ensures that large-scale shifts in these metrics, which are often indicative of bias or errors in the autonomous functions, are addressed. Finally, the audit trail is critical to support post-hoc analysis of any incidents or regulatory inquiries.
Crucially, there must be accountable and has kill switches on each autonomous journey. In practice, I have seen operators that have charged AI journeys to their model teams exclusively fail to invest sufficiently in the integration, consent, and audit parts of the solution, where they are responsible for providing their tools and data. Good governance practices cut across the different functions and include product, data, legal, security, and engineering in the process, with explicit kill switches.
Why customer data governance in telecom comes before the model
Customer data governance telecom teams often find that the hardest part of AI personalization is not the model, but the data beneath it. Personalization quality, consent enforcement, and auditability all depend on a single, consistent, current customer record. When mobile, broadband, and TV each hold a partial record, an AI system either acts on incomplete information or stitches records together on the fly in ways that are neither reproducible nor auditable.
A governed customer data foundation provides a canonical definition of the customer, real-time propagation of changes including consent, clear lineage so every attribute can be traced to its source, and access controls enforced consistently. Only on that foundation can an operator let AI act with confidence, because the same record that powers the personalization also proves, later, that the action was permitted.
The unified customer record behind BT's EE super app
The BT-EE programme shows what this foundation looks like at national scale, and why it matters before any AI is asked to act.
Who
Acquired by BT Group in 2016, EE is the UK's leading mobile network operator and now acts as BT's flagship brand for consumer mobile, broadband and TV services.
What
BT launched the EE Super App and EE ID as the new "New EE" umbrella (BT + EE + Plusnet), shifting from traditional telecom to a subscription-led digital lifestyle brand with a unified customer experience.
How
Torry Harris (THIS) led an enterprise-wide integration transformation, aligning BT's roadmap with TM Forum's ODA framework and Open API standards, enabling a unified customer record and scalable digital journeys across sales and service.
Results
The EE Super App and EE ID platform delivered measurable customer and business impact:
The lesson for AI-owned journeys is direct. A unified customer record and standardized Open APIs are the preconditions for personalization that can be consented, executed, and audited. An operator with this foundation can let an agent act through governed interfaces and later prove what happened. An operator without it will be asking AI to act on fragments.
See how a unified customer record and standards-based APIs underpin scalable, governed digital journeys.
Read the full BT-EE case study from Torry HarrisWhat should telecom leaders put in place before AI owns the journey?
The sequence that follows is practical. Start by classifying the actions you intend to automate customer impact and keep humans in the loop for the highest-impact ones. Make consent a real-time attribute of the customer record, checked now of each action. Decide where AI inference is permitted to run and make that residency boundary explicit and enforceable. Give every agent its own identity with least-privilege permissions, backed by an API layer capable of enforcing them. Build the audit trail before launch, capturing decision context at the time of action so decisions can be reconstructed. And assign a named owner to each autonomous journey with the authority to pause it.
Operators that do this can move from recommending acting incrementally, expanding autonomy as evidence of safe operation accumulates. Operators that skip it tend to find out the cost when a regulator or a customer asks a question the system cannot answer.
Talk to Torry Harris about governed, auditable AI journeys
If your organization is moving from AI that recommends AI that acts, the readiness question is whether your customer record, consent model, and API layer can support autonomy you can later explain and defend. Torry Harris has built that foundation on the national telecom scale.
Assess your readiness for governed, auditable AI with Torry HarrisRelated Services
Related insights
ARTICLE
Why enterprise AI keeps failing, and it has nothing to do with your model
ARTICLE
Integrating BSS/OSS: The backbone of telco transformation
ARTICLE
AI-driven API management: Streamline, govern, connect
Case study
Three Ireland’s 48 disrupts the market with a unique digital experience
Frequently asked questions
Telecom companies use artificial intelligence (AI) to optimize networks, automate customer support, detect fraud, and predict equipment failures.
AI personalization uses machine learning and data analysis to deliver tailored content, product recommendations, and experiences to individual users in real time.
Artificial Intelligence (AI) is not a standalone communication medium like radio or telephone, but it functions as a powerful enabler and transformer of communication technology.
Artificial intelligence optimizes network operations, automates customer support, and enhances security across the telecommunications industry.
Artificial intelligence is transforming telecommunications by enabling self-optimizing networks, predicting service disruptions, and automating customer support.