Соответствие закону Калифорнии SB 53: практическое руководство по Закону о прозрачности передовых систем ИИ

29 сентября 2025 года губернатор Калифорнии Гэвин Ньюсом подписал законопроект Сената 53 — Закон о прозрачности передовых систем искусственного интеллекта (TFAIA). Таким образом, Калифорния стала первой юрисдикцией в США, наложившей обязательства по обеспечению безопасности, прозрачности и отчетности об инцидентах на разработчиков наиболее вычислительно мощных систем ИИ. Закон вступил в силу 1 января 2026 года, и за последние шесть месяцев он незаметно изменил то, как крупнейшие лаборатории ИИ и растущий список разработчиков моделей среднего уровня документируют риски, публикуют структуры управления и информируют регуляторов о сценариях катастрофических рисков.

Если ваша организация обучает, настраивает или существенно модифицирует базовые модели — или управляет крупными вычислительными кластерами, на которые полагаются другие разработчики, — SB 53 на данный момент является самым значимым законом об ИИ в Соединенных Штатах, который вам необходимо понимать. В этом руководстве рассматривается, на кого распространяется закон, что вы должны публиковать, как работает 15-дневный срок отчетности о критических инцидентах, какие обязательства применяются к информаторам и как перевести нормы закона в действующую программу комплаенса.

Что на самом деле регулирует SB 53

В отличие от законов об ИИ в сфере занятости, распространяющихся по штатам (например, местный закон Нью-Йорка 144 или Закон об ИИ штата Колорадо), SB 53 не регулирует алгоритмические инструменты найма, модели кредитного андеррайтинга или системы проверки арендаторов. Он нацелен на гораздо более узкую категорию: передовые базовые модели, обученные на экстраординарных вычислительных мощностях, и сценарии катастрофических рисков, которые могут из них вытекать.

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

Порог вычислительной мощности в 10^26 FLOPs

«Передовая модель» (frontier model) согласно SB 53 определяется как базовая модель, обученная с использованием более чем 10^26 целочисленных операций или операций с плавающей запятой, включая совокупные вычисления от тонкой настройки и последующих модификаций. Этот порог намеренно согласован с триггером отчетности ныне отмененного федерального Указа № 14110 и уровнем ИИ общего назначения в Законе ЕС об ИИ, поэтому большинство крупных американских лабораторий уже знают, пересекают ли они его.

Часто упускается из виду тот факт, что закон учитывает совокупные вычисления от последующих модификаций. Если вы берете базовую модель, которая была обучена вблизи порога, и продолжаете предварительное обучение, выполняете тонкую настройку с подкреплением или объединяете веса с другой моделью, вы можете перевести производную модель в статус передовой, даже если ни один отдельный этап обучения не превысил 10^26 FLOPs. Каталогизация каждой базовой модели, каждой настройки, каждой дистилляции и каждого слияния весов, а также отслеживание FLOPs, потребленных на каждом этапе, теперь является важной учетной дисциплиной.

Порог выручки в 500 миллионов долларов для крупных разработчиков передовых моделей

«Крупный разработчик передовых моделей» — это разработчик, чья организация и аффилированные лица заработали более 500 миллионов долларов годовой валовой выручки в предыдущем календарном году. Тест на выручку является консолидированным: материнские компании, дочерние компании и аффилированные лица под общим контролем суммируются. Небольшой ИИ-стартап, который привлек миллиард долларов инвестиций, но заработал 40 миллионов долларов фактической выручки, не является крупным разработчиком передовых моделей; а публичный технологический конгломерат с небольшим ИИ-подразделением, преодолевшим порог FLOPs, почти наверняка им является.

Такое разделение на уровни важно, потому что на крупных разработчиков передовых моделей ложатся самые серьезные обязательства: публикация структуры управления передовым ИИ (frontier AI framework), проведение оценки катастрофических рисков, ежеквартальное представление отчетов о рисках для внутреннего использования в Управление по чрезвычайным ситуациям Калифорнии (Cal OES) и ведение анонимного внутреннего канала для информаторов. Более мелкие разработчики передовых моделей — те, кто превысил порог FLOPs, но не достиг порога выручки — все равно должны публиковать отчеты о прозрачности и сообщать о критических инцидентах безопасности, но на них не распространяется в полном объеме режим разработки структуры управления.

Что вы должны публиковать: Структура управления передовым ИИ (Frontier AI Framework)

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

Обоснованная структура должна охватывать как минимум:

