AI-агенты на сайте и в Битрикс24: четыре роли, границы прав и порядок внедрения

Слово «нейросеть» в описании модуля уже никого не удивляет, а вот разница между «бот отвечает по FAQ» и «агент сам правит шаблон бизнес-процесса» — огромная. В первом случае ошибка стоит некрасивой фразы в чате, во втором — сломанного согласования и заявки, которая повисла. Поэтому внедрять ИИ на проекте стоит не «вообще», а по ролям: что именно ИИ делает, какими данными он при этом пользуется и какие у него права. Ниже — четыре практические роли, для которых в октябре вышли готовые решения, и то, как ограничить агента так, чтобы получить пользу, а не риск.

Роль 1: чат для посетителей — быстрые ответы и захват заявки

Самая понятная и наименее рискованная роль. Задача: посетитель не уходит с вопросом «сколько стоит и какие сроки».

Первый линк: AI-чат для сайта добавляет на сайт чат-виджет: он отвечает посетителям из локальной базы знаний, а на остальные вопросы — через выбранную AI-модель. Заявлен потоковый вывод ответа, приём заявок прямо в чате и журнал переписок с поиском — без единой правки в шаблоне сайта.

Как устроен поиск ответа. В каждой записи базы знаний — вопрос (или несколько формулировок) и ответ; поиск идёт по ключевым словам с повышенным весом полного совпадения фразы, а запись срабатывает, когда совпадение превышает настраиваемый порог. Режимы работы: «сначала база знаний» (модель включается только если подходящей записи нет), «только база», «база выключена». В поставке уже есть стартовый FAQ на 19 записей — его удобно отредактировать под свои услуги или заменить целиком, есть импорт и экспорт JSON.

Это важная деталь по деньгам: ответ из базы знаний не отправляется к нейросети — «бесплатно и без задержки», как сказано в описании.

Провайдеры. Модель выбирается на отдельной вкладке: провайдер, ключ, адрес API, модель, температура, лимит токенов, таймаут, глубина истории. Готовые адаптеры — BitrixGPT, OpenAI, Yandex GPT (авторизация apikey или bearer), GigaChat (scope настраивается), Anthropic, а также любой OpenAI-совместимый API (OpenRouter, Together, Groq, Ollama, vLLM, LM Studio). Есть кнопка «Проверить подключение»: минимальный запрос к модели сразу после ввода ключа — конфигурация проверяется до того, как на чат начнут приходить посетители.

Техническая часть без правки шаблона. Служебные адреса модуля перехватываются на событии main/OnBeforeProlog до обращения к маршрутизации, поэтому не требуется менять .htaccess, конфигурацию nginx или правила urlrewrite; установщик сам добавляет блок автоподключения в init.php. Если нужен контроль места вывода — режим «Вручную» и одна строка в шаблоне.

Заявки. Форма открывается внутри чата; по заявке одновременно срабатывают три канала: письмо на адреса администраторов, webhook с HMAC-подписью тела (обработчик может проверить целостность и происхождение запроса) и событие OnAibotLead для интеграции с CRM. В параметре события — поля заявки, источник и ссылка на переписку.

Что защищает от злоупотреблений. Публичный эндпоинт чата — это точка, где кто угодно может жечь ваш бюджет на токены. В описании перечислено: антифлуд (по умолчанию 10 запросов в минуту и 100 в сутки на посетителя, 60 в минуту общий по сайту, лимит длины сообщения), штатная капча ядра Bitrix (правильный ответ хранится только на сервере, поэтому обход по содержимому вопроса невозможен), стоп-лист ботов по User-Agent, мастер-выключатель, который гасит и виджет, и все служебные адреса, CORS выключен по умолчанию. Сырые тексты ошибок AI-провайдера посетителю не отдаются — только обобщённые сообщения, детали в серверный журнал. Исходящие запросы идут только по HTTPS с проверкой резолвнутых адресов против приватных диапазонов (защита от SSRF).

Приватность переписки. Идентификатор сессии хранится в localStorage; адрес history отвечает только тому диалогу, чей идентификатор совпал — чужие переписки через него прочитать нельзя. Запись диалогов можно отключить переключателем (например, на страницах с персональными данными) — тогда переписка не пишется вовсе, но заявки сохраняются. Срок хранения настраивается, агент очистки удаляет устаревшие записи.

И практическая деталь про сам переход: демо-версия — 7 дней полного доступа; после истечения чат продолжает отвечать из базы знаний, запросы к модели не отправляются, а посетитель видит настраиваемый текст «Ответ после демо-периода».

