Я всё чаще думаю о том, каким станет бизнес, когда ИИ-агенты по-настоящему войдут в работу. Не в демонстрациях и не в восторженных тредах, а внутри реальных компаний, где есть клиенты, договоры, деньги и ответственность. И чем больше я изучаю, как агенты ведут себя в этом мире, тем яснее вижу: речь уже не про удобный чат.
Пока искусственный интеллект остаётся простым чат-ботом, юридическая картина выглядит привычно. Человек задаёт вопрос, модель отвечает, человек читает, думает и сам решает, брать ответ или нет. Он сам копирует текст, сам отправляет письмо, сам вносит правки в документ, в CRM, в код, в календарь и в платёжную систему. Ответственность очевидна, потому что руку к кнопке прикладывает человек.
С агентом так не выйдет, и именно здесь начинается то, что меня занимает. Агент — это уже не собеседник. Это система, которая получает цель, открывает инструменты, читает документы, проходит по базе данных, заглядывает в почту, находит файлы, создаёт задачу, отправляет сообщение, обновляет CRM, готовит договор, запускает процесс и иногда принимает промежуточное решение сама, без отдельного одобрения на каждом шаге.
Значит, нас ждёт новая юридическая реальность. Потому что ИИ-агент — это не «умная подсказка». Это процесс обработки данных с доступами и действиями. Ровно как сотрудник, которому выдали ключи от офиса.
Старые правила писались не под агентов
Когда я смотрю на корпоративные регламенты, пользовательские соглашения, политики конфиденциальности и договоры с подрядчиками, я вижу, что они писались для другого мира. Для мира, где программа делает только то, что явно нажал человек: пользователь загрузил файл, пользователь отправил письмо, пользователь нажал «опубликовать», пользователь выгрузил данные.
Агент будет работать иначе. Ему можно будет сказать: «Разбери входящие заявки и подготовь ответы», «Найди в CRM клиентов, которым пора написать», «Проверь документы и выдели риски», «Собери из разговоров задачи и разложи их по проектам». Снаружи это выглядит как удобство. Внутри это значит, что агент начнёт ходить по системам и обрабатывать письма, контакты, транскрипты, документы, клиентские записи, коммерческие предложения, финансовую информацию, персональные данные, внутренние заметки и юридические материалы. Раньше на каждый такой шаг человек принимал отдельное решение, а теперь часть действий переедет в автоматический контур. Юридически это уже совсем другая зона.
Агент будет видеть больше, чем кажется
Главный риск агентов вовсе не в том, что они «ошибутся в ответе». Про это все говорят, и это очевидная опасность. Меня больше занимает другое: агент получит доступ к массиву данных, которые раньше никогда не лежали в одном месте.
В обычной компании роли аккуратно разведены: сотрудник видит в CRM только клиентов своего отдела, бухгалтер сидит в финансовой системе, маркетолог в рекламных кабинетах, ассистент в календаре и почте, юрист в договорах. А потом появится агент, которому ради удобства выдадут доступ сразу к почте, календарю, CRM, Notion, Google Drive, базе знаний, записям встреч, транскриптам разговоров, таблицам, документам клиентов, внутренним инструкциям, платёжным данным, тикетам поддержки, репозиторию и API внешних сервисов. Каждый ключ по отдельности кажется безобидным. Вместе они складываются в очень подробную карту бизнеса.
Агент увидит связи, которые прежде были распылены между разными людьми и системами. Он может случайно свести данные, которые организационно не должны были смешиваться, применить старую информацию в новом контексте, сохранить в памяти то, что должно было остаться временным, отправить наружу фрагмент, которому положено было жить только внутри контура. Поэтому вопрос будет не в том, «можно ли дать агенту доступ». Вопрос в том, какой именно доступ, к каким данным, для какой цели, на какой срок и с каким журналом действий.
Агент — это обработчик данных
Мне кажется правильным воспринимать агента не как чат и не как интерфейс, а как обработчика данных. Он читает, анализирует, сравнивает, создаёт новое, передаёт данные между системами и иногда принимает решения на их основе.
Значит, у каждого агента должна быть внятная роль. Не «наш умный ассистент», а конкретика: для какой задачи он создан, какие данные ему нужны, какие данные ему запрещены, где он хранит результат, использует ли память, передаёт ли что-то внешним моделям, какие действия выполняет сам и где обязан остановиться и позвать человека. Без этого агент быстро превратится в юридическую серую зону.
Самая опасная фраза: «он просто помогает»
Каждый раз, когда компания внедряет ИИ, звучит успокаивающее «да он же просто помогает». Чем больше я разбираюсь в теме, тем больше эта фраза меня настораживает, потому что она склеивает совершенно разные уровни.
Если агент только переформулирует текст, который человек вставил руками, это один уровень риска. Если он читает клиентские документы, почту, CRM и сам предлагает действия — это другой уровень. Если он умеет отправлять сообщения, менять статусы, создавать задачи, обновлять карточки клиентов и запускать процессы — третий. А если он работает с персональными данными, медицинской информацией, финансовыми документами, HR-материалами или юридическими заключениями — это уже зона повышенной ответственности. Одним словом «ассистент» все эти сценарии не закрыть. Агентов придётся классифицировать по уровню риска.
Уровни риска для ИИ-агентов
Чем больше я смотрю на реальные сценарии, тем отчётливее вижу четыре уровня.
Уровень 1. Агент без доступа к внутренним данным
Он работает только с тем, что человек сам вставил в чат: переписать текст, предложить заголовки, собрать структуру статьи, объяснить идею, накидать черновик. Риск невысокий, пока пользователь сам контролирует, что именно он туда отдаёт.
Уровень 2. Агент с доступом на чтение
Он читает документы, базу знаний, CRM, письма, календарь и файлы, но ничего не меняет: находит нужный договор, собирает сводку по клиенту, готовит обзор переписки, вытаскивает задачи из встречи. Риск выше, потому что агент уже обрабатывает внутренние данные.
Уровень 3. Агент с правом записи
Он не только читает, но и создаёт или меняет записи: заводит задачу в Linear, обновляет карточку CRM, добавляет запись в Notion, готовит черновик письма, переключает статус заявки. Тут уже нужны логи, ограничения и понятные правила отката.
Уровень 4. Агент с правом внешнего действия
Он отправляет письмо, публикует материал, отвечает клиенту, запускает оплату, меняет договор, шлёт коммерческое предложение — совершает действие с юридическими или финансовыми последствиями. Это самый чувствительный уровень, и почти всегда ему понадобится human-in-the-loop: человек утверждает критическое действие до того, как оно случится.
Human-in-the-loop — не формальность
Во многих разговорах human-in-the-loop звучит красиво и пусто: «ну человек же будет контролировать». Этого мало. Нужно точно назвать, где именно человек включается.
Я представляю себе это так: агент читает документы, но не отправляет вывод клиенту; готовит письмо, но отправка только после человеческого «да»; находит юридический риск, но не выдаёт финальное заключение; предлагает правку договора, но не шлёт версию контрагенту; создаёт задачу, но не назначает ответственного без подтверждения; собирает публикацию, но кнопку «опубликовать» жмёт человек. Контроль должен быть вшит в сам workflow, а не приклеен потом на словах.
Проблема памяти
Отдельно меня занимает память агента. Если он каждый раз стартует с нуля, это один режим. Если он запоминает клиентов, проекты, сотрудников, переговоры, договоры и решения — совсем другой.
Память удобна, она делает агента полезнее, и она же поднимает целый ворох вопросов: что именно агент запомнил, где это лежит, сколько хранится, можно ли это удалить, кто имеет доступ к памяти, уходят ли эти данные в обучение, отделена ли память одного клиента от памяти другого, не применит ли он случайно информацию из одного проекта в другом. Для агентной системы память — это не милая функция удобства, а юридический и управленческий объект. Есть память — должны быть и правила к ней.
Внешние модели и клиентские данные
Ещё один узел, который я для себя разбираю: куда физически уходят данные. Агентные workflow часто опираются на внешние модели, API, плагины, облачные сервисы, векторные базы, SaaS-инструменты и интеграции. В быту это редко кажется проблемой, в клиентской работе — совсем наоборот.
Когда через агента проходит договор, коммерческое предложение, финансовая модель, медицинская информация, HR-резюме, запись встречи, персональные данные, стратегия клиента, внутренние документы компании или неопубликованный креатив, недостаточно отмахнуться фразой «мы используем ИИ». Надо понимать, какие провайдеры участвуют, где стоят их серверы, сохраняются ли данные, уходят ли они в обучение, как настроен retention, можно ли отключить хранение, кто здесь оператор, а кто обработчик, что написано в договоре с клиентом и вообще законно ли отдавать эти данные в такой сервис. Это не бюрократия, это обычная гигиена работы с агентами.
Логи важнее, чем кажется
Если ошибся человек, всегда можно спросить, кто, когда и почему принял решение. С агентом сложнее. Когда он обновил CRM, отправил черновик, создал задачу, изменил документ или передал данные в другой сервис, нужен журнал: когда действие произошло, кто запустил агента, какой была задача, какие данные он использовал, какие инструменты вызвал, какой результат создал, кто утвердил финальный шаг и можно ли всё это откатить.
Без логов агентная система становится непроверяемой. А непроверяемая система в бизнесе — это мина, особенно когда потом приходится разбирать конфликт с клиентом, ошибку в договоре, утечку данных, кривую публикацию или спор о том, кто вообще принял решение.
Должностная инструкция для агента
Самая простая рабочая идея, к которой я прихожу: каждому агенту нужна карточка. У сотрудника есть должность, зона ответственности и доступы — пусть и у агента будет своя «должностная инструкция». Для контент-агента она могла бы выглядеть так:
Название агента:
Контент-агент pimenov.ai
Задача:
Превращает транскрипты, ссылки и заметки в черновики статей.
Доступы:
Notion CMS, база черновиков, папка с транскриптами.
Данные:
Тексты, ссылки, расшифровки разговоров, редакционные заметки.
Запрещено:
Публиковать статью без подтверждения.
Передавать клиентские материалы во внешние сервисы без разрешения.
Использовать материалы одного клиента в статье другого клиента.
Память:
Хранит только редакционные предпочтения и структуру workflow.
Логи:
Сохраняет дату запуска, входной материал, версию черновика, финальный статус.
Критические действия:
Публикация, отправка клиенту, изменение статуса на «готово» — только после подтверждения человека.Выглядит подозрительно формально, но именно такая простая структура превратит агента из магической игрушки в управляемую часть бизнеса.
Агентный реестр
Как только агентов станет больше одного, понадобится база. Можно назвать её AI Agent Registry, можно просто «Реестр ИИ-агентов». Минимальный набор полей я вижу такой: название агента, владелец, бизнес-задача, уровень риска, системы с доступом, типы данных, внешние провайдеры, наличие памяти, место хранения логов, разрешённые действия, запрещённые действия, точки подтверждения человеком, дата последней проверки и статус — эксперимент, черновик, в работе или отключён.
Такой реестр нужен не только юристам. Он нужен владельцу бизнеса, технической команде, клиентскому менеджеру и самому человеку, который жмёт на запуск. Потому что без реестра очень быстро наступает момент, когда никто уже не помнит, сколько агентов запущено, к чему у них доступ и кто отвечает за их действия. А это ровно та точка, где удобный инструмент превращается в неуправляемый риск.
Я не жду, что все ответы появятся сами собой. Я просто продолжаю изучать, как агенты ведут себя в реальном бизнесе, и всё сильнее убеждаюсь в простой вещи: агент — это не магия и не помощник из рекламного ролика, а сотрудник с доступами. А раз так, к нему и относиться надо как к сотруднику: понятная роль, чёткие границы, журнал действий и человек, который отвечает за результат.
Оформляйте своих агентов на работу.
По теме
Если вы задумались, как безопасно ввести агентов в свой бизнес, с понятными ролями, доступами и точками контроля человека, это как раз то, чем я занимаюсь на практике.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov