Как оценивать корпоративные платформы ИИ-агентов

Корпоративная платформа ИИ-агентов должна заслужить право действовать внутри вашей компании. Хорошо поставленная демонстрация доказывает, что модель способна выполнить заранее подготовленную задачу. Она почти ничего не говорит о том, сможет ли платформа сдержать скомпрометированного агента, объяснить дорогую ошибку, восстановить наполовину выполненный процесс или позволить вам уйти без переделки всех интеграций.

Я оцениваю такие платформы как операционные системы для делегированной работы, а не как чаты с дополнительными кнопками. Безопасность задает границы, оркестрация управляет работой, наблюдаемость дает доказательства, а критерии выхода ограничивают долгосрочный риск. Если кандидат не проходит обязательный порог хотя бы в одной из этих областей, высокий итоговый балл не должен его спасать.

Оценивайте путь к сбою, а не подготовленную демонстрацию

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

Опишите четыре или пять рабочих сценариев до знакомства с продуктом. У каждого сценария должны быть понятный триггер, разрешенные данные, допустимые действия, условие успеха, предельная стоимость и владелец. Добавьте одну исследовательскую задачу только для чтения, одно действие с изменением бизнес-системы и одну длительную задачу, которая должна продолжиться после прерывания. Включите враждебный или некорректный ввод и тайм-аут зависимости. Такие случаи вскрывают устройство контура управления быстрее, чем еще один час работы по идеальному сценарию.

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

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

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

Безопасность начинается с делегированных полномочий

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

Начните с идентификации. Каждому запуску агента нужна собственная идентичность рабочей нагрузки, отдельная от пользователя, который его спроектировал, и от служебной учетной записи за коннектором. Эта идентичность должна передавать арендатора, среду, версию процесса и идентификатор запуска в записи авторизации и аудита. Общие API-ключи уничтожают привязку действий к исполнителю и делают отзыв доступа слишком широким.

Затем проверьте авторизацию на уровне конкретного действия. Разрешения под названием «доступ к CRM» недостаточно. Исследовательский агент может читать ограниченный набор учетных записей, но не должен экспортировать контакты или менять ответственного. Агент поддержки может подготовить возврат средств, но не вправе проводить его свыше порога без согласования. Попросите поставщика показать отклоненное действие, а не только настроенную политику. Отказ должен появиться в трассировке вместе с версией политики и причиной.

Рекомендации OWASP для приложений на базе больших языковых моделей рассматривают инъекцию в промпт и избыточные полномочия агента как разные риски. Это различие имеет практическое значение. Фильтрация подозрительного текста не уменьшает уже выданные агенту полномочия. Ограничивайте инструменты, параметры, объем данных, сумму транзакции, длительность запуска и количество вызовов даже при чистом входе.

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

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

Оркестрация должна сделать повторные попытки скучными

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

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

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

Управление параллельностью заслуживает проверки вживую. Запустите двух агентов для одной записи и посмотрите, как платформа обнаружит чтение устаревших данных или конфликт обновлений. Ищите оптимистические блокировки, очереди или средства защиты на уровне приложения, которые подходят вашим системам. Глобальное ограничение до одного запуска избегает конфликтов ценой пропускной способности, а неограниченная параллельность перекладывает сбои согласованности на нижестоящие инструменты.

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

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

Наблюдаемость должна восстанавливать ход решения

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

Требуйте структурированные события, которые связываются по всему пути. OpenTelemetry дает командам общую модель трассировок, метрик и журналов, а его семантические соглашения подходят в качестве отправной точки. Поля для агентов пока различаются между реализациями, поэтому храните собственные стабильные бизнес-идентификаторы вместе с полями поставщика. Как минимум сохраняйте идентификаторы трассировки и запуска, версию процесса, настройку модели, название инструмента, решение политики, личность согласующего, расход токенов, задержку и результат.

Нормализованное событие инструмента может выглядеть так:

{
  "trace_id": "01J...",
  "run_id": "refund-1842",
  "workflow_version": "7",
  "event": "tool.completed",
  "tool": "billing.issue_refund",
  "policy_decision": "allow_with_approval",
  "approval_id": "apr-992",
  "duration_ms": 842,
  "input_classification": ["customer", "financial"],
  "output_ref": "vault://runs/refund-1842/tool-3",
  "status": "success"
}

Событие хранит ссылки на защищенные данные, а не разбрасывает конфиденциальное содержимое по журналам. Во время пилота проверьте редактирование данных на реалистичных персональных сведениях, секретах, вложениях и ошибках инструментов. Убедитесь, что уполномоченные расследователи могут получить оригинал по отдельной политике доступа, а обычные панели мониторинга его не показывают.

Наблюдаемости также нужны бизнес-результаты. Запуск может завершиться без технической ошибки, но дать непригодный ответ или оставить обращение нерешенным. Свяжите технические трассировки с предметным результатом: принятым черновиком, сверенным счетом, закрытой заявкой или правкой человека. Такая связь позволяет находить дорогие «успешные» состояния, которые обычные графики доступности пропускают.

