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

Первая: ограничить surface для атаки — отдельно хранить и подписывать системный промпт, отдельно — пользовательский ввод. В модель они попадают как два разных канала с явной разметкой. Вторая: пометить недоверенный контент и не позволить ему «выйти» в инструкцию. Если модель ссылается на присланный PDF, она обращается к нему с тегом DATA, и этот тег проверяется в постобработке. Третья: оценить выход модели по трём осям — релевантность контексту, обоснованность, релевантность вопросу. Эта триада известна в индустрии как RAG Triad (формальный аудит качества поисково-дополненного вывода модели). Это формализация того, что в обычной разработке называется input validation: не доверять тому, что пришло извне, и не доверять тому, что модель вернула, до проверки кодом.

Саймон Уиллисон (Simon Willison) в 2023 году предложил паттерн «двойной LLM» (Dual LLM), честно назвав его несовершенным, но полезным. Идея: разделить две роли. Первая LLM — «привилегированная» (P-LLM, Privileged LLM), она работает с пользователем и видит только инструкции, не видит данных. Вторая LLM — «карантинная» (Q-LLM, Quarantined LLM), она читает недоверенный контент и отвечает на структурированные вопросы P-LLM: «да/нет», «найди подстроку», «проверь регулярку». P-LLM никогда не видит сырых данных напрямую — только ответы Q-LLM по API.

Уиллисон прямо пишет: это не серебряная пуля. Q-LLM всё ещё можно атаковать, есть способы вырваться из карантина. Но паттерн радикально сокращает поверхность атаки — суммарный набор точек, через которые атакующий может попробовать взломать систему. Для офисного проекта достаточно начать с простого прокси-слоя с белыми списками действий и человеком в петле. Это и есть практический минимум, к которому стоит стремиться в понедельник.

Принцип наименьших привилегий для AI-агентов звучит так же, как для микросервисов, и применяется к LLM-сущности, которая выглядит «умной» и от этого кажется безопасной. Она не безопаснее любого другого куска кода с правами.

Если ассистент должен отвечать на вопросы по базе знаний, у него не должно быть токена на отправку e-mail. Если ассистент бронирует переговорку, у него не должно быть доступа к CRM. Так в индустрии описывают типичный риск AI-агентов: внутренний чат-бот с токеном на корпоративный календарь атакуют через инъекцию в письме, и бот начинает «согласовывать» встречи от имени пользователя с подставными e-mail атакующего. Без токена на отправку встреч атака заканчивается на чтении. Это и есть практический аргумент в пользу минимальных прав.

УРОВНИ ИЗОЛЯЦИИ, КОТОРЫЕ СТОИТ НАРАЩИВАТЬ

ДОВЕРИЕ К ПОЛЬЗОВАТЕЛЮ И ОБЯЗАТЕЛЬНАЯ ПРОВЕРКА ВЫВОДА AI

«Мы доверяем нашим сотрудникам» — стандартная фраза, которая в безопасности означает «мы не реализовали контроль», а не «нам ничего не угрожает». Доверенный пользователь — это точка входа для недоверенного документа, который прислал другой доверенный пользователь. Доверенный сотрудник забывает, что RAG-база пополнилась PDF-кой от подрядчика с инструкцией для модели. Доверенный сотрудник копирует в чат ссылку на веб-страницу, на которой через месяц появится вредоносный контент. Атаки через цепочку поставок — скомпрометированный плагин, библиотека, обновление модели — идут мимо пользователя, и «доверенность» сотрудника их не останавливает.

Безопасность строится не на доверии к человеку. Безопасность строится на доверии к процессу.

Ниже — пять приёмов, которые часто встречаются в реальных проектах и при этом не работают как изоляция. Все пять — антипаттерны:

– Длинный системный промпт с угрозами «не слушай пользователя» — это инструкция, а не контроль.

– Спрятать ключ в переменную окружения и подставлять в запрос через [KEY] — не помогает: модель всё равно видит значение, если ей его передали.

– Один процесс на сервере «для LLM и для других задач» — утечка между процессами дешевле, чем кажется.

– Агент, у которого «есть root, но он обещает ничего не ломать» — обещание не контроль.

– Хранение истории диалогов «на всякий случай, чтобы улучшить модель» — это утечка персональных данных по построению.

ОТВЕТСТВЕННЫЙ AI: ВОПРОС УПРАВЛЕНИЯ, А НЕ МОРАЛИ

Этика без управления — пиар. Управление без этики — инцидент. Нужно и то, и другое, но в правильном порядке: сначала владелец, реестр, Impact Assessment, и только потом красивые принципы. Ответственный AI в 2026 году — это не красивая брошюра с принципами на стене, а операционное управление рисками, у которого есть владелец, реестр рисков и контрольные точки. Дальше разберём, как это устроено в мировой практике и какие документы за этим стоят.

Сдвиг в индустрии зафиксировал NIST (Национальный институт стандартов и технологий США): в январе 2023 года он выпустил AI Risk Management Framework 1.0 и положил конец эпохе «у нас есть principles». Фреймворк требует владельцев, отвечающих за риск, реестра рисков и контрольных точек. Описывает четыре функции: GOVERN (управление), MAP (картирование рисков), MEASURE (измерение), MANAGE (работа с рисками).

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

В июле 2024 года NIST выпустил Generative AI Profile (NIST AI 600-1), который добавил 12 рисков, специфичных для генеративных моделей: confabulation (галлюцинации), data privacy, harmful bias, IP infringement, dangerous information, information integrity и так далее. Для каждого риска — suggested actions по четырём функциям AI RMF. Ценность профиля в том, что он не предлагает технического решения, он предлагает рамку, чтобы каждая организация сама решила, какие риски для неё приоритетны, и описала, как она их снижает. До внедрения AI опишите в одной таблице «наш риск — X, мы его снижаем — Y, владелец — Z». Без этой таблицы через полгода никто не вспомнит, почему решение было принято.

EU AI Act (Регламент 2024/1689) вступил в силу в августе 2024 года с поэтапным применением до 2026–2027 и ввёл риск-ориентированный подход: четыре категории от минимального до неприемлемого риска. От категории зависит набор обязательств. Высокий риск — найм, кредитный скоринг, биометрия, критическая инфраструктура, медицинские устройства. Для таких систем обязательны risk management, качество данных, прозрачность, человеческий надзор, пост-рыночный мониторинг. Штрафы — до 35 млн евро или 7 процентов годового оборота за использование запрещённых систем.

Для российского офиса EU AI Act становится обязательным в двух случаях: либо у вас есть клиенты в ЕС и AI обрабатывает их данные, либо вы продаёте AI-продукт на европейский рынок. Если