Cover image: AI-generated conceptual illustration, not a photograph of the reported event.

Updated 2 November 2026. India’s discussion about artificial intelligence in telecom has a concrete document to examine. The Telecom Regulatory Authority of India released draft guidelines on 30 October, with stakeholder comments invited until 27 November. As of this update, the consultation is open; the proposals should not be described as a completed change to every customer’s service.

What the draft proposes

The official consultation paper sets out an internal AI policy approved by an operator’s board or equivalent body. It proposes classifying AI systems by risk, obtaining designated approvals before use, maintaining records of incidents and providing human oversight. It also addresses data governance and consumer grievances.

The draft distinguishes critical and high-severity incidents from lower-severity events, with reporting to TRAI envisaged for the more serious categories. These are proposals in a consultation document, not a claim that a new consumer compensation process is already operating.

Why it matters beyond a chatbot

A useful way to assess telecom AI is to ask which decision it influences. A system that suggests wording for a support message raises different operational questions from one that changes a network configuration. That comparison is an explanatory example, rather than a statement about a particular operator’s deployment.

For a customer, the practical question is whether a decision can be explained, challenged and escalated. For an operator, it is who owns the decision when an automated system behaves unexpectedly. A polished demonstration alone answers neither question.

A checklist for reading the consultation

  • Identify the proposed scope before assuming that every AI application is covered.
  • Separate the draft’s requirements from controls an operator already uses.
  • Ask how a user would reach a human when disputing an AI-related outcome.
  • Look for clear ownership of testing, approvals and incident follow-up.

Businesses responding to the consultation can make feedback more useful by describing one concrete workflow, the harm that could arise and a control that could be checked in practice. General promises of responsible AI are harder to evaluate.

Read the TRAI consultation page for the current deadline and submission instructions. For related reading, see our AI agent security checklist.

Work through one hypothetical AI decision

Imagine an operator testing a system that recommends how to respond to a sudden increase in customer complaints. Before assessing the recommendation, the team could document the input, the intended task, the person responsible and the consequences of a wrong answer. This is a hypothetical review exercise, not a description of any named telecom company’s systems. It makes an abstract discussion about oversight easier to examine.

The first question is whether the input actually represents the problem. A cluster of complaints may reflect a network fault, a billing misunderstanding or several unrelated events. A confident summary should not close the investigation. The reviewer can compare the proposed explanation with independent operational evidence and record where the evidence is incomplete. A process that rewards a fast answer without checking it can hide uncertainty from the people making the final decision.

Design a useful incident record

A practical incident worksheet could include the time, affected workflow, observed behaviour, immediate response and the person assigned to follow up. Add a separate field for what remains unknown. Keeping observation separate from interpretation prevents an early guess from turning into an accepted explanation merely because it has been copied into several reports. These worksheet suggestions are editorial examples; consult the actual draft for the proposed regulatory requirements.

For example, “the system returned the wrong customer category” is more specific than “AI failed.” A second entry can explain the suspected cause, while a third records whether that cause was confirmed. The record becomes useful when another reviewer can reconstruct the sequence without needing the original operator to remember every step. Include how the outcome was checked after the immediate problem was addressed.

What a consumer can record when seeking help

If you believe an automated decision affected your service, write down what happened, when it happened and the explanation you received. Keep the reference number and relevant messages. Ask a focused question, such as which information would allow a human reviewer to reconsider the outcome. Share only the information needed for the complaint through the provider’s official channel; publishing account identifiers in a public discussion does not help establish the underlying issue.

A response is easier to evaluate when it answers the actual question. If the issue concerns a specific charge, a general description of the company’s AI strategy is not a resolution. Conversely, a customer may not be able to determine from the outside whether AI was involved at all. Describe the observable problem without assuming a technical cause that has not been established.

Questions for the next update

When the consultation moves forward, compare the next official document with this draft rather than treating every proposal as unchanged. Check the scope, the status of the document and any specified implementation arrangements. A stakeholder can keep a simple change log showing the original proposal, its response and the later wording. This makes it possible to explain what changed without presenting a consultation deadline as a service-launch date.