TRAI Draft AI Rules for Telecom: How AI Development Teams Must Classify, Inventory and Report Every AI System

TRAI’s draft AI rules for telecom require a board-approved AI policy, high/medium/low risk classification for every AI system, a complete AI inventory, and reporting of critical and high-severity incidents to TRAI. Comments close 27 November 2026, and the draft is not yet binding law.

AI development teams working with telecom operators in India now have a clear compliance build in front of them: TRAI’s draft guidelines on the responsible use of AI in telecom, released on 30 October 2026, require a board-approved AI policy, a risk classification for every AI system, a complete inventory of AI systems, and reporting of critical and high-severity AI incidents to the regulator. Stakeholder comments are open until 27 November 2026, and the draft is not yet a binding requirement — but the work it describes cannot be assembled in a week, so the operators and vendors who start now will be the ones who can file a credible policy when the final version lands.

Key highlights

• Status: draft guidelines under consultation, released 30 October 2026 — not yet binding law.
• Comments close: 27 November 2026.
• Who is accountable: the telecom entity, for every AI system it uses — in-house, third-party, or both.
• Risk classes: high, medium and low, with approval varying by class.
• Inventory rule: no AI system may be used unless it is inventoried, with source, purpose and risk class.
• Policy filing: board-approved AI policy filed with TRAI within 7 working days of taking effect, reviewed at least once per financial year.
• Incident grades: critical, high, moderate and low; critical and high incidents must be reported to TRAI.
• What the draft does not define: critical vs high severity, the incident reporting format or deadline, and a grievance resolution timeframe.

What is AI development, in one paragraph?

AI development is the process of building systems that learn from data, make predictions or decisions, and improve with feedback — for example, models that detect fraud, optimise a network, or answer customer queries. In telecom, AI development is not the draft’s target in general: the draft regulates how a telecom entity uses AI systems in its network and services, whether its own team built them or a vendor supplied them. That distinction is why the compliance work is mostly inventory, classification, testing evidence and governance, rather than model training alone.

This is not a general AI ethics statement. It is an operating system for AI in a regulated network: who approves a system, how risky it is, where it is recorded, how it is tested before deployment, what happens when it fails, and who answers for it when a third party built it. If your team builds, buys, or runs AI for a telecom operator, a network provider, or a vendor selling into telecom, this draft changes your delivery checklist.

What did TRAI actually propose on 30 October 2026?

The Telecom Regulatory Authority of India (TRAI) released draft guidelines on the responsible use of artificial intelligence in telecommunication networks and services, and invited public comments. The draft rests on the Government of India’s India AI Governance Guidelines of February 2026, built on seven sutras: Trust is the Foundation, People First, Innovation over Restraint, Fairness and Equity, Accountability, Understandable by Design, and Safety, Resilience and Sustainability. Its authority is cited as Section 11(1)(b)(v) of the TRAI Act, 1997, covering quality of service standards and consumer protection.

The framework applies to entities holding a telecom service licence or authorisation, and to entities authorised to establish, operate, maintain or expand telecom networks, if they use or intend to use AI. That scope matters: it reaches operators, network providers, and — through vendor duties — the companies that supply AI embedded in telecom equipment and software.

Who is accountable when AI fails in a telecom network?

The operator is. The draft states that a telecom entity shall be accountable for the outcome of all AI systems it uses, whether developed in-house, procured from a third party, or a combination of both. Buying a model, a chatbot, a fraud-detection system, or an AI feature inside network equipment does not transfer accountability to the vendor.

That single rule drives the rest of the draft. If you are accountable for a system you did not build, you need its inventory entry, its risk class, its approval, its test evidence, its vendor disclosures, and its incident record — before it goes live, not after it fails.

What must a board-approved AI policy contain?

Each operator must adopt an internal AI policy approved by its board or equivalent body, covering risk classification, approval for use, incident classification, human oversight, data governance, and consumer protection. The policy must be reviewed at least once every financial year and filed with TRAI within seven working days of taking effect, along with any amendments.

In practical terms, a policy that only says “we use AI responsibly” will not meet this draft. It must name the classification method, the approval authority by risk class, the incident grades, the oversight mechanism, the data rules, and the grievance route — and it must be a living document with a review cycle, not a one-time PDF.

How must AI systems be classified — high, medium or low risk?

Every AI system must be rated high, medium or low risk, based on its significance to network operations and service delivery, its impact on financial and operational outcomes, and its potential implications for consumers. A system can be used only after approval by a designated officer, with the level of approval varying according to its risk classification.