Пороги катастрофического риска и методы оценки. Какие возможности — помощь в создании химического, биологического, радиологического, ядерного оружия; крупномасштабные атаки на критическую инфраструктуру; сценарии автономной агентной потери контроля — разработчик будет рассматривать как пересечение порога катастрофы? Как разработчик будет тестировать эти возможности перед развертыванием?
Стратегии смягчения рисков. Конкретные меры перед развертыванием: обучение отказам, подавление опасных возможностей, ограничения на развертывание, контролируемый доступ, поэтапное внедрение и мониторинг после развертывания.
Сторонние оценки. Какие внешние ред-тимы, оценщики и аудиторы будут проверять модель и как их выводы будут учтены?
Протоколы кибербезопасности для невыпущенных весов моделей. Контроль внутренних угроз, аппаратные модули безопасности, сегментация сети и логирование доступа для защиты весов моделей от кражи перед развертыванием.
Процедуры реагирования на критические инциденты безопасности. Кто решает, подлежит ли инцидент отчетности, как запускается 15-дневный срок и как компания координирует свои действия с Cal OES.
Механизмы внутреннего управления. Надзор на уровне совета директоров, роль офицера по безопасности ИИ, пути эскалации и периодичность проверок безопасности.
Соответствие стандартам. Явное сопоставление со Структурой управления рисками ИИ NIST (AI RMF 1.0) и ISO/IEC 42001, которые закон рассматривает как основополагающие базы.

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

Отчеты о прозрачности перед каждым развертыванием

Каждый разработчик передовых систем (frontier-разработчик) — а не только крупнейшие из них — обязан опубликовать отчет о прозрачности перед развертыванием новой или существенно модифицированной передовой модели. Отчет о прозрачности является документом по конкретной модели, отдельным от общей структуры, и должен включать:

Название компании, веб-сайт и механизм связи по вопросам безопасности
Дату выпуска модели, список поддерживаемых языков и модальностей вывода
Целевое использование и применимые ограничения на использование
Для крупных разработчиков — резюме оценок катастрофических рисков и их результаты, включая информацию о том, привлекались ли сторонние эксперты и каким образом

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

15-дневный срок отчетности о критических инцидентах

Бремя соблюдения нормативных требований, которое больше всего удивило корпоративных юристов, — это сроки отчетности об инцидентах. Разработчики передовых систем обязаны уведомлять Управление по чрезвычайным ситуациям штата Калифорния (Cal OES) о критическом инциденте в сфере безопасности в течение 15 дней с момента обнаружения, при этом устанавливается более жесткий 24-часовой срок, если инцидент представляет неизбежную угрозу общественной безопасности.

Закон определяет критический инцидент в сфере безопасности широко:

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

Создание надежного внутреннего процесса означает поиск ответов на три вопроса еще до возникновения инцидента:

Кто принимает решение? Ответственность за запуск отсчета времени должна лежать на одном должностном лице (часто это директор по безопасности ИИ или назначенный заместитель) с четко задокументированными критериями эскалации.
Что запускает отсчет? Триггером является «обнаружение». Внутренняя документация должна фиксировать, когда именно был обнаружен инцидент, кем и с помощью какой системы мониторинга, поскольку 15-дневное окно рассчитывается именно с этого момента.
Как передается отчет? Cal OES поддерживает конфиденциальный процесс приема обращений от разработчиков. Команда отчетности должна отрепетировать рабочий процесс подачи — включая зашифрованную передачу конфиденциальных технических деталей — задолго до любого реального инцидента.

Для крупных разработчиков передовых систем обязательства выходят за рамки простого реагирования на инциденты. Каждые три месяца (или в соответствии с другим разумным графиком) крупные разработчики должны направлять в Cal OES резюме любых оценок катастрофических рисков, возникающих при внутреннем использовании их моделей. Эта ежеквартальная периодичность уникальна для SB 53 и является первым случаем, когда законодательство США обязало лаборатории ИИ сообщать о текущих рисках внутреннего использования органу исполнительной власти.

Защита информаторов и анонимный внутренний канал

SB 53 дополняет общий режим защиты информаторов в Калифорнии набором специфических для ИИ мер защиты, которые применяются к «защищенным сотрудникам» — тем, в чьи обязанности входит оценка, управление или устранение рисков катастрофического вреда от передовых моделей.

Разработчики передовых систем не имеют права препятствовать защищенному сотруднику в раскрытии информации или применять к нему ответные меры за раскрытие информации:

Генеральному прокурору Калифорнии
Федеральному регулирующему органу
Непосредственному руководителю или другому руководителю, имеющему полномочия на проведение расследования
Другому защищенному сотруднику, в чьи обязанности входит оценка рисков

Защищенное раскрытие информации охватывает как (а) обоснованное убеждение в том, что деятельность разработчика представляет конкретную и существенную опасность для общественного здоровья или безопасности в связи с катастрофическим риском, так и (б) обоснованное убеждение в том, что разработчик нарушил сам закон SB 53.

Крупные разработчики также обязаны поддерживать анонимный внутренний канал отчетности. Закон требует:

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

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

Определение катастрофического риска

Краеугольным камнем SB 53 является определение «катастрофического риска». Закон определяет его как предсказуемый и существенный риск того, что передовая модель внесет существенный вклад в гибель или серьезное ранение более 50 человек или в ущерб или потерю имущества на сумму более 1 миллиарда долларов через один из трех причинно-следственных механизмов:

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

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

Гражданско-правовые санкции и правоприменение