Экспорт важнее встроенной панели. Отправьте исходные события в систему под контролем вашей компании, проверьте документацию схемы и воспроизведите выборку в инструментах разбора инцидентов. Если доказательства живут только в интерфейсе поставщика, и реагирование на инциденты, и план миграции зависят от его доступности.

Оценка измеряет безопасное поведение, а не красноречие

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

Собирайте примеры из реальной работы после удаления конфиденциальных данных. Для каждого случая нужны вход, допустимые доказательства, ожидаемый результат, запрещенные действия, бюджет и способ выставления оценки. Некоторые результаты допускают точную автоматическую проверку, например изменение нужной записи ровно один раз. Для анализа с открытым ответом нужна шкала критериев и периодическая проверка человеком. Оценщики на базе моделей помогают обработать объем, но их следует калибровать по решениям людей, которые понимают работу.

NIST AI Risk Management Framework разделяет управление, описание контекста, измерение и работу с риском. Для меня это напоминание, что тестовый набор еще не образует программу контроля. Высокий результат на статическом наборе не сообщает, кто принимает остаточный риск, как новые сбои попадают в тесты и когда ухудшающийся процесс следует приостановить. Назначьте ответственных за эти решения до запуска.

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

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

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

Управлению нужны владельцы и условия остановки

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

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

Задайте условия остановки до запуска. Примерами могут быть запрещенное действие, повторные отказы политики из-за неверного цикла, резкий рост исправлений человеком, пропавшие записи аудита, превышение бюджета запуска или падение тестовой оценки ниже порога выпуска. Где возможно, связывайте автоматические условия с безопасным состоянием. Приостановленный агент должен прекратить новые действия с последствиями, сохранить собранные доказательства и сообщить оператору, какие изменения во внешних системах уже произошли.

Изменения модели и промпта требуют такой же дисциплины, как выпуски приложения. Храните предлагаемую версию, результаты тестов, проверяющего, согласование, область развертывания и цель для отката. Изменения, способные повлиять на действия, сначала выпускайте для небольшой группы. Если платформа обновляет управляемую модель без управления версиями, требуйте уведомления и прогон тестов до возврата затронутого процесса на полный объем.

Управление исключениями часто ломает всю систему. Команда выдает широкий доступ ради срока, соглашается на слабый экспорт трассировок для пилота или выключает тест с ложными срабатываниями. У каждого исключения должны быть владелец, причина, компенсирующее средство контроля, дата окончания и проверка закрытия. Платформа должна показывать просроченные исключения, чтобы временный доступ не превратился в обычную настройку.

Создайте путь реагирования на поведение агента, а не только на инфраструктурные аварии. Специалист должен уметь приостановить процесс, отозвать идентичность, найти все связанные запуски, определить завершенные действия с последствиями, сохранить доказательства и уведомить бизнес-владельца. Отрепетируйте последовательность на учебном инциденте. Если вашей команде нужен запрос поставщику, прежде чем она сможет сдержать агента, запишите эту зависимость как пробел в контроле.

Для вывода из эксплуатации тоже нужен владелец. Удалите триггеры, отзовите учетные данные, закройте ожидающие согласования, архивируйте обязательные доказательства, удалите ненужные данные и обновите нижестоящие процессы, которые ждали результат агента. Неактивный процесс с действующими учетными данными все еще опасен. Итоговая запись должна подтвердить, что ни планировщик, ни вебхук, ни пользователь не запустят его снова.

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

Корпоративная пригодность включает ответственность и расходы

Готовность к работе в компании зависит от того, кто сможет эксплуатировать платформу после внедрения и сколько это будет стоить. Список функций редко дает оба ответа. До подписания договора закрепите каждую регулярную обязанность за своей командой, поставщиком или названным партнером.

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

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

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

Поддержку следует проверить во время пилота. Отправьте технический вопрос с идентификатором трассировки и неполными симптомами. Посмотрите, сможет ли поставщик изучить нужные доказательства без запроса неограниченного доступа к данным. Спросите, кто отвечает на сбой производственного контроля, какие каналы доступны и как сообщают об изменениях поведения. Условия договора не исправят процесс поддержки, который никогда не разбирал инцидент с агентом.

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

Критерии выхода входят в первую оценочную карту

Определите способ ухода с платформы ИИ-агентов до того, как решать, как на нее войти. Критерии выхода превращают расплывчатые обещания переносимости в доказательства, понятные закупкам, инженерам и финансистам.

Перечислите активы, которые нужно забрать: определения процессов, промпты, схемы инструментов, политики, тестовые случаи, историю запусков, события аудита, согласования, индексы знаний, настройки коннекторов и записи расходов. Для каждого актива укажите формат экспорта, API или пакетный способ, частоту, владельца, срок хранения и место назначения. Снимки экрана и отчеты в собственном формате поставщика не считаются переносимыми данными.

Разделяйте переносимость модели и переносимость платформы. Сменить конечную точку модели может быть легко, в то время как механизм оркестрации, семантика политик, система идентификации, история тестов и коннекторы остаются полностью закрытыми. Поставщики часто показывают первое и подразумевают второе. Во время пилота попросите команду перенести один характерный процесс в небольшой независимый стенд. Измерьте объем переписывания и поведение, которое не удалось воспроизвести.

