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