Архитектура безопасного ИИ — книга Гарика Давтяна о защите ИИ-систем

Подкаст

Аудиоверсия на Patreon

Полная библиотека

10 $ / месяцподписка

Подписались один раз — слушаете все подкасты по безопасности, ИИ, культуре организаций и Lean: полный архив, новые выпуски и бонусы.

Коллекция по книге

29 $разовая покупка

Открыть коллекцию

Подкаст по книге: риски LLM и ИИ-агентов, архитектура защиты и управление ИИ на практике.

Garik Davtyan · Books & Podcasts

Открыть Patreon

Пишу о технологиях, безопасности, культуре и управлении.

О чём книга

Классические контроли не рассчитаны на систему, которую можно переубедить

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

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

Для кого

Тем, кто уже отвечает за ИИ-системы или будет отвечать завтра

CISO и архитекторам

Когда бизнес внедряет ИИ быстрее, чем вы успеваете описать для него модель угроз.

Риск-менеджерам и комплаенсу

Когда нужно свести ISO/IEC 42001, NIST AI RMF и EU AI Act в одну программу, а не в три параллельные.

Инженерным руководителям

Когда LLM уже в продукте и нужно понять, где проходит граница между подсказкой модели и действием кода.

Что внутри

Полный жизненный цикл — от модели угроз до реагирования на инцидент

Моделирование угроз для ИИ

Как описать угрозы, которых не было в классической ИБ: prompt injection, отравление обучающих данных, извлечение модели, утечка через контекст.

Архитектура LLM-приложения

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

Автономные агенты

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

AI red teaming

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

Реагирование на инциденты

Изоляция модели или агента, сохранение промптов и контекста для расследования, откат на заведомо чистую версию, уведомление регулятора.

Программа 90/180/365 дней

С чего начинать: инвентаризация ИИ-систем, владельцы, данные. Без этой видимости остальные контроли — угадывание.

Эталонная архитектура безопасного ИИ

Ключевая схема книги доступна отдельной интерактивной страницей: 4 зоны доверия, 4 точки контроля, сквозные слои управления, наблюдаемости и Secure ML CI/CD, а также 256 сценариев — от штатного запроса до составных атак и отказа контролей.

Слово автора

Идея появилась из довольно простой проблемы, которую я постоянно вижу в работе с организациями. Знания вроде бы есть, но они разбросаны по разным местам. Что-то лежит в ISO/IEC 42001, что-то в NIST AI RMF и EU AI Act, отдельно есть OWASP для LLM и MITRE ATLAS, а часть вообще существует только в голове архитектора, который уже набил шишки на живом проекте.

Каждый из этих источников полезен сам по себе. Но собрать всё это в цельную картину для конкретной организации, понятную и CISO, и разработчику, и руководителю бизнеса, — это уже отдельная работа. И обычно именно её никто не делает.

Я решил сделать её сам.

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

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

В итоге я пересобрал всё в одну логику: от инвентаризации ИИ-систем до реагирования на инциденты. Своими словами и в той последовательности, в которой сам объясняю эти вещи на встречах.

Это не пересказ стандартов по пунктам. Это попытка быстро ответить на более практичный вопрос: где действительно есть риск, а где вокруг ИИ просто много шума.

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

Гарик Давтян

Вопросы

Что чаще всего спрашивают

Как защитить LLM-приложение от prompt injection?

Prompt injection не закрывается одним фильтром — нужна многослойная защита: валидация ввода, guardrails, фильтрация вывода и строгое разделение между тем, что модель предлагает, и тем, что коду разрешено выполнить. В книге эта архитектура разобрана подробно.

На каких стандартах строить программу безопасности ИИ?

ISO/IEC 42001 даёт систему менеджмента, NIST AI RMF и AI 600-1 — практический риск-фреймворк, OWASP Top 10 for LLM Applications и MITRE ATLAS описывают ландшафт угроз, EU AI Act задаёт регуляторный минимум для высокорисковых систем. Книга показывает, как они складываются вместе, а не конкурируют.

Чем автономные ИИ-агенты отличаются от чат-ботов по рискам?

Агент не просто отвечает — он действует: вызывает инструменты, обращается к данным и может совершить необратимую операцию, исходя из собственной трактовки задачи. Эта автономия требует границ полномочий, подтверждения человеком для критичных действий и полной трассируемости. В книге это отдельный архитектурный паттерн.

Что на самом деле проверяет AI red teaming?

Это не то же самое, что классический пентест. AI red teaming проверяет, можно ли заставить модель выдать данные, обойти guardrails или совершить непредусмотренное действие — и, что важнее, выдерживает ли это давление приложение вокруг модели, а не только сама модель.

Как реагировать на инцидент с участием ИИ-системы?

Для ИИ-инцидентов нужен свой плейбук: изоляция модели или агента, сохранение промптов и контекста для расследования, откат на заведомо чистую версию, уведомление регуляторов в рамках EU AI Act. В книге есть шаблоны для каждого из этих шагов.

С чего начинать построение программы безопасности ИИ?

С инвентаризации: какие ИИ-системы существуют, кто ими владеет, каких данных они касаются. Без этой видимости любой другой контроль — угадывание. Программа на 90/180/365 дней в книге построена именно вокруг такой последовательности.