Роль 2: агент с доступом к API — протокол MCP

Здесь начинается самое интересное для бизнеса и самое опасное технически: дать ИИ-агенту доступ к функциям сайта, не отдавая ему прав администратора.

MCP-шлюз подключает Claude, Codex, Cursor и других ИИ-агентов к сайту по протоколу MCP (Model Context Protocol). Ключевой принцип заявлен прямо: агент получает в качестве инструментов только те методы API, которые вы явно разрешили, а база сайта не открывается — что агент может прочитать или изменить, определяют ваши роуты и их контроллеры.

Требуется API-платформа. MCP-шлюз — это расширение модуля «API-платформа» версии 2.0.0 и новее; без него шлюз не устанавливается. Роли распределены так: API-платформа принимает запрос агента, проверяет токен, группы, ограничения и параметры, а шлюз отвечает за протокол MCP и каталог инструментов.

Три шага до работающего агента. Установить модуль штатным мастером Marketplace и добавить пользователей агентов в группу «MCP: Клиенты»; включить шлюз в настройках API-платформы и отметить роуты, которые станут инструментами; подключить агента по адресу шлюза с access-токеном пользователя. Для публикации собственных инструментов нужен разработчик — методы работы с данными и проверки прав на отдельные записи реализуются в вашем проекте.

Что это дает с точки зрения прав. Три механизма стоит выделить:

• Явная публикация. Инструментом становится только отмеченный роут; остальные методы API агенту недоступны.
• Прежние правила доступа. Запрос агента проходит общий конвейер API-платформы: access-токен, группы пользователя, ограничения по IP, расписания, лимиты запросов, события и кеш.
• Разграничение по группам. Разные пользователи видят разный набор инструментов, и недоступный инструмент нельзя вызвать даже по имени.

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

Честные ограничения версии. Из описания: агент передаёт access-токен API-платформы в заголовке; поддерживаются инструменты, а resources, prompts, tasks и отдельный SSE-поток не реализованы; собственных таблиц, журналов и административных страниц у шлюза нет — токены, журналы и настройки остаются в API-платформе. Подключение, получение каталога и вызов инструментов проверены в Codex и Claude; в документации есть настройки Claude, Claude Desktop, Claude Code, Codex, VS Code, Cursor и Gemini CLI.

Практический вывод: MCP-шлюз — не «кнопка AI», а способ опубликовать уже существующий API наружу в контролируемом виде. Если API-платформы на проекте нет, начинать с этого бессмысленно.

Роль 3: агент, который разбирается в бизнес-процессах

Самая специфичная ниша — и самая недооценённая.

Synapsea BP Agent: доступ AI-агента к шаблонам бизнес-процессов подключает к порталу AI-агента, который умеет разбираться в бизнес-процессах и править их — не подсказывать, где нажать, а находить причину и вносить изменение.

Как это выглядит. Специалист пишет в Claude Code обычным текстом: «В процессе согласования договоров согласующий иногда не назначается, заявка просто повисает. Посмотри, в чём дело». Агент открывает шаблон через модуль, проходит по дереву, находит причину и объясняет её — например, ссылка на действие, которое кто-то удалил два года назад, поэтому исполнитель подставляется пустым. Показывает точное место в дереве, предлагает исправление и — с подтверждения — записывает его обратно. Перед записью сохраняется снимок, к которому можно вернуться одной командой.

Почему это вообще нужно. Визуальный редактор хранит бизнес-процесс как дерево, сжатое zlib поверх serialize(). Процессы согласования в живых компаниях доходят до тысячи узлов, и найти в таком одну ветку через интерфейс — десятки раскрытых блоков. Хуже другое: Битрикс не проверяет ссылки внутри шаблона — ссылка на удалённое действие или на необъявленную константу молча подставляет пустую строку, процесс идёт дальше, письмо уходит с пропуском, согласующий не назначается, а в журнале чисто. И отдельно: штатная проверка пропускает ветки с отключённым действием целиком, поэтому ошибки в них не показываются вообще; ветку включают через год — и она не работает.

Что умеет модуль. Отдаёт шаблон в виде JSON (целиком или отдельной ветвью по пути), ищет действия по типу, заголовку или содержимому свойств, проверяет структуру (битые ссылки на действия, необъявленные константы и переменные, дубли имён, переменные, в которые пишут и которые никто не читает), записывает изменения через штатный загрузчик Битрикса, хранит снимок перед каждой записью, запускает процесс на конкретной сущности и показывает, где он стоит, сопоставляет исполнителей вида user_271 с живыми сотрудниками.

