Безопасность

5.2. Соответствие стандартам

Ответственный искусственный интеллект и соответствие стандартам

1. Наш подход к управлению ИИ

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

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

Мы придерживаемся многоуровневого подхода, который включает:

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

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

2. ISO/IEC 42001: система менеджмента искусственного интеллекта

ISO/IEC 42001:2023 - международный стандарт, определяющий требования к созданию, внедрению, поддержанию и постоянному улучшению системы менеджмента искусственного интеллекта (Artificial Intelligence Management System, AIMS).

Стандарт охватывает управление ИИ на организационном уровне: от определения целей и оценки рисков до контроля эксплуатации и совершенствования процессов. Он предназначен как для организаций, разрабатывающих ИИ-продукты, так и для тех, кто их предоставляет или использует. Официальное описание ISO/IEC 42001.

TozheBot развивает архитектуру и практики безопасности с учётом следующих направлений стандарта.

Управление рисками ИИ

ИИ-агенты могут сталкиваться с попытками prompt injection, раскрытием конфиденциальных данных, некорректными ответами и нежелательными действиями через инструменты.

В TozheBot предусмотрены технические механизмы, помогающие выявлять отдельные классы таких рисков:

ML-слой безопасности OGL-Mini анализирует сообщения на признаки потенциально опасных инструкций и утечки персональных данных.
Разграничение прав ограничивает доступ агента к инструментам и базам знаний.
События безопасности позволяют фиксировать обнаруженные подозрительные ситуации и анализировать их.
Аудит персональных данных помогает отслеживать определённые операции с данными.

Для развития соответствия принципам ISO/IEC 42001 эти средства должны дополняться систематической оценкой рисков, документированием принятых решений, назначением ответственных лиц и периодическим пересмотром эффективности мер.

Ответственность и контроль

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

Организационный уровень управления должен дополнительно определять:

кто отвечает за оценку и принятие ИИ-рисков;
кто утверждает запуск новых функций и интеграций;
кто рассматривает инциденты;
как документируются изменения и исключения из политик безопасности;
как проверяется эффективность защитных мер.

Мониторинг и постоянное улучшение

События безопасности и журналы аудита могут использоваться для выявления повторяющихся проблем, анализа инцидентов и улучшения защитных механизмов.

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

Важно: наличие отдельных технических механизмов не означает автоматического выполнения всех требований ISO/IEC 42001. Соответствие оценивается в отношении системы менеджмента организации в целом, включая процессы, документацию и свидетельства их фактического применения.

3. Защита ИИ-взаимодействий и OGL-Mini

TozheBot использует собственный ML-слой безопасности OGL-Mini для анализа взаимодействий с ИИ-агентами.

Репозиторий проекта: https://github.com/DevsDaddy/ogl-mini

Этот слой предназначен для выявления потенциально опасных входных данных, в том числе:

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

OGL-Mini дополняет, но не заменяет контроль доступа, проверку действий инструментов, ограничения на стороне сервера и мониторинг.

Обнаружение угроз не гарантирует их полного предотвращения. Результаты анализа могут зависеть от конфигурации, используемой модели, эвристик и доступности ML-компонента. В предусмотренных сценариях возможен переход к эвристической проверке при недоступности ML-компонента. Кроме того, режим обнаружения сам по себе не означает, что каждое подозрительное сообщение автоматически блокируется.

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

4. Изоляция агентов и принцип минимальных привилегий

TozheBot поддерживает разграничение доступа на нескольких уровнях:

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

Такой подход помогает уменьшить риск того, что агент получит доступ к ресурсам, не требующимся для его задачи.

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

При проектировании безопасных ИИ-сценариев рекомендуется:

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

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

5. Защита данных и криптографические механизмы

TozheBot использует криптографические механизмы для защиты настроенных полей данных. В проекте также применяется собственный протокол QuarkDash, ориентированный на постквантовый подход к защите данных.

Репозиторий проекта: https://github.com/DevsDaddy/quarkdash

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

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

Для управления ИИ-рисками необходимо рассматривать не только шифрование хранилища, но и весь путь данных: получение, передачу внешним моделям, обработку, журналирование, экспорт, хранение и удаление.

6. Мониторинг безопасности и аудит

TozheBot предусматривает механизмы регистрации событий безопасности и аудита определённых операций с персональными данными.

К событиям безопасности могут относиться:

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

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

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

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

