У компаний с жестким комплаенсом, по сути, всего два пути для внедрения агентного ИИ: строить самим или покупать готовую платформу. На бумаге выбор выглядит как обычный спор build vs buy, но в реальности цена ошибки здесь выше, чем в типичном пилоте с чат-ботом: если архитектура расползается на набор локальных решений, бизнес получает не ускорение, а новый слой операционного долга.
Об этом пишет The New Stack в материале Брайана Росса о скрытых издержках agentic AI в регулируемых отраслях. Главная мысль проста и неприятна: новая технологическая возможность почти всегда сначала заходит в компанию через точечные сценарии. Одна команда автоматизирует внутренний поиск, другая пробует агента для подготовки документов, третья подключает отдельный инструмент к службе поддержки или аналитике. Каждое решение закрывает свою маленькую боль, выглядит разумно и даже дает быстрый локальный эффект. Проблема начинается позже, когда выясняется, что весь этот парк нужно не просто поддерживать, а держать под едиными правилами безопасности, аудита и контроля доступа.
Собственно, в regulated-среде именно это и становится главным аргументом против наивного подхода “сначала соберем быстро, а там разберемся”. Когда речь идет об агентных системах, дело уже не только в модели и не в качестве ответа. Нужно понимать, какие данные агент видит, какие действия может выполнять, как логируются его решения, кто отвечает за права доступа, как проходит проверка изменений и можно ли потом восстановить цепочку действий для внутреннего или внешнего аудита. В обычной продуктовой команде такие вопросы тоже важны, но там их иногда можно временно обойти. В отраслях с жестким регулированием такой роскоши нет: если агент подключен к чувствительным данным или бизнес-процессам, импровизация быстро становится дорогой.
Именно здесь спор build vs buy перестает быть спором про лицензии и превращается в разговор про системные издержки. Самостоятельная разработка кажется привлекательной, потому что дает контроль: можно выбрать стек, настроить интеграции под себя, не зависеть от дорожной карты вендора и точнее подогнать решение под внутренние процессы. Но контроль не бывает бесплатным. Вместе с ним команда берет на себя разработку и сопровождение всего, что обычно прячется за красивой демо-страницей: управление идентификацией, разграничение ролей, наблюдаемость, политики хранения данных, трассировку действий агента, процедуры эскалации, откат изменений и доказуемый контроль над тем, кто, когда и зачем получил доступ к системе. Если таких агентных сервисов в компании становится несколько, стоимость координации начинает расти быстрее, чем ценность отдельных пилотов.
Покупка готовой платформы, наоборот, обещает сократить этот хаос. Один поставщик, единая модель управления, общие политики, более понятная поддержка и меньше самодельных мостов между командами. Но и здесь статья справедливо подводит к неудобному выводу: покупка не отменяет архитектурную ответственность. Готовый продукт может закрыть часть требований комплаенса и стандартизировать работу с агентами, но не снимает вопросов о том, как именно платформа встраивается в существующий ландшафт, где проходят границы ответственности между вендором и заказчиком, что происходит с данными, насколько глубоко можно настроить контроль и не окажется ли компания запертой в одном стеке. Проще говоря, buy сокращает число самодельных деталей, но не освобождает от инженерной дисциплины.
Для русскоязычной IT-аудитории в этом материале важен не столько сам тезис “строить или покупать”, сколько описание паттерна, который знаком почти любой крупной компании. Сначала появляется новая технология, потом вокруг нее возникают быстрые инициативы “на местах”, а затем платформа, безопасность и архитектура приходят собирать последствия чужой скорости. В случае с агентным ИИ эффект усиливается тем, что агент не просто отвечает на вопрос, а потенциально действует: читает внутренние документы, дергает API, инициирует задачи, работает с заявками, влияет на операционные процессы. Это уже не игрушка для хакатона, а новый класс корпоративного ПО, которому нужны взрослые правила эксплуатации. Поэтому разработчикам здесь придется думать не только про orchestration и качество промптов, но и про журналирование, воспроизводимость, ограничения по действиям, ручные проверки и безопасные контуры запуска. Продактам — считать не только time-to-value, но и цену интеграционного зоопарка. IT-директорам — решать не вопрос “есть ли у нас агент”, а вопрос “можем ли мы управлять десятком агентов как системой, а не как коллекцией экспериментов”.
Отдельно показательно, что разговор о скрытых издержках agentic AI идет именно через призму регулируемых отраслей. Обычно enterprise-рынок любит продавать скорость, автоматизацию и новые интерфейсы. Здесь акцент другой: узкое место не в том, чтобы запустить еще один агентный сценарий, а в том, чтобы потом не утонуть в исключениях, ручных согласованиях и несостыкованных политиках. И это довольно трезвый сигнал для всех, кто сейчас собирает внутренние proof of concept. Если у компании нет ответа на вопросы об управлении, аудите и общей архитектуре, то выбор между build и buy пока вторичен. Сначала нужно понять, какой операционной моделью будет жить агентный ИИ внутри бизнеса, а уже потом решать, кто именно напишет код и кому уйдет счет.