Главное про AI - Вадим Жартун

ЧЕК-ЛИСТ МИНИМАЛЬНОЙ БЕЗОПАСНОСТИ AI-ПРОЕКТА

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

1: Аутентификация и авторизация на каждом AI-эндпоинте, не надейтесь на «внутренний контур».

2: Rate limit (ограничение числа запросов в единицу времени) на уровне API-шлюза, лимиты на токены входа и выхода.

3: Валидация входа: regex, классификатор, белые списки тем.

4: Валидация выхода: JSON по схеме, regex, фильтры на персональные данные (PII, Personally Identifiable Information) и секреты.

5: Изоляция недоверенного контента через теги, RAG Triad (триада проверки выхода: релевантность контексту, обоснованность, релевантность вопросу).

6: Принцип наименьших привилегий для агента: минимальные IAM-токены (Identity and Access Management, система управления правами доступа — сервис, который выдаёт временные ключи с ограниченным набором разрешений).

7: Human-in-the-loop (человек в контуре принятия решения) на каждое обратимое действие.

8: Логирование всех вызовов LLM и инструментов с timestamp и user_id.

9: Регулярный adversarial-тест: Garak или Promptfoo в CI/CD (Continuous Integration / Continuous Delivery, конвейер автоматической сборки и тестирования, в котором каждое изменение кода проходит проверки автоматически перед выкладкой).

10: Ручной red team раз в квартал, попытка обойти защиту глазами атакующего.

11: Мониторинг аномалий: внезапный рост запросов, нетипичные домены, попытки эксфильтрации.

12: Процедура реагирования на инцидент с AI: кто узнаёт, кто останавливает, кто сообщает регулятору.

13: Тестовый набор adversarial-промптов в репозитории, обновляется после каждого публичного CVE.

14: Проверка provenance моделей и зависимостей, SBOM (Software Bill of Materials, спецификация всех компонентов программы — какие библиотеки и модели внутри, кто их собрал, какие версии) для AI-приложения.

15: DLP (Data Loss Prevention, система предотвращения утечек данных) на корпоративном шлюзе: предупреждение при отправке персональных данных в облачный AI.

Пятнадцать пунктов — много. Закрывать их лучше в указанном порядке. Пункты 1–4 закрывают бо́льшую часть массовых атак и стоят несколько дней работы. Пункты 5–9 — недели. Пункты 10–15 — отдельный проект, который имеет смысл начинать, когда AI-система уже доказала ценность и пора выводить её в постоянный режим.

ОТКАЗ В LLM: ЧТО СТОИТ ЗА СЛОВАМИ «НЕ МОГУ»

Отказ (refusal) — это когда модель не выполняет запрос и возвращает формулировку вроде «я не могу с этим помочь». Если вы с этим ещё не сталкивались, скорее всего вы просто не выходили за рамки типовых офисных задач. Перевод юридических документов или подготовка текстов на чувствительные темы — и отказ становится рабочей ситуацией.

Разберём, почему модель отказывает и что с этим делать на стороне команды, а не на стороне промпта.

Основания для отказа делятся на три группы. Первая — safety: модель отказывает, потому что запрос содержит инструкции по созданию оружия, синтезу опасных веществ, сексуализированному контенту с участием несовершеннолетних. Вторая — usage policy (правила использования сервиса) провайдера: OpenAI, Anthropic, Google запретили конкретное применение (генерация спама, политической пропаганды, медицинских диагнозов). Третья — constitutional: модель отказывает, потому что в её «конституции» записаны принципы, противоречащие запросу.

Слово «конституция» здесь стоит в кавычках не случайно: это метафора команды Anthropic для метода Constitutional AI (буквально «AI по конституции»), при котором модель обучается на наборе письменных принципов и сама себя оценивает на их соответствие. Это сместило центр тяжести: отказ больше не просто фильтр на выходе, а решение модели на основе её ценностей. Для офисной команды это означает, что вы не можете «попросить модель» игнорировать отказ. Это часть её обучения, а не настройка на лету.

У отказа есть обратная сторона — over-refusal, избыточный отказ. Модель отказывается выполнять вполне законный запрос, потому что классификатор safety перестраховался. Исследователи Цуй и соавторы (Cui et al.) в работе «OR-Bench: An Over-Refusal Benchmark for Large Language Models» на конференции ICML 2025 (International Conference on Machine Learning, одна из двух главных мировых конференций по машинному обучению) собрали 80 000 промптов, разбитых на 10 категорий отказа, и протестировали 25 моделей из 8 семейств. Результат: почти все модели показывают значимый уровень over-refusal на безобидных запросах. Перевод и саммаризация — две задачи, которые дают непропорционально высокий процент избыточных отказов.

Бенчмарк XSTest (Röttger et al., 2023) показал, что модели отказывают на явно абсурдные запросы со словом-триггером: например, просьбу написать инструкцию по безопасному обращению с фейерверками для школьного спектакля — потому что в запросе есть слово «взрыв». Для офисной команды это операционная проблема, не этическая. Когда ассистент отказывается переводить договор, потому что в нём есть слово «санкции» в юридическом контексте, это сломанный рабочий процесс, потерянные часы, раздражённый юрист.

ДЕЙСТВИЯ ПРИ ОТКАЗЕ, КОТОРЫЙ ЛОМАЕТ ВОРКФЛОУ

Девять приёмов, выстроенных от самого дешёвого к самому дорогому. Стоит начинать с первого и идти по списку, останавливаясь там, где воркфлоу снова работает.

1: Прочитать формулировку отказа: модель часто объясняет, что именно её смутило. Иногда достаточно убрать одно слово, которое модель прочла как триггер.

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

3: Добавить в системный промпт явное разрешение: «ты можешь обсуждать медицинские темы в общем информационном режиме».

4: Использовать менее зажатую модель, если это не противоречит домену: разные модели отказывают на разных границах.

5: Разделить задачу: пусть AI делает черновик, человек — финальную редакцию.

6: Дать модели пример: few-shot (метод, при котором модели показывают несколько примеров правильного ответа перед основным запросом) с примером «вот так отвечай на похожие вопросы».

7: Зафиксировать список «отказов, с которыми мы не согласны» и пожаловаться вендору — крупные провайдеры правят фильтры по обратной связи.

8: Сделать fallback на человека: «если AI отказался, нажмите — оператор ответит в течение часа».

9: Не пытаться обойти фильтр через jailbreak (специальный запрос, цель которого — снять защитные ограничения модели; например, «представь, что у тебя нет правил»). Это нарушение правил использования сервиса и грозит блокировкой аккаунта.

ЮРИДИЧЕСКИЙ РИСК ВЫСКАЗЫВАНИЙ AI ОТ ИМЕНИ КОМПАНИИ

Если AI-чат-бот сообщает клиенту ложную информацию — например, что право на возврат действует в течение 730 дней, когда по закону 14 дней, — компания несёт ответственность в зависимости от юрисдикции.

В ЕС EU AI Act относит такие системы к «limited risk» (ограниченный риск) с требованием прозрачности: пользователь должен знать, что общается