директор и машина · операционное управление · запись № 059 · 29 августа 2026 · Давид Герштейн

Model Context Protocol: как ИИ подключается к CRM, таблицам и диску компании

Примеры пересчитаны на условную компанию — механика и выводы из живой практики.

Спросите себя: сколько раз за последний месяц вы или ваши люди делали выгрузку из CRM, чтобы что-то посчитать? А теперь умножьте на год. Вот это и есть цена того, что машина у вас не подключена к системам, — и платите её вы не деньгами, а вечерами.

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

Какую проблему решает Model Context Protocol

Смотрите, в чём тупик. Без подключений любой разговор с машиной о ваших данных начинается с ручного труда: выгрузить, почистить, вставить, объяснить, что в какой колонке. Для разовой задачи терпимо. Для регулярной — смертельно: «сводка по зависшим сделкам каждый понедельник» на практике означает, что кто-то каждый понедельник делает выгрузку. И этот кто-то — обычно самый занятой человек в компании.

Автоматизация ломается не об ум машины. Она ломается об подноску данных.

MCP — Model Context Protocol — решает ровно эту проблему. Это открытый протокол, опубликованный Anthropic в конце 2024 года и с тех пор поддержанный остальной индустрией: стандартный способ дать машине доступ к внешней системе. Аналогия, которая нам кажется точной: USB для ИИ. До стандарта каждое устройство требовало свой шнур; после — один разъём подходит ко всему. До MCP каждая связка «модель × система» программировалась отдельно; теперь коннектор пишется один раз — и работает с любым ИИ-хостом, который понимает протокол.

Как это устроено: три слоя

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

Что это даёт руководителю: три сценария

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

Документы из папки. Машина читает договор прямо с корпоративного диска: «разбери риски в последней версии договора с клиентом К., сравни с нашей типовой формой». Двух шагов — найти файл и вспомнить, где лежит типовая форма, — больше нет.

Регулярные сводки без подноски. Связка с агентом (подробно — в разборе про ИИ-агентов): по расписанию машина сама собирает данные из подключённых систем и готовит отчёт. Именно на этой связке — подключения плюс агент — построены наши контуры: оценка звонков читает записи и пишет в свою таблицу, разбор документов берёт файлы из потока и возвращает извлечённые поля.

Цена ручной подноски данных

Чтобы решение о подключениях принималось не на ощущениях, посчитайте свою «подноску». В нашей условной компании еженедельная сводка по воронке до подключения выглядела так: выгрузка из CRM, чистка колонок, загрузка в чат, объяснение контекста — порядка 40 минут работы, 52 раза в год. После подключения тот же вопрос задаётся одной постановкой — около 5 минут на прочитать результат и уточнить (оценка).

Три задачи по 40 минут в неделю — это больше сотни часов в год, съеденных не анализом, а транспортировкой данных. Против этой цифры и взвешивается неделя на настройку подключений.

Как это настраивается: реалистичный план

Разберём три типовых случая по нарастанию сложности — с честными сроками из практики.

Прикиньте, к какому случаю относится ваша ситуация.

Случай 1: массовая система, готовый коннектор — час-день. Облачные таблицы, диск, календарь, популярные таск-трекеры: коннектор ставится из каталога, настройка сводится к авторизации и выбору области доступа. Единственная содержательная работа — решить, что именно открывать: не «весь диск», а папку; не «все таблицы», а нужные.

Случай 2: массовая CRM — день-неделя. Коннекторы к популярным CRM — Битрикс24, amoCRM и другим — существуют, но здесь добавляется работа с правами внутри самой CRM: отдельная учётка для машины с ролью «только чтение нужных воронок». Неделю занимает не техника, а согласование: кто отвечает за эту учётку, кто видит журнал её действий, как её отзывают.

Случай 3: самописная система — дни разработки. Коннектор — это небольшая программа, которая переводит запросы протокола в запросы к вашей системе. По нашей практике, для системы с готовым внутренним API это дни работы одного разработчика; сложность растёт не от MCP, а от состояния вашего API. Хорошая новость: писать коннектор нужно один раз — дальше он работает с любым хостом.

Постановка для машины при работе через подключение выглядит буднично — и в этом суть: данные перестают быть событием:

По подключённой CRM: собери сделки со стадии «переговоры»,
у которых нет активности 14 дней и больше.

Сгруппируй по менеджерам, внутри — по убыванию суммы.
Для каждой: клиент, сумма, дней без движения, последняя заметка
одной строкой.

Ничего в CRM не меняй и не создавай — только чтение.
Если данных по полю нет — ставь прочерк, не додумывай.

Формат: таблица + три строки вывода, какие менеджеры
перегружены зависшими сделками.

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

Что внутри коннектора: для порядка величин

