Почему компании нужна AI policy, даже если она не разрабатывает модели
Сотрудники уже используют чат-боты, генераторы изображений, расшифровку встреч, расширения браузера и AI-функции внутри привычных SaaS. Риск появляется не только при разработке модели: документ может уйти внешнему провайдеру, ответ - попасть клиенту, а агент - получить доступ к CRM.
Политика использования ИИ задаёт понятные границы, роли и путь согласования. Она должна ускорять безопасные сценарии, а не быть длинным запретом, который никто не читает.
Shadow AI: проблема видимости, а не только дисциплины
Shadow AI - использование неучтённых ИИ-сервисов, аккаунтов, расширений или автоматизаций. Люди выбирают их, когда официальный путь слишком медленный, а задача реальна. Жёсткий запрет без альтернативы переносит работу в личные аккаунты и ухудшает видимость.
Сначала узнайте сценарии: анонимный опрос, интервью команд, SaaS discovery, расходы, browser extensions и API keys. Не превращайте первичную инвентаризацию в наказание - иначе сотрудники будут скрывать полезную информацию.
Управляйте use case, а не названием модели
Один сервис используется для общедоступного brainstorm, анализа договора, отбора кандидатов и автономной рассылки. Риск радикально различается. Поэтому запись реестра связывает инструмент с целью, данными, людьми и действием.
| Один сервис | Сценарий | Риск |
|---|---|---|
| AI-чат | Идеи по публичному брифу | Низкий при проверке результата |
| AI-чат | Загрузка клиентского договора | Данные, договор и retention |
| AI-чат | Рекомендация по найму | Влияние на человека и bias |
| AI-агент | Отправка сообщений из CRM | Права, масштаб и side effects |
Минимальный реестр AI-систем и сценариев
- Название use case и бизнес-владелец.
- Пользователи и затронутые лица.
- Поставщик, продукт, модель и версия.
- Цель, входы, выходы и downstream action.
- Классы данных и источники.
- Интеграции, tools и разрешения.
- Уровень риска и применимые требования.
- Evals, human oversight и мониторинг.
- Договор, retention и регион обработки.
- Дата review и статус решения.
- План fallback, отключения и удаления.
NIST AI RMF прямо включает механизм инвентаризации AI-систем и безопасное decommissioning в функцию Govern.
Классификация данных: простые правила для сотрудника
Для каждого класса перечислите разрешённые среды. Формулировка «не загружайте чувствительное» бесполезна без примеров из процессов компании.
Классификация риска use case
Оценивайте последствия, а не впечатление от технологии. Учитывайте влияние на людей, обратимость, масштаб, автономность, доступ к данным, публичность, возможность независимой проверки и отраслевые требования.
| Уровень | Пример | Процесс |
|---|---|---|
| Низкий | Черновик по публичным данным | Разрешённые tools и обучение |
| Умеренный | Внутреннее резюме документа | Approved environment и owner |
| Высокий | Совет, влияющий на человека | Impact assessment, evals, oversight |
| Запрещённый | Обход прав, скрытая дискриминация | Не запускать и сообщить ответственному |
Красные линии политики
- Не передавать пароли, API keys, токены и private keys.
- Не загружать данные сверх разрешённого класса и цели.
- Не выдавать AI output за проверенный факт без процедуры проверки.
- Не принимать значимые решения о людях только по ответу модели.
- Не давать агенту лишние права и необратимые tools без approval.
- Не обходить договор, авторские права и правила источника.
- Не скрывать использование AI там, где требуется disclosure.
- Не продолжать работу после обнаружения возможной утечки.
Список адаптируется под организацию и законодательство; это не универсальная юридическая формула.
Разрешённый каталог должен быть полезнее запрета
Опубликуйте approved tools по задачам: тексты, код, изображения, встречи, поиск, документы и автоматизация. Для каждого укажите допустимые аккаунты, классы данных, настройки, ограничения, владельца и ссылку на обучение.
Предоставьте корпоративный способ входа и оплаты. Если сотруднику проще открыть личный бесплатный аккаунт, Shadow AI сохранится.
Быстрый review нового сервиса
Подготовь карточку первичной оценки AI-сервиса. Не делай юридический вывод. Сервис и тариф: [данные]. Use case: [цель]. Данные: [классы]. Интеграции и действия: [список]. Сформируй вопросы поставщику по договору, обучению на данных, retention, deletion, region, sub-processors, access control, logs, export, incident notice, model changes и decommissioning. Отдельно перечисли факты, которые нужно подтвердить в официальных документах и договоре.
Ответы маркетингового сайта не заменяют договор и security documentation. Актуальные условия проверяйте для выбранного тарифа.
Проверка поставщика и supply chain
- Кто является provider и processor для сценария.
- Используются ли inputs и outputs для обучения.
- Где и сколько хранятся данные и backup.
- Какие sub-processors и регионы задействованы.
- Есть ли SSO, MFA, RBAC и audit logs.
- Можно ли отключить sharing и удалить данные.
- Как уведомляют об инцидентах и изменениях модели.
- Какие evals, security tests и limitations документированы.
- Как экспортировать данные и прекратить использование.
- Есть ли альтернативный provider или manual fallback.
NIST относит third-party software, data и supply chain к отдельной области governance.
Роли: ответственность нельзя отдать комитету целиком
| Роль | Ответственность |
|---|---|
| Business owner | Цель, польза, процесс и результат |
| Data owner | Классы данных и допустимый доступ |
| Security | Threat model, credentials, logging, incident |
| Legal/privacy | Применимые требования и договор |
| Technical owner | Архитектура, evals, monitoring, rollback |
| Approver | Принимает остаточный риск в пределах полномочий |
У каждой записи реестра должен быть один accountable owner, даже если оценку выполняют несколько функций.
Минимальный шаблон внутренней политики
Политика использования ИИ - черновик 1. Цель и область действия. 2. Определения AI system, use case и approved tool. 3. Роли и канал вопросов. 4. Классы данных и разрешённые среды. 5. Разрешённые сценарии. 6. Сценарии с обязательным review. 7. Запрещённые действия. 8. Проверка результата и human oversight. 9. Покупка и подключение нового сервиса. 10. Инциденты и срочное отключение. 11. Логи, monitoring и retention. 12. Обучение и подтверждение ознакомления. 13. Исключения, срок и владелец. 14. Периодический review и история версий.
Дополните документ примерами из вашей работы и проверьте у ответственных за право, данные и безопасность.
Процесс исключения вместо неофициального обхода
Иногда запрещённый по умолчанию сценарий можно безопасно реализовать в другой среде или с обезличиванием. Форма исключения содержит цель, срок, данные, пользователей, controls, остаточный риск, владельца и план завершения.
Исключение не бессрочно. По окончании оно автоматически истекает, а доступ и данные удаляются либо проходят повторный review.
Обучение команды: тест на реальные ситуации
Одной презентации недостаточно. Дайте сотрудникам сценарии: письмо с клиентским вложением, meeting bot, расширение браузера, генерация кода с секретом, публичная картинка и автономная рассылка. Пусть они определят класс данных и следующий шаг.
Мониторинг политики без слежки за сотрудниками
Измеряйте покрытие реестра, использование approved tools, время review, просроченные исключения, прохождение обучения, инциденты и закрытие controls. Телеметрия должна быть пропорциональна цели и известна сотрудникам.
Не собирайте полный текст prompts «на всякий случай». Он может содержать ещё больше чувствительных данных. Предпочитайте метаданные, DLP-сигналы и агрегаты с ограниченным доступом.
Incident response: сотрудник случайно загрузил данные
- Остановить дальнейшую отправку и сохранить необходимые идентификаторы.
- Сообщить по понятному каналу без самостоятельного сокрытия.
- Определить сервис, аккаунт, данные, время и получателей.
- Отозвать shared links, credentials и integrations.
- Запросить удаление по доступному процессу поставщика.
- Привлечь privacy, security, legal и владельца данных по критериям.
- Оценить обязательства уведомления и влияние.
- Добавить control, обучение и regression-сценарий.
Конкретные юридические действия и сроки зависят от данных и юрисдикции.
Review и безопасное прекращение использования
Модели, тарифы, политики обработки и sub-processors меняются. Назначьте review по времени и событию: изменение поставщика, новый tool, другой класс данных, инцидент или расширение аудитории.
Decommissioning включает отключение аккаунтов и ключей, удаление данных, остановку jobs, экспорт нужных артефактов, замену интеграций, уведомление пользователей и сохранение требуемого audit trail.
План внедрения за 30 дней
Финальный чек-лист AI governance
- Есть владелец AI governance и поддержка руководства.
- Собран реестр сервисов и use cases.
- Каждый use case имеет accountable owner.
- Классы данных описаны примерами.
- Риск оценивает влияние, обратимость и автономность.
- Approved catalog доступен команде.
- Красные линии короткие и однозначные.
- Новый сервис проходит быстрый review.
- Third-party условия проверяются по тарифу и договору.
- High-risk use cases получают impact assessment и oversight.
- Исключения ограничены сроком.
- Обучение основано на реальных сценариях.
- Есть безопасный канал сообщения об ошибке.
- Инциденты имеют playbook и владельца.
- Логи не собирают лишний content.
- Policy и реестр регулярно пересматриваются.
- Есть план fallback и decommissioning.
Рабочая политика делает правильный путь самым простым: сотрудник быстро находит разрешённый инструмент, понимает границы и получает помощь до того, как задача уйдёт в Shadow AI.