Песочница для AI-инструментов: запись без лишних прав

Почему запись от агента опаснее чтения

Чтение редко меняет ход работы. Агент может неверно понять данные и дать плохой ответ, но запись уже меняет систему: правит карточку клиента, обновляет статус, добавляет комментарий, закрывает задачу. После этого ошибка живет не в чате, а в CRM, базе или документе.

Самая частая проблема проста: агент путает похожие сущности. У двух клиентов схожие названия, у двух сделок почти одинаковый номер, у контактов совпадают фамилии. Человек часто ловит такие различия по контексту. Агент нередко берет первый подходящий вариант и пишет данные не туда.

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

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

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

Если нормальных логов нет, поиск причины затягивается. Команда видит, что статус изменился, но не понимает, кто это сделал, по какому правилу и из какого запроса. Дальше начинаются догадки: проверяют интеграции, сотрудников, сценарии. Хотя источник один - неудачное действие агента.

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

Что изолировать в первую очередь

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

Обычно первым слоем изоляции становятся пять зон:

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

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

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

Таблицы, где агент создает или удаляет записи, часто приносят самый дорогой сбой. Дубль клиента появляется легко. Не ту запись удалить еще легче. Рабочее правило простое: удаление по умолчанию запрещено, а новые записи сначала попадают в staging-слой или получают статус "черновик".

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

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

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

Если агент читает и пишет через один и тот же доступ, ему почти всегда дают больше, чем нужно. Для записи это плохая отправная точка. Сначала разделите доступ на два слоя: чтение отдельно, запись отдельно.

Чтение можно открыть шире, если данные уже прошли маскирование и агенту действительно нужен контекст. Запись должна быть узкой с самого начала. Не "доступ к CRM", а право на одно действие в одном сценарии.

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

Что ограничивать в правах

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

• разрешить только нужную команду, например update, но не delete
• открыть только конкретные поля, например "статус", "следующий шаг", "дата контакта"
• запретить массовые правки, экспорт и любые изменения схемы
• привязать запись к одному объекту или типу объекта

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

Отдельный токен на каждый инструмент - еще одно базовое правило. Не используйте один общий секрет для CRM, базы и документов. Если один токен утечет или агент начнет вести себя странно, вы быстро отключите только этот канал, а не весь контур.

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

Рабочая схема выглядит так: агент читает через безопасный слой, формирует действие, а запись выполняет отдельный узкий инструмент с коротким списком разрешений. Если сценарий расширился, создайте новую роль и новый токен. Не растягивайте старые права "на всякий случай".

Как собрать песочницу по шагам

Сначала зафиксируйте, что агенту вообще можно менять. Не "работа с CRM", а короткий закрытый набор действий: создать задачу, обновить статус сделки, добавить комментарий, заполнить одно поле. Удалять запись или менять владельца клиента он не должен. Чем уже список, тем меньше случайных правок.

Ограничения удобно описать заранее:

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

После этого заведите отдельные сервисные учетные записи. Не давайте агенту токен сотрудника или общий доступ интеграции "на все случаи". Для CRM, базы и документов лучше создать разные учетные записи с разными ролями. Если агент обновляет карточки клиентов, ему не нужен доступ к финансовым отчетам, файлам HR и настройкам воронки.

Следующий шаг - тестовый контур. Возьмите копию данных и уберите лишнее: персональные данные, реальные телефоны, внутренние заметки, которые не нужны для сценария. На такой копии удобно проверить, как агент ведет себя на плохих письмах, дублях, пустых полях и странных форматах дат. Даже если модель идет через шлюз вроде AI Router, права на запись лучше отделять от самого вызова модели.

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

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

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

Какие правила ставить перед записью

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

Первое правило простое: проверяйте идентификатор, дату, сумму и формат каждого поля. Не "похоже", а "совпало". Для ID это точное совпадение. Для дат - понятный формат и допустимый диапазон. Для сумм - валюта, знак и число знаков после запятой. Если поле не прошло проверку, агент ничего не меняет.

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

Спорные совпадения нельзя додумывать. Если письмо похоже сразу на два заказа, если у клиента два договора на одну сумму, если в документе неясна дата, цепочку нужно остановить. Нормальная изоляция не поощряет догадки. Система должна запросить подтверждение и записать в журнал, почему не дала выполнить правку.

При высоком риске лучше отправлять человеку черновик, а не готовое изменение. Это нужно для скидок, банковских реквизитов, статусов оплаты, удаления строк и любых правок, которые трудно откатить. Человек должен видеть три вещи: что агент хочет изменить, откуда он взял данные и какие поля остались под вопросом.

Отдельно закройте самые опасные пути записи:

• произвольный SQL
• свободные вызовы API без белого списка
• массовые обновления без лимита строк
• удаление и перезапись файлов без версии

Для безопасного доступа к БД и изоляции действий в CRM лучше давать агенту узкие команды, а не общий доступ. Не "пиши куда угодно", а "обнови сумму сделки", "создай черновик заметки", "добавь тег". Так проще проверить права на запись для AI-агента, сделать аудит изменений AI и быстро откатить ошибку.

Пример: агент обновляет CRM после письма

Проверять стоит не то, умеет ли агент писать в CRM, а насколько мало он может там менять. Самый понятный сценарий: клиент просит сдвинуть срок поставки по заказу. Агент читает письмо, но не правит сделку сразу.

Сначала он ищет нужную карточку по двум признакам: номеру заказа в письме и теме переписки. Одного совпадения по имени клиента мало. Если нашлись две похожие сделки или номер не сходится, цепочка останавливается, а письмо уходит человеку.

Дальше агент готовит черновик изменений. Например: новая дата поставки - 18 июня, задача менеджеру - "уточнить складской слот и подтвердить клиенту ответом". Черновик показывает не только новые значения, но и основание: кусок письма, где клиент попросил перенос.

Менеджер видит это в интерфейсе как предложение, а не как уже внесенное изменение. Он может подтвердить действие одной кнопкой или отклонить его. Если дата выглядит странно, он правит ее вручную. Если письмо двусмысленное, он закрывает черновик без записи.

После подтверждения система пишет только в два разрешенных поля сделки:

• плановая дата поставки
• задача менеджеру

Сумма сделки, этап воронки, ответственный, контакты и комментарии остаются закрытыми для агента. Это простое ограничение резко снижает риск. Даже если модель неверно поняла письмо, она не сможет случайно перевести сделку на другой этап или изменить данные клиента.

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

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

Где команды чаще ошибаются

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

Вторая ошибка появляется при спешке. Ради быстрого старта команда открывает агенту всю CRM, хотя ему нужен доступ только к двум-трем полям и одной сущности. На практике агенту редко надо видеть весь профиль клиента, историю продаж и внутренние комментарии. Если задача звучит как "обновить статус лида после письма", полный доступ к CRM - это лишний риск, а не помощь.

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

Еще одна слабая точка - журналирование. Команда хранит итоговое изменение, но не хранит исходный запрос агента и полный ответ инструмента. В такой схеме почти невозможно разобрать спорный случай. Видно, что поле в CRM изменилось, но не видно, почему агент решил сделать именно это, какие данные получил и что вернул инструмент.

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

Обычно хватает пяти жестких ограничений:

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

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

Короткий список проверок перед запуском

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

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

• У каждого действия есть конкретный владелец. Если агент меняет этап сделки, пишет комментарий в CRM или обновляет запись в БД, должен быть человек, который отвечает за это действие и принимает спорные случаи.
• Список полей для записи закрыт заранее. Агент не должен "импровизировать" и выбирать поля сам. Разрешите только то, что описано в схеме: например, "next_step" и "summary", но не скидку, реквизиты или ответственного менеджера.
• Массовые правки идут по отдельному сценарию. Одно дело - обновить одну карточку после письма. Другое - переписать 10 000 строк в таблице. Для пакетных операций нужны отдельный запуск, лимит и согласование.
• Откат занимает минуты. Команда должна уметь быстро вернуть прошлые значения через журнал изменений, снапшот или очередь команд. Если откат требует ручного разбора на весь день, система еще не готова.
• Смена модели не меняет правила доступа. Сегодня агент работает на одной модели, завтра на другой, но права на запись остаются теми же. Эти правила должны жить вне промпта и вне модели.

Отдельно проверьте аудит. Вы должны видеть, кто запустил действие, что именно агент изменил и какое правило это разрешило. Без такого следа изоляция действий в CRM быстро превращается в спор "кажется, это сделал бот".

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

Что делать после пилота

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

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

Сразу собирайте сухие метрики, а не общие впечатления команды. Полезно смотреть:

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

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

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

Если команда использует единый шлюз вроде AI Router на airouter.kz, сравнивать модели еще проще. Маршрутизацию запросов можно менять отдельно от политики записи, и это удобный способ тестировать модели без лишнего риска для CRM и БД.

Расширяйте права только после спокойной серии запусков. Обычно это значит, что несколько недель подряд агент работает в одном сценарии без роста откатов, ручных разборов и странных записей. После этого добавьте одно новое поле или одно новое действие и снова смотрите на метрики. Такой темп кажется медленным, но почти всегда он быстрее, чем разбирать большой сбой после слишком щедрых прав.