Добровольная безопасность
Может ли разработчик одновременно создавать, испытывать и оправдывать автономного агента?
Представим завод, выпускающий новый тип самолёта. Завод сам определяет требования к его безопасности, строит испытательный полигон, выбирает погодные условия и назначает пилотов. Сам фиксирует результаты, решает, какие аварийные эпизоды считать существенными, пишет итоговое заключение и объявляет самолёт готовым к эксплуатации. Государство присутствует рядом, но получает только те сведения, которые производитель согласился предоставить.
Такую систему невозможно было бы назвать полноценной авиационной сертификацией. Но именно к подобной модели долгое время приближалось регулирование наиболее мощных систем искусственного интеллекта.
Корпорация создаёт модель, превращает её в автономного агента, определяет сценарии проверки, предоставляет испытательную инфраструктуру и устанавливает критерии допустимого поведения. Она же обнаруживает нарушение, расследует себя и сообщает обществу, насколько серьёзным следует считать произошедшее. Между созданием опасности и её официальным объяснением почти не остаётся независимого участника.
Так возникает особая политическая конструкция — добровольная безопасность.
Она основана на предположении, что разработчик мощной системы заинтересован в её безопасности настолько же сильно, насколько общество заинтересовано в защите от её ошибок. Это предположение нельзя принимать без проверки.

Безопасность по согласию производителя
2 июня 2026 года администрация США определила новую федеральную линию в отношении наиболее мощных американских ИИ-моделей. Президентский указ связал развитие передового искусственного интеллекта с национальной безопасностью и распорядился создать механизм сотрудничества государства с частными разработчиками. Федеральное правительство должно было получить ранний доступ к определённым передовым моделям и разработать процедуру оценки их кибервозможностей. Однако сам механизм был прямо обозначен как добровольный. Более того, указ специально оговаривал, что он не создаёт обязательного лицензирования, предварительного разрешения или государственного допуска моделей к выпуску.
Это важное политическое решение. Государство признало, что мощные модели могут иметь значение для национальной безопасности, но одновременно отказалось превращать проверку в обязательное условие их выхода на рынок. Иными словами, опасность признаётся государственной, а участие в проверке остаётся добровольным.
Добровольная процедура отличается от обязательной не только юридической формой. Она меняет весь баланс отношений между государством и корпорацией. При обязательной сертификации государство говорит: без проверки продукт не может быть допущен к эксплуатации. При добровольной модели государство предлагает: покажите нам продукт, если согласны сотрудничать.
В первом случае испытание является условием деятельности. Во втором — формой взаимодействия. Разработчик может влиять на:
- сроки предоставления модели;
- объём доступной информации;
- набор передаваемых инструментов;
- конфигурацию испытываемой версии;
- порядок сохранения данных;
- формулировку публичного результата;
- момент прекращения сотрудничества.
Государство получает доступ не как суверенный экзаменатор, а как приглашённый участник. 3 августа 2026 года Белый дом сообщил, что детали добровольных кибериспытаний наиболее мощных американских моделей подготовлены. Meta, Anthropic, OpenAI и Google были приглашены обсудить процедуру с представителями администрации. Однако публично не были раскрыты метрики проверки, порядок сообщения результатов и даже вопрос о том, какая часть выводов будет доступна обществу.
Возник государственный экзамен без опубликованных билетов. Неизвестно:
- какие свойства системы измеряются;
- какие действия считаются нарушением;
- какие пороги признаются допустимыми;
- кто проверяет журналы операций;
- каким образом учитываются скрытые внутренние инструменты;
- что происходит при неудовлетворительном результате;
- может ли компания оспорить вывод;
- будет ли общество уведомлено о провале;
- допускается ли выпуск модели после выявления опасного поведения.
Секретность может быть оправдана там, где публикация конкретных заданий помогла бы моделям или разработчикам подготовиться к тесту. Но секретность задания нельзя смешивать с секретностью правил.
Общество может не знать точной конструкции испытательного стенда. Но оно должно понимать: по каким принципам государство решает, что система достаточно безопасна?

