Новые ИИ-стандарты Яндекса: требования комплаенса для российского бизнеса

Что произошло

22 сентября 2026 года дочерняя компания «Яндекса» Yandex B2B Tech вывела на российский рынок продукт AI-SPM (AI Security Posture Management). Решение интегрировано в платформу Yandex Security Deck и предназначено для непрерывного мониторинга и управления рисками в искусственном интеллекте. Система позволяет инвентаризировать ИИ-активы — модели, агентов, данные и инфраструктуру — а также выявлять уязвимости и опасные конфигурации. Параллельно с этим в информационном поле продолжает обсуждаться инициатива по созданию национального набора данных для тестирования нейросетей на соответствие российским ценностям.

Идея национального датасета была озвучена в СМИ 17 августа 2026 года со ссылкой на источники в «Коммерсанте». Предполагалось, что набор тестов и эталонных данных позволит проверять модели на предмет генерации контента, противоречащего «духовно-нравственным ценностям». Однако пресс-служба «Яндекса»随后 опровергла информацию о представлении такой концепции правительству, что оставляет статус инициативы неопределённым. На текущий момент не существует ни утверждённого стандарта, ни опубликованной методики тестирования.

Эти события происходят на фоне более ранних шагов «Яндекса» в области безопасности ИИ. Весной 2025 года компания запустила программу поощрения «белых хакеров» за поиск уязвимостей в генеративных нейросетях с выплатами до 1 млн рублей. 17 июля 2026 года «Яндекс» первым в России получил сертификат ISO/IEC 42001 для систем менеджмента ИИ в семействе моделей Alice AI, что подтверждает формализацию процессов управления рисками, но не гарантирует защиты от каждой конкретной угрозы. Совокупность этих действий формирует новый уровень ожиданий к зрелости управления ИИ-проектами в российском корпоративном секторе.

Как это устроено

AI-SPM: управление рисками ИИ-инфраструктуры

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

Ключевая механика AI-SPM — постоянная сверка текущего состояния инфраструктуры с эталонной политикой безопасности. Например, если корпоративный стандарт запрещает использовать определённую версию библиотеки для машинного обучения из-за найденной в ней уязвимости, AI-SPM автоматически обнаружит все инстансы, где она применяется, и сгенерирует оповещение. То же касается и прав доступа: система может выявить, что сервисный аккаунт, используемый для дообучения модели, имеет доступ к базам данных клиентов, что является грубым нарушением принципа наименьших привилегий.

Концепция национального набора данных

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

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

Экономика и модель ответственности

Запуск AI-SPM меняет экономическую модель обеспечения безопасности ИИ. Вместо периодических консультационных проектов или разовых пентестов компании переходят к подписной модели за непрерывный сервис. Это требует включения расходов на лицензирование в годовые бюджеты ИТ- и ИБ-подразделений. Инвестиции «Яндекса» в новое направление безопасности, превышающие 7,5 млрд рублей, свидетельствуют о том, что рынок рассматривается как долгосрочный и капиталоёмкий.

Важно понимать модель разделённой ответственности (shared responsibility). Провайдер, в данном случае «Яндекс», предоставляет инструменты: Guardrails для фильтрации контента, механизмы защиты от prompt injection, API для аудита. Однако клиент обязан настраивать эти политики, интегрировать их в свои процессы, реагировать на инциденты и нести ответственность за корректность работы ИИ в своих бизнес-сценариях. Провайдер отвечает за безопасность платформы, клиент — за безопасность приложений и данных, запущенных на этой платформе.

Ограничения и открытые вопросы

Несмотря на очевидную пользу, у новых подходов есть ограничения. В открытых источниках не указана стоимость лицензии AI-SPM, что затрудняет бюджетное планирование. Неясны и лимиты по количеству моделей, агентов или пользователей, включённых в один тариф. Для национального датасета ключевые вопросы — сроки утверждения, юридический статус (стандарт, рекомендация, закон?) и состав экспертной группы, которая будет определять «духовно-нравственные ценности». Без этих деталей инициатива остаётся скорее политическим, чем технологическим сигналом.

