Если у CRM нет API, не начинайте с «агента, который умеет всё»

В малом бизнесе часто приходится работать с системой, у которой есть только веб-интерфейс: старая CRM, личный кабинет поставщика или отраслевой сервис. Менеджер переносит сведения из письма в форму, прикладывает файл и меняет статус. Возникает соблазн дать ИИ логин и попросить «самому разобраться». Это рискованная архитектура: модель может неверно прочитать поле, повторить действие после тайм-аута или получить больше прав, чем требует задача.

Практичнее разделить понимание документа и выполнение операции. Локальная модель может предложить структурированную карточку заявки, выделить сомнительные поля и показать их сотруднику. Запись в систему выполняет узкий, заранее проверенный адаптер. Если у продукта есть поддерживаемый API, это первый кандидат. Автоматизация браузера нужна там, где API отсутствует или не покрывает конкретную функцию, и только при согласии владельца системы с таким способом работы.

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

Где проходит граница между моделью и исполнителем

Допустим, компания получает заявки на ремонт по электронной почте. Один и тот же смысл может быть записан разными словами: адрес, оборудование, срочность, контакт. Модель полезна для извлечения полей и сверки с внутренним справочником. Но итоговая команда должна быть формальной: «создать заявку с такими-то полями», «найти существующую заявку» или «остановиться и запросить уточнение». Свободный текст вроде «нажми что-нибудь подходящее» не должен попадать к браузеру.

Рекомендуемый контур выглядит так:

  • Входное письмо или документ поступает в контролируемую очередь. Система присваивает ему внутренний идентификатор и сохраняет версию исходных данных.
  • Локальная модель извлекает поля в фиксированную схему. Даты, номера телефонов, адреса и сумма проходят детерминированные проверки; неподтверждённые значения остаются пустыми.
  • Сотрудник подтверждает карточку, если операция меняет учётные данные, создаёт обязательство или влияет на клиента. Правило одобрения задаётся бизнесом, а не текстом ответа модели.
  • Адаптер использует документированный API либо ограниченный сценарий браузера. Он знает разрешённые страницы, поля и действия, но не умеет произвольно переходить по всему интерфейсу.
  • После операции система читает итоговую карточку и сравнивает её с подтверждёнными полями. Только тогда задача помечается завершённой.

Такой процесс не требует выдавать языковой модели пароль от CRM или доступ к кнопке удаления. OWASP относит чрезмерные функции, разрешения и автономность агента к риску Excessive Agency и рекомендует ограниченные инструменты, минимальные права и подтверждение значимых действий человеком. Это особенно важно там, где веб-интерфейс действует от имени реального сотрудника.

Почему «клик прошёл» ещё не значит «заявка создана»

Браузерная автоматизация хрупче нормального API: меняется вёрстка, появляется новый диалог подтверждения, истекает сессия, страница медленно обновляется. Playwright рекомендует искать элементы по роли и видимому названию, а не по случайному положению кнопки или длинному CSS-пути. Его автоматическое ожидание помогает дождаться видимого и доступного элемента, но не заменяет проверку бизнес-результата.

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

Журнал должен содержать идентификатор входного события, подтверждённые поля, версию сценария, результат проверки и причину остановки. Трассы Playwright полезны при разборе сбоя: они показывают последовательность действий, снимки DOM и сеть. Но сами трассы могут содержать клиентские данные. Документация Playwright отдельно предупреждает, что файл сохранённой авторизации может включать чувствительные cookie и заголовки, позволяющие выдать себя за пользователя. Поэтому хранение сессий и трасс должно иметь ограниченный доступ, срок жизни и процедуру удаления; их нельзя отправлять в обычный чат или включать в публичный репозиторий.

Когда браузерный путь не подходит

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

Не стоит маскировать отсутствие API «более умной моделью». Языковая модель не устраняет юридические условия использования сервиса, ограничение скорости, блокировки сессий и невозможность надёжно сопоставить дубли. Иногда дешевле оставить экран человеку, а ИИ поручить только подготовку черновика и поиск расхождений. Это тоже автоматизация, но с гораздо меньшей ценой ошибки.

Как посчитать пилот без иллюзии экономии

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

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

Следующий управленческий шаг — попросить ИТ-ответственного показать одну полную трассу пилота: от исходного письма до проверенной записи в CRM и безопасного восстановления после тайм-аута. Если команда не может объяснить, как предотвращает дубль и кто разрешает запись, расширять автоматизацию рано. Локальная модель, API и браузер здесь не конкуренты: каждый выполняет свою, ограниченную роль.