Съответствие със SB 53 на Калифорния: Практическо ръководство за Закона за прозрачност във водещия ИИ

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

Ако вашата организация обучава, донастройва или съществено модифицира базови модели — или оперира големи изчислителни клъстери, на които разчитат други разработчици — SB 53 вече е най-значимият закон за ИИ в Съединените щати, който трябва да разберете. Това ръководство разглежда кой е обхванат, какво трябва да публикувате, как работи 15-дневният срок за докладване на критични инциденти, какви задължения се прилагат за подателите на сигнали и как да пренесете закона в работеща програма за съответствие.

Какво всъщност регулира SB 53

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

Законът се намира в пресечната точка на две регулаторни традиции. От правото за безопасност на продуктите той заема идеята, че компаниите трябва да публикуват оценки на риска и да уведомяват властите при възникване на инциденти. От финансово-регулаторното право той заема идеята, че най-големите играчи носят по-голяма тежест за оповестяване от по-малките. Резултатът е режим на нива, изграден около два прага.

Прагът на изчисления от 10^26 FLOPs

„Авангарден модел“ съгласно SB 53 се дефинира като базов модел, обучен с използване на повече от 10^26 целочислени операции или операции с плаваща запетая, включително кумулативни изчисления от фина настройка и последващи модификации. Този праг е умишлено съгласуван с вече отменения федерален тригер за докладване по Изпълнителна заповед 14110 и нивото за ИИ с общо предназначение в Акта за ИИ на ЕС, така че повечето големи американски лаборатории вече знаят дали го пресичат.

Това, което понякога се пропуска, е че законът брои кумулативните изчисления от последващи модификации. Ако вземете базов модел, който е бил обучен близо до прага, и продължите предварителното обучение, направите фина настройка чрез обучение с подкрепление или обедините тегла с друг модел, можете да вкарате деривата в статус на авангарден модел, дори ако нито един отделен цикъл на обучение не е пресякъл 10^26 FLOPs. Каталогизирането на всеки базов модел, всяка фина настройка, всяка дестилация и всяко обединяване на тегла — и проследяването на FLOPs, консумирани от всяка стъпка — сега е съществена счетоводна дисциплина.

Прагът на приходи от 500 милиона долара за големи разработчици на авангарден ИИ

„Голям разработчик на авангарден ИИ“ е разработчик, чието дружество и свързани лица са спечелили повече от 500 милиона долара годишни брутни приходи през предходната календарна година. Тестът за приходите е консолидиран: компаниите майки, дъщерните дружества и общо контролираните свързани лица се събират заедно. Малък стартъп за ИИ, който е набрал милиард долара финансиране, но е спечелил 40 милиона долара действителни приходи, не е голям разработчик на авангарден ИИ; публично търгуван технологичен конгломерат с малко подразделение за ИИ, което пресича прага на FLOPs, почти сигурно е такъв.

Разделянето на нива е важно, защото големите разработчици носят най-тежките задължения: публикуване на рамка за авангарден ИИ, провеждане на оценки на катастрофален риск, подаване на тримесечни обобщения на риска за вътрешна употреба до Службата за извънредни ситуации на Калифорния и поддържане на анонимен вътрешен канал за сигнали. По-малките разработчици — тези над прага на FLOPs, но под прага на приходите — все пак трябва да публикуват доклади за прозрачност и да докладват критични инциденти за безопасност, но не са задължени за пълния режим на рамката.

Какво трябва да публикувате: Рамката за авангарден ИИ

Всеки голям разработчик на авангарден ИИ трябва да публикува рамка за авангарден ИИ на своя уебсайт и да я поддържа актуална. Годишният преглед е задължителен, а всяка съществена модификация трябва да задейства актуализация в рамките на 30 дни след промяната.

Една защитима рамка разглежда най-малко:

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

Рамката не е маркетингов документ. Тя е артефакт за регулаторите, който Главният прокурор може да използва, за да прецени дали публичните ангажименти на компанията съответстват на вътрешната ѝ практика. Изготвянето ѝ със същата строгост като оповестяването на рискови фактори към SEC или описание на системата по SOC 2 е правилната нагласа.