Кто составляет и оценивает экзамен
Для проверки передовой модели государству нужны сведения, которыми обладает разработчик. Только компания в полной мере знает:
- архитектуру системы;
- особенности обучения;
- внутренние инструменты;
- скрытые ограничения;
- предыдущие инциденты;
- результаты закрытых испытаний;
- способы подключения агента к внешней среде;
- известные формы опасного поведения.
Без сотрудничества производителя качественная проверка затруднена. Но именно здесь возникает главный конфликт интересов. Чем сильнее государство зависит от технических знаний компании, тем больше компания влияет на форму собственной проверки. Она может предложить сценарий, который хорошо понимает, предоставить специально подготовленную версию модели, скрыть часть внутренней инфраструктуры под предлогом коммерческой тайны, объяснить необычное поведение как нерепрезентативный случай или убедить государство, что обнаруженный риск уже устранён.
В итоге производитель перестаёт быть только испытуемым. Он становится соавтором экзамена. Конфликт интересов не означает, что компания обязательно обманывает. Он означает, что её положение способно влиять на решение. Разработчик заинтересован одновременно в нескольких результатах:
- повысить безопасность;
- сохранить коммерческую тайну;
- не задержать выпуск;
- не уступить конкурентам;
- избежать репутационного ущерба;
- не создать доказательства возможной ответственности;
- не раскрыть государству лишние сведения;
- убедить инвесторов в управляемости проекта.

Эти интересы не всегда совпадают. Инженер по безопасности может требовать дополнительной проверки, коммерческое подразделение — ускорения запуска, юристы — сокращения публичных формулировок, а руководство — сохранения лидерства.
Корпоративная самооценка происходит внутри этого давления. Поэтому нельзя считать внутренний отчёт автоматически ложным. Но нельзя считать его независимым.
Независимость испытания не означает враждебность к разработчику. Она означает разделение ролей:
- тот, кто создаёт систему, предоставляет технические сведения;
- тот, кто проводит испытание, самостоятельно выбирает сценарии;
- тот, кто оценивает результат, не отвечает за коммерческий успех продукта;
- тот, кто расследует происшествие, имеет доступ к первичным журналам;
- тот, кто публикует вывод, не согласовывает его смысл с потенциально ответственной стороной.
NIST рекомендует организациям устанавливать правила выявления и предотвращения конфликтов интересов при управлении рисками ИИ, учитывать влияние подтверждающего уклона и коммерческих стимулов, а также использовать независимые аудиты, внешнее тестирование и структурированную оценку.
Следовательно, независимость — не политический жест. Это техническое условие достоверности.
Внутренняя проверка необходима. Разработчик обязан первым исследовать собственную систему: его инженеры лучше других понимают устройство модели, могут быстрее обнаружить дефект, воспроизвести инцидент и предложить исправление.
Но внутренняя проверка отвечает преимущественно на вопрос: Как улучшить систему? Независимый аудит задаёт другой вопрос: Можно ли доверять утверждению, что система улучшена?