Генеральный прокурор Калифорнии обладает исключительными полномочиями по принудительному исполнению закона. Гражданско-правовые санкции могут достигать 1 миллиона долларов за каждое нарушение, в зависимости от тяжести деяния. Сам законопроект SB 53 не предусматривает права на частный иск, однако положения о защите осведомителей от преследования могут быть реализованы через гражданские иски, подаваемые пострадавшими сотрудниками.

На практике риски правоприменения сосредоточены в трех областях:

Манипуляции с порогами. Компании, которые структурируют циклы обучения так, чтобы оставаться чуть ниже порога в 10^26 FLOPs, при этом выпуская модели с явными возможностями «фронтирного» уровня, окажутся под пристальным вниманием. Положения закона о совокупном объеме вычислений делают эту стратегию ненадежной.
Пробелы в структуре управления. Регламент, в котором перечислены политики без доказательств их реализации, будет гораздо уязвимее для претензий, чем тот, где каждое обязательство подкреплено операционными артефактами, назначенными ответственными лицами и логами аудита.
Задержки в отчетности об инцидентах. Несоблюдение 15-дневного срока или 24-часового окна при возникновении неминуемой угрозы — это те типы четких, документируемых нарушений, которые регуляторы исторически преследуют наиболее агрессивно.

Разработка 90-дневного плана внедрения

Для организации, которая еще не запустила программу соблюдения SB 53, эффективной будет следующая последовательность действий:

Дни с 1 по 30: Анализ охвата и выявление пробелов.

Составьте каталог каждой обученной, дообученной, объединенной или существенно модифицированной базовой модели с оценкой совокупных вычислений для каждой из них.
Определите, превысила ли консолидированная выручка (включая всех аффилированных лиц) 500 миллионов долларов в предыдущем календарном году.
Сформируйте кросс-функциональную рабочую группу по безопасности и комплаенсу в сфере ИИ, в которую войдут представители инженерного отдела, службы безопасности, юридического отдела, отдела коммуникаций и HR.
Сопоставьте текущие практики с NIST AI RMF 1.0 и ISO/IEC 42001 для выявления пробелов.

Дни с 31 по 60: Разработка документации и управление.

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

Дни с 61 по 90: Операционная готовность.

Проведите командно-штабные учения по реагированию на инциденты, симулирующие кражу весов и материализацию катастрофического риска, и отработайте 15-дневный и 24-часовой рабочие процессы отчетности.
Проведите обучение соответствующих сотрудников по правам осведомителей и работе анонимного канала.
Опубликуйте отчет о прозрачности для любой модели, находящейся на этапе развертывания, с перекрестной ссылкой на регламент по фронтирному ИИ.
Внесите в календарь подачу ежеквартальных сводок о катастрофических рисках в Cal OES и ежегодный пересмотр регламента.

Координация с другими режимами регулирования ИИ и конфиденциальности

SB 53 не существует в вакууме. Командам по комплаенсу следует сопоставлять его с:

NIST AI Risk Management Framework, на который закон прямо ссылается и который служит основой для большей части содержательного управления.
Уровнем ИИ общего назначения в Законе ЕС об искусственном интеллекте (EU AI Act), где требования к документации существенно пересекаются, и единая гармонизированная внутренняя структура может удовлетворить оба режима.
Законом Колорадо об ИИ и Законом Техаса об ответственном управлении ИИ, которые регулируют обязательства разработчиков систем ИИ для принятия решений с высоким уровнем риска и могут применяться к вашим последующим клиентам.
Калифорнийским законом о защите конфиденциальности потребителей (CCPA) и предстоящими правилами Агентства по защите конфиденциальности Калифорнии в отношении технологий автоматизированного принятия решений, которые пересекаются с развертыванием моделей, но действуют независимо от SB 53.
Добровольными обязательствами федерального Института безопасности ИИ и любым будущим федеральным законодательством о приоритете права, которое может изменить базовый уровень комплаенса.

Точные записи о соблюдении требований и четкие контрольные журналы (audit trails) необходимы во всех этих режимах — и та же дисциплина документирования, которая поддерживает финансовую отчетность, поддерживает и отчетность по управлению ИИ. Регламенты фронтирного ИИ, оценки катастрофических рисков, логи инцидентов и записи расследований по сообщениям осведомителей должны храниться не менее пяти лет таким образом, чтобы они сохранялись при смене руководства или реструктуризации корпорации.

Поддерживайте финансовую и комплаенс-отчетность в готовности к аудиту

Публикуете ли вы регламент фронтирного ИИ, планируете квартальные отчеты в Cal OES или готовитесь к запросу Генерального прокурора, базовая дисциплина остается неизменной: четкие, версионные и проверяемые записи. Тот же текстовый подход с контролем версий, который команды разработчиков ИИ используют для своих кодовых баз, отлично подходит и для бухгалтерии. Beancount.io предоставляет систему учета в текстовом формате (plain-text accounting), которая обеспечивает полную прозрачность и контроль над вашими финансовыми данными — без «черных ящиков», зависимости от поставщика и с чистым контрольным журналом, который естественным образом сочетается с культурой управления, ожидаемой современными регуляторами. Начните бесплатно и узнайте, почему разработчики и финансовые специалисты переходят на текстовый учет.