AI Safety

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

Коротко

Коротко. AI Safety — это работа с рисками AI-систем: от ошибки в ответе до утечки данных или нежелательного действия агента. Безопасность не создаётся одним фильтром. Она складывается из границ сценария, проверки модели, минимальных прав, контроля человеком, журналов, мониторинга и процедуры на случай сбоя.

Что это такое

AI-модель почти никогда не работает одна. Вокруг неё есть данные, интерфейс, инструменты, пользователи и бизнес-правила. Поэтому безопасность оценивают у всей системы.

Например, одна и та же ошибка имеет разную цену:

• черновик письма можно перечитать и исправить;
• неверная медицинская подсказка способна повлиять на здоровье;
• агент с доступом к почте может отправить конфиденциальный файл;
• система с платежным инструментом может выполнить необратимую операцию.

AI Safety помогает заранее описать такие последствия и поставить защиту там, где она действительно нужна.

Из каких областей состоит AI Safety

• Надёжность. Система сохраняет ожидаемое поведение на необычных, шумных и неполных данных.
• Информационная безопасность. Модель и инструменты защищены от prompt injection, утечек, подмены данных и избыточных прав.
• Оценка поведения. Тесты измеряют не только среднее качество, но и опасные ошибки, отказы и крайние случаи.
• Снижение злоупотреблений. Продукт ограничивает сценарии, в которых его можно использовать для вреда.
• Управление. У решений есть владельцы, критерии запуска, журнал изменений и порядок остановки.
• Интерпретируемость. Команда пытается понять причины поведения модели и обнаруживать закономерности ошибок.
• Alignment. Поведение системы согласуется с поставленной задачей и допустимыми ограничениями.

Эти области пересекаются. Prompt injection одновременно относится к AI Safety и обычной кибербезопасности, а необъяснимая дискриминация — к безопасности, качеству и этике.

Риск начинается со сценария

Полезный первый вопрос звучит не «насколько опасна эта модель вообще?», а «что именно она может сделать в нашем продукте?».

Для описания сценария достаточно пяти элементов:

1. Кто пользуется системой. Сотрудник, клиент, ребёнок, злоумышленник или другой сервис.
2. Какие данные она видит. Публичные тексты, документы компании, медицинские сведения, пароли.
3. Какие действия ей доступны. Только ответ в чате, чтение файлов, отправка письма, запуск кода, платёж.
4. Как выглядит ошибка. Неверный факт, утечка, отказ, дискриминация, нежелательное действие.
5. Как ошибку заметят и остановят. Проверка человеком, лимит, журнал, автоматический тест или аварийное отключение.

Чем выше последствия и труднее обнаружение, тем сильнее нужны ограничения до запуска.

Жизненный цикл безопасности

Один из устойчивых способов организации работы — цикл управлять, описывать, измерять и снижать риск. Эту логику использует NIST AI Risk Management Framework.

1. Управлять

Команда определяет владельца системы, допустимые сценарии, правила доступа, требования закона и критерии остановки. Здесь же фиксируются поставщики, версии моделей и ответственные за инциденты.

2. Описывать

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

3. Измерять

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

4. Снижать риск

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

Защитные слои продукта

Универсального набора нет, но часто встречается такая комбинация:

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

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

Пример на практике

Компания добавляет помощника для обработки обращений клиентов. Он читает заявку, ищет справочную статью и предлагает ответ оператору.

На первом этапе помощник ничего не отправляет сам. Команда записывает его черновик, выбранный источник и правки оператора. Из этих данных становится видно, где модель путает тарифы, раскрывает лишнее или не замечает срочный случай.

После улучшения ей можно разрешить автоматически отвечать на узкий класс безопасных вопросов. Для остальных обращений остаётся проверка человеком. Если позже появится доступ к возвратам денег, это будет новый уровень риска и отдельный набор тестов — старый успешный чат-аудит его не покрывает.

Такой постепенный запуск даёт полезные данные без предположения, что модель либо «полностью безопасна», либо «совсем бесполезна».

Red teaming и evaluations

Обычный тест проверяет ожидаемый запрос. Red team специально ищет обходные пути:

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

Red team не заменяет количественную оценку. Найденные атаки превращают в повторяемые тесты, чтобы исправление не исчезло после смены модели или промпта.

С чем часто путают

• AI Safety и alignment. Alignment — часть более широкой работы с безопасностью.
• AI Safety и AI Ethics. Этика отвечает на вопросы справедливости, допустимости и общественных последствий; safety сосредоточена на управляемом риске. Граница между ними не жёсткая.
• AI Safety и cybersecurity. Кибербезопасность защищает систему и данные от атак. В AI-продукте она остаётся обязательным слоем, но не покрывает, например, вредный правдоподобный совет.
• Модерация и безопасность. Фильтр контента решает только часть задачи и может ошибаться в обе стороны.
• Отказ и безопасность. Слишком частый отказ тоже бывает вредным, если система перестаёт выполнять законную и важную работу.

Частые ошибки и заблуждения

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

«Если тесты прошли, риск закрыт». Трафик, атаки и версии меняются. После запуска нужны наблюдение и повторная проверка.

«Логи решают проблему». Журнал полезен только при ограниченном доступе, понятном сроке хранения и процессе разбора. Иначе он сам становится источником утечки.

«Человек в контуре гарантирует безопасность». Оператор может торопиться и автоматически соглашаться с моделью. Интерфейс должен показывать источник, сомнительные места и последствия подтверждения.

«Открытая модель всегда опаснее закрытой». Риск зависит от сценария, настройки и доступа. Открытые веса дают больше контроля над средой, а облачный сервис может давать встроенные ограничения; ни один вариант не безопасен автоматически.

Частые вопросы

С чего начинается минимальная программа AI Safety? С описания сценария, владельца риска, данных и возможных действий. Затем появляются собственный тестовый набор, минимальные права, журнал, ручное подтверждение для опасных операций и процедура реакции на инцидент.

Что такое red teaming? Это целенаправленная попытка вызвать нежелательное поведение системы. Результатом должны стать не только примеры атак, но и воспроизводимые тесты и изменения защиты.

Нужен ли AI Safety небольшому внутреннему инструменту? Да, но масштаб зависит от последствий. Для генератора черновиков может хватить ограниченных данных и проверки человеком; агенту с доступом к инфраструктуре нужны изоляция, права, лимиты и подробный аудит.

Как связаны безопасность и приватность? Приватность отвечает за допустимый сбор и использование данных. Safety учитывает, как утечка или неверная обработка этих данных может навредить. В AI-системах обе области часто встречаются в одном риске.

Существуют ли готовые стандарты? Да. Например, NIST AI RMF предлагает цикл управления риском, а ISO/IEC 42001 описывает систему управления AI в организации. Применимые юридические требования зависят от страны, отрасли и роли компании.

Главное

AI Safety — не запрет на использование моделей и не один фильтр перед ответом. Это способ связать возможности системы с последствиями: понять контекст, измерить ошибки, ограничить права, наблюдать за работой и уметь остановиться. Чем больше у AI доступа к данным и реальным действиям, тем важнее независимые защитные слои и ясная ответственность человека.