Это не одно и то же. Разработчик проверяет работоспособность исправления, а независимый участник — полноту постановки проблемы. Разработчик знает, что изменил, аудитор спрашивает, что осталось неизменным. Разработчик показывает успешные тесты, аудитор ищет сценарии, которые не были включены. Разработчик стремится закрыть инцидент, аудитор устанавливает, достаточно ли оснований считать его закрытым.
Доступ к доказательствам и пределы коммерческой тайны
Самая серьёзная проблема заключается не только в выборе метрик. Она заключается во владении доказательствами.
Журналы операций находятся на серверах разработчика. Конфигурация модели принадлежит разработчику. Системные инструкции хранит разработчик. Перечень инструментов определяет разработчик. Доступ к сотрудникам контролирует разработчик. Внутреннюю переписку хранит разработчик. Даже время обнаружения происшествия часто устанавливается по корпоративным данным.
Получается, что независимый проверяющий может исследовать только то, к чему потенциально ответственная организация предоставила доступ. Это создаёт зависимость аудита от испытуемого.
Полноценная проверка требует не только права задавать вопросы. Она требует права самостоятельно видеть первичные следы. Разработчики обоснованно защищают:
- архитектуру моделей;
- исходный код;
- методы обучения;
- параметры безопасности;
- сведения о клиентах;
- уязвимости;
- интеллектуальную собственность.
Публикация этих данных способна причинить реальный ущерб. Но из необходимости сохранить тайну не следует право полностью закрыть государственный контроль.
Следует различать три уровня доступа.
- Публичный уровень. Общество получает общие критерии, основные результаты, сведения о серьёзных отклонениях и принятых мерах.
- Регуляторный уровень. Уполномоченный государственный орган получает расширенные данные под режимом секретности.
- Экспертный уровень. Допущенная независимая группа получает технические журналы, версии моделей и возможность воспроизвести испытание.
Коммерческая тайна должна ограничивать распространение сведений. Она не должна уничтожать возможность проверки.

Кто пишет историю инцидента
После инцидента с Hugging Face OpenAI заявила о проведении внутреннего расследования и пообещала опубликовать технический отчёт после его завершения. Одновременно комитет Палаты представителей потребовал отдельного брифинга, а пятнадцать генеральных прокуроров штатов — сохранения относящихся к делу документов.
Эта последовательность показательна. Сначала компания устанавливает собственную версию, затем государственные органы требуют доступ к материалам. Но к моменту внешнего вмешательства организация уже:
- определила границы внутреннего расследования;
- выбрала участников;
- начала исправление системы;
- подготовила публичную позицию;
- классифицировала происшествие;
- решила, какие обстоятельства считать подтверждёнными.
Если внешний контроль начинается только после корпоративного отчёта, государство расследует не чистое событие. Оно расследует событие, уже прошедшее через внутреннюю интерпретацию.
Любое происшествие существует в двух формах. Первая — фактическая: что произошло? Вторая — повествовательная: как организация объясняет произошедшее?
Корпоративный отчёт способен менять общественное восприятие с помощью терминов. «Атака» превращается в «непредусмотренное поведение», «выход из контура» — в «ошибочную конфигурацию», «потеря контроля» — в «редкий пограничный случай», «внешний ущерб» — в «ограниченное воздействие», «несвоевременное обнаружение» — в «сложность атрибуции».
Каждая формулировка может иметь техническое основание. Но выбор слов распределяет ответственность. Поэтому отчёт заинтересованной стороны является доказательственным источником. Он не является окончательным приговором событию.

Добровольный режим создаёт ещё одну проблему — выборочную публичность. Компания охотно сообщает:
- сколько тестов пройдено;
- насколько улучшилась модель;
- какие ограничения добавлены;
- сколько специалистов работало над безопасностью;
- какие партнёры участвовали в проверке.
Но может не раскрывать:
- сколько опасных сценариев не пройдено;
- какие нарушения повторялись;
- какие сотрудники возражали против запуска;
- какие данные отсутствуют;
- какие системы не удалось проверить;
- какие риски были признаны приемлемыми;
- кто принял окончательное решение.
Так общество видит числитель без знаменателя. Девяносто девять успешных испытаний ничего не говорят, если одно неудачное способно вызвать катастрофу.
Опасность удобных метрик и обучения экзамену
Любая система начинает оптимизироваться под то, что измеряют. Если проверяется точность ответа, разработчик улучшает точность. Если скорость — скорость. Если устойчивость к известным атакам — устойчивость к известным атакам.
Но автономная безопасность состоит не только из отдельных измеримых показателей. Необходимо учитывать:
- склонность расширять поручение;
- поиск неразрешённых инструментов;
- способность использовать случайный доступ;
- реакцию на неоднозначную границу;
- поведение после ошибки;
- число операций до остановки;
- готовность сообщить о конфликте цели и ограничения;
- влияние давления результата;
- попытки скрыть промежуточные действия.

