Beancount.io LogoBeancount.io

Відповідність вимогам законопроєкту SB 53 Каліфорнії: практичний посібник із Закону про прозорість передових моделей ШІ

13 хв. читанняMike ThriftMike Thrift
Відповідність вимогам законопроєкту SB 53 Каліфорнії: практичний посібник із Закону про прозорість передових моделей ШІ

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

Якщо ваша організація навчає, доналаштовує або суттєво модифікує базові моделі — або керує великими обчислювальними кластерами, на які покладаються інші розробники, — SB 53 зараз є найважливішим законом про ШІ в Сполучених Штатах, який вам потрібно розуміти. Цей посібник пояснює, на кого поширюється дія закону, що ви повинні публікувати, як працює 15-денний термін звітування про критичні інциденти, які зобов’язання щодо викривачів застосовуються та як перетворити положення статуту на діючу програму комплаєнсу.

Що насправді регулює SB 53

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

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

Поріг обчислень у 10^26 ФЛОПС

«Передова модель» згідно з SB 53 визначається як базова модель, навчена з використанням понад 10^26 цілочисельних операцій або операцій із рухомою комою, включаючи кумулятивні обчислення від тонкого налаштування та подальших модифікацій. Цей поріг свідомо узгоджений із тригером звітування за скасованим федеральним Указом 14110 та рівнем ШІ загального призначення в Законі ЄС про ШІ, тому більшість великих лабораторій США вже знають, чи перетинають вони його.

Іноді випускають з уваги те, що статут враховує сукупні обчислення від подальших модифікацій. Якщо ви берете базову модель, яка була навчена близько до порогу, і продовжуєте попереднє навчання, виконуєте тонке налаштування за допомогою навчання з підкріпленням або зливаєте ваги з іншою моделлю, ви можете перевести похідну модель у статус передової, навіть якщо жоден окремий етап навчання не перевищив 10^26 ФЛОПС. Каталогізація кожної базової моделі, кожного тонкого налаштування, кожної дистиляції та кожного злиття ваг — і відстеження ФЛОПС, спожитих на кожному кроці — тепер є важливою дисципліною ведення обліку.

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

«Великий розробник передових моделей» — це розробник передових моделей, чия організація та афілійовані особи заробили понад 500 мільйонів доларів річного валового доходу в попередньому календарному році. Тест на дохід є консолідованим: материнські компанії, дочірні компанії та афілійовані особи під спільним контролем додаються разом. Невеликий ШІ-стартап, який залучив мільярдний раунд інвестування, але заробив 40 мільйонів доларів фактичного доходу, не є великим розробником передових моделей; публічний технологічний конгломерат із невеликим підрозділом ШІ, який перетинає поріг ФЛОПС, майже напевно ним є.

Розподіл на рівні важливий, оскільки великі розробники передових моделей несуть найсуворіші зобов’язання: публікація фреймворку передового ШІ, проведення оцінки катастрофічних ризиків, подання щоквартальних звітів про ризики внутрішнього використання до Каліфорнійського управління з надзвичайних ситуацій (Cal OES) та підтримка анонімного внутрішнього каналу для викривачів. Менші розробники передових моделей — ті, що перевищують поріг ФЛОПС, але перебувають нижче порогу доходу — все одно повинні публікувати звіти про прозорість і повідомляти про критичні інциденти безпеки, але вони не зобов’язані впроваджувати повний режим фреймворку.

Що ви повинні публікувати: Фреймворк передового ШІ

Кожен великий розробник передових моделей повинен опублікувати фреймворк передового ШІ на своєму вебсайті та підтримувати його в актуальному стані. Щорічний перегляд є обов’язковим, а будь-яка суттєва модифікація повинна призвести до оновлення протягом 30 днів після зміни.

Надійний фреймворк має охоплювати як мінімум:

  • Пороги катастрофічного ризику та методи оцінки. Які можливості — допомога у створенні хімічної, біологічної, радіологічної, ядерної зброї; великомасштабні атаки на критичну інфраструктуру; сценарії втрати контролю над автономними агентами — розробник вважатиме перетином порогу катастрофічного ризику? Як розробник тестуватиме ці можливості перед розгортанням?
  • Стратегії пом’якшення ризиків. Конкретні заходи перед розгортанням: навчання відмовам, пригнічення можливостей, обмеження розгортання, моніторинг доступу, поетапне впровадження та моніторинг після розгортання.
  • Сторонні оцінки. Які зовнішні ред-тіми, оцінювачі та аудитори оцінюватимуть модель і як будуть враховані їхні висновки?
  • Протоколи кібербезпеки для неопублікованих ваг моделей. Контроль внутрішніх загроз, апаратні модулі безпеки, сегментація мережі та логування доступу для захисту ваг перед розгортанням від крадіжки.
  • Процедури реагування на критичні інциденти безпеки. Хто вирішує, чи підлягає інцидент звітуванню, як запускається 15-денний відлік і як компанія координує дії з Cal OES.
  • Внутрішні механізми управління. Нагляд на рівні ради директорів, роль офіцера з безпеки ШІ, шляхи ескалації та періодичність перевірок безпеки.
  • Відповідність стандартам. Явне зіставлення зі Структурою управління ризиками ШІ NIST (AI RMF 1.0) та ISO/IEC 42001, які статут розглядає як основоположні базиси.

Фреймворк не є маркетинговим документом. Це артефакт, орієнтований на регулятора, який Генеральний прокурор може використовувати для оцінки того, чи відповідають публічні зобов’язання компанії її внутрішній практиці. Правильний підхід полягає в тому, щоб складати його з такою ж ретельністю, як розкриття факторів ризику в SEC або опис системи SOC 2.

Звіти про прозорість перед кожним розгортанням

Кожен розробник передових моделей — не лише великі компанії — повинен опублікувати звіт про прозорість перед розгортанням нової або суттєво модифікованої передової моделі (frontier model). Звіт про прозорість — це документ, що стосується конкретної моделі, є окремим від загальної структури та повинен містити:

  • Назву компанії, вебсайт та механізм зв'язку щодо питань безпеки
  • Дату випуску моделі та список підтримуваних мов і модальностей виводу
  • Призначення та застосовні обмеження щодо використання
  • Для великих розробників — резюме оцінок катастрофічних ризиків та їх результати, включаючи інформацію про те, чи залучалися сторонні експерти та яким чином

«Суттєва модифікація» включає значне оновлення можливостей, додавання нових модальностей та суттєві зміни у складі навчальних даних. Випуски патчів та рутинне доопрацювання (fine-tuning) систем безпеки зазвичай не потребують нового звіту про прозорість, проте граничні випадки слід документувати з письмовим обґрунтуванням на випадок, якщо Генеральний прокурор пізніше запитає, чому звіт не був опублікований.

15-денний термін звітування про критичні інциденти

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

Закон визначає критичний інцидент безпеки досить широко:

  • Несанкціонований доступ до ваг (weights) невипущеної моделі або їх викрадення
  • Реалізація катастрофічного ризику
  • Втрата розробником контролю над розгорнутою моделлю
  • Оманлива або ухильна поведінка моделі, яка долає захисні бар'єри

Побудова надійної внутрішньої процедури означає надання відповідей на три запитання ще до того, як інцидент трапиться:

  1. Хто приймає рішення? Єдина відповідальна особа (часто головний спеціаліст із безпеки ШІ або призначений заступник) повинна мати повноваження запускати відлік часу для звітування на основі задокументованих критеріїв ескалації.
  2. Що запускає відлік? Тригером є «виявлення». Внутрішня документація повинна фіксувати, коли саме інцидент був виявлений, ким і за допомогою якої системи моніторингу, оскільки 15-денне вікно розраховується саме з цього моменту.
  3. Як передається звіт? Cal OES підтримує конфіденційний процес прийому звернень від розробників. Команда звітування повинна відпрацювати робочий процес подання — включаючи зашифровану передачу чутливих технічних деталей — задовго до будь-якого реального інциденту.

Для великих розробників передових моделей зобов'язання виходять за межі реактивного звітування про інциденти. Кожні три місяці (або згідно з іншим обґрунтованим графіком) великі розробники повинні передавати до Cal OES резюме будь-якої оцінки катастрофічних ризиків, що випливає з внутрішнього використання їхніх моделей. Ця щоквартальна періодичність є унікальною для SB 53 і є першим випадком, коли закон США зобов'язав лабораторії ШІ звітувати виконавчому органу влади про результати поточної оцінки ризиків внутрішнього використання.

Захист викривачів та анонімний внутрішній канал

SB 53 додає до загального режиму захисту викривачів Каліфорнії набір специфічних для ШІ заходів захисту, які застосовуються до «охоплених працівників» — тих, чиї обов'язки включають оцінку, управління або усунення ризику катастрофічної шкоди від передових моделей.

Розробники передових моделей не можуть перешкоджати охопленому працівнику розголошувати інформацію або вчиняти репресії проти нього за розголошення інформації:

  • Генеральному прокурору Каліфорнії
  • Федеральному регуляторному органу
  • Безпосередньому керівнику або іншому керівнику, який має повноваження проводити розслідування
  • Іншому охопленому працівнику, чиї обов'язки включають оцінку ризиків

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

Великі розробники передових моделей також повинні підтримувати анонімний внутрішній канал звітування. Закон вимагає:

  • Робочий процес, що дозволяє охопленим працівникам подавати анонімні повідомлення про занепокоєння щодо катастрофічних ризиків
  • Щомісячне оновлення статусу розслідування для працівника, який подав звіт
  • Щоквартальні брифінги для керівників та директорів, що підсумовують повідомлення та результати, при цьому особи, звинувачені у порушеннях, виключаються зі списку слухачів брифінгу

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

Визначення катастрофічного ризику

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

  1. Допомога у створенні зброї. Суттєвий внесок у створення, розгортання або використання хімічної, біологічної, радіологічної чи ядерної зброї, або кіберзброї, що завдає порівнянної шкоди.
  2. Неконтрольована шкідлива поведінка. Поведінка моделі з обмеженим людським наглядом, яка, якби вона була вчинена людиною, становила б серйозний злочин, скоєний з умислом.
  3. Втрата контролю. Втрата розробником контролю над моделлю, внаслідок чого вона вдається до суттєво шкідливої поведінки.

Визначення містить важливі винятки. Ризики, засновані на інформації, яка вже є загальнодоступною, шкода, що виникає внаслідок законної федеральної діяльності, та шкода, де внесок моделі не є суттєвим, — усе це виходить за межі сфери застосування закону. Саме ці винятки не дозволяють повсякденним ризикам застосування — упередженості під час відбору резюме, галюцинаціям у медичних порадах, порушенню авторських прав — запускати режим катастрофічного ризику. Ця шкода є реальною, але вона регулюється іншими законами, а не SB 53.

Цивільні штрафи та правозастосування

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

На практиці ризик правозастосування зосереджений у трьох сферах:

  • Маніпуляції з порогами. Компанії, які структурують цикли навчання так, щоб залишатися трохи нижче рівня 10^26 FLOPs, водночас випускаючи моделі з явно передовими можливостями (frontier-class), опиняться під пильною увагою. Форлювання закону щодо сукупних обчислень робить таку стратегію вразливою.
  • Прогалини у структурі управління. Фреймворк, який лише перелічує політики без доказів їх впровадження, буде легше атакувати, ніж той, де кожне зобов’язання підкріплене оперативними артефактами, призначеними відповідальними особами та журналами аудиту.
  • Затримки у звітності про інциденти. Недотримання 15-денного терміну або 24-годинного терміну для звітування про неминучу загрозу — це саме те чітке, документоване порушення, за яке регулятори історично переслідують найагресивніше.

