Введение
Если в компании работает 1С, рано или поздно появляется вопрос: можно ли дать ИИ-агенту доступ к базе, чтобы он отвечал на вопросы о данных, готовил черновики документов и проверял остатки, не переписывая интеграцию под каждую модель. Протокол MCP (Model Context Protocol) — один из самых обсуждаемых способов это сделать. Ниже разобрано, что он даёт, где проходят ограничения и с чего начать пилот.
Материал носит практический характер. Он не заменяет техническое задание и не гарантирует совместимость с конкретным релизом платформы: это нужно проверять на вашей конфигурации.
Что такое MCP простыми словами
MCP — открытый стандарт того, каким способом модель подключается к внешним системам: файлам, базам данных, API и сервисам. Без стандарта каждая связка «модель — система» писалась бы отдельно. Теперь можно написать один MCP-сервер для системы и подключать к нему разных клиентов: настольные AI-приложения, среды разработки, собственные агенты.
Схема состоит из трёх ролей. Хост — приложение, в котором работает модель, например чат или редактор кода. Клиент — компонент внутри хоста, который держит соединение с сервером. Сервер — программа, которая открывает доступ к данным и действиям. Сообщения между ними построены на JSON-RPC 2.0, а транспорт бывает двух видов: stdio, когда сервер запускается как локальный процесс, и Streamable HTTP, когда сервер работает как отдельный сетевой сервис.
Для бизнеса важен не транспорт, а то, что стандарт задаёт единый способ описать, какие действия доступны агенту и какие данные он может прочитать. Это снижает стоимость смены модели или клиента.
Что изменилось: MCP становится общим стандартом
Стандарт, который Anthropic открыла в конце 2024 года, в декабре 2025 года передан в Agentic AI Foundation — фонд под эгидой Linux Foundation. По данным обзоров рынка за 2026 год, MCP используют и SDK, и тысячи публичных серверов, но цифры в разных источниках расходятся. Поэтому в расчётах мы не опираемся на отраслевые проценты внедрения: их стоит перепроверять по первоисточнику перед тем, как ссылаться на них в документах.
Практический смысл в другом. Как следует из обзоров рынка, всё больше клиентских приложений поддерживают MCP, и инструмент, написанный один раз, может работать в нескольких клиентах. Для компании это уменьшает риск привязки к одному поставщику модели.
Официальная документация стандарта доступна на сайте modelcontextprotocol.io. Перед внедрением сверяйте версию спецификации: в открытых источниках упоминаются разные ревизии протокола.
Как MCP работает: три примитива
У сервера есть три вида возможностей, и разница между ними важна при проектировании.
Инструменты (tools) — функции, которые модель может вызвать сама. Например, «найти контрагента по ИНН», «создать черновик счёта», «получить остатки на складе». Клиент получает список инструментов через запрос tools/list, а выполняет их через tools/call. Решение о вызове принимает модель, поэтому именно инструменты требуют самого строгого контроля прав.
Ресурсы (resources) — данные только для чтения, которые приложение или пользователь прикрепляют к контексту. Это могут быть карточка товара, выгрузка отчёта или текст регламента. Каждый ресурс имеет адрес в виде URI. Решает обычно не модель, а пользователь или приложение.
Промпты (prompts) — шаблоны запросов, которые пользователь вызывает явно, часто как команду в интерфейсе. Например, «сверка взаиморасчётов за месяц» с заранее заданной структурой ответа.
Для автоматизации в 1С чаще всего нужны инструменты и ресурсы. Промпты полезны, когда у команды появляется набор типовых вопросов, которые задают одинаково.
Зачем MCP бизнесу, которому нужна 1С
Большинство российских компаний, работающих с учётом, закупками и продажами, держат основной учётный контур в 1С. Данные там структурированы, но доступ к ним для неспециалиста закрыт: нужно знать конфигурацию, открыть отчёт, выбрать период, выгрузить в таблицу. Агент, подключённый через MCP, может взять на себя часть этих запросов.
Важно сразу разделить два класса задач. Первый — чтение: ответы на вопросы по данным, поиск документа, сводка по контрагенту. Здесь риск ниже, потому что изменения не происходят. Второй — запись: создание документов, изменение статусов, проводки. Запись требует подтверждения человеком, журнала действий и отдельной роли пользователя в 1С.
Начинать стоит с чтения. Оно даёт понятный эффект и позволяет проверить качество ответов до того, как агент получит право что-то менять.
Два пути подключения 1С к MCP
Сообщество разработчиков 1С предлагает несколько подходов. На момент подготовки материала единого официального MCP-сервера от 1С для платформы «1С:Предприятие 2026» мы не нашли, поэтому речь идёт о проектах сообщества и подходах на базе платформы.
Первый путь — готовое расширение с открытым исходным кодом. Например, проект vladimir-kharin/1c_mcp позволяет создать MCP-сервер средствами самой 1С. Он берёт на себя технические детали протокола, а разработчик описывает бизнес-логику инструментов. Инструменты для работы с метаданными конфигурации в нём доступны сразу. Такой вариант подходит для пилота, потому что его можно поднять на тестовой базе за короткое время.
Второй путь — реализация MCP-сервера на уровне интеграционной шины «1С:Шина». По описанию авторов, доступ к данным в этом варианте разграничивается по пользователям: для каждого пользователя выпускается отдельный токен, который передаётся до сервера и определяет, какие данные вернёт база. Это ближе к модели прав, которую уже использует компания, но требует большего объёма разработки.
Третий вариант — агентская среда разработки, где MCP-сервер вызывает сторона, на которой работает ИИ-агент. В этом случае адреса и ключи лучше держать в переменных окружения, а не в конфигурации агента, и ограничивать список разрешённых инструментов. Каждый лишний инструмент — ещё один канал, по которому данные могут уйти в модель.
Как подключить MCP к Claude или другому клиенту, описано в документации самого клиента. Сервер при этом должен быть готов заранее, и его инструменты проверены на тестовой базе.
Совместимость с конкретной версией платформы нужно проверять отдельно. Открытые проекты часто указывают поддерживаемые релизы, и это первое, что стоит уточнить у исполнителя.
Какие процессы можно отдать агенту
Ниже — процессы, с которых обычно начинают. Для каждого указано, что агент делает и что остаётся за человеком.
Ответы на вопросы по учёту. Менеджер спрашивает, сколько дебиторской задолженности у клиента на сегодня и когда была последняя оплата. Агент находит контрагента, читает нужные регистры через инструмент и формирует ответ со ссылками на документы. Решения по взысканию принимает человек.
Поиск документов. Бухгалтер ищет счёт-фактуру по номеру из письма поставщика. Агент сопоставляет номер, дату и сумму, а затем открывает карточку документа. Проведение документа остаётся за бухгалтером.
Черновики. Агент готовит черновик заявки на закупку по остаткам и среднему расходу за период. Заявка не уходит в работу, пока её не утвердит ответственный сотрудник.
Сверка. По просьбе пользователя агент сравнивает данные из выгрузки банка с платёжными документами в базе и выделяет расхождения. Итоговый список проверяет человек.
Поддержка внутренних пользователей. Сотрудники задают вопросы по регламентам, которые загружены как ресурсы. Агент отвечает по тексту регламента и указывает раздел.
Сценарии записи — отдельная история. Их стоит добавлять только после того, как чтение стабильно работает, и только с подтверждением пользователя перед каждым изменением.
Кому подходит и какие роли нужны
Подход подходит компаниям, которые уже используют 1С как основной учётный контур и готовы выделить время на один пилотный процесс. Его разумно рассматривать, если в компании есть постоянные вопросы к данным, которые отнимают время у бухгалтеров, менеджеров и руководителей.
Для пилота нужны три роли. Владелец процесса — сотрудник, который знает бизнес-правила и может оценить качество ответов. Администратор 1С — человек, который настраивает права, учётные записи и тестовую базу. Разработчик — исполнитель, который пишет или настраивает MCP-сервер и отвечает за инструменты.
В маленькой компании одна и та же задача может закрываться одним человеком, но права доступа всё равно нужно настроить отдельно от личного пользования.
Что нужно для запуска: данные, доступы, инфраструктура
Минимальный набор такой.
Тестовая база 1С — копия продуктивной базы, на которой можно проверять инструменты без риска для данных. Копия должна обновляться по расписанию, иначе ответы агента будут устаревать.
Описание процесса: какие вопросы задают, какие данные нужны, какой ответ считается правильным. Без этого не с чем сравнивать качество.
Учётные записи 1С с ограниченными правами. Для агента заводится отдельный пользователь, которому доступны только нужные роли и объекты. Если в базе есть персональные данные, их доступ ограничивается отдельно.
Сервер MCP и место его размещения. Если сервер работает локально, для него нужен защищённый канал до базы. Если он работает в сети, нужны сетевые правила и журнал запросов.
Модель и клиент. Выбор зависит от требований к передаче данных. Если данные не должны покидать контур компании, нужна локальная модель или корпоративный шлюз, и это влияет на бюджет и качество ответов.
Инструкция для сотрудников: что можно спрашивать, какие ответы проверять вручную, куда писать об ошибке.
Пошаговый план пилота
Пилот удобно разбить на шесть шагов.
Первый шаг — выбор одного процесса. Берите задачу, которая повторяется каждую неделю и не требует записи в базу. Хороший признак: сейчас на неё уходит несколько часов и её можно проверить за несколько минут.
Второй шаг — описание инструментов. Для каждого вопроса нужен отдельный инструмент с понятными входными параметрами. Например, «получить задолженность контрагента на дату» вместо общего «выполнить запрос».
Третий шаг — настройка прав и тестовой базы. Учётная запись агента получает только нужные объекты. Все инструменты сначала проверяются вручную, без модели.
Четвёртый шаг — проверка качества на наборе вопросов. Подготовьте 30–50 реальных вопросов с эталонными ответами. Прогоните их через агента и посчитайте, сколько ответов совпало, сколько потребовало уточнения, сколько ошибочных.
Пятый шаг — ограниченный запуск. Доступ получают два-три сотрудника, которые понимают задачу. Ошибки фиксируются в журнале.
Шестой шаг — решение. По итогам пилота принимается одно из трёх: расширять процесс, доработать инструменты или остановиться. Остановка тоже результат, если выяснилось, что данные не готовы.
Ориентировочные расходы и эффект
Точная стоимость зависит от конфигурации, объёма данных, выбранного варианта подключения и исполнителя. Поэтому ниже только порядок величин и логика расчёта, без обещанных цифр.
Основные статьи расходов: работа разработчика по инструментам, настройка тестовой базы и прав, модель и её использование, сопровождение после запуска. Первая статья обычно самая заметная, потому что каждый инструмент требует проверки на реальных данных.
Эффект считается через время. Возьмите один процесс, посчитайте, сколько часов в месяц уходит на вопросы и поиск, и сравните с затратами на пилот и сопровождение. Если сэкономленное время не покрывает сопровождение, процесс выбран неудачно или инструменты слишком дорогие в разработке.
Оценочный показатель для планирования: если пилот занимает несколько недель и касается одного процесса, решение о масштабировании обычно принимают по данным за один-два месяца работы. Раньше делать выводы рискованно.
Риски и ограничения
Первый риск — неверный ответ, который выглядит уверенным. Модель может соединить данные из двух объектов или неправильно понять период. Защита — эталонный набор вопросов, ссылки на документы в ответе и обязательная проверка при любых финансовых выводах.
Второй риск — утечка данных. Если агент получает доступ к персональным данным, а клиент или модель находятся за пределами контура компании, данные могут уйти туда, где их не должно быть. Перед запуском проверьте, какие поля попадают в ответы, и где обрабатывается запрос.
Третий риск — избыточные права. Агент с правами на всю базу опаснее сотрудника, который делает запросы вручную, потому что он делает их быстрее и без паузы. Права ограничиваются по роли и по объекту.
Четвёртый риск — зависимость от сообщества. Открытые проекты могут не поддерживаться или отставать от новых релизов платформы. Заложите время на обновление и на возможную замену компонента.
Пятый риск — ожидания руководства. MCP не даёт автоматического роста производительности. Он убирает часть ручных запросов, а остальную работу по-прежнему делают люди.
Ограничение технического характера: инструменты работают с тем, что описано. Если в конфигурации есть нестандартные объекты, их придётся описывать отдельно, и это увеличивает объём работ.
Безопасность: права, токены, журнал
Безопасность в такой схеме строится на трёх уровнях.
Первый уровень — учётные записи. Агент работает под отдельным пользователем 1С, и его роли должны совпадать с ролью человека, который задаёт вопрос, или быть уже. Если агент отвечает на вопросы бухгалтера, он не должен видеть то, чего бухгалтер не видит.
Второй уровень — токены и секреты. Ключи доступа к модели и к базе хранятся в переменных окружения или в хранилище секретов, а не в тексте конфигурации агента и не в репозитории. При смене сотрудника или подозрении на утечку токены перевыпускаются.
Третий уровень — журнал. Каждый вызов инструмента фиксируется: кто задал вопрос, какой инструмент вызван, с какими параметрами, сколько записей вернулось. Журнал нужен для разбора ошибок и внутреннего аудита.
Отдельно стоит решить, какие инструменты могут менять данные. На старте таких инструментов лучше не делать вовсе. Если они нужны, каждое изменение должно требовать подтверждения человеком в интерфейсе, а не по решению одной модели.
MCP или прямой API: что выбрать
Прямой вызов API 1С или интеграционной шины часто проще для одной фиксированной задачи, например для выгрузки в отчёт по расписанию. Здесь не нужны модель и диалог, достаточно обычного кода.
MCP выигрывает там, где вопросы заранее не известны, а пользователь хочет спрашивать на естественном языке и получать ответ со ссылками на данные. Стандарт также полезен, если компания рассчитывает подключать несколько клиентов, например чат для сотрудников и редактор кода для разработчиков, к одному набору инструментов.
Правило простое: если задача повторяется по расписанию и формат ответа фиксирован, берите обычный API. Если задача звучит как вопрос, на который заранее нельзя написать один запрос, рассматривайте MCP.
Вывод и следующий шаг
MCP даёт способ подключить ИИ-агента к данным 1С без отдельной интеграции под каждую модель. Для бизнеса практичная отправная точка — один пилотный процесс, в котором агент отвечает на вопросы по данным, без права записи. Пилот проверяет три вещи: качество ответов, корректность прав и реальное время, которое удалось сэкономить.
Если вы хотите понять, подходит ли такой подход вашей базе, начните с инвентаризации: какие вопросы задают чаще всего, какие отчёты строятся вручную и какие права уже есть у пользователей. Эти три списка дают основу для технического задания.
Похожие вопросы разбираются в материалах о том, как заказать ИИ-агента: там описано, какие данные и документы нужны исполнителю. Общий обзор задач для агентов в бизнесе есть в материале AI-агент для бизнеса: задачи, стоимость и окупаемость. Новости рынка агентов за октябрь 2026 года разобраны в отдельном обзоре.