7. Другие стандарты и рамки управления ИИ

ISO/IEC 42001 - не единственный ориентир для ответственного ИИ. В зависимости от сценария использования TozheBot может сопоставлять архитектуру и процессы с несколькими дополняющими друг друга стандартами и рамками.

ISO/IEC 23894: управление рисками искусственного интеллекта

Этот стандарт содержит рекомендации по управлению рисками, связанными с ИИ.

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

ISO/IEC 22989: терминология и концепции ИИ

Стандарт задаёт общую терминологию и концептуальную основу для описания систем искусственного интеллекта.

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

NIST AI Risk Management Framework

NIST AI RMF - добровольная рамка управления рисками ИИ, построенная вокруг четырёх взаимосвязанных функций:

Govern: управление, роли и ответственность.
Map: контекст использования и выявление рисков.
Measure: оценка и измерение рисков.
Manage: приоритизация рисков и выбор мер реагирования.

Для TozheBot эта модель служит практическим ориентиром при построении процесса оценки ИИ-рисков: от инвентаризации агентов и их возможностей до тестирования защитных мер и контроля инцидентов.

Официальный ресурс: https://www.nist.gov/itl/ai-risk-management-framework

ISO/IEC 27001 и ISO/IEC 27701

ISO/IEC 27001 посвящён системе менеджмента информационной безопасности, а ISO/IEC 27701 - управлению информацией о конфиденциальности.

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

Регулирование ИИ и защита персональных данных

В зависимости от юрисдикции, назначения агента, категории пользователей и характера обработки могут применяться законодательные требования, включая EU AI Act, GDPR и российское законодательство о персональных данных, в том числе Федеральный закон № 152-ФЗ.

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

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

8. Жизненный цикл ИИ-агента

Ответственное использование ИИ требует контроля не только во время выполнения запросов, но и на протяжении жизненного цикла агента.

Рекомендуемый процесс для проектов на TozheBot включает следующие этапы:

Определение назначения. Зафиксировать задачи агента, целевую аудиторию, допустимые сценарии и ограничения.
Оценка рисков. Определить возможные ошибки, угрозы конфиденциальности, риски доступа и последствия действий через инструменты.
Настройка ограничений. Выдать минимально необходимые разрешения, ограничить базы знаний и интеграции, настроить защитные механизмы.
Тестирование. Проверить обычные сценарии, некорректные входные данные, попытки prompt injection, нежелательный доступ и поведение при сбоях.
Эксплуатация и мониторинг. Отслеживать события, анализировать инциденты и пересматривать настройки.
Изменения и вывод из эксплуатации. Повторно оценивать риски после существенных изменений модели, инструментов, данных или назначения агента; безопасно отзывать доступ и обрабатывать данные при прекращении использования.

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

Если у вас есть необходимость получить помощь в вопросах комплайенса и безопасности, а также соблюдения стандартов - свяжитесь с нами.

9. Прозрачность, человеческий контроль и ограничения ИИ

ИИ-агенты могут формировать ошибочные, неполные или вводящие в заблуждение ответы. Механизмы безопасности снижают отдельные риски, но не устраняют вероятность ошибок полностью.

Для сценариев с существенными последствиями рекомендуется:

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

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

10. Что необходимо для подтверждения соответствия

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

Для развития системы управления ИИ на базе TozheBot целесообразно поддерживать следующие артефакты:

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

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

11. Границы заявлений о соответствии

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

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

Мы не считаем наличие отдельных защитных механизмов автоматическим подтверждением полного соответствия ISO/IEC 42001, ISO/IEC 27001, ISO/IEC 27701, GDPR, 152-ФЗ или другим требованиям. Такие заявления допустимы только в отношении фактически проверенной области и при наличии достаточных оснований. Поскольку сами стандарты еще активно развиваются, мы делаем всё возможное, чтобы стать частью данных стандартов.

Заключение

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

Изоляция проектов и агентов, разграничение разрешений, OGL-Mini, криптографические механизмы, события безопасности и аудит создают основу для снижения ряда рисков ИИ-агентов. Для зрелой системы управления необходимы также документированные процедуры, тестирование, человеческий контроль, регулярная оценка рисков и непрерывное улучшение. Однако это невозможно сделать только в рамках одной платформы и требует трехсторонней ответственности между платформой, бизнесом и конечным пользователем.

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