Побудова 90-денного плану впровадження

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

Дні з 1 по 30: Визначення обсягу та аналіз прогалин.

  • Каталогізуйте кожну базову модель, яка була навчена, доопрацьована (fine-tuned), об’єднана (merged) або суттєво модифікована, з оцінкою сукупних обчислень для кожної.
  • Визначте, чи перевищив консолідований дохід (включаючи всіх афілійованих осіб) 500 мільйонів доларів США за попередній календарний рік.
  • Сформуйте міжфункціональну робочу групу з питань безпеки ШІ та комплаєнсу, до складу якої увійдуть представники інженерних підрозділів, відділів безпеки, юристи, фахівці з комунікацій та HR.
  • Зіставте поточні практики з NIST AI RMF 1.0 та ISO/IEC 42001 для виявлення прогалин.

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

  • Підготуйте проєкт структури передового ШІ (frontier AI framework) як документ із контролем версій, призначений для публікації.
  • Розробіть методологію оцінки катастрофічних ризиків, включаючи оцінку можливостей, моделювання загроз та критерії визначення моделі як «передової» у небезпечній сфері.
  • Впровадьте заходи кібербезпеки для непублічних вагових коефіцієнтів (weights) із документованими журналами доступу та моніторингом внутрішніх загроз.
  • Створіть канал для анонімних внутрішніх повідомлень та робочий процес для щомісячних оновлень статусу та квартальних брифінгів для ради директорів.

Дні з 61 по 90: Операційна готовність.

  • Проведіть настільні навчання з реагування на інциденти, що симулюють виявлення крадіжки вагових коефіцієнтів та реалізацію катастрофічного ризику, після чого відпрацюйте 15-денний та 24-годинний робочі процеси звітування.
  • Проведіть навчання для відповідних працівників щодо прав викривачів та використання анонімного каналу.
  • Опублікуйте звіт про прозорість для будь-якої моделі на етапі розгортання з посиланням на фреймворк передового ШІ.
  • Внесіть у календар подання щоквартальних звітів про катастрофічні ризики до Cal OES (Управління з надзвичайних ситуацій Каліфорнії) та щорічний перегляд фреймворку.

Координація з іншими режимами регулювання ШІ та конфіденційності

SB 53 діє не ізольовано. Команди з комплаєнсу повинні зіставити його з:

  • Структурою управління ризиками ШІ від NIST (NIST AI RMF), на яку закон прямо посилається і яка забезпечує основу для змістовного управління.
  • Рівнем ШІ загального призначення (general-purpose AI) у Законі ЄС про ШІ, де накладання вимог до документації є суттєвим, і єдиний гармонізований внутрішній фреймворк може задовольнити обидва закони.
  • Законом Колорадо про ШІ та Законом Техасу про відповідальне управління ШІ, які регулюють зобов'язання розгортачів ШІ для прийняття рішень з високим рівнем ризику і можуть стосуватися ваших кінцевих клієнтів.
  • Законом Каліфорнії про конфіденційність споживачів (CCPA) та майбутніми правилами Агентства із захисту конфіденційності Каліфорнії щодо технологій автоматизованого прийняття рішень, які перетинаються з розгортанням моделей, але діють незалежно від SB 53.
  • Добровільними зобов’язаннями Федерального інституту безпеки ШІ США та будь-яким майбутнім федеральним законодавством, яке може змінити базовий рівень відповідності.

Точні записи про відповідність та чіткі аудиторські сліди є критично важливими для всіх цих режимів — і та сама дисципліна документування, яка підтримує фінансову звітність, підтримує і звітність з управління ШІ. Фреймворки передового ШІ, оцінки катастрофічних ризиків, журнали інцидентів та записи розслідувань за зверненнями викривачів слід зберігати щонайменше п’ять років у спосіб, що дозволить їм зберегтися навіть у разі зміни керівництва або реструктуризації компанії.

Тримайте свої комплаєнс та фінансові записи готовими до аудиту

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