For an AI development team, this means risk classification is a design input, not a compliance afterthought. A spam-detection model that flags billions of calls, a customer-identification system, a fraud-prevention model, and a network-optimisation system do not carry the same risk, and they should not carry the same approval path. Build the classification into the project kickoff: what does this system touch, what breaks if it is wrong, who is affected, and who signs it off?

What is the AI inventory, and why does “no entry, no use” matter?

Operators must maintain an up-to-date inventory of all active, inactive and decommissioned AI systems, recording their source, purpose and risk class. No system may be used unless it appears in that inventory.

This is the hardest requirement for most organisations, because AI sprawls: a model in a vendor’s platform, a feature toggled on in a SaaS tool, an experiment that became production, a legacy script nobody owns. The inventory forces a single register with an owner for every system. If your team cannot list every AI system in production today — including embedded AI in purchased equipment — that gap is now the first deliverable, before any new AI work.

What testing is required before an AI system is deployed or changed?

Before deploying a new AI system or modifying an existing one, companies must undertake validation, conformity and impact assessments covering accuracy, robustness, explainability, fairness and resilience to model drift, plus human oversight. For fairness, the draft points to TEC standard 57050:2023 or an applicable international standard.

That list is a test plan, not a slogan. Accuracy on what data, robustness against what inputs, explainability to whom, fairness across which groups, drift measured how often, and human oversight exercised where? A deployment checklist that answers those six questions, with evidence kept on file, is what conformity assessment looks like in practice.

What due diligence is required before buying third-party AI?

Before buying AI from third parties, operators must assess the supplier’s credibility, the system’s soundness and limitations, and the quality of training data. They must obtain disclosures from suppliers when buying equipment or solutions with embedded AI, and supplier agreements will need enforceable clauses on audit and inspection rights, incident management, risk allocation and accountability.

For vendors, this is a sales requirement as much as a compliance one: if you cannot provide a soundness and limitations note, training-data quality information, and an incident-management commitment, an operator following this draft cannot responsibly buy from you. Prepare that pack before the procurement conversation, not during it.

How must AI incidents be recorded and reported to TRAI?

Companies must maintain a central database of AI incidents, classify them by severity — critical, high, moderate or low — follow predefined standard operating procedures to address disruptions, and investigate and mitigate them. Critical and high-severity incidents, including material malfunctions and recurring failures, must be reported to TRAI.

Two honest limits in the draft, reported by ThePrint, must not be smoothed over: the draft does not define what counts as a critical- or high-severity incident, and it does not set out the reporting format or deadline — those will be prescribed. Each operator will define its own incident categories in its internal policy. So do not promise a client a TRAI reporting deadline that the draft has not given. Build the incident database, the severity definitions, and the SOP now, and leave the reporting format as a configurable template that can be updated when TRAI prescribes it.

What governance structure must sit above all of this?

Each entity must establish an AI Governance and Safety Committee with board approval, including representation from network operations, service delivery, information technology, data management, regulatory affairs and consumer affairs. It will be headed by a senior executive designated as the AI Governance and Safety Officer. The committee will review AI system performance at least once every financial year and identify vulnerabilities, weaknesses in oversight, fairness concerns and emerging risks.

That committee needs a working rhythm, not just a charter: a quarterly or half-yearly review of the inventory, the incident database, the drift and fairness evidence, and the vendor register, feeding into the annual policy review. Without that rhythm, the committee is a name on a policy page.

What about human oversight, data and consumer complaints?

The draft requires a predefined human-oversight mechanism covering all AI systems, lawful and secure collection, use, sharing and disposal of data across the AI lifecycle in line with privacy, confidentiality and cybersecurity rules, and a consumer grievance mechanism through which user-reported AI harms are resolved within a reasonable time. The same boundary applies in other regulated operations: an AI agent flags, a human decides — see how AI development warns a dairy plant before a milk-quality batch fails, where the agent never auto-rejects supplier milk or files regulatory reports unsupervised.

Note the same honesty as with incident reporting: the draft does not specify what that “reasonable time” is. Do not invent a service-level deadline in a client policy. Define the grievance route, the triage owner, and the escalation path, and set your own internal target explicitly as your own target, not as TRAI’s rule.

What should an AI development team build first?

Use a 30-day pilot with measurable outcomes before a plant-wide or network-wide rollout — the same pilot pattern used for AI development monitoring of solar inverters, where detection is proved on one block before scaling.

If you are starting from zero, build in this order, because each step unlocks the next:

1. Inventory sprint (2–3 weeks): list every AI system in production, in pilot, and embedded in purchased tools, with source, purpose, owner and current risk guess. Retire or formally decommission the systems nobody owns.
2. Risk classification framework: a one-page scoring method for network significance, financial impact and consumer impact, with approval authority by risk class. Apply it to the inventory, highest-risk first.
3. Board policy draft: classification, approval, incident grades, human oversight, data governance and grievance route, written so it can be filed with TRAI within seven working days of taking effect.
4. Incident database and SOP: central log, severity definitions, mitigation steps, investigation owner, and a TRAI reporting template ready to be completed when the format is prescribed.
5. Vendor pack: due-diligence checklist, disclosure request, and contract clauses for audit, inspection, incident management and accountability, applied to every new purchase and, over time, to renewals.
6. Pre-deployment assessment template: accuracy, robustness, explainability, fairness (TEC 57050:2023 or an applicable international standard), drift resilience and human oversight, with evidence stored against the inventory entry.
7. Governance committee calendar: membership, an AI Governance and Safety Officer, and a review cycle that feeds the annual policy review.

That sequence is also the right response to the consultation window. Comments close on 27 November 2026, and a separate MeitY consultation paper on AI regulation is expected in the first week of November. Teams that can comment from experience — because they have already inventoried and classified their systems — will write stronger submissions than teams commenting from theory.

What does this draft NOT do?

It does not create a new AI law, it does not define critical and high severity, it does not prescribe the incident reporting format or deadline, and it does not specify a grievance resolution timeframe. It also does not remove the underlying tension noted in coverage of the draft: MeitY has said it is not regulating AI as such, relying on existing laws and sector regulators, while TRAI’s draft uses “shall” throughout. Treat the draft as a sector regulator setting concrete operating duties under existing telecom law, not as a voluntary framework — and expect the consultation to test exactly that boundary.

Frequently asked questions

Does TRAI’s draft AI framework apply to every company using AI in India?

No. It applies to entities holding a telecom service licence or authorisation, and entities authorised to establish, operate, maintain or expand telecom networks, if they use or intend to use AI. Other sectors are governed by their own regulators and existing laws, with MeitY’s broader AI governance guidelines as the voluntary backdrop.

When do stakeholder comments close?

27 November 2026, according to coverage of the draft. Comments should be filed through TRAI’s consultation process for this draft, not through a general feedback form.

Must a telecom operator file its AI policy with TRAI?

Under the draft, yes — the board-approved internal AI policy, and any amendments, must be filed with TRAI within seven working days of taking effect, and reviewed at least once every financial year.

Can an operator use an AI system that is not in its inventory?

No. The draft states that no AI system may be used unless it appears in the up-to-date inventory of active, inactive and decommissioned systems, with source, purpose and risk class recorded.

Who is responsible if a third-party AI system fails?

The telecom entity using it. The draft makes the operator accountable for the outcome of all AI systems it uses, whether built in-house, procured from a third party, or a combination of both — which is why vendor due diligence and contract clauses matter.

What must be reported to TRAI when an AI incident happens?

Critical and high-severity incidents, including material malfunctions and recurring failures, must be reported to TRAI, with the incident recorded in a central database, classified, investigated and mitigated under a standard operating procedure. The draft does not yet define critical/high severity or prescribe the reporting format and deadline, so those details must be tracked as they are prescribed.

The bottom line

TRAI’s draft does not ask telecom operators to stop using AI. It asks them to prove, system by system, that they know what AI they run, how risky it is, who approved it, how it was tested, what happens when it fails, and who answers for it. That proof is a buildable system: inventory, classification, policy, incident database, vendor pack, assessment template, and a governance committee with a calendar. Start with the inventory, file a policy you can actually operate, and use the consultation window to 27 November to comment from evidence, not from intention.

Sources and further reading

• TRAI consultation page — Draft Guidelines on Responsible Use of AI in Telecommunication Networks and Provision of Telecommunication Services, released 30 October 2026
• ET Telecom (31 Oct 2026) — TRAI proposes board-approved AI policies, risk classification and mandatory incident reporting for telcos
• ET Now (30 Oct 2026) — TRAI draft AI guidelines for telecom: key rules explained

Sources: TRAI draft guidelines as reported by ET Telecom (31 Oct 2026), Free Press Journal (31 Oct 2026), ThePrint (31 Oct 2026) and ET Now (30 Oct 2026); India AI Governance Guidelines, February 2026. This article summarises a draft under consultation, not a final regulation, and does not constitute legal advice — operators should confirm filing and reporting duties with legal counsel when the final guidelines are published.