Как это выглядит на практике

Сценарий 1: Банк, использующий ИИ для скоринга

Крупный розничный банк внедрил модель для предварительной оценки кредитной заявки на основе анализа транзакций и данных из анкеты. С помощью AI-SPM банк провёл инвентаризацию и обнаружил, что сервис, дообучающий модель, имел доступ к полной базе данных клиентов, а не только к анонимизированной выборке. Система также выявила попытки внешнего злоумышленника провести prompt injection через API, отправляя в поле комментария к заявке скрытые инструкции для модели. После настройки политик доступа к данным и включения Guardrails для фильтрации входных запросов риск несанкционированного доступа к ПДн и манипуляции решениями модели был снижен.

Сценарий 2: Ритейлер с чат-ботом для поддержки

Сеть магазинов электроники использует генеративного чат-бота для консультирования покупателей. В ходе анализа AI-SPM выявил, что модель имела доступ к API внутренней системы учёта, что теоретически позволяло ей запрашивать информацию о наличии товара на складах. Более того, тестирование показало, что при определённых промптах бота можно было заставить «предоставить скидку» в виде генерации промокода, который затем оказывался рабочим. В результате были отключены лишние права доступа у агента чат-бота и введены жёсткие ограничения на генерацию любого текста, похожего на коды купонов или ссылки на внутренние системы.

Сценарий 3: Промышленное предприятие и предиктивная аналитика

Машиностроительный завод использует ИИ-модель для прогнозирования отказов оборудования на основе данных с датчиков. AI-SPM помог выявить, что поток данных с производственной линии (OT-сегмент) в облачную среду для обучения модели не шифровался, создавая риск перехвата промышленной тайны. Кроме того, система обнаружила, что одна из версий модели использовала open-source библиотеку с известной уязвимостью, позволяющей провести DoS-атаку на сервис инференса. После внедрения шифрования каналов данных и обновления зависимостей уровень безопасности производственных процессов был приведён в соответствие с корпоративными стандартами.

Что это значит для российской компании

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

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

Что делать: пошагово

1. Составьте реестр ИИ-активов. Зафиксируйте все модели, агентов, MCP-серверы, RAG-системы, используемые данные, их версии, владельцев и бизнес-процессы, в которых они задействованы. Без полного понимания того, что у вас есть, невозможно управлять рисками.
2. Классифицируйте сценарии по уровню критичности. Разделите все ИИ-проекты на категории: высокие риски (финансы, медицина, ПДн), средние (внутренняя автоматизация, аналитика) и низкие (генерация маркетинговых текстов). От уровня риска зависит глубина проработки мер безопасности.
3. Проведите аудит прав доступа и потоков данных. Чётко определите, какие данные и в каком виде поступают в модель, где они хранятся, передаются ли внешним провайдерам и используются ли для дообучения. Применяйте принцип наименьших привилегий.
4. Внедрите технические средства контроля. Настройте Guardrails для фильтрации входных и выходных данных, используйте механизмы защиты от prompt injection, изолируйте секреты (API-ключи, пароли) от кода агента и обеспечьте журналирование всех действий.
5. Разработайте внутренний набор тестов. Пока нет национального стандарта, создайте собственный бенчмарк для проверки моделей на галлюцинации, утечки данных, генерацию вредоносного контента, устойчивость к инъекциям и знание российской специфики.
6. Закрепите зоны ответственности. Владелец бизнес-направления отвечает за определение допустимого риска, ИТ-директор — за архитектуру и эксплуатацию, служба ИБ — за мониторинг угроз и реагирование, а юристы — за соответствие законодательству о персональных данных.
7. Оцените и протестируйте инструменты класса AI-SPM. Запустите пилотный проект на одной из некритичных систем, чтобы понять, как решение работает в вашей инфраструктуре, какую ценность приносит и какие ресурсы требует на интеграцию и поддержку.
8. Мониторите регуляторную среду. Отслеживайте новости о статусе национального датасета и других инициативах в области регулирования ИИ, чтобы своевременно адаптировать свои внутренние политики и процессы.

