Глава 15 — Построение безопасной ИИ-организации

Опубликовано: 2026-05-24 Последнее обновление: 2026-07-13 Версия: 1
Глава 15 — Построение безопасной ИИ-организации

Глава 15 — Построение безопасной ИИ-организации

Пятнадцатый пост поглавного разбора LLM Primer VII: AI Security. Глава, обращающаяся с культурой безопасности, red teams, рисками поставщиков и долгосрочным сопровождением как с организационной инфраструктурой, несущей дисциплину через годы.


Зачем существует эта глава

Технические контроли без организационной дисциплины не переживают встречи со временем. Глава 15 проходит слой, где живут культура безопасности, практика red-team, оценка рисков поставщиков, непрерывная оценка и долгосрочное сопровождение. Предпосылка в том, что системы ИИ — часть периметра безопасности, а не инструменты, используемые внутри него: саму модель можно атаковать, манипулировать или извлечь, и её поведение может быть вектором для нижестоящих атак. Организационная инфраструктура должна это отражать. Глава опирается на опубликованные responsible-scaling-фреймворки — Anthropic, OpenAI, DeepMind, Microsoft, Meta — как на индустриальный этаж и прорабатывает, что требует поддержание этого этажа от команд и структур.

Если коротко: дисциплина безопасности прочна ровно настолько, насколько прочна организация, её несущая. Культура, red teams, оценка поставщиков, оценка и сопровождение — то, что превращает контроли из частей I–IV в практику, переживающую смены руководства, сокращения бюджетов и обновления моделей, приходящие каждый квартал.

15.1 Культура, red teams и внутренний аудит задают операционный этаж

Культура безопасности — общий набор установок, через которые члены организации адресуют безопасность в повседневной работе. Её сложно инжинирить напрямую; это нижестоящее свойство структур, стимулов и историй. Для AI-команд культура должна признать, что модель сама часть периметра и что AI-специфичные режимы отказа — prompt injection, галлюцинации, эрозия выравнивания — ответственность команды, а не чья-то ещё. Red teams дают культуре её измерение. AI Red Team Microsoft, учреждённая в 2018, была заметным публичным вкладчиком, а фреймворк PyRIT, выпущенный в 2024, дал полю конкретный инструментарий. Внутренние red teams отличаются от традиционных — входы естественно-языковые, а не сделанные эксплойты, поверхность атаки — поведение, а не код, критерий успеха — вывод модели, а не компрометация системы, — но дисциплина та же. Покрытие prompt injection, джейлбрейков, элицитации вредоносного контента, проверок смещения, утечки приватности и фактических ошибок — текущий ожидаемый scope. Внешний red teaming дополняет внутренний для приложений с высоким импактом. Внутренний аудит замыкает цикл, верифицируя, что контроли, которые организация заявляет, что имеет, — это контроли, которые действительно на месте, — та же дисциплина, что обслуживала information security десятилетиями, применённая к новому классу активов.

15.2 Оценка рисков поставщиков — слой цепочки поставок

Современные системы ИИ строятся из компонентов: foundation-модели от одного провайдера, инфраструктура файн-тюнинга от другого, инструменты оценки от третьего, векторные базы данных от четвёртого, observability-платформы от пятого. Цепочка поставок длинна, компоненты гетерогенны, и отказ любого из них может скомпрометировать целое. Оценка рисков поставщиков — дисциплина оценки рисков, вводимых цепочкой поставок, и управления ими. Начальная точка — инвентарь: организация, не знающая, от каких AI-вендоров зависит, не может оценить риски, которые эти вендоры вводят. Инвентарь захватывает потребляемые сервисы, вовлечённые потоки данных, контрактные условия, имеющиеся сертификации (SOC 2 Type II, ISO/IEC 27001, ISO/IEC 42001 где доступен), публичную информацию о позиции безопасности и критичность для операций. От инвентаря следует оценочная работа: обзор SOC 2 и ISO-отчётов, рассмотрение обязательств по обработке данных, оценка track record реагирования на инциденты, тестирование собственных заявлений вендора о безопасности и мониторинг сигналов, что позиция вендора изменилась. Стандарт ISO/IEC 42001 AI management system, опубликованный в 2023, становится естественной точкой фокуса для сертификации вендоров в ИИ, дополняя общие сертификации информационной безопасности, которые поле уже использует.

