Регламент работы с ИИ в компании: что зафиксировать

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

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

Когда пора оформлять правила корпоративного ИИ

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

Сигналы, что документ пора писать:

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

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

Разрешённые данные и права доступа

Этот раздел отвечает на вопрос «что модель вообще может видеть». Он фиксируется до первого запроса к модели, а не постфактум.

Что здесь записывают:

• Классы данных, разрешённые для внешних моделей. Часть информации нельзя выносить за контур, но тексты документов могут оставаться на сервере с локальной моделью эмбеддингов — тогда источник знаний работает внутри компании, а наружу уходят только запросы.
• Место работы системы. Ваш сервер или арендованная площадка в России; требования 152-ФЗ учитывают при выборе площадки и каналов доступа к моделям.
• Источники данных. Конкретный список: 1С, CRM, почта, Telegram, внутренняя база знаний, открытые каталоги.
• Права доступа. Агент получает минимальные права: читать сделки — да, менять статусы — нет. Секреты и ключи хранятся отдельно от кода и не передаются через формы, чаты и письма.
• Прямые запреты. Пароли, ключи доступа, специальные категории персональных данных и конфиденциальные документы в запросы к внешним моделям не попадают.

Допустимые задачи: где заканчивается автономность

Здесь правила корпоративного ИИ делят все операции на две группы: агент выполняет их сам и операции, которые ждут подтверждения человека. Границу проводят не по типу задачи, а по последствиям ошибки.

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

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

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

Подтверждения и ответственность

Точки подтверждения описывают формально: какое действие, кто подтверждает, в каком канале и что происходит, если подтверждения нет. По умолчанию действует правило: нет подтверждения — операция не выполняется.

Пример сценария. Отдел продаж использует агента, который читает сделки в CRM и готовит ответ клиенту. Агент сам формирует черновик и предлагает варианты сроков по складским остаткам. Отправка письма клиенту и изменение суммы в сделке всегда требуют подтверждения менеджера. Если клиент задал вопрос вне разрешённой темы, агент не отвечает, а передаёт диалог назначенному сотруднику. Всё, что агент сделал, попадает в журнал действий, поэтому спорную ситуацию можно разобрать по записям, а не по памяти участников.

Роли в регламенте:

• владелец процесса — руководитель отдела, он отвечает за результат и утверждает перечень операций;
• ИТ и ИБ — площадка, классы данных, права доступа, резервное копирование;
• куратор — принимает спорные случаи и подтверждает промежуточные результаты;
• сотрудник-пользователь — соблюдает инструкцию и не обходит точки подтверждения.

Журналирование: что фиксировать и где хранить

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

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

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

Порядок действий при инциденте

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

1. Остановить. Отключить агента или закрыть ему доступ к затронутой системе.
2. Зафиксировать. Сохранить журнал действий и содержимое диалога до исправления.
3. Оценить объём. Какие данные и какие операции затронуты, есть ли внешние последствия.
4. Уведомить. Ответственный куратор информирует руководителя процесса, ИТ и ИБ по согласованному каналу; секреты и ключи в канале обсуждения не появляются.
5. Восстановить. Откатить изменения, при необходимости восстановить из резервной копии.
6. Разобрать и поправить. Причина, изменение правил, точка подтверждения или доступа, обновление инструкции.

Шестой пункт пропускают чаще всего — и тогда инцидент повторяется.

Как ввести регламент и проверить результат

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

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

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

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

Частые вопросы

Кто утверждает регламент работы с ИИ в компании? Документ утверждает руководитель, который отвечает за результат процесса. Перед этим проект согласуют ИТ-служба и ответственный за информационную безопасность: они отвечают за площадку, классы данных и права доступа.

Нужна ли отдельная инструкция для сотрудников помимо регламента? Да. Регламент читают руководители и администраторы, а сотрудникам нужна короткая памятка: как ставить задачу ИИ, какие данные нельзя передавать и когда звать человека. Памятка живёт рядом с рабочим инструментом и обновляется вместе с ним.

Как регламент относится к публичным чат-ботам, которыми пользуются сотрудники? Публичные боты включают в политику отдельным разделом: перечисляют, какие типы данных туда передавать нельзя, и какие задачи решаются только в корпоративном контуре. Запрет без списка разрешённых альтернатив не работает.

Как часто нужно обновлять регламент? Документ пересматривают при изменениях в системе: смене модели, появлении новой интеграции, новом отделе или после инцидента. Раз в год пересмотр без учёта изменений почти ничего не даёт.

Что делать, если ИИ-агент работает с персональными данными? До запуска фиксируют площадку и классы данных, которые видит модель, а также операции, где обязательно подтверждение человека. Действия агента журналируются, доступы выдаются с минимальными правами.