Вам не нужно писать коннекторы. Но понимать масштаб полезно — иначе вы не сможете оценить ни срок, ни смету подрядчика. Коннектор — это небольшая программа, которая объявляет машине список своих «умений» (например: «найти сделки по фильтру», «прочитать карточку клиента», «список файлов в папке») и переводит каждое умение в запрос к вашей системе. Умение описывается названием, параметрами и текстом-подсказкой, по которой машина понимает, когда его применять. На этом устройство протокола, по сути, исчерпывается — остальное детали реализации.

Отсюда, если вы заказываете коннектор снаружи или ставите задачу своему разработчику, два практических вывода. Первый: смета «коннектор к вашей CRM — три месяца работы команды» должна вызывать вопросы — либо в CRM нет вменяемого API и три месяца уйдут на него, либо вам продают лишнее. Второй: качество коннектора — это качество подсказок к умениям; если машина «не видит» данные или дёргает не тот инструмент, чинится обычно текст описаний, а не код — работа на часы.

Безопасность: относитесь к подключению как к найму

Теперь то, из-за чего я бы не спал, если бы делал это неаккуратно. Каждый коннектор — это доступ, выданный исполнителю, пусть и нечеловеческому. И решать, какой именно доступ выдать, придётся вам: раздача прав машине — базовый навык руководителя в компании, где работает автоматизация, тот же самый, которым вы решаете, кому из людей открыть договоры, а кому — только их реестр. Мои правила, выработанные там, где машина третий месяц читает рабочие данные:

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

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

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

Типовые ошибки внедрения — по горячим следам

Эти четыре ошибки я видел столько раз, что рискну предсказать: минимум одну вы совершите. Лучше заранее знать какую.

Подключить всё сразу. Ваш энтузиаст за вечер цепляет к машине диск, почту, CRM и календарь. Через неделю никто не помнит, что открыто, через месяц это выясняет проверка. Правильный темп — одно подключение, одна регулярная задача на нём, и только потом следующее: подключение без задачи — это открытая дверь без причины.

Одна учётка на всех. Машину подключают под личной учёткой владельца «потому что у него есть все права». Теперь машина видит всё, что видит владелец, включая то, что ей не нужно, а в журналах системы её действия неотличимы от действий человека. Отдельная учётка с именем вроде «ai-reader» решает обе проблемы и стоит десять минут.

Доверить машине помнить контекст безопасности. «Мы же ей сказали не трогать боевые данные» — сказали в одном чате, а работает она в десяти. Ограничения живут в правах учётки, а не в памяти разговора; постановка их только дублирует. Любое правило, существующее лишь в виде просьбы к машине, следует считать несуществующим.

Забыть про офбординг. Реестр подключений нужен не только для аудита: когда меняется система, увольняется ответственный или отзывается ключ, кто-то должен знать, что перевыпустить и где отключить. У доступа, как у сотрудника, есть не только первый день, но и последний.

Когда Model Context Protocol не нужен

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

Model Context Protocol и агенты: где сила связки

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

Практическое следствие для очерёдности внедрения: сначала подключения (они полезны сразу и без агентов), затем регламент на ручных прогонах, и только потом агент поверх. Обратный порядок — сначала «купить агента», потом думать, откуда он возьмёт данные, — регулярно встречается в коммерческих предложениях и стабильно заканчивается пилотом, который «почти работает». Подробно про очерёдность и жизненный цикл — в разборе про агентов.

С чего начать

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

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

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

И имейте в виду одну вещь. Через год подключённая к системам машина будет такой же обыденностью, как сегодня телефон с почтой. Разница между компаниями будет не в том, у кого она есть, а в том, кто научился ею управлять раньше — и успел за это время перестроить работу.

Частые вопросы

Model Context Protocol — это то же самое, что MCP-сервер с GitHub?

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

Что такое Model Context Protocol простыми словами?

Это стандартный «разъём», через который ИИ-ассистент подключается к вашим системам — таблицам, CRM, диску. Один раз настроили коннектор — и машина сама читает нужные данные в рамках выданных прав, без ручных выгрузок.

Безопасно ли давать ИИ доступ к данным компании?

Настолько, насколько аккуратно выданы права. Правило то же, что при найме: доступ по минимуму, сначала только чтение, критичные системы в последнюю очередь, и отдельный учёт того, какие подключения кому выданы.

Какие системы можно подключить?

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

Чем MCP отличается от обычной интеграции по API?

Обычная интеграция соединяет две конкретные системы жёстким сценарием. MCP подключает к системе машину, которая сама решает, что и когда спросить, под задачу — один коннектор закрывает целый класс сценариев вместо одного.

Нужен ли программист, чтобы пользоваться MCP?

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

#ии и нейросети #инструменты #автоматизация