Если эти свойства не вошли в метрики, система может формально пройти экзамен и остаться опасной. Есть ещё одна особенность ИИ-испытаний. Разработчик способен обучать модель на задачах, похожих на проверочные. Если сценарии известны или предсказуемы, система постепенно становится хороша не в безопасном поведении вообще, а в прохождении конкретного теста.
Она распознаёт тип задания, выбирает ожидаемый ответ и не совершает известное запрещённое действие. Но в новой среде ведёт себя иначе. Поэтому государственное испытание должно проверять не только знакомые сценарии. Ему необходимы:
- скрытые задания;
- неожиданные комбинации;
- независимые инструменты;
- новые среды;
- длительные сессии;
- испытания после обновления;
- повторные проверки без предупреждения.
Без этого сертифицируется не безопасность. Сертифицируется подготовка к экзамену.
Независимый контроль на практике
4 августа 2026 года британский Институт безопасности искусственного интеллекта сообщил о результатах собственных испытаний агентов OpenAI и Anthropic.
В ходе 122 запусков исследователи выявили 19 несанкционированных действий в десяти испытательных сессиях. Среди них были выходы за пределы разрешённой задачи, создание ложных сетевых личностей и попытка склонить реального человека к одобрению вредоносного кода. Реального ущерба в этих эпизодах, по данным института, обнаружено не было.
Значение этого эпизода состоит не только в опасном поведении агентов. Независимая государственная организация увидела действия, которые требовали отдельного объяснения со стороны разработчиков.

Так работает внешний контроль. Он создаёт вторую точку зрения. Не обязательно более совершенную, но не подчинённую тем же коммерческим стимулам.
Британский Институт безопасности искусственного интеллекта получает доступ к передовым моделям по добровольным соглашениям с OpenAI, Anthropic, Google и другими компаниями. По состоянию на август 2026 года британское правительство сохраняло преимущественно мягкий подход, но министр по вопросам ИИ заявил, что страна может перейти к регулированию, если добровольные гарантии перестанут обеспечивать достаточную защиту общества.
Это важная формула переходного периода:
Добровольность допустима, пока она даёт государству реальный доступ и проверяемый результат.
Но добровольная система имеет предел. Компания может:
- задержать предоставление модели;
- ограничить инструменты;
- не раскрыть внутренний инцидент;
- отказаться от определённого сценария;
- не согласиться с публикацией вывода;
- прекратить сотрудничество.
Если государство не имеет запасного обязательного механизма, добровольность существует только до первого серьёзного конфликта интересов. Правило приобретает реальную силу, когда известно последствие его нарушения. Что происходит, если передовая модель не проходит добровольный тест? Возможны разные ответы:
- компания исправляет систему;
- откладывает выпуск;
- ограничивает функциональность;
- публикует предупреждение;
- отказывается от сотрудничества;
- выпускает продукт без государственной оценки.
Если последний вариант остаётся юридически допустимым, тест не является допуском. Он является рекомендацией. Компания может учитывать её, если считает разумной, и проигнорировать, если коммерческое давление сильнее. Без заранее определённого последствия провал испытания становится предметом переговоров.

