Агенту открывают ровно те методы систем, которые нужны для перечисленных в договоре операций, и ни одного сверх. Практически это означает три категории: чтение с обязательным фильтром по конкретному клиенту, заказу или складу; запись только в черновик или в обратимую пометку; и закрытый список действий, которые агент не выполняет никогда — он их готовит, а кнопку нажимает человек. Всё остальное — «дадим полный доступ, потом разберёмся» — и есть тот момент, после которого выясняется, что агент технически может списать оплату.
Ошибка здесь почти всегда происходит не от небрежности, а от спешки на этапе отладки. Разработчику проще получить широкий доступ и сузить его позже, а позже не наступает: интеграция работает, трогать её страшно, а формулировка в договоре звучала как «интеграция с CRM» и границу не задавала. Через полгода никто в компании не может ответить на вопрос, что именно агент умеет изменить.
Ниже — матрица прав по пяти типовым системам, формулировка минимальных прав в виде, который можно вставить в приложение к договору, разбор того, почему конфигурация 1С важнее слова «1С», роль отдельной технической учётной записи и список операций за порогом необратимости. Цены и требования — по состоянию на сентябрь 2026 года.
Три категории прав вместо галочки «доступ разрешён»
Интерфейсы систем предлагают выдавать права ролями: «менеджер», «оператор», «администратор». Для сотрудника это работает, потому что человек ограничен ещё и здравым смыслом. Для агента роль не годится: он делает ровно то, что позволяет метод, и не задаётся вопросом, уместно ли это. Поэтому права агенту описываются не ролью, а тремя категориями по каждой операции.
Ограничение, которое накладывается на право чтения помимо самого метода: не «читать сделки», а «читать сделку по идентификатору, который пришёл в текущем обращении». Без области права чтения агент технически способен выгрузить базу целиком одним циклом запросов, и никакого взлома для этого не требуется. Механику такой утечки через штатные вызовы мы разбирали в материале про безопасность агента с доступом к базе.
| Система | Чтение с фильтром | Запись под условием | Не выдаётся никогда |
|---|---|---|---|
| CRM: Битрикс24, amoCRM, RetailCRM | Карточка сделки и контакта по идентификатору из обращения, история переписки, текущий этап | Комментарий в сделку, задача на менеджера, черновик письма, смена этапа в пределах списка из ТЗ | Удаление сделок и контактов, изменение суммы, выгрузка базы массивом, права других пользователей |
| 1С: конкретная конфигурация и релиз | Остаток по номенклатуре, статус заказа, цена из действующего прайса, реквизиты контрагента | Создание документа в статусе черновика, без проведения | Проведение и распроведение, изменение цены, списание со склада, платёжные документы |
| Телефония: Mango Office, Sipuni, UIS, Novofon | Карточка звонка, длительность, расшифровка по конкретному номеру | Постановка задачи на перезвон, тег на звонок | Исходящий обзвон по списку, правка схемы маршрутизации, выгрузка записей массивом |
| Склад и WMS | Остаток, резерв, адрес хранения, статус отгрузки по конкретному заказу | Заявка на подбор в статусе «на проверке» | Списание, пересорт, снятие резерва, подтверждение отгрузки |
| Почта: один выделенный ящик | Тема, тело и вложения писем этого ящика | Черновик ответа в папке «Черновики» | Отправка наружу, удаление, правила пересылки, доступ к чужим ящикам |
Матрицу стоит читать по столбцам, а не по строкам. Первый столбец — то, без чего агент бесполезен: он должен видеть данные, иначе будет отвечать по памяти модели, а не по вашим цифрам. Второй — то, что даёт экономию и при этом откатывается за минуту. Третий — то, что не откатывается вовсе или откатывается с потерями, и там граница не двигается никогда. Подробный разбор самих необратимых операций — в отдельном материале.
Нарисованная матрица-таблица с шапкой «Права агента по системам». Пять строк слева: «CRM», «1С (конфигурация и релиз)», «Телефония», «Склад и WMS», «Почта (один ящик)». Три колонки: «Чтение с фильтром» — зелёные заполненные квадраты; «Запись под условием» — половинчатые квадраты с подписями «черновик», «комментарий», «заявка на проверке»; «Не выдаётся» — квадраты, перечёркнутые крест-накрест, с подписями «удаление», «проведение», «обзвон по списку», «списание», «отправка наружу». Справа узкая колонка «область данных» с пометкой «по идентификатору из обращения». Чертёжный стиль, подписи по-русски.
Почему конфигурация 1С важнее слова «1С»
Строка «интеграция с 1С» в коммерческом предложении не означает ничего, кроме того, что подрядчик ещё не смотрел вашу базу. 1С:Бухгалтерия, 1С:УНФ и 1С:УТ — разные конфигурации с разным составом объектов, и агент, которому нужен остаток по складу, в Бухгалтерии его просто не найдёт: там нет оперативного складского учёта в том виде, в каком он есть в УТ.
- 1С:Бухгалтерия — реквизиты контрагента, взаиморасчёты, документы после проведения. Агент здесь читает факт, а не оперативные данные: остатка «прямо сейчас» и резерва в ней нет.
- 1С:УНФ — заказы, простой складской учёт, цены. Хороший источник для агента в небольшой компании, но набор методов беднее, чем в УТ, и часть операций доступна только через доработку.
- 1С:УТ — полноценные заказы, резервы, адресный склад, ценообразование с видами цен. Самый богатый источник и самый дорогой в разборе: методов много, и границу прав приходится проводить руками по каждому.
- Релиз конфигурации — отдельная строка. Между релизами меняются реквизиты документов, и интеграция, написанная под один, на другом начинает молча терять поля.
Разница видна и в деньгах: одна и та же по описанию задача «агент видит статус заказа» стоит по-разному в зависимости от того, есть ли в конфигурации готовый механизм обмена, требуется ли расширение и кто будет его сопровождать при обновлении. Мы разбирали это в материалах о способах обмена с 1С и о том, дорабатывать 1С или строить внешнюю интеграцию. Практическое правило простое: в техническом задании пишется конфигурация, релиз и перечень объектов, к которым агент обращается.
Широкое право выдают на неделю разработки, а сужают после запуска — то есть тогда, когда трогать работающую интеграцию уже никто не хочет. Рабочая практика: временный доступ выдаётся с датой окончания в заявке и с календарным напоминанием на день отзыва. Тот же механизм описан в статье про принцип минимальных прав доступа — для агента он работает так же, как для подрядчика.
Как это пишется в договоре
Приложение к договору с перечнем методов — единственная формулировка, которая переживает смену команды у подрядчика. Она занимает одну-две страницы и составляется до начала работ, а не после. Строка «система предоставляет доступ, необходимый для функционирования решения» юридически не значит ничего: границу в этом случае проводит разработчик в момент отладки.
- 1Перечень методов с областью, а не название системы
Не «доступ к amoCRM», а построчно: получить сделку по идентификатору, получить контакт по идентификатору сделки, добавить комментарий, создать задачу. Каждая строка — одна операция. Всё, чего в перечне нет, считается неразрешённым; это условие пишется прямым текстом.
- 2Отдельные ключи на каждую систему
Один общий ключ для всех интеграций удобно и неверно: его нельзя отозвать частично. При компрометации или при уходе подрядчика вы либо останавливаете всё, либо не останавливаете ничего. Где эти ключи хранятся — отдельный вопрос с отдельным регламентом.
- 3Право отзыва без участия подрядчика
В договоре фиксируется, что заказчик может отключить ключ агента самостоятельно и в любой момент, а подрядчик обязан обеспечить корректное поведение системы при отключении: остановку, а не молчаливое накопление ошибок.
- 4Изменение перечня — допсоглашением
Новый метод добавляется в перечень письменно. Это не бюрократия, а единственный способ через год ответить на вопрос, кто и когда разрешил агенту менять цену. Что ещё должно быть в договоре на разработку, разбирали отдельно.
Нарисованный абстрактный документ с шапкой «Приложение № 2. Перечень методов, доступных агенту». Таблица из четырёх колонок: «Система», «Операция», «Область данных», «Отзыв». Восемь строк-примеров: получить сделку по идентификатору, получить контакт по идентификатору сделки, добавить комментарий, создать задачу, получить остаток по номенклатуре, создать документ в статусе черновика, получить карточку звонка по номеру, создать черновик письма. В колонке «Область данных» у большинства строк подпись «по идентификатору из текущего обращения». Внизу документа выделенная строка «всё, что не перечислено выше, считается неразрешённым» и строка «изменение перечня — допсоглашением». Чертёжный стиль, подписи по-русски.
Отдельная техническая учётная запись — и что теряется без неё
Самый частый способ подключить агента — выдать ему учётную запись живого сотрудника: руководителя отдела, администратора, «того, у кого точно всё есть». Работает мгновенно и ломается ровно один раз — в день, когда нужно понять, кто изменил данные. В журнале системы стоит имя человека, и разговор превращается в выяснение отношений вместо разбора инцидента.
Отдельная техническая учётная запись решает это одной строкой в журнале. У неё говорящее имя, собственный ключ, ограниченный набор прав из приложения к договору и запрет на вход через обычный интерфейс. Стоит она 4 часа работы инженера — 12 000 ₽ по ставке 3 000 ₽/час. Ниже — во что обходится её отсутствие при разборе всего одного спорного изменения.
Арифметику легко повторить: 0,5 часа инженера по 3 000 ₽ — это 1 500 ₽; во втором варианте 2 + 3 = 5 часов инженера дают 15 000 ₽, плюс 1,5 часа опроса по ставке 900 ₽/час — ещё 1 350 ₽, итого 6,5 часа и 16 350 ₽. Разница на одном разборе — 14 850 ₽, то есть учётная запись за 12 000 ₽ окупается на первом же спорном случае. И это без учёта главного: во втором сценарии вы получаете не ответ, а версию.
Парная столбиковая диаграмма. Слева пара столбиков «с технической учётной записью»: время 0,5 часа, деньги 1 500 ₽. Справа пара «под учётной записью сотрудника»: время 6,5 часа, деньги 16 350 ₽, с разбивкой второго столбика на три сегмента — «выгрузка изменений 6 000 ₽», «опрос сотрудников 1 350 ₽», «сверка с телефонией и почтой 9 000 ₽». Между парами выноска «разница 14 850 ₽ на одном разборе». Под правым столбиком приписка «результат — версия, а не ответ». Оси подписаны: часы и рубли. Чертёжный стиль, подписи по-русски.
Порог необратимости: что не выдаётся ни на каком уровне автономности
Есть операции, где право записи не выдаётся агенту вообще — независимо от того, насколько хорошо он себя показал и какой уровень автономности ему присвоен. Признак один: результат нельзя вернуть в исходное состояние действием той же стоимости. Отменить проведённый платёж дороже, чем его провести; отозвать отправленную рассылку невозможно в принципе.
- Движение денег в любую сторону: платёж, возврат, скидка, списание, зачёт предоплаты, изменение суммы счёта.
- Проведение и распроведение документов в учётной системе, любые операции с платёжными документами.
- Отправка наружу: письмо клиенту, рассылка, публикация, сообщение в мессенджере от имени компании.
- Изменение цен в прайсе и в карточках товара, включая «временную» акционную цену.
- Удаление и массовая выгрузка любых данных, в том числе выгрузка «на посмотреть» в файл.
- Изменение прав доступа — своих или чужих. Агент, который может расширить собственные права, ограничителя не имеет вовсе.
Правильная схема для этих операций — не запрет агента, а подготовка решения человеку: агент собирает основание, показывает карточку «что будет сделано и почему», а кнопку нажимает сотрудник. Экономия при этом сохраняется почти вся — подробный расчёт цены такого контура есть в статье про человека в контуре принятия решений, а шкала, по которой уровень автономности выбирается для каждой операции, — в разборе пяти уровней автономности.
Полная нарезка прав по пяти системам из таблицы выше — это 27 часов инженера: 6 часов на матрицу и перечень методов, 4 на техническую учётную запись и отдельные ключи, 8 на фильтры области данных, 6 на журнал вызовов с записью основания и 3 на приёмочный прогон на демо-стенде. По ставке 3 000 ₽/час — 81 000 ₽ разово. Это от шестой части до трети бюджета заказного агента в 250 000–500 000 ₽, и в смете эта строка должна стоять отдельно: если её там нет, работа не исчезла, а просто не запланирована.
Когда матрица прав избыточна
Конструкция выше рассчитана на агента, который ходит в боевые системы. Заметная часть задач до этого не доходит, и тогда 81 000 ₽ на нарезку прав — деньги, потраченные на защиту от несуществующего риска.
- Агент работает только на чтение из одной базы знаний и ничего не меняет. Тогда весь вопрос прав сводится к тому, что попало в саму базу, — а это задача её подготовки, а не доступов.
- Агент готовит черновики, которые сотрудник копирует руками. Записи в системы нет вовсе, техническая учётная запись не нужна, журнал ведёт сама CRM по действиям человека.
- Пилот на обезличенных данных в тестовом контуре. Здесь важнее корректное обезличивание выгрузки, чем матрица методов: боевых данных в контуре нет.
- Одна система и три метода. Если агент читает статус заказа и пишет комментарий, перечень умещается в четыре строки, и отдельного приложения на две страницы не требуется — достаточно абзаца в техническом задании.
Честный порядок такой: сначала выясняется, нужна ли агенту запись вообще, потом составляется перечень методов, и только под него выдаются ключи. Обратный порядок — сначала доступ, потом разбираемся — обходится не в 81 000 ₽, а в стоимость первого инцидента плюс невозможность доказать, что его причиной был именно агент.
Права агенту выдаются под перечень операций, а не под обещание, что он не сделает ничего лишнего.