Модель безопасности — образец для любого агента. Ключи выдаются с раздельными правами: чтение, запись, создание, запуск, справочник сотрудников. Изменение блоков «Выполнить код» — отдельное право, по умолчанию отключённое, потому что это возможность загрузить на сервер произвольный PHP. Область действия ключа ограничивается типами документов или конкретными ID шаблонов: ключ на три шаблона одной воронки к остальным процессам портала доступа не имеет — на запрос к чужому шаблону он получит тот же ответ, что и на запрос к несуществующему.

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

Требования: Битрикс24 в коробке с модулем бизнес-процессов, PHP 8.2 и новее, MySQL или PostgreSQL, zlib; для клиентской части — Claude Code. Скилл для Claude Code распространяется отдельно и открыто, без модуля работает только с файлами, выгруженными вручную.

Роль 4: генерация метатегов и текстов

Про генерацию контента на сайте уже есть отдельные материалы, поэтому здесь — только о том, что отличает «генератор текста» от инструмента, встроенного в рабочий процесс.

SolverWeb: SEO AI — метатеги и тексты создаёт Title, Description, Keywords, H1, анонсы и полноценные HTML-тексты для элементов и разделов инфоблоков прямо из админпанели. Поддерживаются OpenAI, Claude, Gemini, Qwen, DeepSeek, MiMo и другие OpenAI-совместимые сервисы; API-ключи — ваши, оплата AI-сервисов не входит в стоимость модуля.

Что здесь важнее всего с точки зрения контроля:

• Сабпромпт — постоянный контекст проекта. Название компании, город, регион, особенности услуг, преимущества, условия доставки, порядок работы, тон общения, допустимые факты и запрещённые формулировки. Это главный инструмент против «галлюцинаций» про скидки, гарантии, сроки и цены.
• Существующий контент под защитой. По умолчанию тексты записываются только в пустые поля; заполненные модуль не заменит, пока явно не включить «Заменять уже заполненные».
• Сначала предложение — потом публикация. Стандартный сценарий — предпросмотр, ручная правка, применение. Режим «Записывать сразу, без проверки» есть, но именно он и есть основной источник риска.
• SEO-шаблоны инфоблока не трогаются. Метатеги пишутся в собственные SEO-настройки элемента или раздела — точечно, без поломки общей логики каталога.
• Найти страницы, которым нужен SEO. Фильтры по инфоблоку, разделу, названию и ID, заполненности метатегов, типу материала — можно быстро найти страницы без собственного Title или Description и обработать именно их.

И отдельно про инфраструктуру, потому что это техническая гигиена: ключи API и пароли прокси хранятся в зашифрованном виде (AES-256-GCM), после сохранения полный ключ не выводится — только маска, ключи не попадают в журнал. По умолчанию разрешены только HTTPS и публичные адреса, обращения к локальным и внутренним адресам блокируются, адреса облачных metadata-сервисов блокируются независимо от настроек. Для каждого подключения можно отдельно настроить прокси (HTTP, HTTPS, SOCKS5, SOCKS5h) — только для этого подключения.

Особая роль: ИИ, который улучшает поиск, а не пишет текст

BUSSOL Neuro — нейросети и умный поиск показывает другой класс задач: работать не с контентом, а с поведением покупателей.

Проблема описана точно: в каталоге есть «Смартфон Apple iPhone 16 Pro», а посетители вводят «айфон 16про», «iphone16 pro», «эпл 16 про», «айфон шестнадцать». Стандартный поиск не всегда связывает такие запросы с нужными товарами — покупатель получает пустую выдачу, хотя товар есть.

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

Главное отличие от генератора текста — проверка до и после. AI получает кандидатов из реального каталога (товары, разделы, свойства, значения списков, HL-справочники, существующий AI-словарь) и не должен применять случайно сгенерированное значение; перед созданием рекомендации выполняется контрольный поиск, и если новый вариант не улучшает результат — рекомендация не считается полезной. После применения правила проблема не считается исправленной автоматически: цикл продолжается через переиндексацию и контрольный поиск до статуса RESOLVED.

Поддерживаются GigaChat, DeepSeek, OpenRouter и другие OpenAI-совместимые API. В описании также заявлены массовая генерация контента и SEO, история изменений и безопасный откат результатов AI-генерации.

Как ограничить права агента: общие принципы из этих решений

Четыре разных модуля дают на удивление согласованный набор правил. Это готовая рамка для любого ИИ-внедрения.

