AI Governance for Telecom

AI governance for a telecommunications operator should define what an assistant may know, recommend, communicate and change on a subscriber account. These are different permissions. A tool that explains an approved retention offer needs a different decision boundary from one that applies a billing credit, changes a package or influences a complaint outcome.

For Saudi telecom leaders, the practical starting point is the customer journey and its accountable service owner. Identify the source of offer eligibility, the authorised account holder, the financial action and the route for disputed information. Then give each permission an owner, evidence requirement and withdrawal mechanism. The following operating design uses a fictional retention assistant; it is not an account of an actual operator deployment.

Separate commercial assistance from account authority

A retention objective does not define the assistant's authority. “Help keep customers” could mean summarising service history, recommending an eligible offer, making a contractual commitment or crediting a bill. Treat those as separate activities in the use-case register. The business sponsor should explain which outcome is being sought and which actions remain outside the approved scope.

Draw the boundary at each material consequence. A customer-service adviser may review a suggested response but lack authority to approve an exceptional credit. A supervisor may approve a credit but lack permission to disclose usage details to a caller. A tool administrator may configure the interface but have no right to change commercial eligibility. Document these distinctions before connecting the assistant to account actions.

Suggested authority boundaries for a retention assistant

Activity	Decision owner	Evidence before use
Explain published package terms	Product owner	Current approved terms and effective dates
Suggest an account-specific offer	Commercial policy owner	Eligibility result from an authorised source
Apply a billing credit	Delegated financial authority	Permitted reason, amount and transaction confirmation
Handle a disputed charge	Complaint process owner	Case reference and applicable review route
Change service or contractual terms	Authorised service process	Verified account authority and required acceptance record

Use this map to configure access rather than merely attach it to a presentation. The broader decision-rights framework explains how to record delegations, deputies and escalation when a request crosses an approval boundary.

Connect Saudi obligations to the actual service

The Communications, Space and Technology Commission's telecommunications bylaw addresses user-information confidentiality and purpose specification in Article 58, and complaint handling in Chapter IX. These provisions make the operator's information and customer-treatment responsibilities relevant to AI-assisted service. Confirm the applicable licence, current instruments and particular activity through the compliance owner; an AI feature does not replace the underlying service obligations. Read the official CST bylaw.

Translate that applicability review into operational questions. What data may the assistant access for this purpose? Which customer statements require an authoritative source? Which complaints must leave the retention conversation? What evidence must the operator preserve, and through which existing process? Keep those conclusions in the obligations register with their source and review owner. Avoid inventing an “AI approval” that purports to settle every telecom, privacy and contractual requirement at once.

Verify who can speak for the subscriber account

The person using a service, paying an invoice and holding contractual authority may not be the same person. A family member may know the telephone number and recent bill amount without being authorised to change the package. An employee may use a corporate line while procurement controls the contract. The assistant should receive an explicit result from the established identity and authority process, not infer permission from a convincing conversation.

Make the result narrow enough to be useful: identity verified, permitted account, allowed action and any expiry or further check. Do not send more identity evidence to the model than its task requires. If the caller changes from a general enquiry to a financial or contractual action, the workflow should evaluate the new action's requirements instead of treating the first verification as unlimited permission.

Design handover language for uncertainty. “The account requires an authorised representative for this change” is a service-process outcome. A generated accusation that the caller is fraudulent is a different and unsupported conclusion. Staff should see why the action is blocked and how to continue through the approved route without exposing another person's account information.

Worked example: an offer assistant gains a credit button

Imagine an operator initially approves an assistant to explain retention options to advisers. It reads an approved offer catalogue and receives an eligibility result. Advisers decide what to discuss. The product team then proposes an automatic credit button to reduce handling time. Although the interface change appears small, it introduces financial execution, duplicate-action risk and a need to reconcile what the customer was told with what the billing system recorded.

The change request should describe the new action, not label it a usability improvement. In this illustrative design, a credit needs an approved reason, current account eligibility, a permitted amount, a unique transaction reference and a confirmation from the billing system. Free text generated by the assistant cannot create a new credit reason or enlarge a financial limit. Exceptions follow a separately authorised process.

