когда платформенная vs коробочная AI-архитектура в ITSM теряет управляемость

Платформенная vs коробочная AI-архитектура в ITSM: быстрый запуск против потери контроля

AI в ITSM перестал быть экспериментом. Он уже влияет на данные, решения и безопасность. Главный вопрос — не функции, архитектура: кто управляет данными, агентами и ответами.

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

Разница становится заметной при росте. Rovo Teamwork Graph уже отслеживает более 100 млрд объектов и связей из 100+ приложений. У enterprise-клиентов Atlassian около 50% MCP-операций — это записи. Это значит: системы не просто читают, они активно изменяют данные.

Скорость внедрения тоже разная. Freshservice запускается за 2–4 недели, базовые модули ServiceNow — за 8–12 недель. Но быстрый старт не равен управляемости. При масштабировании это превращается в рост затрат: TCO для 50 агентов Freshservice за 3 года — $90 000–175 000.

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

Где возникает проблема при быстром запуске

Обычно внедрение AI в ITSM начинают с коробочного решения. Логика простая: подключить агента и быстро снизить нагрузку. Freshservice можно запустить за 2–4 недели, ServiceNow — за 8–12.

На практике это выглядит иначе. Например, агент поддержки получает запрос собрать логи пользователя. Он отправляет данные во внешнюю модель, а журналы действий сохраняются в разных системах. В итоге никто не видит полной картины.

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

По мере роста это усиливается. Связей и записей становится больше, как в Rovo Teamwork Graph с его 100+ млрд объектов. Когда половина операций — это записи, система начинает менять данные быстрее, чем вы можете их контролировать.

В итоге быстрый старт превращается в накопление долга: растёт число точек утечки, усложняется аудит и увеличиваются затраты. Короткая выгода сегодня создаёт долгосрочный риск завтра.

Как архитектура влияет на контроль

Как это работает

Платформенная AI-архитектура строится вокруг контроля. Все данные проходят через единый слой управления: policy engine, audit logs и правила доступа.

Доступ регулируется через RBAC и ABAC. Это значит, что агент видит только те данные, которые ему разрешены. Все действия фиксируются в журналах, а источники для RAG-пайплайна заранее проверены.

Важно и размещение данных. Платформа позволяет держать их внутри периметра (data residency), а не отправлять во внешние сервисы. В результате любой ответ можно проследить до источника.

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

Почему это происходит

Первое — рост использования внешних моделей. Объём корпоративных данных, отправляемых в неконтролируемые AI-инструменты, вырос на 485% за год. Это увеличивает риск утечек.

Второе — быстрый рост агентов. В BMC Helix новые роли выходят каждые 2–3 недели, а HelixGPT Agent Builder появился в мае 2025 года. Количество точек принятия решений растёт быстрее, чем управление ими.

Третье — усложнение связей. Когда система содержит десятки миллиардов объектов и половина операций — записи, как у Atlassian, аудит становится сложной задачей. Найти источник ошибки или удалить данные становится дороже.

К чему это приводит

Риск становится системным. Gartner прогнозирует: к 2030 году 40% компаний столкнутся с инцидентами из-за неуправляемого AI.

При этом архитектура напрямую влияет на восстановление. Компании с предиктивными ITSM-практиками восстанавливаются вдвое быстрее (Forrester). Это результат контроля, а не набора функций.

Финансы подтверждают ту же логику. Быстрый запуск даёт эффект сразу, но при росте TCO увеличивается. Для 50 агентов Freshservice — $90k–175k за 3 года.

Что из этого следует

Архитектура определяет три вещи: контроль данных, поведение агентов и управляемость RAG. Если эти элементы централизованы, система масштабируется.

Если нет — растёт фрагментация, стоимость и риск. Поэтому скорость запуска — вторична. Ключевой критерий — контроль.

Типовые сбои при коробочном подходе

Агент выгружает чувствительные логи

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

Итог: риск утечки и невозможность быстро провести аудит.

Что делать: ограничить доступ через роли, зафиксировать все действия в едином журнале и контролировать внешние запросы.

Агенты дают противоречивые решения

DevOps использует один автоматический плейбук, HR — другой агент. При изменении конфигурации они предлагают разные действия.

Итог: задержки, ошибки и откаты в продакшене.

Что делать: использовать единый источник знаний и централизованную оркестрацию агентов.

Быстрый запуск превращается в долг

Агенты внедрены по разным подразделениям. Через полгода резко растёт число записей интеграций.

Итог: сложный аудит, рост затрат и проблемы при инцидентах.

Что делать: ограничивать масштаб через централизованную архитектуру и контролировать точки записи.

Почему платформа даёт устойчивость

Платформа решает не задачу запуска, а задачу управления. Она объединяет данные, агентов и процессы в одном контуре.

Это даёт конкретные эффекты:

• Управляемость: все действия агентов видны и контролируются

• Аудит: можно отследить источник ответа и цепочку решений

• Контроль доступа: данные доступны только по правилам

• Быстрое восстановление: меньше времени на поиск причины инцидента

В коробочной модели этого нет. Данные и логика распределены, поэтому любая ошибка требует больше времени и ресурсов.

При росте разница усиливается. Фрагментация увеличивает объём записей, усложняет аудит и повышает стоимость управления.

Поэтому платформа — это не про «больше возможностей». Это про снижение риска при масштабировании.

Выбор архитектуры сводится к трём критериям: где находятся данные, кто управляет агентами и как контролируются решения.

Если эти элементы распределены, система быстро теряет управляемость. Если они централизованы, появляется контроль и предсказуемость.

Платформенная AI-архитектура в ITSM решает именно эту задачу. Она объединяет политики данных, управление агентами и RAG в одном слое. Это снижает риск и делает масштабирование управляемым.

На практике такой подход реализуют системы вроде АСПЕКТ: обработка документов, анализ и генерация происходят внутри инфраструктуры клиента. Данные не покидают периметр, а все ответы опираются на проверенные источники.

Итог простой: выбор идёт не между функциями. Он идёт между контролем и фрагментацией. Архитектура определяет, сможете ли вы масштабировать AI без потери управляемости.

Частые вопросы по архитектуре AI в ITSM