India opened AI telecom rules for comment. Publish the network risk register

THE SIGNAL IN ONE SENTENCE

A telecom network is a bad place to discover that nobody wrote down where the AI lives. One model predicts equipment failure. Another hunts fraud. Another decides which customer complaint needs attention. Another adjusts network resources while millions of people are using the thing. Then a system drifts, a supplier pushes an update or an automated rule treats a neighborhood like a suspicious pattern. Everybody agrees that an AI system is involved. Nobody can immediately name its owner, version, risk class, training limits, connected data or the person allowed to stop it. That is not a clever network. It is a cupboard full of unlabeled switches. India's Telecom Regulatory Authority released draft guidelines on October 30 for the responsible use of AI in telecommunication networks and services. The consultation remains open through November 27, so these are proposals rather than final, binding requirements. The proposal is unusually concrete. It would apply to authorized entities using or planning to use AI in telecom networks, telecom services or both. Each covered organization would need a board-approved internal AI policy. Every AI system would be classified as high, medium or low risk based on its significance to the network or service, its financial and operational effects, and its possible consequences for consumers. Every incident would also receive a severity class: critical, high, moderate or low. The organization would keep an up-to-date inventory of active, inactive and decommissioned AI systems. Each entry would include the system's source, purpose and risk classification. An AI system could not be used unless it appeared in that inventory. That last sentence is the signal. You cannot govern the model somebody forgot to list. TRAI's draft goes further. Before a new AI system or a modification enters service, the operator would need validation, conformity assessment and impact assessment. The conformity work would cover accuracy, robustness, explainability, fairness, resilience to drift and human oversight. Third-party systems would require due diligence on the supplier, the soundness and limitations of the system, and the suitability and quality of training data. Supplier agreements would need enforceable provisions covering compliance, audit and inspection rights, incident management, allocation of risk and accountability. The operator would need a central database for AI incidents, including problems found during testing. It would also need a central database for reports of AI-related harm to telecom users and the resolution of those reports. Critical and high-severity incidents would be reported to TRAI in a prescribed form, manner and timeframe. An AI Governance and Safety Committee would oversee the policy, with representation from network operations, service delivery, information technology, data management, regulation, consumer affairs and other relevant business functions. A senior executive would serve as AI Governance and Safety Officer. The organization would remain accountable for outcomes whether the AI was built internally, purchased from a supplier, outsourced or assembled from all three. This is not a vague request to "use AI ethically." It is an operating model. The draft connects the model inventory to approval, testing, contracts, incident response, consumer complaints, training, governance and records. It recognizes that telecom AI is not one product category. It can sit inside a network, a customer service, a security process, a billing workflow or a piece of purchased equipment. The useful next step is to publish a public version of the network risk register. Not the source code. Not the attack surface. Not a dump of customer complaints or security logs. A public register should tell people which important AI systems affect the services they depend on, what those systems are allowed to do, who is accountable and what happens when they fail. The draft requires an internal inventory but does not say that the inventory itself must be public. That is a meaningful limitation, especially when AI can influence essential connectivity, fraud intervention, service quality and the handling of consumer grievances. An internal register helps the operator and regulator find the system. A public register helps the customer understand the service. Start with a plain name and purpose. "Network optimization model" is not enough. Does it predict congestion, allocate radio resources, recommend maintenance, change routing or take an automated action? Which part of the service can it affect? Is it used nationwide, in selected circles, inside a pilot or only during testing? Then state the decision boundary. Does the system advise a person, make a reversible change automatically or trigger a consequential action without prior review? Can it suspend service, flag suspected fraud, prioritize a complaint, set an appointment, alter a bill or direct a technician? The public does not need a mathematical lecture. It needs to know whether the machine whispers, recommends or acts. Add the risk class and the reason for it. TRAI proposes high, medium and low classes based on materiality. A public entry should explain the materiality in ordinary language. A system can be high risk because it touches critical network functions, affects many people, changes an essential service, processes sensitive data or can cause financial and operational harm. Do not turn the classification into a colored badge with no explanation. State the harm being managed. Add the accountable owner. The draft distributes responsibility across a board, designated officers, an AI Governance and Safety Committee and a senior AI Governance and Safety Officer. The public register should name the responsible organization, the business function and a contact route with authority to investigate. A generic help desk is not an accountability chain. Add the human control. The draft requires appropriate human oversight based on risk. The public entry should say when a person reviews the output, who can intervene, what can be paused, how quickly a serious action can be reversed and what service remains available if the AI is taken offline. "Human in the loop" is not a control description. It is a seating chart. The register needs the job, authority and timing of the human. Add the evidence date. TRAI proposes validation, conformity assessment and impact assessment before deployment or modification. Publish when the last assessment occurred, which version it covered, what conditions were tested and when it expires or must be repeated. Do not publish a score without the test boundary. An accuracy figure from ordinary daytime traffic does not prove resilience during a disaster, a major festival, a rural outage or a coordinated attack. A fairness result on one customer dataset does not prove that another language, region, disability or payment pattern is treated properly. The register should say what was not tested. Add the supplier boundary. Telecom equipment can arrive with embedded AI. A cloud service can change beneath an operator. A fraud product can depend on outside data, subcontracted models and proprietary rules. The draft correctly says the authorized entity remains accountable regardless of who built the AI. Public entries should therefore name the supplying organization where disclosure is safe, identify whether the operator can inspect and audit the system, and state which changes require a new assessment. If a supplier can update the model without the operator knowing what changed, the inventory is already stale. Add the incident summary. TRAI proposes a central incident database and reporting of critical and high-severity incidents. A public register should include aggregate counts by severity and harm type, the date of the most recent serious incident, whether customers were notified, whether the system was modified or removed, and whether unresolved harms remain. There are good reasons to protect technical details during an active security investigation. There are not good reasons to pretend nothing happened forever. The publication threshold can be designed around safety. Delay sensitive details, remove exploit instructions, protect personal data and coordinate with incident responders. Still publish the existence, scope, consumer impact and corrective action once disclosure no longer creates an unreasonable risk. Add the grievance route. The draft says AI-related harms reported by users should be resolved within a reasonable timeframe through a predefined mechanism. That phrase needs a clock. Customers should know how to identify an AI-related problem, what information to submit, how quickly the operator must acknowledge it, when a human will review it, how to appeal and when the complaint can be escalated to TRAI or another authority. The complaint should be linked back to the system inventory. Otherwise the customer says, "Your automation cut my service," and the operator's case system files it under "general dissatisfaction." The register also needs change history. TRAI proposes annual review of the internal policy and annual review of each system's risk categorization, with additional reviews after incidents. Annual review is a floor, not a useful cadence for every live system. Models, data, thresholds, suppliers and network conditions can change weekly. Every public entry should show the current version, last material change, reason for the change, assessment completed and next review date. Decommissioned systems should remain in the archive long enough to support complaints, investigations and learning. Do not erase the old switch label after it sparks. This public layer would help people outside India too. Telecom regulators around the world are confronting the same awkward fact: AI is entering infrastructure through many doors. It arrives in network management, customer support, cybersecurity, procurement, analytics and equipment firmware. A sector-specific inventory can reveal those doors more effectively than a general-purpose list of "AI use cases." India's draft also joins technical testing to organizational accountability. That matters. A robust model can still be dangerous inside a bad approval process. A fair classifier can still cause harm if nobody reviews complaints. An explainable system can still become unaccountable if the supplier contract blocks inspection. A trained oversight team can still fail if it cannot pause the service. The AI register should therefore be read as a living control surface, not a museum catalog. Each entry connects six things: The system. The decision. The risk. The person. The evidence. The remedy. If one is missing, the register has found useful work. There are cautions. The consultation is still open. The final guidelines may change. The draft does not yet provide the reporting forms, exact deadlines for serious incidents or the detailed criteria that separate critical from high, moderate and low severity. It also uses several phrases that will need consistent interpretation, including "reasonable timeframe," "appropriate human oversight" and "where appropriate." Operators can implement those phrases well or turn them into decorative compliance. The proposal calls for records and databases, but more data collection does not automatically produce better protection. Incident records and harm reports may contain sensitive customer, network and security information. They need access controls, retention limits, audit logs, privacy review and reliable links to correction and deletion rights. The AI Governance and Safety Committee can become a serious cross-functional control or a quarterly meeting where every slide is green. The difference will be evidence. How many unlisted systems were discovered? How many deployments were delayed after assessment? How many supplier contracts changed? How many incidents reached customers? How long did grievances take? How many systems were modified or decommissioned? What did the operator learn across regions and languages? Those are the measurements a regulator, board and public can use. TRAI is asking stakeholders to comment by November 27. The consultation page says comments will be published only after site-administration approval. The draft itself also provides an email route for written comments. That process should produce more than broad support or rejection. Consumer groups can ask for public inventory fields and complaint deadlines. Operators can identify which disclosures could create genuine security risk and propose safe alternatives. Suppliers can specify the evidence they can provide before procurement. Engineers can test whether the proposed incident taxonomy works in a live network. Researchers can ask whether fairness assessments cover India's languages, regions, disabilities and uneven connectivity. The draft has already supplied the important skeleton. Inventory every AI system. Classify the risk. Assess it before use. Write the supplier obligations down. Record the incident. Keep a human responsible. Resolve the harm. Now put a safe, useful window in the cupboard door. People should not need a network outage and a regulatory investigation to learn which switch was labeled AI.