Чек-лист: 7 вопросов ИИ-вендору до подписания договора

Почему важно: Формулировка «в облаке» ничего не значит. Данные могут храниться в российском дата-центре, в европейском, в США — или вообще на сервере неизвестного субподрядчика. От этого зависит, под какую юрисдикцию попадает ваш бизнес и что будет с данными при инциденте.

✅ Что должно быть в ответе: 

✅ Конкретный адрес дата-центра или название хостинг-провайдера

✅ Схема потоков данных (Data Flow Diagram) — от ввода до ответа

✅ Подтверждение, что данные хранятся на территории РФ (требование 152-ФЗ, ст. 18)

✅ Список субподрядчиков, которые имеют доступ к инфраструктуре

🚩 Красный флаг: «Мы используем облако партнёра, там всё безопасно»

Если вендор не может назвать, кто этот «партнёр» и где физически лежат серверы — вы передаёте данные в чёрный ящик.

📄 Просить документально: 

• Схему архитектуры с указанием локаций серверов
• Договор с хостинг-провайдером (хотя бы выписку о локации)
• Перечень всех субподрядчиков

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

✅ Что должно быть в ответе: 

✅ Чёткий ответ: логируются или нет

✅ Если логируются — точный срок хранения (в днях)

✅ Кто имеет доступ к логам: роли, количество людей, процедура авторизации

✅ Процедура удаления логов по запросу клиента

🚩 Красный флаг: «Мы не сохраняем данные, но храним обезличенную статистику для улучшения сервиса»

«Обезличенная статистика» часто означает агрегированные паттерны на основе ваших данных. Уточните: какие именно поля собираются, можно ли их удалить, как проверяется обезличивание.

📄 Просить документально: 

• Политику логирования (лог-менеджмент)
• Техническое описание процесса анонимизации
• Регламент доступа к логам

Почему важно: Это самый опасный вопрос. Многие вендоры включают в пользовательское соглашение пункт о том, что клиентские данные могут использоваться для улучшения моделей. Даже если галочка «опт-аут» стоит по умолчанию, агрегированные паттерны и синтетические данные на основе ваших документов могут попасть в обучающие выборки.

✅ Что должно быть в ответе: 

✅ Прямой письменный отказ от использования ваших данных для обучения

✅ Этот отказ закреплён в договоре отдельным пунктом

✅ Техническое подтверждение: модель разворачивается отдельно для вас и не смешивается с данными других клиентов

🚩 Красный флаг: «Модель обучается на ваших данных, но это сделает её умнее для вас»

Это не «обучение для вас». Это передача вашей интеллектуальной собственности в чужой датасет. Если требуется дообучение — только локально, на изолированных весах, без внешних вызовов.

📄 Просить документально: 

• Пункт договора об отказе от использования данных для обучения
• Техническое описание изоляции модели (если требуется дообучение)
• Аудит весов модели до и после вашего пилота (опционально, но сильный маркер)

Почему важно: По закону субъект персональных данных может потребовать их удаления, и оператор обязан выполнить это в течение 10 рабочих дней. Но если ваши данные попали в векторные индексы, кэши, резервные копии и логи — «удалить из базы» недостаточно. Нужен технический пайплайн удаления.

✅ Что должно быть в ответе: 

✅ Описание процедуры удаления: какие системы затрагиваются, в какой последовательности

✅ Срок полного удаления (включая резервные копии)

✅ Подтверждение удаления актом или техническим логом

✅ Процедура удаления при расторжении договора

🚩 Красный флаг:  «Мы удалим данные из основной базы, но резервные копии хранятся 30 дней по политике безопасности»

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

📄 Просить документально: 

• Технический регламент удаления данных
• Образец акта об удалении
• Описание процедуры при расторжении договора

Почему важно: Если вендор не может развернуть решение без внешнего интернета — значит, архитектура построена вокруг внешних вызовов. Это автоматически означает, что данные покидают ваш периметр. Для данных, подпадающих под 152-ФЗ, коммерческую или врачебную тайну, это критический риск.

✅ Что должно быть в ответе: 

✅ Да, оффлайн-развёртывание возможно

✅ Описание архитектуры локальной версии (модель, векторная база, интерфейс)

✅ Требования к вашему оборудованию (конкретные характеристики)

✅ Подтверждение, что все компоненты работают без внешних вызовов

🚩 Красный флаг: «Оффлайн-версия возможна, но с урезанной функциональностью»

Уточните, что именно урезается. Если базовые функции (поиск по документам, генерация ответов, интеграция с вашей БД) требуют внешнего соединения — это не оффлайн.

📄 Просить документально: 

• Техническое описание оффлайн-архитектуры
• Спецификацию оборудования
• Схему сетевой изоляции (egress-правила)

Почему важно: Если ИИ имеет доступ к вашим документам, но все сотрудники видят всё — вы создали новую уязвимость. Бухгалтер не должен видеть техкарты, технолог — клиентскую базу, ИИ — только разрешённые сегменты. Все действия должны логироваться в вашей системе.

✅ Что должно быть в ответе: 

✅ Интеграция с вашей Active Directory / LDAP / другой системой учёта пользователей

✅ Настройка ролей: кто видит какие данные, кто может редактировать

✅ Логирование всех запросов и ответов в вашу SIEM-систему

✅ Процедура пересмотра прав (рекомендуется ежеквартально)

🚩 Красный флаг: «У нас все пользователи видят всё, но мы добавим роли в следующем релизе»

Если ролевой модели нет на старте — вы получаете доступ к системе, где любой сотрудник с логином может вытащить весь объём данных. Это не «доработка», это архитектурный дефект.

📄 Просить документально: 

• Описание ролевой модели с примерами
• Формат логов и способ интеграции с вашей SIEM
• Регламент пересмотра прав доступа

Почему важно: Инциденты случаются у всех. Вопрос не в том, будут ли они, а в том, как вендор на них реагирует. Если в договоре нет процедуры уведомления, сроков восстановления и ответственности — в момент утечки вы останетесь один на один с регулятором и клиентами.

✅ Что должно быть в ответе: 

✅ Срок уведомления об инциденте (рекомендуется не более 24 часов, по 152-ФЗ — не более 72 часов для РКН)

✅ Процедура расследования и предоставления отчёта

✅ План восстановления и минимизации ущерба

✅ Ответственность вендора по договору (штрафы, возмещение ущерба)

🚩 Красный флаг: «Мы уведомим вас в разумные сроки»

«Разумные сроки» — это юридическая ловушка. В договоре должны быть конкретные цифры: 24 часа на уведомление, 72 часа на отчёт, 7 дней на устранение.

📄 Просить документально: 

• Раздел договора об инцидентах безопасности
• План реагирования на инциденты (Incident Response Plan)
• Контактное лицо и каналы экстренной связи