Две трети существенных изменений правил безопасности ИИ не указали в отчётах

Авторы не просто сравнили старую и новую версии документов. Они разбили правила на отдельные обязательства — например, что именно разработчик должен проверить, когда срабатывает проверка, кто участвует и что нужно раскрыть, — а затем проследили судьбу каждого обязательства между соседними версиями. Изменение считали существенным, если оно меняло область действия, порог или условие запуска, ответственного, силу требования, объём раскрытия или последствия результата. Такой подход нужен потому, что общий рассказ «мы обновили правила из-за новых обстоятельств» не всегда показывает, какое конкретно требование стало слабее или исчезло.

Для проверки авторы заморозили набор документов с точными версиями и сопоставили его с журналами изменений, перечёркнутыми версиями и объявлениями разработчиков. Отдельно вручную разобрали 244 случая, чтобы сверить применение кодировочной схемы. Оказалось, что форма отчёта важнее его длины: повествовательные объявления чаще оставляли изменения неявными, чем списки пунктов. При подсчёте на уровне целых разделов доля неуказанных изменений была ниже, чем при разборе отдельных обязательств — 49%, — то есть крупный раздел мог выглядеть понятным, хотя внутри него терялась важная деталь.

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