AI Safety (безопасность ИИ)

Безопасность ИИ (AI safety) — это область практик, оценок и управленческих процессов, которые снижают вероятность вреда от ИИ-систем при разработке, внедрении и эксплуатации. Проще всего понимать ее не как одну функцию модели, а как постоянный цикл: определить риски, протестировать систему, ввести ограничения, проверить снова и пересматривать меры по мере изменений.

Единого канонического определения у термина нет. В официальных источниках NIST безопасность названа одним из essential building blocks of AI trustworthiness, в EU AI Act она раскрывается через непрерывное управление рисками для high-risk AI, а у разработчиков frontier-моделей — через versioned policies, behavior specs и deployment mitigations.

Английский термин: AI safety. Также встречается: безопасность искусственного интеллекта, безопасность систем ИИ. Близкие, но не тождественные понятия: AI risk management, trustworthy AI, frontier safety.

Простыми словами

Грубо говоря, безопасность ИИ — это ответ на вопрос: «Что может пойти не так, если эта система окажется в реальном процессе?» Не только на уровне вредного ответа, но и на уровне утечки данных, опасной автоматизации, неверных рекомендаций, обхода правил и неправильного использования.

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

Как это работает

Если собрать вместе официальные рамки и практики, то AI safety обычно выглядит как управляемый цикл. Для high-risk AI в ЕС Article 9 требует continuous, iterative risk-management process throughout the lifecycle, включая identifying, analyzing, estimating and evaluating risks, а также testing before market placement or putting into service. NIST AI RMF 1.0 описан как voluntary, rights-preserving, non-sector specific и use-case agnostic каркас; страница публикации также прямо трактует его как living document с formal review AI community no later than 2028.

Сценарий использования
        ↓
Выявление возможного вреда
        ↓
Анализ и оценка риска
        ↓
Тестирование до запуска
        ↓
Adversarial testing / AI red teaming
        ↓
Меры смягчения:
- правила поведения модели
- runtime-ограничения
- ограничения доступа
- человеческая проверка
        ↓
Запуск
        ↓
Мониторинг, повторные оценки, обновление мер

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

Отдельный слой — AI red teaming. NIST CSRC определяет его как structured adversarial testing effort, цель которого — найти flaws, vulnerabilities и possible misuse risks в AI system. Еще один слой — runtime-ограничения, которые часто оформляют как guardrails.

Еще одна важная часть — evaluations. UK AI Safety Institute подчеркивает, что оценки — это nascent science; они не являются comprehensive safety assessments и не предназначены для того, чтобы объявить систему «safe». Это полезная, но ограниченная практика: тесты помогают увидеть часть проблем, а не доказать отсутствие всех проблем.

Для более мощных frontier-моделей компании публикуют отдельные versioned frameworks. У Anthropic Responsible Scaling Policy текущая версия 3.4 вступила в силу 2026-07-08 и страница обновлена той же датой. Google DeepMind представил Frontier Safety Framework 2024-05-17, затем обновил его 2025-02-04 с stronger security protocols и deployment mitigations; на текущей frontier-safety page перечислены версии 1.0, 2.0, 3.0 и 3.1. У OpenAI Model Spec markdown-источник и архив released HTML versions вынесены в репозиторий, а release notes описывают Model Spec как living document.

Где применяется

• Корпоративные чат-ассистенты и support-боты. Здесь AI safety нужна, чтобы минимизировать вредные советы, несанкционированные действия и утечки чувствительной информации, а также проверять поведение системы до и после запуска.
• Кодовые ассистенты и AI-ревью в разработке. Если вы внедряете помощника вокруг Continue или используете AI-подсказки при ревью PR, как в сценариях вокруг CodeRabbit, безопасность ИИ означает контроль за опасными рекомендациями, доступами и последствиями автоматизации.
• Контент и креатив. В текстовой и визуальной генерации важно не только качество ответа, но и предотвращение нежелательного контента, нарушений внутренних правил и ошибочного использования автоматизации в продакшене.
• Frontier-модели и решения о масштабировании. Здесь в ход идут отдельные governance-подходы: threshold-based scaling, capability tracking, deployment mitigations и versioned policies, о которых пишут Anthropic и Google DeepMind.

Практический пример

Допустим, вы запускаете внутреннего LLM-ассистента для сотрудников. Минимально рабочий сценарий AI safety будет выглядеть так:

1. Зафиксируйте контекст использования. Кто обращается к системе, какие данные она видит, какие действия может инициировать и какой вред для вас неприемлем.
2. Составьте список рисков. Например: опасные инструкции, утечка данных, выдуманные ответы в критическом процессе, обход внутренних ограничений, некорректное использование модели вне изначального сценария.
3. Оцените риски до релиза. В логике Article 9 это не разовая заметка, а continuous and iterative process на протяжении lifecycle.
4. Прогоните тесты и adversarial-проверки. Для LLM-оценок можно использовать Inspect AI — open-source framework для evaluations, созданный UK AI Security Institute; в репозитории указаны built-in components и more than 200 pre-built evaluations.
5. Внедрите меры смягчения. Это могут быть правила поведения модели, runtime-ограничения, ограничение доступа к функциям, человеческое подтверждение для опасных действий и дополнительные проверки перед production use.
6. Повторите оценку после изменений. Если вы сменили модель, расширили доступы, добавили новые инструменты или изменили сценарий, прежние результаты тестов уже нельзя считать достаточными.

Практический вывод: если у вас нет документированного цикла «риски → тесты → меры смягчения → повторная проверка», то у вас, скорее всего, еще нет полноценной программы AI safety — есть только отдельные защитные меры.

Чем отличается от…

Ограничения и заблуждения

• Заблуждение: «AI safety = модель не говорит запрещенных вещей». На практике это только один слой. Safety включает lifecycle risk management, testing, red teaming, mitigations и post-deployment review.
• Заблуждение: «Если тесты пройдены, система безопасна». UK AI Safety Institute прямо предупреждает, что evaluations — nascent science, не comprehensive и не предназначены для маркировки системы как safe.
• Заблуждение: «Vendor policy = общий стандарт». Model Spec, Responsible Scaling Policy и Frontier Safety Framework полезны как ориентиры, но они vendor-specific и периодически пересматриваются.
• Ограничение: единого словаря нет. В source pack отдельно отмечено, что AI safety has no single canonical glossary; определения варьируются между NIST, регуляторами, вендорами и исследовательскими группами. Даже NIST trustworthy AI glossary опубликован как beta glossary.
• Ограничение: официальные summary pages не равны полной юридической экспертизе. Например, service-desk материалы по EU AI Act объясняют требования, но сами по себе не заменяют работу с binding legal text и отраслевыми обязанностями.
• Ограничение: документы живые. NIST AI RMF, OpenAI Model Spec и vendor frameworks прямо или фактически развиваются по версиям, поэтому даты, версии и scope нужно перепроверять перед внедрением политики у себя.

Редакционная оговорка: эта статья сознательно собирает термин из нескольких официальных рамок, потому что на дату source pack единого общепринятого определения AI safety не существует. Если вам нужен обязательный compliance-контур, ориентируйтесь не только на глоссарий и vendor docs, но и на требования вашей юрисдикции и класса системы.

Связанные материалы на COMRAD404

• Guardrails (ограждения) в AI-системах — соседний термин про runtime-ограничения.
• Copy.ai: ИИ для маркетинговых и sales-текстов — пример класса инструментов, где safety касается контента, политик и контроля применения.
• Freepik AI — пример визуальной генерации, где безопасность ИИ пересекается с правилами использования и рисками нежелательного вывода.

Источники

• AI Risk Management Framework | NIST
• AI Risk Management Framework – Resources | NIST

• Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Trustworthy and responsible AI | NIST
• Glossary – AIRC
• red teaming – Glossary | CSRC
• Article 9: Risk management system | AI Act Service Desk
• Anthropic’s Responsible Scaling Policy | Anthropic
• GitHub – openai/model_spec: The OpenAI Model Spec
• Model Release Notes | OpenAI Help Center
• Introducing the Frontier Safety Framework — Google DeepMind
• Frontier safety at Google DeepMind — Google DeepMind
• AI Safety Institute approach to evaluations – GOV.UK
• GitHub – UKGovernmentBEIS/inspect_ai: Inspect: A framework for large language model evaluations

Вопросы и ответы

Есть ли единое официальное определение AI safety?

Нет. В проверенном source pack прямо отмечено, что единого canonical glossary нет: трактовки различаются между NIST, регуляторами, вендорами и исследовательскими организациями.

Можно ли доказать безопасность модели одним набором тестов?

Нет. UK AI Safety Institute пишет, что evaluations — nascent science, не comprehensive safety assessments и не предназначены для того, чтобы объявить систему safe.

Нужна ли безопасность ИИ только frontier-моделям?

Нет. Frontier-модели действительно имеют отдельные frameworks, но NIST AI RMF 1.0 описан как non-sector specific и use-case agnostic, то есть сам подход к risk management шире, чем только frontier AI.

Достаточно ли следовать vendor policy вроде Model Spec или Responsible Scaling Policy?

Нет. Это полезные, но vendor-specific документы. Они не заменяют требования конкретной юрисдикции, внутреннее управление рисками и независимые проверки.