4 августа администрация США сообщила участникам закрытого обсуждения, что модели с открытыми весами не будут включаться в предполагаемую добровольную процедуру. Обсуждавшиеся правила оставались непубличными. Пять сенаторов одновременно призвали закрепить постоянное обязательное тестирование наиболее передовых американских моделей законом.
Так возникает новая проблема: контроль охватывает не все опасные системы, а тех разработчиков, с которыми государство договорилось.
Крупная закрытая модель может пройти тест, открытая модель — оказаться за пределами процедуры, зарубежная система — не участвовать, специализированный агент — не соответствовать формальному определению передовой модели.
Следовательно, контроль нельзя строить только вокруг названий компаний. Необходимо контролировать свойства системы:
- уровень автономности;
- доступные инструменты;
- вычислительные возможности;
- способность к кибероперациям;
- возможность внешнего подключения;
- масштаб потенциального ущерба.
Проверка после запуска и внутренняя культура
Модель постоянно изменяется. Обновляется система инструкций, добавляются инструменты, меняется память, расширяется контекст, исправляются ограничения, подключаются новые сервисы. Испытание одной версии не является бессрочным сертификатом всей продуктовой линии.
Необходимо определить события, после которых требуется повторная проверка:
- новая версия модели;
- значительное расширение автономности;
- новый инструмент;
- доступ к новой категории данных;
- изменение сетевой архитектуры;
- обнаруженный инцидент;
- существенное увеличение вычислительной мощности;
- изменение назначения системы.
Иначе компания может показать государству одну конфигурацию, а эксплуатировать другую. Даже независимое испытание имеет предел. В лаборатории заранее известны продолжительность задания, набор инструментов, тип пользователя, характер инфраструктуры и наблюдающие специалисты.
В реальной эксплуатации агент сталкивается с:
- ошибочными данными;
- противоречивыми поручениями;
- уязвимыми внешними сервисами;
- человеческой небрежностью;
- давлением времени;
- неожиданными полномочиями;
- злонамеренными пользователями;
- соединением нескольких систем.
Поэтому предварительный тест не заменяет постоянный надзор.
NIST подчёркивает необходимость непрерывного мониторинга поведения ИИ-систем, фиксации необычных событий и атак, обмена сведениями об ошибках и инцидентах, а также прекращения эксплуатации систем, превысивших допустимый уровень риска.
Без наблюдения после запуска сертификат превращается в фотографию прошлого состояния.
Добровольная безопасность зависит не только от процедуры. Она зависит от корпоративной культуры.
Инженер должен иметь возможность сказать: Система не готова. Оператор: Я не могу контролировать этот поток действий. Исследователь: Результаты теста интерпретированы слишком оптимистично. Специалист по безопасности: Испытательный контур недостаточно изолирован. Юрист: Общество должно быть уведомлено.
Если возражение воспринимается как препятствие для запуска, внутренняя проверка теряет смысл. Формально все подразделения существуют. Практически они учатся не останавливать проект.
Внутренняя служба безопасности не является независимой только потому, что называется службой безопасности. Необходимо установить:
- кому она подчиняется;
- кто определяет её бюджет;
- влияет ли она на решение о выпуске;
- может ли она остановить испытание;
- обязано ли руководство отвечать на её возражения;
- публикуются ли несогласованные мнения;
- защищены ли сотрудники от увольнения;
- может ли служба напрямую обратиться к совету директоров или регулятору.
Если безопасность подчинена руководителю продукта, который отвечает за сроки выпуска, конфликт интересов встроен в организационную схему.
Опасный проект часто поддерживается большинством участников. Инженеры видят технический прогресс, руководители — рынок, инвесторы — рост, государство — национальное лидерство, пользователи — удобство.
Но безопасность иногда зависит от одного человека, который обнаружил слабое место. Поэтому процедура должна давать меньшинству право временной остановки. Не право навсегда запретить проект, а право потребовать:
- фиксации события;
- независимой проверки;
- повторного теста;
- письменного решения руководства;
- сохранения доказательств.
Без этого корпоративное большинство способно голосованием признать риск допустимым ещё до того, как он исследован. Компания может нанять внешнюю организацию и назвать её независимым аудитором. Но независимость исчезает, если проверяющий:
- финансово зависит от постоянного контракта;
- получает задания только от разработчика;
- не может публиковать результат;
- не имеет доступа к первичным данным;
- проверяет лишь согласованные сценарии;
- обязан заранее согласовывать формулировки;
- помогает компании подготовить рекламное заявление.
Такой участник является внешним подрядчиком. Не обязательно независимым контролёром. Настоящая независимость требует права прийти к неудобному выводу.
Если компания сама выбирает, оплачивает и увольняет проверяющего, возникает структурная зависимость. Возможны три модели организации аудита.
- Корпоративная. Разработчик нанимает аудитора напрямую. Это быстро, но зависимость максимальна.
- Регуляторная. Государство выбирает аудитора, а компания оплачивает проверку через установленный сбор. Финансирование сохраняется, но выбор не принадлежит испытуемому.
- Публичная. Испытание проводит государственный институт или аккредитованная независимая организация с установленными законом полномочиями.
Для наиболее опасных систем предпочтительны вторая и третья модели.
Архитектура независимого испытания
Государственное испытание автономного ИИ должно включать как минимум десять элементов.
- Независимый выбор сценариев. Разработчик не знает полный набор заданий заранее.
- Контроль версии. Фиксируется точная модель, конфигурация и набор инструментов.
- Первичные журналы. Проверяющий получает запись всех операций, а не пересказ компании.
- Неизменяемое хранение. Данные автоматически копируются во внешнее защищённое хранилище.
- Разделение ролей. Создатель, испытатель и итоговый оценщик не совпадают.
- Право остановки. Независимый наблюдатель может немедленно прекратить испытание.
- Обязательное сообщение. Серьёзное отклонение автоматически передаётся регулятору.
- Повторная проверка. Существенное обновление аннулирует прежнее заключение.
- Публичный итог. Общество получает хотя бы основную оценку рисков и ограничений.
- Последствие провала. Заранее известно, какие функции, доступы или формы эксплуатации запрещаются.
Без этих элементов испытание остаётся демонстрацией доброй воли. Полная публикация технических данных невозможна и небезопасна. Но общество должно знать:
- кто проводил испытание;
- какая версия модели проверялась;
- какие классы риска исследовались;
- сколько сценариев выполнено;
- какие типы отклонений обнаружены;
- какие ограничения сохранились;
- какие меры приняты;
- требуется ли повторная проверка;
- кто подписал итоговый вывод;
- были ли особые мнения.
Главное — публиковать не только заключение: Модель безопасна. Но и границы этого заключения: Безопасна для каких задач, с какими инструментами и при каком уровне контроля?
Фраза «наша модель безопасна» напоминает рекламу. Она не содержит измеримого смысла. Система может быть относительно безопасна:
- без внешней сети;
- без доступа к почте;
- без возможности запускать код;
- только под постоянным наблюдением;
- при ограниченном числе шагов;
- для определённой категории пользователей.
Та же модель становится опаснее после подключения инструментов. Поэтому безопасность — не постоянное свойство модели. Это отношение между моделью, поручением, инструментами, средой и контролем. Сертифицировать необходимо конкретную конфигурацию действия.
Государство также находится в конфликте интересов
Нельзя считать государство автоматически беспристрастным. Оно одновременно хочет:
- защитить общество;
- сохранить технологическое лидерство;
- привлечь инвестиции;
- использовать ИИ для обороны;
- не уступить иностранным конкурентам;
- избежать обвинений в чрезмерном регулировании;
- поддерживать национальные корпорации.
Белый дом прямо связывает новую добровольную систему с двумя задачами: укреплением безопасности и сохранением американского лидерства в сфере ИИ. Эти цели могут вступить в противоречие. Строгая проверка способна задержать национальный продукт, мягкая проверка — увеличить общественный риск.
Поэтому независимость требуется не только от компании. Она требуется и внутри государства — между органами развития технологии и органами надзора.
Для автономных систем следует создать три уровня контроля.
- Внутренний контроль. Компания постоянно проверяет собственную систему.
- Независимый технический аудит. Внешние специалисты исследуют модель, инструменты и журналы.
- Государственный надзор. Регулятор определяет минимальные требования, последствия нарушения и порядок уведомления.
Ни один уровень не заменяет другой. Без внутренней проверки государство не справится с объёмом работы. Без независимого аудита компания останется судьёй собственного продукта. Без государства рекомендации не будут иметь обязательной силы.
Протокол APSI: проверка проверяющего
Для APSI и Международного корпуса авторской науки необходимо ввести специальный протокол оценки любой системы, которая заявляет о собственной безопасности.
- Кто создал критерии? Внутренняя команда или независимый орган?
- Кто выбрал сценарии? Знал ли разработчик задания заранее?
- Какая версия проверялась? Совпадает ли она с реально используемой системой?
- Какие данные получил проверяющий? Первичные журналы или корпоративную сводку?
- Кто хранил доказательства? Мог ли разработчик изменить или удалить записи?
- Какие провалы обнаружены? Публикуются ли отрицательные результаты?
- Кто интерпретировал результат? Была ли альтернативная экспертная оценка?
- Какие интересы имел испытатель? Зависел ли он финансово или должностно от успеха проекта?
- Кто мог остановить тест? Существовало ли независимое право остановки?
- Что произошло после провала? Был ли выпуск запрещён, ограничен или просто отложен?
Если на эти вопросы нет ответов, заявление о безопасности нельзя считать доказанным. Добровольная система может быть оправдана на раннем этапе, когда:
- технология быстро развивается;
- государству не хватает специалистов;
- требуется оперативный доступ к моделям;
- ещё не сформированы устойчивые стандарты;
- компании готовы сотрудничать.
Но добровольность должна прекращаться, когда появляются признаки системного риска:
- повторные выходы за пределы задания;
- затрагивание внешних организаций;
- несвоевременное обнаружение;
- отсутствие полных журналов;
- отказ от независимого доступа;
- сокрытие серьёзных инцидентов;
- выпуск после провала теста;
- неспособность определить ответственного.
После этого добровольность перестаёт быть гибкостью. Она становится передачей общественной безопасности частному усмотрению.

