Databricks: только 19% организаций вывели AI‑агентов в продакшен — названы ключевые практики

В отчёте State of AI Agents Databricks фиксирует низкую зрелость развёртывания агентов (19% организаций) и называет препятствия — доступ к данным, оценка корректности и перестройка процессов.

Databricks в отчёте State of AI Agents констатирует: лишь 19% организаций фактически развернули AI‑агентов в продуктивной среде, а большинство проектов остаются экспериментальными или частичными. Основные препятствия — трудности с переработкой существующих рабочих процессов и неопределённость в том, к каким корпоративным ресурсам и данным стоит давать доступ агентам, что тормозит масштабирование. Определение AI‑агента, которое использует компания и её глава направления AI Крейг Уайли (Craig Wiley), выходит за рамки последовательных подсказок: агент способен подключаться к базам данных, исполнять код вне большой языковой модели, вызывать внешние приложения (например, почту) и объединять несколько действий в единую автоматизированную цепочку. Такое поведение увеличивает и функциональность, и риск неконтролируемых взаимодействий с корпоративными системами.

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

Вместо быстрого «переключения» на агента Databricks рекомендует три приоритета перед выводом в продакшен: настроить управляемый, жёстко лимитируемый доступ к данным и инструментам для разных ролей; заранее организовать методы оценки корректности и полезности выводов агента; и начинать с небольших, чётко ограниченных сценариев вместо попытки сразу заменить целые бизнес‑процессы. Как пример осторожного подхода компания указывает Franklin Templeton, где при рассылке клиентских отчётов недопустима любая путаница данных.

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