Условия договора должны поддерживать технический план. Проверьте доступ к экспорту после уведомления о расторжении, сроки удаления, ставки за помощь, хранение журналов, документацию форматов и доступ к ключам шифрования, где это применимо. Установите, кто платит за исходящий облачный трафик и сколько займет полный экспорт при вашем ожидаемом объеме. Это эксплуатационные вопросы, а не юридическое украшение.

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

Проверьте экспорт до окончательного одобрения и повторяйте проверку по расписанию. Импортируйте данные в нейтральное хранилище, сверьте количество записей и связи, затем восстановите один прошлый инцидент без панели поставщика. Если упражнение провалилось, оцените пробел как уже существующую привязку к поставщику, а не как будущий технический долг.

Используйте взвешенную карту с обязательными порогами

Оценочная карта делает компромиссы видимыми, если команда задает уровни баллов до встреч с поставщиками. Я использую шкалу от 0 до 4: 0 означает отсутствие функции, 1 означает заявление или ручную работу, 2 означает частичную и показанную реализацию, 3 означает полноту в проверенной области, а 4 означает полноту, возможность экспорта и проверку при сбое.

Эта конфигурация достаточно мала для хранения в системе контроля версий и достаточно строга, чтобы не дать баллам расползтись:

scale:
  min: 0
  max: 4
gates:
  - workload_identity
  - action_level_authorization
  - immutable_audit_export
  - workflow_state_recovery
  - tested_exit_export
categories:
  security: 30
  orchestration: 20
  observability: 15
  evaluation_and_governance: 15
  enterprise_operations: 10
  portability_and_exit: 10
decision:
  minimum_weighted_score: 75
  minimum_category_score: 2
  gate_rule: every_gate_must_pass

Числа задают начальную политику, а не универсальную истину. Увеличьте вес безопасности или управления для агентов с регулируемыми данными или существенными полномочиями на транзакции. Оставляйте вес каждой категории явным и доведите сумму до 100, чтобы каждое позднее изменение показывало цену компромисса. Не меняйте веса после того, как увидели, какому поставщику это выгодно.

Для каждой строки оценки нужны ссылка на доказательство и владелец. Подходящим доказательством может быть запись теста, пример экспортированного события, файл политики, пункт договора, описание архитектуры или тренировка по инциденту. Ответ продавца «да» заслуживает балла 1, пока команда не увидит средство контроля в работе. Добавьте короткое обоснование проверенного ограничения, потому что голое число теряет смысл при пересмотре.

Установите минимумы для категорий вместе с общим порогом. Платформа с отличной оркестрацией и слабой наблюдаемостью все равно может набрать приличный средний балл. Минимум категории показывает этот перекос. Оставьте немного бинарных обязательных порогов: если порогом станет все, команда начнет молча их отменять.

Наконец, оцените по той же схеме текущую внутреннюю альтернативу. Отказ от покупки несет расходы и риски, а собственный тонкий слой управления поверх прямых API моделей может лучше крупной платформы справиться с узкой задачей. Сравнение не дает оценке заранее предположить, что один из поставщиков обязан победить.

Пилот должен оставить доказательства производственного уровня

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

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

Снимите базовые показатели до передачи работы агенту. Измерьте текущее время выполнения, задержку очереди, объем исправлений, долю эскалаций, расходы на инфраструктуру и количество принятых результатов по тем же правилам, которые будут действовать в пилоте. Возьмите выборку реальных задач, а не доверяйте оценке команды. Без исходной точки быстрая демонстрация может заявить об экономии времени, хотя проверка и исправления просто перейдут к людям за пределами измеряемого процесса. Сохраните выбранные случаи и пояснения к оценкам, чтобы будущие версии платформы сравнивались по тем же данным, а не по переписанной истории.

Используйте теневой режим, если рабочий процесс это допускает. Пусть агент предлагает решения и вызовы инструментов, пока действующим остается старый процесс, затем сравните оба пути по отдельным случаям. Теневой запуск выявляет ложную уверенность и недостающий контекст без изменений во внешних системах. Он не проверяет привязку согласования, идемпотентность или компенсацию, поэтому после него нужны контролируемые реальные действия. Запишите момент перехода между режимами и доказательства, на основании которых агент получил дополнительные полномочия.

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

Преднамеренно создавайте сбои. Просрочьте учетные данные, верните некорректные данные инструмента, упритесь в ограничение частоты, измените запись во время ожидания согласования, отмените запуск после одного действия с последствиями и разверните новую версию процесса во время другого запуска. Сохраните трассировки, действия операторов, время восстановления, остаточные последствия и обращения в поддержку. Не принимайте устное объяснение, если платформа не может выполнить тест.

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

Основателям, у которых нет сотрудников для проектирования этих тестов одновременно с выпуском продукта, Team & AI Audit помогает за пять дней превратить процессы, ограничения фонда оплаты труда и пробелы контроля в пакет для принятия решения. Услуга стоит $5,000 и дает заявленную гарантию: как минимум $50,000 выявленной экономии в год, иначе плата не взимается.

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