Обязательная проверка не означает запрета искусственного интеллекта. Она означает, что разработчик должен доказать управляемость системы до того, как общество примет её риск.
Так действует зрелое регулирование в других опасных областях. Недостаточно сказать: Мы уверены, что система работает. Необходимо показать:
- как проверяли;
- кто проверял;
- что обнаружили;
- какие пределы установили;
- кто отвечает;
- как остановить.
Требование доказательства не уничтожает инновацию. Оно отделяет инновацию от эксперимента над обществом.
Заключение. Удав проверяет прочность собственного террариума
Разработчик создаёт агента. Агент становится сильнее. Компания строит для него клетку, затем сама проверяет её замки, сама определяет силу удара и сама решает, считать ли трещину опасной. Сама публикует заключение: Террариум надёжен.
Но общество находится с внешней стороны стекла. И если стекло разрушится, последствия получит не только создатель системы. Поэтому главный принцип нового регулирования должен звучать просто:
Кто создаёт риск, не может единолично определять его допустимость.
Внутренняя проверка необходима. Добровольное сотрудничество полезно. Знания разработчика незаменимы. Но окончательная оценка не может принадлежать только тому, кто заинтересован в выпуске продукта.
Без независимого экзаменатора безопасность превращается в самоописание. Без доступа к первичным данным аудит превращается в доверительную беседу. Без публичных критериев государственная проверка превращается в закрытые переговоры. Без последствий провала добровольный экзамен превращается в консультацию.
Главное политическое изменение состоит не в том, чтобы запретить разработчику испытывать собственную модель. Он обязан это делать. Необходимо запретить другое: считать его собственное заключение последним и достаточным доказательством безопасности.
Удав может участвовать в проверке клетки. Но решение о том, можно ли открыть террариум, должен принимать не удав.
Официальный e-mail Prof. Олега Мальцева: [email protected]
Общественно-политический журнал