1. Раздельные права по операциям. Чтение, запись, создание, запуск — отдельно. Особо опасное действие (выполнение кода) — отдельным правом и по умолчанию выключено.
2. Ограничение области действия. Ключ или токен выдаётся на конкретные объекты (шаблоны, воронки, роуты), а не на портал целиком. Запрос за границы области не должен отличаться от запроса к несуществующему объекту — так агент не получает даже подсказку о существовании чужих данных.
3. Явная публикация вместо «всё видно». Инструментом становится только отмеченный роут; недоступный инструмент нельзя вызвать даже по имени.
4. Проверка версии и собственные сверки перед записью. Обязательная проверка версии не даёт затереть чужую правку; преобразование проверяет само себя и отклоняется при расхождении.
5. Снимок перед изменением и откат. Одна команда возврата к рабочей версии дешевле, чем разбор последствий.
6. Журнал каждого обращения. Какой ключ, какой объект, что менялось, затрагивался ли исполняемый код.
7. Лимиты и антифлуд на публичных точках входа. Особенно там, где каждый запрос стоит денег.
8. Защита исходящих запросов. Только HTTPS, проверка резолвнутых адресов против приватных диапазонов, блокировка metadata-сервисов, шифрование ключей.
9. Выключатель. Одно действие, которое останавливает агента целиком, — не «удалить модуль», а галочка.

Сценарии связки

• Чат + SEO-генерация. Чат закрывает вопросы посетителей из базы знаний (без токенов), SEO-модуль наполняет каталог метатегами. Обе задачи не пересекаются, но обе требуют сабпромпта и аккуратных фактов о компании.
• MCP-шлюз + контент. Агент, подключённый к API сайта, может читать каталог и готовить изменения для страниц, а человек принимает их через админку. Важно, чтобы за агентом стояли «читающие» инструменты и отдельно — изменяющие с подтверждением.
• BP Agent + любой агент. Отдельный портал с десятками процессов согласования лучше вынести на отдельный ключ с правами только на нужные шаблоны — даже если у вас уже есть универсальный агент для контента.
• Умный поиск + генерация текстов. Поиск подсказывает, какие запросы не находят товар; генерация текстов помогает довести карточки до нужного уровня. Это две разные метрики, и смешивать их в один «AI-проект» не стоит.

Типичные ошибки внедрения ИИ-агентов

• Дать агенту общий токен администратора «чтобы работало». Все четыре решения содержат механизмы ограничения прав — стоит ими пользоваться.
• Включить запись без проверки. Режим есть, но он и есть основной источник испорченных текстов и сломанных процессов.
• Не заполнить сабпромпт. Тогда модель сама придумает сроки, цены и гарантии — именно то, что нельзя придумывать.
• Публичный чат без лимитов. Один скрипт на цикле превращает публичный эндпоинт в счёт за токены.
• Хранить переписку «на всякий случай». Нужны переключатель записи, срок хранения и исключения по URL (в описании чата это решено).
• Считать, что ИИ сам найдет ошибки в выключенных ветках процессов. Штатная проверка Битрикса их пропускает — нужен отдельный инструмент с отдельной пометкой.
• Отдавать записи в БД агенту напрямую. Описанный подход обратный: агент работает с разрешёнными роутами, а не с базой.
• Забыть про откат. Снимок перед записью — не роскошь, а минимальное условие запуска агента на боевом портале.
• Не логировать вызовы. Без журнала невозможно понять, кто сломал шаблон или почему вырос расход токенов.

С чего начать: чек-лист

1. Выберите одну роль, а не «внедрить ИИ». Самая безопасная отправная точка — чат с локальной базой знаний.
2. Определите, какие данные ИИ видит. Для чата — это база знаний и системная инструкция, а не вся база сайта.
3. Сформулируйте сабпромпт: кто вы, что можно утверждать, что запрещено.
4. Проверьте, какие действия агент может совершить и какие из них требуют подтверждения.
5. Выдайте минимальные права и ограничьте область их действия конкретными объектами.
6. Проверьте биллинг: нужны свои ключи, лимиты токенов, антифлуд, отключение при всплеске.
7. Определите политику хранения диалогов и персональных данных.
8. Убедитесь, что есть снимок/откат и журнал перед включением записи.
9. Проверьте исходящие запросы: HTTPS, запрет приватных диапазонов, шифрование ключей.
10. Прогоните тест: 10–20 реальных вопросов в чате, 5–10 шаблонов в агенте, несколько страниц в SEO-модуле.
11. Только после этого включайте на всех страницах и только затем — автоматическую запись.

Итог

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