Отчети за прозрачност преди всяко внедряване

Всеки разработчик на авангардни модели — не само големите — трябва да публикува отчет за прозрачност преди внедряването на нов или съществено модифициран авангарден модел. Отчетът за прозрачност е специфичен за модела документ, отделен от рамката, който трябва да включва:

Име на компанията, уебсайт и механизъм за контакт относно опасения за безопасността
Дата на пускане на модела и списък с поддържаните езици и модалности на изхода
Предвидени употреби и приложими ограничения за ползване
За големите разработчици – обобщение на оценките на риска от катастрофални събития и резултатите, включително дали и как са били ангажирани външни оценители

„Съществена модификация“ включва големи подобрения на възможностите, добавяне на нови модалности и значителни промени в микса от данни за обучение. Корективните версии (patch releases) и рутинните фини настройки за безопасност обикновено не изискват нов отчет за прозрачност, но граничните случаи трябва да бъдат документирани с писмена обосновка, в случай че Главният прокурор по-късно попита защо не е бил публикуван отчет.

15-дневният срок за докладване на критични инциденти

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

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

Неоторизиран достъп до или кражба на непубликувани тегла на модела
Реализиране на катастрофален риск
Загуба на контрол от страна на разработчика върху внедрен модел
Измамно или уклончиво поведение на модела, което преодолява защитните механизми

Изграждането на защитим вътрешен процес означава отговор на три въпроса, преди да възникне какъвто и да е инцидент:

Кой взема решението? Един определен служител (често главният служител по безопасност на ИИ или назначен заместник) трябва да има правомощието да стартира часовника за докладване, с документирани критерии за ескалация.
Какво стартира срока? „Откриването“ е тригерът. Вътрешната документация трябва да улавя точно кога е открит инцидентът, от кого и чрез коя система за мониторинг, тъй като 15-дневният прозорец се изчислява от този момент.
Как се предава докладът? Cal OES поддържа поверителен процес за приемане на заявления от разработчици. Екипът за докладване трябва да упражнява работния процес по подаване — включително криптирано предаване на чувствителни технически детайли — много преди да възникне реален инцидент.

За големите разработчици на авангардни модели задължението надхвърля реактивното докладване на инциденти. На всеки три месеца (или съгласно друг разумен график), големите разработчици трябва да предават на Cal OES резюме на всяка оценка на риска от катастрофални събития, произтичаща от вътрешната употреба на техните авангардни модели. Тази тримесечна периодичност е уникална за SB 53 и е първият случай, в който американски закон задължава лабораториите за ИИ да докладват текущи констатации за рискове при вътрешна употреба на орган на изпълнителната власт.

Защита на лицата, подаващи сигнали, и анонимен вътрешен канал

SB 53 добавя към общия режим на Калифорния за защита на лицата, подаващи сигнали за нарушения (whistleblowers), набор от специфични за ИИ защити, които се прилагат за „обхванати служители“ — тези, чиито задължения включват оценка, управление или справяне с риска от катастрофални вреди от авангардни модели.

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

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

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

Големите разработчици на авангардни модели трябва също така да поддържат анонимен вътрешен канал за докладване. Законът изисква:

Работен процес, позволяващ на обхванатите служители да подават анонимни сигнали относно опасения за катастрофален риск
Месечни актуализации на статуса към служителя, подал сигнала, относно разследването
Тримесечни брифинги за служителите на ръководни позиции и директорите, които обобщават разкритията и резултатите, като посочените лица, обвинени в нарушение, се изключват от аудиторията на брифинга

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

Дефиниция на катастрофален риск

Центърът на тежестта на SB 53 е неговата дефиниция за „катастрофален риск“. Законът го определя като предвидим и съществен риск, че авангарден модел ще допринесе значително за смъртта или сериозното нараняване на повече от 50 души, или за повече от 1 милиард долара щети или загуба на имущество, чрез един от три причинно-следствени механизма:

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

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

Граждански санкции и правоприлагане

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

