Поскольку ИИ берет на себя все большую операционную роль, руководители предприятий должны ответить на фундаментальный вопрос: кто несет ответственность за результат?
В этой статье
- В агентском предприятии надежность заключается не только в восстановлении систем. Она заключается в сохранении контроля над бизнес-результатами, даже когда ИИ действует самостоятельно
- «Здоровые» системы все еще могут подвести бизнес. ИИ-агент может действовать в рамках своих полномочий и все равно остановить легитимные процессы, поэтому измеряйте результаты работы сервисов, а не только работоспособность компонентов
- Каждый критически важный сервис нуждается в четком владельце и строгих ограничениях относительно того, что агенты могут менять самостоятельно, что требует одобрения и кто может вмешаться
Рассмотрим банк, где ИИ-агент изменяет правило борьбы с мошенничеством, и легитимные платежи перестают проходить. Приложения и инфраструктура остаются доступными, но клиенты не могут завершить транзакцию. Системы кажутся работоспособными, однако бизнес-сервис дал сбой.
Агенту не обязательно быть скомпрометированным, чтобы вызвать такой сбой. Он может действовать в пределах своих разрешений и все равно привести к непредвиденному результату. По мере того как предприятия наделяют ИИ-агентов большей автономностью в работе с приложениями и данными, планирование таких сбоев становится столь же важным, как и подготовка к авариям и атакам.
Это меняет само понятие надежности. В агентском предприятии надежность — это не просто способность восстанавливать системы. Это способность сохранять контроль над бизнес-результатами, даже когда ИИ действует автономно.
В агентском предприятии надежность — это не просто способность восстанавливать системы. Это способность сохранять контроль над бизнес-результатами, даже когда ИИ действует автономно.
Сделайте бизнес-сервис единицей измерения надежности
Результаты работы многих организаций зависят от того, что инфраструктура и данные обеспечивают совместно: обработанный платеж, выполненный заказ или возможность сотрудника использовать важнейшее приложение. Планирование надежности должно начинаться с этого комплексного сервиса.
Руководители должны определить сервисы, потеря которых недопустима для бизнеса, и выстроить цепочку в обратном направлении через их зависимости. После этого бизнес- и технологические команды смогут прийти к согласию относительно того, что должно работать бесперебойно, где локальный сбой может привести к более масштабным последствиям и что нужно защищать и восстанавливать в первую очередь.
Назначайте ответственность до возникновения сбоя
Сервис может охватывать несколько команд, каждая из которых отвечает за отдельный компонент. Это не устанавливает ответственность за общий результат. Каждый критически важный сервис нуждается в собственнике, который понимает его влияние на бизнес и может координировать действия при сбое.
Такое владение должно включать четкие границы для действий ИИ: какие изменения агент может вносить автономно, какие требуют одобрения и кто может приостановить рабочий процесс или санкционировать корректирующие действия. Эти решения должны приниматься до инцидента, когда у команд есть время взвесить все последствия.
Приостановка автоматизированного процесса может локализовать сбой, одновременно прерывая легитимную работу. Цель состоит не в том, чтобы требовать одобрения для каждого действия, а в том, чтобы четко определить, где требуется человеческое суждение, а также предоставить необходимый контекст и полномочия для действий.
Измеряйте результаты работы сервисов, а не только работоспособность систем
Работоспособность компонентов не тождественна работоспособности сервиса. Руководителям нужны метрики, которые отвечают на три вопроса.
Что должно продолжать работать? Определите основной результат и уровень сбоев, допустимый для бизнеса. Например, для платежного сервиса это означает определение того, какие транзакции должны проходить в обязательном порядке и что означают задержки для клиентов и операций.
Как мы распознаем сбой? Оценивайте результаты работы сервиса наряду с работоспособностью компонентов. Неожиданный паттерн блокировки легитимных платежей требует расследования, даже если приложения сообщают о нормальной доступности.
Что считается восстановлением? Перезапущенное приложение или восстановленная база данных недостаточны, если сервис по-прежнему не работает. Восстановление должно учитывать зависимости, возвращать затронутые компоненты в правильном порядке и подтверждать, что сервис приносит запланированный результат.
Восстановление инфраструктуры и данных не обязательно отменяет действия, которые агент уже совершил. Командам также может потребоваться сверить затронутые транзакции, исправить последующие изменения и убедиться, что причина устранена.
Предприятиям необходима видимость того, как агенты, данные и приложения связаны между собой через эти границы, чтобы они могли отслеживать влияние действия, локализовывать его и восстанавливать затронутый сервис. Новые возможности ИИ, разрешения и рабочие процессы должны вызывать необходимость проверки этих связей.
Проектируйте с учетом контроля в гибридных средах
Агенты, данные, приложения и инфраструктура все чаще пересекают границы сред и организаций: частные облака, публичные облака, периферийные вычисления, традиционная инфраструктура, а также партнеры и провайдеры, на которых полагается бизнес. Одно действие агента может затронуть системы, принадлежащие разным командам, управляемые разными политиками и контролируемые с помощью разных инструментов. На многих предприятиях ни у одного человека нет целостного представления о последствиях.
Это архитектурная, а не только операционная задача. Предприятиям необходима видимость того, как агенты, данные и приложения связаны между собой через эти границы, чтобы они могли отслеживать влияние действия, локализовывать его и восстанавливать затронутый сервис. Новые возможности ИИ, разрешения и рабочие процессы должны вызывать необходимость проверки этих связей. Ответственность за надежность должна распространяться так же далеко, как и зависимости.
В HPE мы помогаем клиентам создавать гибридную основу, необходимую для этого: единообразную видимость и управление в различных средах, а также возможности для защиты и восстановления приложений и данных, от которых зависят критически важные сервисы. Эта основа поддерживает — но не заменяет — владение сервисами, управление и операционные процессы клиента.
Проверка перед переходом к большей автономности
Прежде чем предоставить агентам большую автономность, каждая команда руководителей должна задать себе более сложный вопрос: спроектировали ли мы систему так, чтобы иметь возможность понимать действия агентов, прерывать их и восстанавливаться после них?
Если ответ «нет», предприятие расширяет автономность быстрее, чем способно справляться с последствиями. По мере расширения возможностей ИИ мерой надежности становится уже не только то, как быстро восстанавливаются системы, а то, сохраняет ли бизнес контроль над своими результатами.