Типичные ошибки

1. Игнорирование цепочки поставок. Компания проверяет свою модель, но не проверяет, на каких облачных сервисах, библиотеках или оборудовании она работает. Уязвимость в любом звене компрометирует всю систему.
2. Смешение разработки и эксплуатации. Разработчики модели имеют полные права на продакшн-инстанс, что позволяет им незаметно изменять её поведение или выгружать обучающие данные. Это дорого обходится репутационными и юридическими издержками в случае утечки.
3. Недооценка рисков промптов. Считается, что основная угроза — в самой модели, в то время как пользовательский ввод (промпт) является одним из самых простых векторов атаки (prompt injection, jailbreak).
4. Отсутствие «человека в цикле» для критичных решений. Полная автоматизация решений в высокорисковых сферах (кредитование, медицина) без возможности экспертной проверки или ручного вмешательства приводит к катастрофическим ошибкам, которые сложно оспорить.
5. Считать сертификат панацеей. Наличие у поставщика сертификата, например ISO/IEC 42001, не освобождает заказчика от ответственности за безопасную эксплуатацию ИИ в своих сценариях. Сертификат подтверждает зрелость процессов разработчика, а не безопасность конкретного внедрения.
6. Экономия на документировании. Отсутствие чётко задокументированных политик использования ИИ, сценариев отказа и процедур реагирования на инциденты значительно усложняет расследование и увеличивает штрафы со стороны регуляторов.

Как понять, что вы на верном пути

1. У вас существует и регулярно обновляется единый реестр всех ИИ-активов компании с указанием владельцев и уровней критичности.
2. Риски ИИ-проектов оценены и одобрены не только ИТ-директором, но и руководителями бизнес-подразделений и службой информационной безопасности.
3. Процессы безопасности (тестирование, проверка прав, аудит) встроены в каждый этап жизненного цикла модели — от разработки до вывода в эксплуатацию и дообучения.
4. Вы внедрили технические средства контроля (Guardrails, фильтры), и их срабатывания регулярно анализируются, а не игнорируются как ложные срабатывания.
5. Существует формализованная процедура для вывода модели из эксплуатации в случае обнаружения некорректного поведения или критической уязвимости.
6. Ваш CIO и CISO говорят об ИИ на одном языке, обсуждая не только архитектуру и производительность, но и бизнес-риски, комплаенс и этические аспекты.

Вопросы, которые нам задают

Обязателен ли национальный датасет уже сейчас?

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

Достаточно ли сертификата ISO/IEC 42001 для комплаенса?

Нет, недостаточно. Сертификат ISO/IEC 42001 подтверждает, что у поставщика (например, у «Яндекса») существуют и поддерживаются процессы управления рисками в разработке ИИ. Он не гарантирует безопасности каждой конкретной модели и не снимает ответственности с заказчика за безопасную и корректную эксплуатацию технологии в своих бизнес-процессах.

Как AI-SPM интегрируется с существующими SIEM/SOC?

AI-SPM генерирует оповещения и данные о рисках, которые можно передавать в SIEM-систему для корреляции с другими событиями ИБ. Интеграция требует настройки коннекторов и правил обработки в SOC. Цель — включить события из ИИ-инфраструктуры в единый контекст реагирования на инциденты.

Что делать, если мы используем зарубежные модели (например, через API)?

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

Источники

• Яндекс вывел на рынок AI-SPM для управления безопасностью ИИ-инфраструктуры
• CNews: Яндекс запускает AI-SPM
• Коммерсантъ: Яндекс предложил тесты для проверки ИИ на нравственность
• РИА: Яндекс не представлял концепцию национального датасета
• Яндекс получил сертификат ISO/IEC 42001
• Известия: Инвестиции Яндекса в безопасность