Условия сценария и участники
Допустим, в оптовой компании работают менеджер по продажам, бухгалтер, руководитель отдела и администратор. У каждого есть свой ИИ-агент. Данные о клиентах лежат в CRM и 1С, а права в этих системах уже разделены по ролям. Задача агентов — не расширять доступ, а работать в границах прав сотрудника.
Для наглядности возьмём один день и четырёх сотрудников. Всё, что делает агент, проходит через права его сотрудника, поэтому достаточно проследить, что видит и что может каждый из четверых.
Утро: менеджер видит своих клиентов
Менеджер просит агента подготовить список клиентов, с которыми нужно связаться сегодня. Агент читает CRM и показывает только карточки, закреплённые за этим менеджером. Чужие клиенты ему недоступны, потому что у менеджера нет к ним доступа. Агент готовит черновики писем, менеджер правит и отправляет их сам.
День: бухгалтер просит то, чего у агента нет
Бухгалтер спрашивает у своего агента о переписке менеджера с клиентом по условиям скидки. Доступа к почте менеджера у бухгалтера нет, поэтому агент отвечает, что данных не видит, и предлагает запросить их у менеджера или руководителя. Агент не обходит права и не пересказывает чужие письма.
Вечер: руководитель смотрит сводку и журнал
Руководитель получает сводку по отделу: активные сделки, просроченные задачи, обращения клиентов. Если нужно разобраться, почему агент предложил то или иное действие, он открывает журнал. Видно, кто просил, что агент подготовил и кто подтвердил. Для спорных случаев это основа разбора.
Что нужно настроить, чтобы такой день стал реальным
Для сценария нужна небольшая подготовка:
- матрица ролей: кто какие разделы CRM и 1С видит
- правило, что агент видит ровно то, что видит сотрудник
- список действий, требующих подтверждения человека
- порядок просмотра журнала и ответственный за него
- процедура отзыва доступа при уходе или переводе сотрудника
Роль, доступ и подтверждение в одной таблице
| Роль | Что видит агент | Что требует подтверждения |
|---|---|---|
| Менеджер по продажам | Свои карточки клиентов и переписку | Письма клиентам, изменения в сделках |
| Бухгалтер | Документы и расчёты, нужные для учёта | Платёжные документы, акты сверки |
| Руководитель отдела | Сводные данные по отделу и журнал действий | Передача клиентов между менеджерами |
| Администратор | Настройки, роли и доступы, но не содержание переписки | Любые изменения прав |
Что пойдёт не так, если права не настроены
Сценарий работает, только если права в системах настроены заранее. Если этого не сделать, возникают типичные проблемы:
- менеджер видит клиентов чужого отдела, и его агент показывает их в сводке
- бухгалтер получает доступ к переписке, которая ему не нужна
- уволившийся или переведённый сотрудник сохраняет доступ к данным
- никто не может восстановить, кто и что подтверждал
Персональные данные клиентов и роль юриста
Клиентские данные часто относятся к персональным. Платформа вроде Coagent помогает выстроить обработку по Закону № 99-З: она ставится на сервер компании, а доступы и правила агентов задаются обычными словами. Если выбрана внешняя модель, часть данных обрабатывается за пределами сервера, это нужно учесть. Допустимые цели обработки, сроки хранения и согласия решает юрист компании.
Как проверять права регулярно
Права доступа устаревают быстрее, чем кажется: сотрудники переходят в другие отделы, уходят в отпуск, меняют обязанности. Раз в квартал администратор вместе с руководителями просматривает список ролей и сверяет его с реальными обязанностями. Лишние права закрываются, а изменения фиксируются в журнале.
Агент помогает с подготовкой: показывает, какие разделы сотрудник давно не открывал, и предлагает список прав для пересмотра. Решение о сокращении доступа принимает руководитель, а изменение настроек выполняет администратор. Журнал проверок хранится вместе с остальными документами по безопасности.
Составьте матрицу ролей для вашей компании: кто какие данные о клиентах видит и зачем.