Resumen

  • El borrador de TRAI, publicado el 30 de octubre, hace responsable de los resultados de la IA a la entidad autorizada, incluso cuando un tercero desarrolló el sistema.
  • La propuesta exige una política aprobada por el consejo, un inventario de IA, evaluaciones previas al despliegue, registros de incidentes y supervisión ejecutiva.
  • TEC 57090:2025 aporta cuatro niveles cualitativos de gravedad y ejemplos; TRAI permite también una taxonomía equivalente.
  • Los incidentes críticos y de gravedad alta deben comunicarse a TRAI, pero el documento de consulta no incluye formulario ni plazo.

La cláusula que no cabe en el contrato del proveedor

La cláusula 3.8 del proyecto de TRAI coloca la responsabilidad donde se controla la red y el servicio: en la entidad autorizada. El sistema puede ser propio, comprado o una mezcla. En los tres casos, la empresa responde por el resultado bajo el texto propuesto. Un contrato puede repartir costes, auditorías y gestión de incidentes entre comprador y proveedor. No puede cambiar quién debe responder ante el regulador en este borrador.

El ámbito está definido por la función, no por la etiqueta del producto. La propuesta alcanza a titulares de licencias o autorizaciones para prestar servicios de telecomunicaciones y a entidades autorizadas para establecer, operar, mantener o ampliar redes, cuando utilizan o planean utilizar IA en esas redes o servicios. TRAI publicó el documento el 30 de octubre e invita a enviar comentarios hasta el 27 de noviembre de 2026. La página de consulta y un comunicado del Ministerio de Comunicaciones muestran ese plazo.

El consejo de administración debe aprobar la política interna de IA. Allí se clasifica cada sistema como de riesgo alto, medio o bajo según su materialidad para la red o el servicio, incluidos los efectos financieros, operativos y las posibles consecuencias para los consumidores. Un funcionario designado autoriza cada uso y puede delegar esa aprobación según la clasificación.

La lista de controles llega hasta la operación diaria. Antes de desplegar un sistema nuevo o modificar uno existente, la empresa debe validarlo y realizar evaluaciones de conformidad e impacto. El borrador menciona exactitud, explicabilidad, equidad, resistencia a la deriva y supervisión humana. Al comprar a un tercero, exige revisar al proveedor, las limitaciones del sistema y la calidad de los datos usados para entrenarlo. El inventario debe abarcar sistemas activos, inactivos y retirados, con su origen, propósito y nivel de riesgo. Lo que no está inventariado no se puede utilizar.

TRAI también traslada la discusión al consejo. El comité de gobernanza y seguridad de IA reuniría funciones de operación de red, prestación de servicios, informática, datos, regulación y atención al consumidor. Lo dirige un alto ejecutivo con el cargo de AI Governance and Safety Officer. El comité revisa el desempeño y los incidentes al menos una vez por ejercicio fiscal; puede exigir cambios o el retiro de un sistema. La política se revisa anualmente y se presenta a TRAI dentro de los siete días laborables siguientes a su entrada en vigor.

Riesgo del sistema no es gravedad del incidente

El borrador emplea dos escalas distintas. Alto, medio y bajo clasifican un sistema de IA según la política de la empresa. Crítico, alto, moderado y bajo clasifican cada incidente. Todos los incidentes deben registrarse, investigarse y analizarse; solo los dos niveles superiores activan el aviso a TRAI.

La escala de incidentes tiene un punto de partida común. TRAI remite a TEC 57090:2025 o a una taxonomía equivalente. El estándar describe como críticos los apagones nacionales importantes o los fallos completos; como altos, las interrupciones significativas o la degradación fuerte del servicio; como moderados, las caídas regionales o la degradación parcial; y como bajos, las interrupciones menores o las ralentizaciones breves. TEC incluyó el documento entre sus estándares notificados el 24 de abril de 2026. La lista de notificaciones confirma la fecha.

La taxonomía ofrece ejemplos, no una fórmula cuantitativa. El proyecto acepta además equivalentes. Para los incidentes críticos y altos, TRAI exige comunicar en la forma, modo y plazo que se prescriban; el documento consultado no especifica esos elementos. El operador puede tener que crear el registro central, guardar eventos detectados durante pruebas y mantener una base separada para daños denunciados por usuarios, pero la puerta de salida hacia el regulador aún no tiene una hora marcada.

La diferencia importa porque una base interna no es una notificación. El mecanismo de reclamaciones debe resolver daños relacionados con IA en un plazo “razonable”, según la propia política. TRAI puede pedir registros y usar informes para aprendizaje sectorial, evaluación de riesgos y avisos preventivos. El texto no obliga a publicar las bases internas ni un agregado del sector. La empresa puede conservar cada caso mientras clientes y otros operadores carecen de una vista comparable.

La documentación pública revisada no incluye una base de incidentes entre operadores para medir si ya clasifican casos parecidos de forma distinta. La instrucción futura de TRAI —el evento que activa el aviso, los campos obligatorios y el plazo— determinará si un incidente alto produce reportes comparables.

Una obligación común, decisiones de red locales

La asignación central tiene lógica: el operador aprueba sistemas, elige proveedores, define controles, gestiona el servicio y conserva los registros. TRAI tiene funciones de calidad del servicio y protección al consumidor en virtud de la Ley TRAI de 1997. Las India AI Governance Guidelines prevén la intervención de reguladores sectoriales, entre ellos TRAI, para aplicar reglas en sus ámbitos. La cronología oficial sigue sin cuadrar: el borrador de TRAI y un comunicado del PIB del 30 de octubre de 2026 sitúan la publicación en febrero de 2026, mientras un comunicado del 5 de noviembre de 2025 dice que las directrices se presentaron ese día y un resumen publicado el 15 de febrero de 2026 habla de su lanzamiento en la India AI Impact Summit; un historial público de versiones permitiría saber si son ediciones distintas.

El regulador debería fijar los elementos que hacen comparables los avisos: un umbral de notificación, el momento que inicia el plazo, los campos mínimos y una prueba para aceptar taxonomías equivalentes. Cada operador puede decidir qué sistemas requieren más supervisión, cómo auditar a un proveedor y quién aprueba cambios. La variedad de redes exige controles locales; no exige plazos incompatibles para avisar al mismo regulador.

Los comentarios vencen el 27 de noviembre. La versión final dirá si TRAI conserva su regla más fuerte —el operador responde también por la IA de terceros— y le añade el procedimiento necesario para hacerla comprobable.

Fuentes