Привет, Хабр.
Я Алексей Арустамов, директор компании‑разработчика аналитической платформы, и некоторое время назад мы начали активно прикручивать на нее MCP. Разумеется, по ходу этого процесса у меня с коллегами происходят разные беседы и споры о планах развития, и несколько недавних показались мне достаточно любопытными для того, чтобы вынести их идеи сюда. Если уже было или банальщина — не обессудьте, но мне лично на глаза эта тема здесь не попадалась, поэтому я ее и сюда и вынес.
Тема дискуссии — в заголовке, но начну я все же немного издалека.
Эволюция интерфейсов
Давайте вспомним, как менялась торговля. Сначала были рынки, где продавец был обязательным посредником между вами и товаром. Потом появились универсамы, где уже можно было ходить самому, но товар всё равно взвешивал и отпускал продавец за прилавком. Дальше — супермаркеты, где мы получили почти полную свободу выбора. Наконец, мы пришли к кассам самообслуживания и покупкам в один клик с телефона (см. рис. 1).
Эволюция торговли была в том, что на каждом таком шаге убирался посредник — и таким образом наше взаимодействие с системой (в данном случае, системой продаж) делалось все прямее и прямее. Получился такой многовековой тренд на самообслуживание.
Теперь обратимся к нашим (и, пожалуй, вашим тоже) рабочим задачам. Раньше рядовой сотрудник обращался к оператору, чтобы тот вбил данные в систему. Потом, чтобы получить аналитику, он шёл к аналитику, который строил отчёт. Однако уже сегодня менеджер часто сам «лезет в 1С» или другую систему. Да, зачастую это еще пока бывает похоже на блуждание по огромному супермаркету со сложной навигацией (в некоторых программах можно вообще потеряться).
Есть основания думать, что следующий логичный шаг — убрать и этот барьер, позволив оператору просто спросить у системы то, что нужно, на естественном языке. Напомню: раньше продавцы обходились без ИТ‑систем, а теперь почти все они — операторы кассовых аппаратов со сканерами штрих‑ и QR‑кодов.
Иными словами уровень необходимой технической грамотности для выполнения базовых функций постоянно снижается.
И вот мы подходим к главному вопросу, который и стал темой для спора (а иногда и холивара) в нашей команде: действительно ли чат‑интерфейсы, усиленные платформами вроде MCP, — это следующий логичный этап эволюции, который со временем вытеснит привычный нам графический интерфейс (GUI) в корпоративной среде? Или это очередной хайп, который займёт свою узкую нишу и на этом всё закончится?
Вспомните интерфейс на своем первом рабочем ПО. Помните сколько времени ушло, чтобы понять, где какая кнопка или менюшка? А теперь представьте, что кнопок и менюшек нет вообще.
Классический GUI и его ограничения
И все же, прежде чем с головой нырять в мир ИИ‑ассистентов и MCP, давайте отдадим должное ветерану — GUI, все‑таки он с нами уже полвека.
Как он начинался, хорошо видно по старым фильмам, где показывают работу ЭВМ — черный экран, зеленые строчки. И тогда это было прорывом по сравнению с бумажными отчетами из под печатной машинки — по сути полотном текста, в котором надо было глазками искать что‑то полезное. Сейчас мы пользуемся GUI с графиками, анимациями и дашбордами — которые позволяют видеть картину целиком и быстро находить нужное. Ну и чем не революция?
Однако от дизайнеров UI/UX на этот счет я слышал такое мнение: «Лучший интерфейс — это тот, которого нет». В идеале, конечно, так — удобно же работать, не задумываясь, какую кнопку нажать. А в реальности, корпоративное ПО до сих пор зачастую выглядит как полная противоположность этому идеалу. Возникает вопрос — почему так сложно сделать этот идеал?
Во‑первых, не всякую рабочую задачу можно уместить в одну кнопку. Сформировать, например, квартальный отчет — это не одно действие, а целая последовательность шагов, или workflow. Разработчикам приходится городить многоэкранные «мастера» и многоэтажные меню.
Во‑вторых, когда в программе уже сотни функций, каждая новая кнопка — это проблема. Куда ее добавить, чтобы пользователи нашли? Как сделать, чтобы она не перегружала экран еще больше?
В итоге пользователь не может найти нужную фичу и считает, что «разработчик тупой, и интерфейс у него тоже тупой», а разработчик проклинает все, пытаясь впихнуть еще одну фичу в и без того раздутый UI (замечу, в основном по хотелкам того же пользователя).
При этом у GUI есть одно неоспоримое достоинство — он честный и предсказуемый. Если кнопка «Сохранить» неактивна, вы сразу понимаете: ага, я не заполнил какое‑то важное поле. Правила игры ясны.
А вот ИИ‑ассистент на базе LLM может «забыть» уточнить у вас критичный параметр и выдать в итоге некорректный результат. Конечно, это не значит, что чаты безнадежны. Просто за красивым фасадом диалога с ИИ‑ассистентом должен стоять «целый конвейер детерминированных инструментов» — строгая логика, которая будет вести модель по шагам и не даст ей ошибиться. Но об этом чуть позже.
И вот тут, на мой взгляд, проявляется важное философское различие в этих подходах, скажем, дашборда и ИИ‑ассистента. Есть такая классификация, которую предложил физик Фримен Дайсон в статье «Птицы и лягушки». Он делил ученых на тех, кто парит высоко и видит общую картину («птицы»), и тех, кто разбирается в деталях («лягушки») (см. рис. 2). Дашборд дает именно «взгляд сверху», как у птицы. Вы видите всю картину данных и сами решаете, куда «нырнуть» для детального изучения. Иногда такое изучение называется разведочный анализ.
А вот совет/рекомендация от ИИ‑ассистента — это скорее «взгляд снизу», как у лягушки в камышах. ИИ подсвечивает вам один конкретный факт, одну аномалию: «Обрати внимание вот сюда». По сути, создается фокус.
Предвижу возражение: но если за чат‑интерфейсом стоит целая толпа агентов, вооруженных инструментами, они же могут показать всю картину, да еще и с рекомендациями, куда смотреть! Могут. Но рекомендация «посвети сюда, потом сюда» — это тот же фонарик, просто направленный по очереди в разные стороны. Как ни крути, фонарик остается фонариком: вы смотрите на данные через серию фокусов и собираете общую картину в голове, а не видите ее целиком. За последнее время и в дашбордах вполне научились управлять вниманием. Но в базовом случае это два разных, взаимодополняющих способа работы с информацией: прожектор и фонарик.
Кстати, именно поэтому часто на разных презентациях меня веселят заявления типа: «Вам больше не нужно смотреть на графики, ИИ сейчас сам все объяснит!» И тут на экране появляется «портянка» ИИ‑текста… Эээ… Постойте, но ведь мы полвека назад как раз от таких «портянок» и уходили в сторону наглядных графиков! Не получается ли, что в погоне за хайпом мы рискуем вернуться к тому, с чего начинали? Ладно, идем дальше.
Новая парадигма: чат‑интерфейс + MCP + low‑code бэкенд
Итак, я надеюсь, мне удалось как‑то донести (уверен, вы и без меня это неплохо знали), что у классического GUI есть свои пределы, а ИИ‑ассистенты без «поводыря» — вещь в корпоративном мире ненадежная.
Но я также упомянул, что за фасадом диалога с ИИ должен стоять «целый конвейер детерминированных инструментов». Предлагаю немного углубиться в этот вопрос: как такой конвейер устроен и почему связка «чат + MCP + low‑code» может стать той самой новой парадигмой (рис. 3).
Итак, представьте, что вы наняли умного товарища помощником (это я про LLM, если что). Он эрудирован и способен рассуждать практически на любую тему, но работает только с текстом: разговаривать и делать выводы из прочитанного — это все, что он умеет.
Чтобы он мог, скажем, посчитать выручку, ему нужен калькулятор (внешний инструмент). Раньше вам приходилось бы каждый раз писать для него инструкцию с нуля:
«Вот калькулятор. У него есть кнопки „+“, „—“, „*“, „/“. Чтобы сложить 2 и 2, нажми „2“, потом „+“, потом „2“, потом „=“».
А если калькуляторов (инструментов) сотни, и они постоянно меняются? Инструкции превратятся в «библии», которые неудобно и дорого поддерживать. Собственно, по этой причине и случилась популярность у MCP — универсального стандарта для таких инструкций. Теперь при правильном подходе можно просто сказать про предоставляемый ИИ‑ассистенту инструмент: «Этот инструмент поддерживает стандарт MCP». Дальше ассистент уже сам «соображает», как им пользоваться. Если более формально, то MCP — это протокол, который автоматизирует передачу информации о доступных инструментах в ИИ‑модель.
Вопрос на засыпку: почему весь мир перешел на USB, а не на какой‑нибудь другой разъем? Нет, не потому что USB идеален. Просто однажды он набрал критическую массу, и все остальные производители его приняли, чтобы их устройства были совместимы.
С MCP произошла похожая история. Компания Anthropic предложила этот протокол в ноябре 2024-го, его поддержал OpenAI в марте 2025-го, и таким образом он «легким движением руки превратился» в отраслевой стандарт — то есть теперь разные системы могут говорить на одном языке. Удобно.
Чтобы вся эта магия заработала — ИИ‑ассистента мало. Нужны как минимум три компонента:
MCP‑сервер — это наш бэкенд, где и живут те самые «калькуляторы» (бизнес‑логика, алгоритмы).
MCP‑хост — это фронтенд, то самое чат‑окно, куда пишет пользователь.
Сервер моделей, где, собственно, и крутится мозг нашего ИИ‑ассистента.
Сам по себе MCP‑сервер полезен не более, чем розетка без вилки и электроприбора.
Теперь давайте посмотрим, как работает эта связка на каком‑нибудь базовом запросе (привожу примеры из нашей сферы, но вы можете экстраполировать эту логику на продукт).
Пользователь пишет в чат (MCP‑хост): «Рассчитай скидку для ООО „Вектор‑Альянс“».
Хост «показывает» модели список доступных инструментов, полученный от MCP‑сервера («У меня есть инструмент для расчета скидки, вот его параметры...»).
Модель анализирует запрос и список инструментов, после чего формирует вызов инструмента в формате JSON: «Окей, вызови
calculate_discountс параметром client_name: „Вектор Альянс“».Хост получает этот JSON, вызывает соответствующий MCP‑сервер с указанными параметрами.
Сервер выполняет заложенный в него алгоритм (например, лезет в базу, проверяет историю заказов, считает по формуле) и возвращает результат, например,
{"discount": 3}.Этот результат снова отправляется модели, которая уже на естественном языке формулирует ответ пользователю: «Скидка для ООО „Вектор‑Альянс“ составит
3%».
Ну где же брать эти «инструменты» для MCP‑сервера? Писать код вручную? Можно, но долго. Как вариант — low‑code платформы. Они позволяют «собирать» нужный алгоритм из готовых визуальных блоков, как в детском конструкторе. Аналитик, который хорошо знает бизнес‑процесс, но не является программистом, может сам собрать сценарий расчета той же скидки, причем с пониманием того, что и как считается, а затем опубликовать как MCP‑сервер (в разных продуктах такая публикация реализуется по‑разному, у нас можно просто поставить галочку). Всё, инструмент готов к использованию ИИ‑помощником.
Вот и получается, что фронтенд превращается просто в окно чата без сложных менюшек и наборов кнопочек, а весь сложный бэкенд реализуется в визуальном редакторе.
Без MCP эта магия не работает. Если мы у LLM (без наворотов) просто спросим: «Какую скидку дать ООО „Вектор Альянс“?», она выдаст какую‑нибудь банальную ерунду типа: «Размер скидки зависит от истории покупок, объема заказов и вашей маркетинговой политики...». Да‑да, верно, но бесполезно (рис. 4). Вот она — сила детерминированного инструмента.
Окей. Усложним задачу. Менеджер пишет в чат: «Забронируй 100 единиц товара X». А на складе их всего 70. Что сделает ИИ‑ассистент? Тут будет дилемма.
Если в воркфлоу с инструментом не предусмотрены жесткие правила, то ИИ‑ассистент может просто ответить «Хорошо, забронировано 100 единиц».
А если предусмотрены, то, скажем, MCP‑сервер, получив такой запрос, обратится к реальным остаткам, увидит, что их 70, и вернет результат модели, а та выдаст пользователю: «Запрошенного количества нет в наличии, доступно только 70».
Это я к тому, что над логикой работы MCP‑сервера и инструментов предстоит много работать. Доверять в бизнесовых задачах вероятностной природе LLM никак нельзя, особенно там, где ответ должен быть единственно верным. Например, при расчете по методике ЦБ или нормативам Налогового кодекса — здесь нет места для «творчества» модели. Это базовые вещи, но проговорить я их должен. Идем дальше.
Аргументы «за»: где чат‑интерфейс выигрывает
Вернемся к философскому различию между «взглядом птицы» (дашборд) и «взглядом лягушки» (ИИ‑ассистент). Возникает резонный вопрос: а есть ли класс задач, где «лягушка» не просто удобнее, а на голову выше «птицы»? Есть. Представьте менеджера, который говорит с клиентом по телефону. У него нет времени «нырять» в дашборды и заниматься разведочным анализом. Ему нужен конкретный ответ здесь и сейчас. В такой ситуации готовые рекомендации от ИИ гораздо удобнее, чем сложные отчеты.
Получается, что ИИ‑ассистент отлично работает в любой ситуации, когда для решения нужны рекомендации на основе анализа кучи информации, особенно, если цена ошибки не слишком велика. По сути, ИИ‑ассистент — это персональный советчик по любым вопросам. Но, как мы уже выяснили, чтобы он мог давать дельные советы, а не быть «капитаном очевидность», ему нужна качественная информация из корпоративных систем.
Ну а на практике, в чем польза от такого ИИ‑ассистента? Первыми приходят на ум такие варианты (рис. 5).
Продажи и маркетинг: подсказать, что ещё можно предложить клиенту (cross‑sell/up‑sell), написать персонализированное письмо, собрать полный профиль клиента из разных баз данных или найти похожих на него в общей базе.
Безопасность и поддержка: предупредить менеджера, что клиент похож на мошенника и его стоит проверить дополнительно, автоматически ответить на типовой вопрос в техподдержку или грамотно маршрутизировать сложную заявку на нужного специалиста.
Работа с данными и контентом: найти нужную информацию в корпоративной базе знаний, извлечь из текста или изображения нужные объекты (например, найти все договоры с определённым условием), обогатить данные из внешних источников.
Да, каюсь, я немного зациклился на продажах и маркетинге. Исправляюсь — набор возможных применений гораздо шире. Продолжу:
Производство: рекомендация по предиктивному ремонту оборудования на основе данных с датчиков.
HR: помощь в найме персонала, например, первичный скрининг резюме или предложение наиболее подходящих кандидатов из базы.
Логистика: оптимизация маршрутов доставки с учетом пробок и загруженности складов.
Менеджмент: анализ рисков по новому проекту, контроль качества или даже анализ конкурентной среды. По сути, в любой сфере, где для принятия решения нужно обработать большой массив разнородной информации, ИИ‑ассистент с доступом к нужным инструментам может оказаться незаменимым.
Стоит отметить, что ИИ‑ассистент — может быть не только реактивным, но и проактивным. Как поиск в Google — там только начинаешь вводить запрос, а он уже предлагает варианты. Но здесь же такое тоже можно сделать. Например, вы открыли карточку клиента, с которым давно не общались. Может ИИ‑ассистент сработать на опережение и предложить: «Давно ничего не заказывал. Напомнить ему о себе? Вот черновик»? Почему бы и нет?
Аргументы «против»: ограничения, риски и неготовность к полной замене
Итак, новую парадигму похвалили, пора и покритиковать. Помните притчу о слепых мудрецах и слоне? Каждый из них ощупал лишь одну часть — хобот, ногу или хвост, — и был абсолютно уверен, что знает, как выглядит всё животное. Пользователь ИИ‑ассистента — это такой же мудрец, который держится за «хобот» (конкретный факт от ИИ) и думает, что познал всю истину, пока весь остальной «слон» остается для него невидимым (рис. 6).
Между тем, есть целый класс задач, где диалог с машиной в принципе неудобен. Я, например, не могу представить художника, который «просит» ИИ не набросать черновик, а довести до ума, например, подвигать ползунки в палитре, или инженера в Автокаде, который пытается объяснить системе, что нужно передвинуть какую‑то линию на два пикселя левее. Это же абсурд.
Такие задачи требуют прямого взаимодействия — взять и подвинуть, видя результат в реальном времени. Означает ли это, что ИИ‑ассистенты бесполезны? Да нет, конечно. Это лишь означает, что мы вряд ли перейдем на интерфейс с одной‑единственной строкой ввода. Скорее всего, будущее за гибридом: мы сможем голосом попросить ИИ‑ассистента «создать чертеж стандартного фланца по ГОСТ X», а затем, получив заготовку, откроем графический редактор и уже «напильником» доведем его до ума, вращая модель и корректируя детали. GUI мы развиваем полвека, ИИ‑ассистенты в их нынешнем виде совсем молоды — им еще предстоит найти свое место в экосистеме, а не заменить ее целиком.
Предвижу вопрос о безопасности — ведь хитрый пользователь сможет «обмануть» ИИ и заставить его сделать что‑то нехорошее (я про prompt injection). Однако в упомянутой выше MCP‑архитектуре этот риск не так велик. Модель ведь сама ничего не исполняет, а лишь просит выполнить действие отдельный инструмент, который работает по строгим правилам.
Это значит, что если мы, к примеру, попросим ИИ‑ассистента заказать пиццу, то он вызовет посредника — защищенное приложение для заказа, а не получит прямой доступ к вашему банковскому счету. Настоящая опасность в другом — когда ИИ имеет прямой доступ к ресурсам сервера и может, например, сам писать и выполнять код. Вот это уже настоящая компрометация.
Но и тут не все безнадежно и есть решение из мира «классического» энтерпрайза: MCP‑сервер может и должен работать с правами, унаследованными через стандартные протоколы вроде LDAP или OpenID. Главное, чтобы сценарии, которые мы ему даем, были спроектированы правильно и с учетом принципа минимальных привилегий.
И, наконец, два важных принципа любого бизнесового ПО: аудит и ответственность. И вот если банк сегодня клиенту отказал в кредите, а завтра — одобрил, то регулятор или служба безопасности могут задать неудобный вопрос — «почему?». На такие запросы у банка должен быть четкий ответ с протоколом: какой запрос пришел, какие данные использовались, какой ответ был получен. LLM с ее вероятностной спецификой тут здесь не прокатит.
Точно так же и с ответственностью. Если что‑то пошло не так, кто виноват? Модель не уволишь. И у себя на платформе мы сделали так, что ответственность несет человек — тот, кто спроектировал, протестировал и утвердил сценарий, который потом используется как инструмент. Модель в данном случае — лишь посредник, а вся логика и, как следствие, ответственность за результат остаются в руках человека.
Заключение
Заканчиваю этих размышления я некоторыми соображениями, которые высказываются у нас в команде. Было бы интересно почитать и ваши соображения на этот счет — что мы упускаем из виду?
Когда ждать массового внедрения
Оптимисты в нашей команде считают, что ждать осталось недолго: уже через 3–4 года мы увидим массовые пилотные проекты, а ИИ‑расширения станут стандартной частью большинства корпоративных продуктов. Это продолжит тренд на «демократизацию» работы с данными: если сейчас кассиру не нужно было быть программистом, чтобы работать с кассой, то скоро и менеджеру не понадобится глубокое знание BI‑системы, чтобы получить нужную аналитику.
Другие коллеги настроены более сдержанно, проводя аналогию с появлением Windows и MacOS. По их мнению, переход будет сначала плавным, а потом, по мере накопления критической массы, — скачкообразным. Самый смелый прогноз — за 10 лет доля классических GUI в корпоративном секторе может упасть до 10–20%.
Кто внедрит быстрее
Есть мнение, что именно некорпоративные пользователи и стартапы внедрят новые интерфейсы гораздо раньше. Им не мешает груз legacy‑систем и строгих политик ИБ. Для них горизонт — ближайшие 5 лет, и речь может идти даже о появлении новых операционных систем, изначально построенных вокруг взаимодействия с ИИ‑ассистентом.
А вот у крупных корпораций путь будет дольше, возможно, до 10 лет. Больше всего процесс будет тормозиться из‑за безопасности, боязни утечек чувствительных данных и, как следствие, к повышенной осторожности ко всяким там ИИ‑новшествам.
Без чего MCP не взлетит
Конечно, можно долго и красиво рассуждать о светлом будущем с ИИ‑ассистентами в связке с MCP, но вообще‑то чтобы это все стало по‑настоящему энтерпрайзовым инструментом сначала нужно разгрести не одну конюшню выстроить ИИ‑инфраструктуру: развернуть серверы для моделей, настроить безопасные шлюзы, организовать логирование и мониторинг. Без этой рутины разговоры о более высоких уровнях абстракции (MCP, low‑code инструменты и пр.) будут похожи на попытку клеить обои в доме без стен.
Ну и конечно, не забываем про базовый для ИИ принцип: garbage in — garbage out. Без правильных, актуальных и доверенных входных данных, даже на самой волшебной ИИ‑инфраструктуре о точных отчетах и рекомендациях ассистентам можно даже не мечтать.
Ну и что думаете, в итоге, уважаемые читатели? Будет тренд на замену GUI правильными ИИ‑ассистентами? Где замена маловероятна? Встретимся в комментах.
