DXC пустила ИИ-агентов в IT банков и больниц: время решения инцидентов упало на 95%

Когда агент может зайти на продакшен-сервер банка, вопрос «какую модель взять» отходит на второй план. Публичные инциденты, в которых автономные агенты совершали разрушительные действия, о которых никто не просил, показывают: дело редко в самой модели. Проблема в агенте, у которого прав больше, чем нужно для задачи, и в архитектуре, которая его не останавливает. Подрядчик DXC Technology (115 000 сотрудников в 70 странах, клиенты — банки, больницы, госструктуры) рассказал в блоге AWS, как строил такой ограничитель для своей платформы DXC OASIS.

Два слоя: подложка и обвязка

Идея простая: вопрос «какая модель» отделён от вопроса «как делается работа». Нижний слой DXC называет подложкой (substrate). Это Amazon Bedrock: единый API к Claude, Amazon Nova, Meta Llama и open-weight семействам. Поверх него стоят Bedrock Guardrails с фильтрацией контента, вычисткой персональных данных и запрещёнными темами, одинаковыми для всех моделей. Трафик инференса идёт через PrivateLink внутри VPC клиента, а серверless-модель избавляет от собственного парка GPU как точки отказа.

Верхний слой — «обвязка» (harness) самой DXC. Оркестрация построена на open-source LangGraph: супервайзер-агент делит задачу и раздаёт её узким агентам. В обвязке же лежит операционный контекст из 60 лет ранбуков и данных ITSM, проверка политик на каждый запрос и журнал действий.

Важная деталь — где проходит граница. Guardrails фильтруют вход и выход модели, но не могут ограничить, что агент вправе сделать с сервером. Это умеет только обвязка, потому что зависит от контекста и ответственности конкретного заказчика.

Как это выглядит на одном инциденте

В демо-среде вымышленной авиакомпании на сервере FlightOps заканчивается место, а ранбук не помогает. CIO видит алерт как бизнес-риск, а Linux-инженер получает те же данные с техническими деталями. Супервайзер строит план и подключает агентов Metrics, Linux System и ITSM. Первый подтверждает, что диск заполнен на 99%, и ссылается на статьи базы знаний, второй находит один временный файл на 5 ГБ.

Дальше ключевой момент: агент показывает полный план, и ничего не выполняется, пока инженер не подтвердит. Диагностировать он может свободно, менять прод — только с записанным одобрением. Журнал (что запущено, где, кто утвердил, когда) формирует обвязка, а не пересказ самого агента.

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

Цифры и что с ними делать

С выхода в GA в марте 2026 года OASIS обслуживает 12 операционных персон (Linux, Windows, SAP, сети, бэкапы, AWS, Azure и другие). По заявлению DXC, среднее время решения упало на 95% на 56 измеренных сценариях. Инцидент с файловой системой раньше занимал 53–90 минут, теперь 3–6. Проблемы базы данных: с 2–3 часов до 5–12 минут. Сложный problem management: с 2–6 дней до 8–10 минут. Точность диагностики — 92% и выше относительно оценки старших инженеров.

К этим числам стоит относиться осторожно. Это совместный пост AWS и вендора, независимой проверки нет, методика замеров «до/после» не раскрыта, а 92% точности означает, что в каждом двенадцатом случае диагноз может быть неверным. Поэтому человеческое одобрение здесь не формальность.

Практический вывод для тех, кто строит агентов под прод:

• Держите выбор модели, оркестрацию и среду развёртывания как независимые решения. Тогда сбой провайдера или депрекейшн — это правка маршрутизации. Но равный API не значит равное поведение: перед выпуском новой модели в роутинг гоняйте её через собственные наборы задач.
• Не доверяйте модели ограничивать саму себя. Права, ступени автономии и аудит должны жить вне модели, в коде и политиках.
• Начинайте с read-only и расширяйте автономию по задачам, а не по умолчанию.
• Учтите привязку: вся схема опирается на Bedrock, а набор доступных моделей зависит от региона AWS.

Главный урок не про конкретный облачный сервис. Безопасность агента определяется тем, что ему разрешено делать, а не тем, насколько умна модель. Пока эта граница не прочерчена явно, масштабировать агентов на боевые системы рано.