15.3 Непрерывная оценка и долгосрочное сопровождение замыкают цикл

Пред-развёртывательная оценка — снимок. Непрерывная оценка — операционная дисциплина, не дающая снимку устареть. Stanford HELM предоставляет публичную инфраструктуру для непрерывной оценки способностей и справедливости между моделями, и получающиеся дашборды позволяют организациям сопоставлять их развёрнутые модели с внешними референсами. Для внутреннего использования инфраструктура непрерывной оценки включает canary-промпты, запускаемые периодически с baseline-сравнением, red-team-пробы, запускаемые по расписанию и после обновлений модели, safety-бенчмарки, перезапускаемые для ловли регрессий, и продакшн-сэмплирование для человеческого обзора. Anthropic Responsible Scaling Policy, OpenAI Preparedness Framework и DeepMind Frontier Safety Framework каждый указывают триггеры и пороги, требующие дополнительной оценки при приближении к конкретным вехам способностей. Долгосрочное сопровождение продлевает дисциплину через годы. У моделей есть жизненный цикл — разработка, оценка, развёртывание, эксплуатация, обновление, депрекация. У каждого перехода есть требования сопровождения: разработка производит документацию и начальную оценку; развёртывание производит операционные обязательства; эксплуатация производит логи и оценку; обновление производит новые версии со своей документацией; депрекация производит обработку конца жизни. Cross-cutting-дисциплина, поддерживающая непрерывность через фазы, — то, что имя «сопровождение» несёт, и это слой, отделяющий организации, эксплуатирующие ИИ ответственно на горизонте лет, от эксплуатирующих его ответственно на горизонте кварталов.

Стоит запомнить: контроли в этой книге прочны ровно настолько, насколько прочна организация, их поддерживающая. Культура, red teams, дисциплина поставщиков, непрерывная оценка и сопровождение — слой, где дисциплина переживает смены руководства и квартальные перерасстановки приоритетов — или не переживает.

Что подготавливает глава 15

Глава 16 сужается до файн-тюнинга как отдельной поверхности безопасности. Глава обращается с файн-тюненным моделью как с артефактом, чьи свойства безопасности должны быть заработаны, а не унаследованы. Даже безобидные файн-тюнинговые данные могут эродировать выравнивание базовой модели, как показали Qi и др. в статье ICLR 2024 «Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!» Преднамеренное отравление — «Shadow Alignment» Yang и др. 2023 — превращает тот же механизм в атаку. Глава проходит механизм эрозии выравнивания, модель угроз отравления, CI-оценочные ворота, ловящие регрессии до развёртывания, техники выравнивания (RLHF, DPO, Constitutional AI, RLAIF), переустанавливающие то, что тюнинг эродировал, и дисциплину отката, превращающую плохое обновление в пятиминутный инцидент, а не в день борьбы с пожарами. Глава 17 затем закрывает том формирующимися угрозами.


Дальше — Глава 16: Безопасный файн-тюнинг и адаптация. Эрозия выравнивания через безобидные данные, преднамеренное отравление, оценочные ворота, останавливающие плохие чекпойнты, и реестр моделей, делающий откат рутинной операцией.

Хочется всю картину? В книжной главе — полное сравнение responsible-scaling Anthropic-OpenAI-DeepMind-Microsoft, шаблоны инвентаря вендоров, паттерны инфраструктуры непрерывной оценки и врезки In Plain English, которые эта статья только резюмирует. LLM Primer VII на Amazon →

SHO
SHO
CTO и основатель RECEIPTROLLER. Ориентирован на данные, движим инновациями, всегда любознателен.