На практика рискът от правоприлагане е концентриран в три области:

Манипулиране на праговете. Компании, които структурират тренировъчните процеси така, че да останат малко под 10^26 FLOPs, докато същевременно предоставят способности от висок клас (frontier-class), ще бъдат обект на внимателна проверка. Текстът на закона относно кумулативната изчислителна мощ прави тази стратегия несигурна.
Пропуски в рамката. Рамка, която изброява политики без доказателства за тяхното прилагане, ще бъде по-лесна за атакуване от такава, която обвързва всеки ангажимент с оперативни артефакти, посочени отговорници и одитни логове.
Закъснения при докладване на инциденти. Пропускането на 15-дневния срок или на 24-часовия срок при непосредствена заплаха е вид ясно, документируемо нарушение, което регулаторите исторически преследват агресивно.

Изграждане на 90-дневен план за внедряване

За организация, която все още не е стартирала програма по SB 53, следната последователност работи добре:

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

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

Дни 31 до 60: Изготвяне и управление.

Изготвяне на рамката за авангарден ИИ (frontier AI) като документ с версии, който може да бъде публично оповестен.
Изграждане на методология за оценка на катастрофални рискове, включително оценки на способностите, моделиране на заплахи и критерии за обявяване на модел за притежаващ способности от висок клас в опасна област.
Установяване на контроли за киберсигурност за непубликувани тегла, с документирани логове за достъп и мониторинг за вътрешни заплахи.
Създаване на анонимен канал за вътрешно докладване и работен процес за месечни актуализации на статуса и тримесечни брифинги за борда на директорите.

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

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

Координиране с други режими за ИИ и поверителност

SB 53 не съществува в изолация. Екипите по съответствие трябва да го съпоставят с:

Рамката за управление на риска в областта на ИИ на NIST (NIST AI RMF), към която законът изрично препраща и която осигурява голяма част от същинската управленска структура.
Нивото за ИИ с общо предназначение в Акта за ИИ на ЕС, където припокриването на документацията е значително и една единствена, хармонизирана вътрешна рамка може да задоволи и двете.
Закона за ИИ на Колорадо и Тексаския закон за отговорно управление на ИИ, които регулират задълженията на внедряващите лица за ИИ системи за вземане на решения с висок риск и могат да се прилагат за вашите крайни клиенти.
Калифорнийския закон за поверителност на потребителите (CCPA) и предстоящите правила на Калифорнийската агенция за защита на личните данни относно технологиите за автоматизирано вземане на решения, които се пресичат с внедряването на модели, но действат независимо от SB 53.
Доброволните ангажименти на федералния Институт за безопасност на ИИ и всяко бъдещо федерално законодателство с приоритетна сила, което би могло да промени базата за съответствие.

Точните записи за съответствие и ясните одитни следи са от съществено значение във всички тези режими — и същата дисциплина на документиране, която поддържа финансовата отчетност, поддържа и отчетността за управление на ИИ. Рамките за авангарден ИИ, оценките на катастрофални рискове, логовете за инциденти и записите от разследвания по сигнали на служители трябва да се съхраняват поне пет години по начин, който позволява запазването им при смяна на ръководството или корпоративно преструктуриране.

Поддържайте записите си за съответствие и финансова отчетност готови за одит

Независимо дали публикувате рамка за авангарден ИИ, планирате тримесечни подавания към Cal OES или се подготвяте за проверка от Главния прокурор, основната дисциплина е една и съща: ясни, контролирани по версии, подлежащи на одит записи. Същият подход на обикновен текст с контрол на версиите, който екипите за разработка на ИИ използват за своите кодови бази, работи отлично и за техните счетоводни книги. Beancount.io предоставя счетоводство в обикновен текстов формат, което ви дава пълна прозрачност и контрол върху вашите финансови данни — без „черни кутии“, без обвързване с доставчик и с чиста одитна следа, която естествено се съчетава с управленската дисциплина, която регулаторите вече изискват. Започнете безплатно и вижте защо разработчиците и финансовите професионалисти преминават към счетоводство в обикновен текстов формат.