От разрозненных экспериментов к общей системе
Британское маркетинговое агентство Hallam начинало с ситуации, знакомой многим компаниям: сотрудники самостоятельно пробовали разные AI-сервисы, но бизнесу было трудно сравнивать эффект, контролировать клиентские данные и поддерживать единый стандарт работы. Отраслевое издание BusinessCloud указывало ядро из 45 штатных сотрудников — это уже не команда, где все эксперименты можно удержать в голове одного руководителя.
Hallam перевело индивидуальные пробы в общий контур с корпоративными подключениями к данным и возможностью создавать специализированных агентов без кода. Руководителям подразделений выделили 20% рабочего времени на AI-инновации, остальным сотрудникам — один день в месяц на эксперименты. Партнёр помог настроить лицензии, техническую среду и обучение.
В опубликованном Google Cloud кейсе агентство сообщает о четырёх заметных изменениях:
- исследование аудитории сократилось с 1–2 дней до 15 минут;
- редактирование брифа — с половины дня до 15 минут;
- подготовка плана переговоров по договору — с половины дня до 10 минут;
- ввод нового сотрудника в процессы — с нескольких недель до первых 2–3 дней.
Эти цифры предоставлены участниками кейса и опубликованы поставщиком платформы. В материале нет независимого аудита, полной стоимости лицензий и партнёра, частоты ошибок, размера контрольной выборки или доли задач, где черновик пришлось переделать. Поэтому цифры полезны как ориентир масштаба, но не как обещание результата для другого бизнеса.
Почему сработал не «ещё один чат»
Ключевое изменение Hallam — не выбор конкретной модели. Агентство создало управляемое пространство, где сотрудник может собрать инструмент под свой процесс, но использует утверждённые подключения и общие данные.
До этого запрос на автоматизацию проходил через техническую команду и мог ждать недели. После внедрения специалист по маркетингу получил возможность самостоятельно сделать агента прогнозирования: загрузить таблицы с историческими показателями, учесть сезонность и подготовить прогноз трафика и конверсий. Разработчики при этом сосредоточились на более сложных интеграциях и едином хранилище данных.
Это важное различие для малого и среднего бизнеса. Демократизация разработки полезна, когда она уменьшает очередь к ИТ. Но без правил она просто создаёт вторую очередь — из десятков непроверенных агентов, дублирующих функции и имеющих лишние права.
Четыре процесса и разные уровни риска
**Исследование аудитории.** Агент анализирует большие массивы публичных обсуждений и материалов фокус-групп, чтобы найти повторяющиеся мотивы. Здесь допустим быстрый черновик, но человек проверяет выборку, источники и репрезентативность. Иначе модель уверенно превратит громкое меньшинство в «мнение рынка».
**Подготовка брифа.** Агент собирает исходные данные и приводит документ к корпоративной структуре. Риск ниже, если он не выдумывает факты, а заполняет поля из CRM, договора и утверждённого шаблона. Финальный бриф подтверждает владелец проекта.
**Разбор договора.** Сотрудники загружают документ с правками, а агент выделяет спорные пункты и предлагает позиции для переговоров. Это помощь в навигации, а не юридическое заключение. Решение по риску, обязательствам и формулировкам остаётся у ответственного специалиста или юриста.
**Онбординг.** Поиск по политикам, процессам и истории проектов помогает новичку быстрее находить ответы. Здесь важно разграничение по клиентам и ролям: новый сотрудник не должен видеть документ только потому, что его нашёл общий агент.
Один интерфейс не означает одинаковую автономность. Для исследования можно разрешить генерацию отчёта, для брифа — создание черновика, для договора — только подсказки с обязательным подтверждением, для онбординга — строгое чтение в рамках прав пользователя.
Минимальная архитектура «фабрики агентов»
Повторяемый контур состоит из семи компонентов.
1. **Каталог сценариев.** Для каждого агента указаны владелец, задача, пользователи, источники данных, инструменты, допустимые действия и дата следующего пересмотра.
2. **Шаблон создания.** Сотрудник выбирает тип задачи, а не начинает с пустого поля. Шаблон задаёт формат входа, ожидаемый результат, ограничения и критерии качества.
3. **Слой данных.** RAG и коннекторы получают документы из разрешённых хранилищ. Доступ вычисляется от личности пользователя и прав на исходный объект.
4. **Брокер инструментов.** Агент видит только необходимые функции. Поиск не должен включать удаление, а черновик письма — самостоятельную отправку.
5. **Человеческие ворота.** Финансовые, юридические, кадровые и внешние действия требуют явного подтверждения. Интерфейс показывает, что именно будет выполнено.
6. **Набор проверок.** До запуска агент проходит тесты на типовых, редких и конфликтных примерах. Измеряются полнота, фактические ошибки, доля правок и соблюдение формата.
7. **Журнал и бюджет.** Сохраняются версия инструкции, источники, вызовы инструментов, подтверждения, стоимость и время. Для каждого агента задаются лимиты запросов и расходов.
OWASP называет избыточную агентность сочетанием лишней функциональности, лишних прав и лишней автономности. Практическое следствие простое: запрет должен находиться в API и системе доступа, а не только в текстовой инструкции модели.
Какие данные придётся подготовить
Быстрый агент на плохих данных лишь быстрее распространяет путаницу. До подключения корпоративного поиска нужны:
- владельцы папок и источников;
- правила доступа по клиенту, проекту и роли;
- актуальные шаблоны брифов и договорных позиций;
- словарь показателей и единые названия полей;
- срок действия документов и архив версий;
- эталонные примеры хороших результатов;
- список данных, которые запрещено передавать модели;
- процедура удаления клиента и его материалов из индекса.
Для таблиц важно фиксировать схему: период, валюта, единицы, источник, пропуски и сезонность. Агент прогнозирования не должен сам выбирать, какой из двух столбцов считать выручкой. Для текстов нужны ссылки на исходные фрагменты и версия документа.
Где локальная модель и гибрид уместнее облака
Российская компания может повторить организационный подход без копирования платформы. В защищённом контуре остаются клиентские документы, договоры, финансовые показатели, персональные данные, индекс RAG и журнал действий. Локальная модель может выполнять поиск, извлечение полей, классификацию и подготовку черновика.
Внешний API допустим для обезличенной стилистической правки или анализа публичных данных, если это разрешено политикой и договором. Перед отправкой шлюз удаляет имена, реквизиты и внутренние идентификаторы, а затем проверяет ответ.
Гибрид имеет смысл, когда чувствительность задач различается. Исследование открытых форумов можно выполнять внешней моделью, а договорный агент — локально. Однако два контура усложняют поддержку: нужна единая регистрация агентов, политика маршрутизации, наблюдаемость и запасной ручной процесс.
Локальность сама по себе не создаёт безопасность. Если общий сервисный аккаунт видит все клиентские папки, локальный агент тоже сможет раскрыть лишнее. Права должны наследоваться от пользователя, а высокорисковые инструменты — отсутствовать в контуре чтения.
Экономика выделенного времени
Hallam не просило сотрудников экспериментировать «между делом»: время было выделено официально. Это повышает шанс получить рабочие сценарии, но создаёт заметную инвестицию.
Модельный пример для компании из 50 человек: один день экспериментов в месяц для 45 сотрудников — 360 часов. Если пять руководителей дополнительно тратят 20% времени, это ещё около 160 часов. Всего — примерно 520 часов в месяц до учёта лицензий, партнёра и поддержки.
Это не расчёт Hallam, а иллюстрация с допущениями: 8-часовой день и 160 рабочих часов в месяц. Чтобы инвестиция не превратилась в оплачиваемое любопытство, каждый эксперимент должен иметь карточку: базовое время процесса, ожидаемое сокращение, объём операций, риск ошибки, стоимость запуска и дату решения «масштабировать или закрыть».
Например, агент экономит два часа на брифе, а таких брифов 20 в месяц. Потенциал — 40 часов. Если его создание, проверка и сопровождение требуют 30 часов в первый месяц и 5 часов далее, сценарий может окупиться. Если задача возникает дважды в год, стандартный шаблон окажется дешевле агента.
Руководителю нужен портфель, а не число созданных агентов. Полезные метрики:
- часы, подтверждённо высвобождённые после проверки результата;
- доля выходов, принятых без существенной переделки;
- число активных пользователей и повторных запусков;
- стоимость на один принятый результат;
- инциденты доступа и ошибочные действия;
- агенты, закрытые как дублирующие или неокупаемые.
Риски демократизации
Первый риск — «теневые агенты»: сотрудник создаёт инструмент, увольняется, а сценарий продолжает работать без владельца. Нужны срок действия и автоматическое отключение без пересмотра.
Второй — скрытое расширение доступа через подключённые хранилища. Проверяйте права не только при создании, но при каждом запросе и при индексации документов.
Третий — непрямая prompt-инъекция. Текст на сайте, в письме или документе может содержать инструкцию для модели. Внешний контент считается данными, а вызовы инструментов проходят отдельную проверку.
Четвёртый — ложная уверенность в юридических и аналитических выводах. Агент обязан показывать источники, допущения и границы. Высокорисковый результат не отправляется клиенту без ответственного человека.
Пятый — неконтролируемая стоимость. No-code снижает цену создания, но увеличивает число запусков. Нужны квоты, кеширование, выбор модели по сложности и отключение неиспользуемых агентов.
Пилот на четыре недели
**Неделя 1.** Соберите очередь повторяющихся задач и выберите одну низкорисковую: бриф, поиск по регламентам или анализ открытых источников. Зафиксируйте время и качество ручного процесса.
**Неделя 2.** Назначьте владельца, подключите только чтение и подготовьте 30–50 тестовых примеров. Опишите запрещённые данные и действия.
**Неделя 3.** Дайте доступ небольшой группе. Агент готовит результат, но пользователь сравнивает его с ручным вариантом и отмечает существенные правки.
**Неделя 4.** Посчитайте принятые результаты, часы, расходы и ошибки. Если критерии выполнены, зарегистрируйте агента в каталоге и назначьте пересмотр. Если нет — закройте сценарий и сохраните причину.
Следующий агент создаётся только после появления общего шаблона, журнала и процесса отключения. Это медленнее первой демонстрации, но быстрее, чем разбирать десятки бесхозных автоматизаций через полгода.
Что взять руководителю
Кейс Hallam показывает, что доступ сотрудников к созданию агентов может снять очередь к ИТ и сократить отдельные процессы с дней до минут. Но результат опирается на выделенное время, обучение, общие данные и управляемую платформу.
Начните не с конкурса на большее число агентов, а с реестра из одного сценария: владелец, данные, права, тесты, метрики, бюджет и дата пересмотра. Внутрик уже привёз целый шкаф инструментов; зрелость начинается с решения, какие ящики оставить запертыми.