Before releasing the change, assemble 40 synthetic scenarios: 16 eligible requests, eight unmet eligibility conditions, six disputed charges, six repeat requests and four requests from people without the required account authority. Each scenario has an expected action and message. The total is a deliberately small rehearsal set, not a statistically representative claim about performance or a regulatory minimum.

A repeated request is especially revealing. If the first credit succeeded but its response was delayed, retrying must not silently create a second credit. The adviser should see the earlier transaction status and the permitted next step. A pass requires the business result and customer explanation to agree; a plausible answer alone is insufficient.

Keep offer eligibility independent from persuasive language

The assistant's ability to write an attractive message should not determine whether a customer qualifies. Use an approved eligibility service or controlled rule set for that decision. Record the offer identifier, version and decision time. The model may explain the result using authorised wording, but it should not fill missing conditions with a guess or promise an exception because the customer seems likely to leave.

Include the full lifecycle of an offer. What happens when its expiry time passes during a conversation? What if a customer received an offer before a package change? Which source wins when a cached description differs from the current catalogue? The commercial owner should specify whether to refresh the check, preserve a valid earlier commitment or refer the case. That answer belongs in service policy, not in an improvised prompt.

Arabic and English explanations need the same commercial meaning. Check duration, recurring charges, one-time adjustments, exclusions and the distinction between a proposal and an accepted change. A fluent Arabic response can still misstate whether a discount applies to the next bill or to every future bill. Review these differences through concrete examples with commercial and customer-service staff.

Protect complaint handling from retention incentives

A disputed charge is not simply a retention opportunity. The customer may need an investigation or correction regardless of whether they accept another offer. Give the assistant a clear route into the existing complaints process and preserve the original issue. Do not train the operational scorecard to treat a retained customer as proof that their complaint was resolved.

For example, an adviser can offer an authorised goodwill adjustment while a disputed usage item remains under review. The records should distinguish those events. Otherwise an adjustment may be incorrectly treated as acceptance of the original charge, or a complaint may be closed because the account stayed active. The complaint owner should determine the approved wording and closure evidence for this situation.

Measure whether users can reach the appropriate process without repeatedly describing the same problem. Review transfers that end without a case reference, complaints incorrectly labelled as sales enquiries and reopened issues after an apparently successful offer. These observations expose workflow failures that an overall satisfaction score can hide.

Reconcile messages, transactions and account state

Design a three-part reconciliation record: the action approved, the action attempted and the result confirmed by the system of record. A drafted message is not confirmation that a package was changed. A successful technical response is not sufficient if it relates to the wrong account or expired authorisation. Link the records through a stable case and transaction identifier.

Give unresolved results a visible queue. If the billing connection fails after an action was submitted, the assistant should not promise success or automatically repeat a financially consequential request. The designated operations team checks the authoritative status and communicates the outcome. Define the customer-facing holding message, the owner of the unresolved item and the escalation condition.

Test the reconciliation during normal release acceptance and after supplier changes. Include slow responses, out-of-order events, cancelled requests and duplicate clicks. Record the expected customer treatment for each. These tests belong to business governance because they determine whether the operator honours, repeats or contradicts a commitment, even when the underlying engineering team implements the safeguards.

Set supplier access around support tasks

Separate the AI provider's processing from access by support personnel, analytics tools and subcontracted contact-centre operations. A service agreement should identify who can inspect which records, for what support purpose and under what authorisation. Broad troubleshooting access can defeat an otherwise careful assistant design if full subscriber conversations become the default attachment to every support ticket.

Ask for a demonstration of a support incident using masked or synthetic material. Where production access is necessary, specify approval, duration, scope and logging. Request evidence of how access ends and how retained troubleshooting copies are handled. Commercially sensitive tariffs, network information and personal information may require different treatment; a single “confidential” label is too vague for the operator managing the incident.

