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

Внедрим ИИ в работу вашей компании
Бесплатно разберём процессы и подготовим план запуска ИИ.

Составьте карту инструментов и данных
Перечислите используемые сотрудниками ИИ-сервисы, их владельцев и задачи. Затем разделите данные: публичные материалы, внутренние инструкции, сведения о клиентах, договоры и учётные данные. Для каждого сочетания укажите разрешённый инструмент и условия доступа. Нельзя написать «конфиденциальное не загружать» и оставить сотрудников гадать, считается ли черновик КП конфиденциальным.
| Ситуация | Правило, которое должно быть понятно |
|---|---|
| Редактура публичной статьи | Можно ли использовать внешний сервис |
| Анализ обращения клиента | Какие данные обезличить и где работать |
| Подготовка договора | Какой контур разрешён и кто проверяет результат |
| Отправка ответа клиенту | Кто утверждает и отправляет |
Эта схема — пример вопросов для решения. Конкретные разрешения зависят от вашей инфраструктуры и договоров с поставщиками.
Разделите черновик и действие
ИИ может подготовить ответ, найти документ или предложить изменение карточки CRM. Отправка клиенту, изменение договора, платёж и доступ к закрытой системе — отдельные действия с отдельными правами. Укажите, какие из них требуют подтверждения человека. Если в компании есть агент, которому разрешены действия, запишите пределы по ролям и возможность быстро остановить его.
В NIST AI Risk Management Framework роли, измерение и постоянное управление рассматриваются вместе. Для внутренней политики это означает, что правила нельзя выпускать один раз навсегда: нужен владелец, журнал исключений и пересмотр после нового инструмента или инцидента.
Что делать сотруднику при ошибке
Правило должно описывать простой маршрут: остановить отправку, сохранить исходный запрос и ответ, сообщить ответственному, проверить затронутые данные и исправить результат. Если бот уже назвал клиенту неверную цену, сотрудник должен знать, кто ведёт коммуникацию и кто отключает ошибочный источник. Наказание за сообщение об ошибке только скроет случаи и ухудшит качество.
Добавьте примеры: модель придумала источник; вложение содержит личные данные; ИИ-агент изменил не ту карточку; сотрудник случайно вставил секрет. Для каждой ситуации достаточно конкретного контакта и первого безопасного действия.
Внедрение правил
Проверьте документ на трёх реальных задачах с сотрудниками разных ролей. Попросите их объяснить своими словами, что они сделают. Если ответы расходятся, формулировка слишком общая. Поддерживайте короткую страницу правил и отдельные инструкции для сложных сценариев, обновляйте их по конкретной дате и уведомляйте команду об изменениях.
Пример решения для типового дня
Менеджер хочет вставить в публичный чат переписку с клиентом и попросить резюме. Правило должно дать ясный ответ: разрешён ли этот сервис, какие данные нужно убрать, где находится согласованный корпоративный инструмент и кто проверяет результат. Если инструкция лишь говорит «соблюдайте конфиденциальность», сотрудник останется без решения. Включите в короткую страницу пять подобных сценариев из реальной работы команды.
Как проверять соблюдение без тотального контроля
Смотрите на доступность разрешённых инструментов, обучение и сообщения об ошибках. Если сотрудники регулярно обходят запрет, выясните, какую задачу официальный процесс не решает. Исправьте маршрут или предложите безопасный вариант. Журнал доступа и выборочная проверка критичных действий важнее попытки читать каждый промпт сотрудника. Правила работают, когда помогают делать работу и ясно показывают границы ответственности.
Правило для внешнего ИИ-сервиса
В документе должно быть ясно, кто разрешает новый сервис и какие вопросы задаёт перед подключением: где обрабатываются данные, как управляются доступы, доступны ли журналы, что происходит после прекращения подписки. Сотрудник не должен создавать рабочий процесс на личной подписке, к которой компания потом потеряет доступ. При этом запрет без альтернативы заставит людей искать обходной путь. Предложите разрешённый инструмент или канал оценки нового сервиса.
Как обновлять политику после ошибки
После инцидента уточните, был ли нарушен понятный пункт или сам документ не описывал ситуацию. Если сотрудник не мог понять правило о вложениях, перепишите его на примере. Если агент получил лишнее право, исправьте матрицу доступа и техническую настройку, а не только памятку. Укажите дату новой редакции и кому нужно пройти короткое повторное ознакомление.
Минимальная памятка рядом с инструментом
В интерфейсе рабочего ИИ полезно коротко напомнить: для каких задач он разрешён, какие данные сюда не загружать и где сообщить об ошибке. Полная политика может лежать отдельно, но сотрудник принимает решение в момент вставки документа. Если он узнаёт о запрете только после случайной отправки, правило плохо встроено в процесс. Для важных действий — письма клиенту, изменения CRM — показывайте явное подтверждение и источник результата.
Проверьте памятку с сотрудником, который не участвовал в её написании. Он должен суметь ответить, можно ли использовать конкретный файл, без звонка автору документа.
Общие правила превращаются в практику через матрицу доступа к документам.
О материале и источниках
Материал подготовлен редакцией Потока с участием ИИ. Первоисточники проверены 30 сентября 2026 года. Примеры иллюстрируют метод и не являются результатами испытания продукта редакцией. Обложка создана через ImageGen и не документирует реальное событие.
- NIST AI Risk Management Framework
Первичный материал для проверки подхода и границ применения; пример в статье подготовлен редакцией.
Опубликовано