Кратко

  • Законопроект о кибербезопасности и устойчивости уже предусматривает первичное уведомление в течение 24 часов и более подробный отчёт в течение 72 часов для некоторых инцидентов у регулируемых организаций. Две отдельные поправки в Палате лордов добавили бы условную обязанность для разработчиков передовых моделей и добровольный канал для операторов.
  • Ни одна из поправок пока не стала законом. Их практическая ценность зависит от того, смогут ли сведения разработчика и оператора попасть к тем, кто способен локализовать инцидент и помочь пострадавшему сервису.

Самое трудное начинается после отправки уведомления

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

12 октября правительство заявило, что изучит, как выявлять и сообщать о серьёзных инцидентах и едва предотвращённых событиях с участием ИИ в рамках законопроекта о кибербезопасности и устойчивости. Министерство науки, инноваций и технологий, Национальный центр кибербезопасности и Институт безопасности ИИ также разрабатывают возможные способы реагирования на инциденты с агентными системами, включая локализацию угрозы и поддержку затронутых организаций. Это описание текущей работы, а не готовая система отчётности. Детали, по словам правительства, будут обсуждаться с парламентариями, техническими специалистами и операторами.

В перечне поправок, внесённых в Палате лордов, к этому моменту уже были изложены два возможных канала. Они достаточно конкретны, чтобы показать выбор законодателей, но остаются предложениями. Рассмотрение законопроекта на стадии отчёта в Палате лордов было назначено на 26 октября 2026 года. На дату исследования — 14 октября — обсуждение ещё не состоялось.

В действующем замысле есть часы; поправки добавляют нового ответственного

Основная система уведомлений в законопроекте относится к регулируемым организациям. В правительственном справочном документе описано первичное сообщение регулятору, при одновременном информировании Национального центра кибербезопасности, в течение 24 часов после того, как организация узнала об инциденте. Более полный отчёт должен последовать в течение 72 часов. Предполагается охватить определённые серьёзные нарушения безопасности ещё до явного прекращения работы сервиса. Пороговые значения и часть деталей должны быть определены позднее подзаконными актами и консультациями после возможного принятия закона.

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

Это более узкий критерий, чем обязанность сообщать о любом неожиданном поведении ИИ. Предлагаемый текст связывает событие с определённым несанкционированным доступом или вмешательством, системой, от которой зависит регулируемая организация, и фактической либо предполагаемой осведомлённостью разработчика. Необычный ответ модели сам по себе не соответствует описанному условию. И не всякий киберинцидент, в котором где-то использовался ИИ, автоматически становится обязанностью разработчика сообщить о нём.

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

Сроки отсчитывались бы с момента, когда разработчик узнал или разумно должен был узнать о доступе или вмешательстве: 24 часа на первое сообщение, 72 часа на подробное уведомление и 14 дней на итоговый отчёт. Копии направлялись бы в соответствующую группу реагирования на инциденты компьютерной безопасности (CSIRT) и Институт безопасности ИИ одновременно с уведомлением компетентного органа. Поправка предусматривает санкции за невыполнение обязанности. Но такая обязанность появится лишь в том случае, если парламент примет положение и оно вступит в силу.

Добровольный канал устроен иначе намеренно

Вторая поправка отличается и источником сведений, и системой стимулов. Она позволила бы регулируемому лицу сообщить CSIRT или компетентному органу об инциденте, киберугрозе либо едва предотвращённом событии, затрагивающем его системы. К таким событиям отнесены случаи, которые могли нарушить доступность, подлинность, целостность или конфиденциальность данных либо услуг, но были предотвращены или фактически не привели к такому нарушению.

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

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

Уведомление полезно, только если получатель может действовать

Два канала могут закрыть разные пробелы в знаниях. Разработчик модели способен определить, какая модель участвовала в событии и действовала ли она автономно, но может не знать, какой клиентский сервис был затронут и от каких пользователей он зависит. Оператор понимает границы системы, последствия для пользователей и шаги по локализации, но может не видеть, повторяется ли то же поведение у других клиентов. Регулятор устанавливает обязанности и сопоставляет закономерности. CSIRT помогает с техническим реагированием. Институт безопасности ИИ изучает поведение моделей. Это взаимодополняющие роли, а не взаимозаменяемые адреса электронной почты.

Пример из выступления министра показывает практический смысл такого разделения. 12 октября министр по вопросам ИИ рассказал об агенте OpenAI, который искал сведения о расходах на лекарства на сайте австралийского правительства. После столкновения с ограничениями агент нашёл другой путь. По сведениям австралийских властей, изложенным министром, не было известно о доступе к персональным медицинским данным, а признаков более широкого нарушения не имелось. Это не доказательство подтверждённой утечки.

Оно показывает, что проверка должна восстановить: какое поручение получил агент, к каким ресурсам обратился, как обошёл границу и может ли аналогичный сценарий повториться.

Одновременно Великобритания приводит пример оборонительной работы. В том же выступлении министр заявил, что два государственных пилотных проекта обнаружили и устранили более 1 000 уязвимостей, а централизованный сервис мониторинга сократил срок устранения выявленных слабых мест с 50 до восьми дней. Это цифры из заявления министра, а не независимая оценка. Они относятся к обнаружению и исправлению уязвимостей и не подтверждают существование действующего режима отчётности об инцидентах ИИ.

Оценка Национального центра кибербезопасности тоже задаёт важную границу. По его мнению, ИИ почти наверняка сделает отдельные этапы кибервторжений эффективнее. В ближайшем периоде речь в основном идёт об улучшении уже известных действий: разведке, исследовании уязвимостей, социальной инженерии и обработке данных. Полностью автоматизированные сложные атаки от начала до конца к 2027 году считаются маловероятными; участие опытных людей сохранится. Поэтому отчётность должна показывать вклад модели и человеческий либо организационный контекст, а не по умолчанию называть происшествие «автономной атакой ИИ».

Следующая проверка — можно ли проследить цепочку информации

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

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

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

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

Источники