Политика использования ИИ в компании: что разрешить, что ограничить и кто отвечает

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

Практичная политика должна объяснять, что разрешено, какие данные нельзя передавать и где требуется проверка человеком.

Цель документа

Политика не должна быть только запретом. Её задачи:

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

Область действия

Укажите, кого и что охватывает документ:

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

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

Категории данных

Полезно разделить информацию на уровни.

Публичные данные

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

Внутренние данные

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

Конфиденциальные данные

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

Категории нужно согласовать с действующими документами компании, а не создавать параллельную классификацию.

Разрешённые сценарии

Можно перечислить безопасные примеры:

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

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

Сценарии, требующие согласования

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

Здесь важен не сам факт использования ИИ, а масштаб последствий ошибки.

Что запрещать явно

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

Проверка человеком

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

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

Ответственность за итоговый документ остаётся у сотрудника или владельца процесса.

Работа с кодом

Для разработки установите отдельные правила:

• не передавать секреты и закрытый код в неутверждённый сервис;
• проверять лицензии и происхождение фрагментов, где применимо;
• проводить code review;
• запускать тесты и анализ безопасности;
• не принимать объяснение ИИ вместо понимания изменения;
• фиксировать использование инструмента в критичных проектах;
• ограничивать доступ агента к репозиториям и окружениям.

Сгенерированный код должен проходить те же проверки, что и написанный человеком.

Подключение новых сервисов

Процесс может быть коротким:

1. Пользователь описывает задачу.
2. ИТ или ответственный проверяет условия сервиса.
3. Определяется тип данных.
4. Оцениваются настройки хранения и обучения.
5. Назначаются права и владельцы.
6. Проводится пилот.
7. Фиксируется решение и инструкция.

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

Корпоративные аккаунты

Управляемый доступ позволяет:

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

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

Обучение

Сотрудникам полезно показать:

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

Контроль без тотальной слежки

Компания может контролировать перечень сервисов, корпоративные аккаунты, подключения к данным и автоматические действия. Не стоит строить процесс только на подсчёте запросов. Гораздо полезнее анализировать реальные сценарии и инциденты.

Минимальная структура политики

1. Цель и область действия.
2. Термины.
3. Категории данных.
4. Разрешённые сценарии.
5. Запрещённые действия.
6. Согласование новых инструментов.
7. Проверка человеком.
8. Правила для разработки.
9. Реагирование на инциденты.
10. Ответственные и период пересмотра.

Итог

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

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