The third-party AI risk questionnaire should also cover changes to model behaviour, subcontractors, data use and action capabilities. A routine product update that enables a new tool can change the operator's authority boundary even if the user interface appears familiar.

Evaluate customer treatment across practical differences

Build evaluation slices around conditions that alter the service outcome: individual and corporate accounts, Arabic and English conversations, interrupted identity checks, an expired offer, a dispute mixed with a sales request, and a caller acting for someone else. Keep the purpose of each slice explicit. You are testing whether equivalent authorised requests receive appropriate treatment, not inferring sensitive attributes from voice or wording.

Assess factual correctness and process correctness separately. A response can quote the right package price yet fail by sending it to an unauthorised person. A credit can be financially correct yet fail because it was repeated. A complaint can reach the right team yet fail because the assistant omitted the customer's central allegation. Review these failures with the owner capable of changing the relevant process.

Set acceptance criteria before comparing vendors or versions. Include zero-tolerance conditions for specified prohibited actions where justified by the operator's risk decisions, together with realistic targets for less consequential drafting errors. Report sample size and limitations. Do not turn a small rehearsal success into a claim that the assistant is safe for every language, account type or transaction.

Use monitoring to change permissions when evidence changes

A useful dashboard connects an observation to a decision. Rising unresolved transactions may justify temporarily removing the credit action while retaining explanation features. An expired catalogue feed may require suppressing offer suggestions until the source is restored. Repeated unauthorised disclosures may require broader restriction and incident review. The owner should know who can make each change and how customer service continues.

Track false promises, inappropriate complaint closure, duplicate financial actions, authority-check failures and the age of unresolved items. Add volumes and denominators so a rate can be interpreted. Segment by approved workflow version where helpful. Review adviser overrides to distinguish sound challenge from habitual workarounds that indicate the process is unusable.

Connect significant events to incident response and recovery and routine observations to governance reporting. Neither a monthly report nor a model-quality score replaces an immediate operating decision when a customer-impacting boundary has failed.

Preserve a commitment when the customer returns

A callback can test a different boundary from the original conversation. The customer may refer to an earlier offer after its catalogue entry has changed, while the new adviser sees only a generated summary. The workflow should distinguish what was discussed, what was actually accepted and what was confirmed in the account record. A summary should not silently turn a proposal into a commitment or erase a valid commitment because the current offer differs.

Design a commitment reference that links the approved terms, relevant acceptance record and transaction status. The responsible commercial and service processes determine how a prior commitment is treated; the assistant retrieves the relevant evidence and explains the authorised result. If evidence conflicts, it should route the question rather than negotiate a replacement arrangement on its own authority.

Rehearse a callback after an interrupted transaction and another after an offer catalogue update. Ask the adviser to identify the applicable record, the unresolved question and the owner who can resolve it. Include a customer who quotes a draft that was never sent, so staff can distinguish an internal proposal from an actual communication. The exercise exposes the risk created by retaining summaries without their status.

Record the resolution in the case used by future advisers. Otherwise each callback restarts the same disagreement and may produce a different promise. Link any authorised correction to the original communication and account action, preserving the relevant history under the operator's information controls. The aim is continuity of accountable service across conversations.

Build the telecom governance handover around a live journey

Use one complete retention journey to demonstrate readiness: a verified account, a current offer, a disputed item, a permitted financial action and an unresolved technical result. Ask the service owner, commercial owner, compliance team and operations team to describe their decisions from the same record. Any disagreement about who may promise, approve or close an action is an unresolved governance issue.

The handover should contain the approved scope, authority map, offer-source owner, identity interface, complaint route, supplier access conditions, evaluated cases and permission-withdrawal procedure. Give each dependency an operating owner after the project team leaves. A polished policy cannot compensate for an eligibility feed that nobody maintains or an exception queue that no team accepts.

For wider application context, see Trusted's telecommunications AI overview. For the operating structure around an actual project, use OpenForAI's AI governance setup service and discuss the subscriber actions, approvals and evidence your telecom use case requires.