# TRAI AI Guidelines: What the Telecom Draft Would Require

India's telecom regulator wants operators to account for the AI they buy as well as the AI they build, with a consultation open until November 27.

By Paras Madan | 2026-10-30


TRAI released draft AI guidelines on October 30 covering accountability, risk assessment and human oversight in telecom networks and services. The [consultation is open until November 27](https://www.trai.gov.in/draft-guidelines-responsible-use-artificial-intelligence-ai-telecommunication-networks-and). **These are proposals, not final rules taking effect today.**

For teams selling AI into telecom, the supplier provisions deserve attention. A working model would be only part of the purchase decision. Operators would also need evidence that helps them understand and supervise what they are buying.

## What TRAI proposes for telecom AI

The [official draft](https://www.trai.gov.in/sites/default/files/2026-10/Draft_CP_30102026.pdf) covers relevant licensed or authorised telecom entities using or planning to use AI. It proposes board-approved policies, high/medium/low system-risk categories, deployment approvals and an inventory of active, inactive and decommissioned systems.

Operators would assess new or modified AI before deployment, maintain human oversight and investigate incidents. Critical and high-severity incidents would be reported to TRAI. The draft does not specify a numerical reporting deadline in those clauses.

A governance and safety committee, led by a senior executive, would oversee implementation. Third-party procurement would involve due diligence and contractual provisions covering audits, compliance, incident management and accountability. The operator would remain accountable regardless of whether it built or bought the AI.

That last point changes the practical question in a procurement meeting. Asking whether a vendor can deliver a feature is different from asking whether the buyer can explain and investigate its behaviour after deployment.

## Why supplier contracts matter

Consider an operator buying a customer-service tool that recommends how to resolve complaints. The system might work well during a demonstration but fail on an unusual combination of account history and customer language. The useful evidence would be the input, the version used, its output and what happened afterwards.

This is an illustrative workflow, not an incident described by TRAI. It shows why an audit right is valuable only when the underlying product can produce something worth auditing. A contract cannot recreate logs that were never kept.

For AI vendors, a sensible product discussion would therefore include how failures can be reproduced, what information is available to the customer's investigators and which changes the supplier can make without obscuring earlier behaviour. Those are engineering and commercial questions, not simply a longer disclaimer on a model card.

**Buying AI does not remove the need to understand its failure modes.** It can instead make that understanding harder, because the operator and supplier each see only part of the system.

## Risk-based oversight has an implementation tradeoff

[Reporting on the proposal](https://www.fortuneindia.com/business-news/trai-proposes-board-approved-ai-policies-mandatory-reporting-of-serious-incidents-by-telcos-2/167781) highlights board-level policies and serious-incident reporting. Both sound straightforward until a team has to connect them to individual deployments.

A spreadsheet of approved models is not especially useful if it cannot identify the version currently operating in a service. Similarly, saying a human is in the loop does not explain whether that person can stop an action, how quickly they can respond or what information they receive.

These are implementation questions, rather than additional requirements in the proposal. They also explain the tradeoff in risk-based oversight. A lightweight writing assistant and an automated network-control system should not be assumed to need identical processes, but assigning the wrong risk category could leave consequential behaviour poorly supervised.

The consultation will be useful if it makes those boundaries clearer without turning every small software update into the same exercise as a critical deployment.

## What developers and vendors should watch next

The immediate milestone is the consultation deadline, not a new compliance launch date. Teams should distinguish the text under discussion from whatever final framework emerges.

For a supplier preparing its next telecom conversation, the more durable lesson is about product evidence. A benchmark explains performance on a defined test. A buyer also needs to understand how the product behaves when the inputs, users or surrounding systems change. Clear technical documentation can connect those two conversations, but it cannot substitute for evidence the product does not generate.

The strongest enterprise AI pitch may increasingly be one that explains not only what works, but how the customer will know when it stops working.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help teams explain complex enterprise AI products clearly, from technical capabilities to the operational questions their buyers need answered.

[Book a 30-minute call](https://cal.com/paras-madan/30min).