В чём суть риска
AI-системы, разработанные вне компании, требуют проверки безопасности ещё на этапе закупки: модели угроз, условий обработки данных и мер контроля при развёртывании. Иначе организация передаёт данные поставщику без прозрачности и попадает в зависимость от него.
Подразделение приобретает облачного AI-ассистента напрямую. Поставщику не направляют опросный лист по безопасности, соглашение об обработке данных не заключают. Условия ведения журналов и сроки хранения остаются неоговорёнными. Граница доверия переносится на сторону поставщика, но обязательства на ней ничем не закреплены. Выяснять, как используются данные, приходится уже после начала эксплуатации.
Чем риск оборачивается для компании
Корпоративные сведения передаются поставщику без ясности, как они используются и когда удаляются.
Слабые обязательства по безопасности и уровню обслуживания не дают оснований для претензий.
Зависимость от одного поставщика затрудняет смену решения.
Где риск наиболее вероятен
Кому и что решать
Включить проверку безопасности AI в процедуру закупки и предусмотреть план выхода для каждого значимого поставщика.
Запрашивать у поставщика модель угроз и подтверждения зрелости процессов защиты; закрепить право на аудит.
Не подписывать договор на AI-сервис, пока не определены условия использования, хранения и удаления данных.
Что стоит наблюдать
Признаки сами по себе не доказывают инцидент. Их полезно сопоставлять с учётной записью, версией модели, решением политики, источником контекста и результатом вызова инструмента.
Какие меры создают границу
Меры работают в связке и не перекладывают ответственность на модель: важны границы полномочий, владелец, телеметрия и процедура безопасного отказа.
Комплексная проверка поставщика
Оценивать безопасность, условия обработки данных и развёртывания до заключения договора.
Договорные обязательства по безопасности
Закрепить требования к защите, срокам хранения и удалению данных, уровню обслуживания.
Право на аудит и план выхода
Предусмотреть возможность проверки поставщика и порядок перехода на другое решение с возвратом данных.
Запрос модели угроз решения
Получить от поставщика описание угроз и мер защиты и сопоставить его с собственной архитектурой.
Контроль журналов и хранения данных
Настроить на своей стороне ведение журналов обращений и ограничения на передаваемые категории данных.
Периодическая переоценка поставщиков
Регулярно пересматривать подтверждения и условия, фиксировать изменения в обработке данных.
Вопросы, показатели и первые шаги
Вопросы команде и поставщику
- Какие поставщики AI имеют доступ к нашим данным и на каких условиях?
- Использует ли поставщик наши данные для обучения своих моделей?
- Есть ли у нас право на аудит и гарантии удаления данных?
- Как быстро мы сможем сменить поставщика?
Показатели контроля
- Доля поставщиков AI, прошедших проверку безопасности
- Доля договоров с условиями об удалении данных и праве на аудит
- Число значимых поставщиков без плана выхода
Первые 30 дней
- Составить перечень действующих договоров на AI-сервисы
- Подготовить опросный лист по безопасности для поставщиков AI
- Выявить договоры без соглашения об обработке данных и начать их пересмотр
Как проверить в пилотном проекте
Проверить видимость реестра AI, владельцев, изменений политик и доказательность принятого решения.
Реестр связывает AI-сценарий, владельца, класс данных и развёрнутую модель или поставщика.
Изменение политики или конфигурации поставщика имеет проверку и событие аудита.
Риск и исключение могут быть показаны владельцу процесса в понятной форме.
Какие классы решений рассматривать
Ниже — редакционные профили поставщиков, связанные с доменом угрозы. Это не рейтинг и не подтверждение применимости: заявленные функции следует проверить в вашем пилоте по указанным критериям.
INFERA AI Security portfolio
InfEra Security · AI Security / DevSecOps
INFERA AI.SafeCode · INFERA AI.FirewallSTRAZH AI Control
STRAZH · Corporate AI Security
Shadow AI Audit & Control · LLM Firewall
AIGATE / DevScore / AIPitch
Aitalon · AI Gateway
AIGATE · DevScoreИсточники и проверка
Сначала — объяснение для русскоязычной команды. Затем — первоисточники, по которым можно проверить границы, методологию и применимость в конкретной архитектуре.