Кратко

  • Проект TRAI возлагает ответственность за результаты ИИ-систем на лицензированную или уполномоченную организацию, даже если систему разработал внешний поставщик.
  • Оператору понадобятся одобренная советом директоров политика по ИИ, реестр систем, оценки до запуска, база инцидентов и комитет по управлению во главе со старшим руководителем.
  • TEC 57090:2025 описывает качественные уровни тяжести, но проект не задаёт форму и срок сообщения об инцидентах классов critical и high.

Поставщик продаёт модель. Перед регулятором отвечает оператор.

Проект Управления по регулированию телекоммуникаций Индии (TRAI) закрепляет ответственность за той уполномоченной организацией, которая применяет ИИ в сети или услуге. Пункт 3.8 охватывает системы собственной разработки, купленные у третьих лиц и собранные из обоих источников. Договор может распределить между покупателем и поставщиком расходы, право аудита и компенсации. Он не переносит регуляторную ответственность, которую проект оставляет оператору.

Это важно там, где ИИ влияет на работу сети, предоставление услуг и положение потребителей. Проект распространяется на держателей лицензии на телекоммуникационные услуги и на организации, которым разрешено создавать, эксплуатировать, обслуживать или расширять сети, если они используют ИИ в этих функциях или планируют его внедрение. TRAI опубликовало проект 30 октября 2026 года; замечания принимаются до 27 ноября. Страница консультации и сообщение Министерства связи указывают этот срок.

Первое решение принимает совет директоров или сопоставимый орган управления: он утверждает внутреннюю политику по ИИ. Затем каждую систему относят к классу high, medium или low по её значимости для сети или услуги, включая финансовые и операционные последствия и возможный эффект для потребителей. Назначенный руководитель одобряет применение системы; полномочия можно делегировать с учётом класса риска.

До запуска новой системы или изменения действующей организация должна провести проверку, оценку соответствия и оценку воздействия. Проект называет точность, объяснимость, справедливость, устойчивость к дрейфу и человеческий контроль. При работе с внешним поставщиком добавляются проверка его надёжности, ограничений системы, качества и пригодности обучающих данных. Реестр должен охватывать действующие, неиспользуемые и выведенные из эксплуатации системы, указывать источник, цель и класс риска. Систему вне реестра использовать нельзя.

Политика получает и организационное продолжение. Совет директоров утверждает комитет по управлению и безопасности ИИ с участием сетевых операций, предоставления услуг, IT, специалистов по данным, регулированию и защите потребителей. Комитетом руководит старший исполнительный руководитель — AI Governance and Safety Officer. Не реже одного раза в финансовый год комитет проверяет работу систем и записи об инцидентах; он может потребовать изменить или вывести систему из эксплуатации. Политику и её поправки нужно передать TRAI в течение семи рабочих дней после вступления в силу.

Риск системы и тяжесть инцидента — разные шкалы

Проект использует два классификатора. High, medium и low описывают значимость самой ИИ-системы и определяются внутренней политикой организации. Critical, high, moderate и low характеризуют отдельный инцидент. Каждый инцидент необходимо зарегистрировать, расследовать и проанализировать; TRAI требуется уведомлять об инцидентах классов critical и high.

Регулятор не оставил компаниям право придумать всю терминологию тяжести самим. Проект ссылается на TEC 57090:2025 или эквивалентную классификацию. По стандарту крупное общенациональное нарушение или полный отказ — critical; значительный сбой или сильное ухудшение услуги — high; региональный отказ или частичное ухудшение — moderate; краткое замедление или незначительный перерыв — low. В официальном перечне уведомлённых стандартов TEC указана дата уведомления 24 апреля 2026 года.

Примеры дают общий словарь, но не числовую формулу. Кроме того, проект разрешает эквивалентную таксономию. Сообщения об инцидентах critical и high должны подаваться в установленной форме, порядке и сроке, однако текст консультации не содержит ни формы, ни срока в часах или днях.

Оператору предписана центральная база инцидентов, включая случаи, обнаруженные при тестировании. Отдельная база должна учитывать вред от ИИ, о котором сообщили пользователи, и его устранение. Жалобы разбираются в «разумный срок», который оператор задаёт сам. TRAI может запросить оценки, отчёты и другие документы; сведения об инцидентах могут использоваться для отраслевого анализа и оценки рисков. Публиковать внутренние базы или сводные отраслевые данные проект не требует.

Общедоступной межоператорской базы инцидентов для сравнения сходных случаев нет. Если последующие указания TRAI определят основание для уведомления, обязательные поля и момент начала отсчёта, сообщения о событиях высокой тяжести можно будет сопоставлять.

Общий срок для уведомления, оперативные решения — у оператора

Распределение обязанностей следует за контролем над сетью: оператор выбирает системы, разрешает их использование, проверяет поставщиков, контролирует изменения и хранит сведения об инцидентах. Закон о TRAI 1997 года закрепляет за регулятором функции в области качества услуг и защиты потребителей. Национальные рекомендации Индии по управлению ИИ называют TRAI отраслевым регулятором и предусматривают профильные правила для отдельных секторов. Официальная хронология расходится: проект TRAI и сообщение PIB от 30 октября 2026 года относят публикацию рекомендаций к февралю 2026 года, тогда как сообщение PIB от 5 ноября 2025 года говорит об их представлении в этот день, а обзор PIB от 15 февраля 2026 года описывает публикацию на India AI Impact Summit; открытая история версий показала бы, относятся ли даты к разным редакциям.

TRAI стоит унифицировать то, что делает уведомления сопоставимыми: основания для сообщения, точку начала срока, обязательные поля и условия признания эквивалентных классификаторов. Выбор систем для усиленного контроля, проверка поставщика, согласование обновления и команда, следящая за результатами, могут оставаться решениями оператора. Сети требуют разной инженерной настройки; одно и то же серьёзное событие не должно получать десять разных часов уведомления.

Срок подачи комментариев истекает 27 ноября. Окончательная редакция покажет, сохранит ли TRAI самый жёсткий принцип проекта — оператор отвечает за результаты и приобретённого ИИ — и добавит ли процедуру уведомления, с которой эту ответственность можно проверить.

Источники