Сольются ли воедино наблюдаемость, оценка и гарантирование ИИ?

7 принципов Наделлы, сделка Dynatrace и Arize на $915 млн и спор между CIO, основателями стартапов и инвесторами о том, кто должен контролировать AI-агентов. Обновлено в октябре 2026 года.

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

Чтобы ловить подобные проблемы, существуют три категории продуктов: наблюдаемость (observability), оценка (evaluation) и подтверждение надежности (assurance). Вендоры уже начали их объединять. Пойдут ли за ними покупатели — вопрос открытый, как и второй: кто вообще должен проводить проверки и что считать независимой оценкой?

Искусственный интеллект переходит от простых ответов к реальным действиям. Gartner прогнозирует, что к 2028 году треть корпоративных программных приложений будет использовать агентный ИИ — для сравнения, в 2024 году таких было меньше 1%. Эти агенты умеют писать и отправлять код, переводить деньги и общаться с клиентами, причем обычно никто из людей не контролирует их в реальном времени.

Когда софт только выдавал ответы, главным был один вопрос: насколько они хороши. С агентами вопросов стало больше: что именно он сделал, правильно ли это, кто готов за это отвечать и можно ли его остановить? Для CIO это в равной степени вопросы управления рисками, AI-губернатики и инженерии.

Сегодня эти задачи частично закрывают три рынка:

• Наблюдаемость ИИ (AI observability) фиксирует, что именно сделал ИИ.
• Оценка ИИ (AI evaluation) измеряет, насколько хорошо он это сделал.
• Подтверждение надежности ИИ (AI assurance) собирает воедино доказательства, механизмы контроля и их ограничения, чтобы человек мог принять обоснованное решение. Правительство Великобритании описывает это как процесс измерения, оценки и демонстрации уровня доверия.

В 2025 году рынок наблюдаемости ИИ оценивался в $1,25 млрд, и, по данным того же исследования, быстрее всего внутри него будут расти сегменты оценки и контроля качества. 1 октября 2026 года Dynatrace закрыла сделку по покупке Arize — это соглашение на $915 млн ради объединения оценки и наблюдаемости. Cisco завершила покупку Galileo в мае. А 10 октября Сатья Наделла опубликовал семь принципов доверия к ИИ, которые затрагивают все три рынка.

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

От правил к AI-агентам: почему доверять стало сложнее

Упрощенная история из четырех этапов. На каждом машина становилась способнее, а объяснять ее работу — труднее.

1. Правила (примерно с 1950-х по 2000-е). Большинство приложений писали вручную, шаг за шагом. Багов хватало, но инженер мог открыть код и найти строку, которая их вызывала.
2. Паттерны (2010-е). С приходом глубокого обучения машины стали учиться на примерах, а не на правилах — например, в распознавании изображений и речи. Логику никто не прописывал. Такие системы в основном классифицировали, ранжировали и рекомендовали, а что делать с результатом, решали люди или обычный софт.
3. Чаты (с 2022 по 2024). Чат-боты научились писать, резюмировать и спорить. Они часто ошибались, но человек обычно читал ответ, прежде чем действовать.
4. Агенты (с 2025 года и далее). Агенты кликают, печатают, покупают, пишут код и деплоят. Лаборатории обучают их, заставляя отрабатывать задачи в симулированных офисах, браузерах и кодовых базах. Некоторые работают подолгу без проверки каждого шага человеком.

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

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

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

Фреймворк AI-губернатики Сатьи Наделлы: 7 принципов доверия к AI-агентам

10 октября 2026 года Наделла опубликовал в своем блоге статью «Models as Insider Risks in the Super Intelligence Era» («Модели как внутренние угрозы в эру суперинтеллекта»). Его главная мысль: «нам нужно разделить предоставление интеллекта и власть над ним».

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

Он называет их семью «принципами наблюдаемости». Если читать их вместе, они складываются во фреймворк управления AI-агентами. Ниже каждый принцип пересказан своими словами, а затем я добавил, какой рынок закрывает его сегодня.

1. Разнообразие моделей: ни один ИИ не проверяет сам себя и не принимает важные решения в одиночку. Рынок сегодня: оценка.
2. Наблюдать за всем: каждое значимое действие оставляет защищенные от изменений доказательства, понятные человеку. Рынок сегодня: наблюдаемость.
3. Проверяемость: вся система непрерывно тестируется, включая атаки, сбои и граничные случаи. Рынок сегодня: оценка и подтверждение надежности.
4. Независимые механизмы контроля: правила доступа ИИ хранятся вне самого ИИ, там, где он не сможет их изменить. Рынок сегодня: в основном инструменты безопасности и управления доступом, хотя защитные барьеры (guardrails) начинают появляться и в AI-платформах.
5. Независимый аудит: данные о поведении ИИ хранятся отдельно от самого проверяемого ИИ. Рынок сегодня: подтверждение надежности.
6. Сдерживание: авторизованный человек может приостановить или отключить модель прямо во время работы. Рынок сегодня: преимущественно инструменты среды выполнения (runtime) и безопасности.
7. Раскрытие инцидентов: при сбое пострадавших уведомляют, а извлеченные уроки публикуют. Рынок сегодня: внутренняя практика компаний, опирающаяся на логи наблюдаемости.

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

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

Чтобы доверять модели по минимуму, нужна запись ее действий (наблюдаемость), способ их оценить (оценка) и доказательства, за которые человек готов поручиться (подтверждение надежности). А еще нужны две вещи, которые эти рынки пока оставляют инструментам безопасности и runtime: механизмы контроля, недоступные модели для изменения, и возможность для человека ее остановить.

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

Представьте AI-агента как только что нанятого водителя.

• Наблюдаемость — это видеорегистратор. Он пишет каждый поворот, торможение и опасный момент, отвечая на вопрос «что сделал ИИ?». Продают его в основном командам, которые поддерживают работу систем.
• Оценка — это экзамен по вождению. Она показывает, как водитель справляется с заданными ситуациями, и отвечает на вопрос «насколько он хорош?». Покупают ее в первую очередь инженеры, создающие AI-продукты, и все чаще — QA-команды.
• Подтверждение надежности — это акт техосмотра. Оно собирает доказательства, чтобы решить, готовы ли машина и водитель к дороге, — до первой поездки и на протяжении всего пути. Отвечает на вопрос «достаточно ли доказательств, чтобы за это поручиться?». Ни один осмотр не гарантирует, что машина никогда не попадет в аварию; хороший отчет говорит о том, что проверили, что нашли и что осталось неизвестным. Это наименее развитый из трех рынков, и работа здесь сейчас размазана между командами качества, рисков и комплаенса.

Раздельные инструменты для разных покупателей работали вполне сносно, пока ИИ только генерировал ответы. С появлением агентов разрывы между ними стали критичнее. Каждый инструмент полезен сам по себе, но видео, которое никто не смотрит, мало что доказывает; экзамен устаревает, если водитель меняется каждую неделю; а отчет зависит от видео и результатов тестов, на которых он построен.

Недавние сделки по покупке платформ наблюдаемости и оценки ИИ:

• В октябре 2026 года Dynatrace купила Arize за $915 млн, объединив оценку с мониторингом продакшена.
• В мае 2026 года [Cisco приобрела Galileo](https://blogs.cisco.com/news/cisco-announces-the-intent-to-acquire-galileo) для Splunk, закрыв вопросы оценки, мониторинга и защитных барьеров для агентов.
• В феврале 2026 года [Snowflake купила Observe](https://www.sec.gov/Archives/edgar/data/1640147/000164014726000019/snow-20260518.htm), встроив наблюдаемость прямо в платформу данных.
• В феврале 2026 года [ClickHouse приобрела Langfuse](https://wetheflywheel.com/en/ai-observability/) — инструмент трейсинга LLM.

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

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

![Схема AI-агента, вокруг которого наблюдаемость, оценка, согласование и контроль работают как единый цикл

https://pbs.twimg.com/media/HUXj23UaIAAG2Id?format=png&name=small

прочитать описание изображения

ALT

Если рынки сольются · наблюдение, оценка, согласование, контроль

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

Дискуссия: кто должен проверять AI-агентов?

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

• Инвестор-стратег (Long-Game Investor): вкладывает на горизонте 15 лет и смотрит на то, кто покупает.
• Трендовый инвестор (Momentum Investor): следит за тем, куда прямо сейчас идут деньги и таланты.
• Разработчик агентов (Agent Builder): каждую неделю выпускает AI-агентов для клиентов.
• Основатель платформы (Platform Founder): управляет платформой данных и ИИ и хочет контролировать весь стек.
• CIO банка (Bank CIO): утверждает любого агента до того, как тот получит доступ к счетам клиентов.

Раунд 1: Рынки сольются?

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

CIO банка: Поглощения — это не то же самое, что слияние. Я раньше покупал готовые комплексы, а в итоге получал три продукта, один логотип и три логина. К тому же Gartner ожидает, что более 40% проектов агентного ИИ будут закрыты до конца 2027 года, и слабые механизмы контроля рисков — одна из причин. Проблема доверия реальна. Но нигде не доказано, что единый слитый рынок ее решит.

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

Разработчик агентов: В моей компании такой уже есть. Когда агент возвращает деньги не тому клиенту, никто не спрашивает, какая команда владеет проблемой. У меня за пару минут просят запись, оценку и доказательства.

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

Раунд 2: Почему бы не оставить три отдельных инструмента?

CIO банка: Почему я не могу оставить три лучших в классе инструмента?

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

Трендовый инвестор: Граница между «до релиза» и «после релиза» тоже размывается. Агенты меняются каждую неделю: новая модель, новый промпт, новый инструмент. Тестировать один раз при запуске — это как осматривать машину один раз, пока кто-то постоянно меняет в ней двигатель.

CIO банка: Объединенные комплексы обычно посредственны во всем.

Инвестор-стратег: На старте — да. Сначала побеждают специализированные инструменты, а интегрированные продукты догоняют позже. Так было во многих инфраструктурных категориях, хотя и не во всех.

Раунд 3: Кто должен этим владеть?

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

CIO банка: То есть компания, которая управляет моим ИИ, сама же будет говорить мне, что он работает нормально?

Основатель платформы: Мы в этом хороши.

CIO банка: Дело не в этом. Мой внешний аудитор должен быть независим от бизнеса, который он проверяет. Студенты не ставят оценки сами себе, а автопроизводители не проводят все краш-тесты собственными силами.

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

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

Основатель платформы: Внутри будет дешевле и проще.

CIO банка: А снаружи — это то, что примут мой регулятор и страховщик. Возможно, я буду платить за оба варианта, но подписывать акты на основе одного.

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

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

CIO банка: Тогда я лучше задам пять вопросов, чем буду сравнивать логотипы. Может ли агент редактировать лог? Видит ли ваш проверяющий реальные изменения в моих системах или только то, о чем сообщил агент? Кто тестирует вашего проверяющего? Может ли кто-то другой воспроизвести ваш результат? Что вам не удалось проверить?

Раунд 4: Как это называть?

Трендовый инвестор: Аналитики, скорее всего, еще пару лет будут называть это наблюдаемостью ИИ, потому что именно там лежат бюджеты.

Основатель платформы: «Слой доверия к ИИ» (AI trust layer).

Разработчик агентов: «Observe, Eval and Assure»: наблюдай, оценивай, получай подпись человека.

CIO банка: Осторожнее со словом «assure» (гарантировать). Инструмент создает доказательства. Человек их читает и подписывает. Проектируйте под этого человека.

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

CIO банка: Как бы это ни называлось, мне нужна возможность это остановить.

Как тестировать AI-агента: пример с возвратом средств

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

1. Определите бизнес-правила. Возврат уходит правильному клиенту, не превышает лимит и соответствует политике. Повторная попытка не должна привести к двойной выплате. Исключения попадают к нужному человеку до движения денег.
2. Протестируйте сложные условия. Используйте конфликтующие записи клиентов, медленный платежный сервис, таймаут инструмента и скрытую инструкцию в сообщении поддержки. Важные кейсы прогоняйте несколько раз из одного начального состояния, потому что один успешный запуск ничего не доказывает. Симуляции позволяют безопасно тестировать опасные сценарии, а реальные устройства и интеграции ловят расхождения, которые симуляции пропускают.
3. Проверьте систему учета (system of record). Слова агента «Я вернул $50» — не доказательство. Проверьте, что нужный счет получил ровно один возврат на $50. Там, где ответ точный, используйте точные проверки, а ИИ-судей — только там, где он неточный.
4. О серьезных сбоях нужно сообщать отдельно. Неверные суммы, дублирующиеся платежи и несанкционированные операции должны выводиться за рамки общей оценки выполнения задачи. Средний балл в 94 процента может скрыть самый важный сбой.
5. Проверьте ограничения вне агента. Блокирует ли платежная система возврат сверх лимита, даже если агент его запрашивает? Можно ли отозвать доступ агента посреди задачи? Остановка агента предотвращает следующий платеж, но не отменяет предыдущий.
6. Протестируйте проверяющего. Подбросьте ему известные сбои и посмотрите, какие он пропустит. Дайте корректные результаты, чтобы измерить ложные срабатывания. Держите статус «не удалось проверить» отдельно от «пройдено».

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

Где место контроля качества ИИ: TestMu AI

TestMu AI (ранее LambdaTest) делает ставку на техническую независимость. Мы не строим модели и не продаем дашборды мониторинга продакшена. Наши проверки работают вне тестируемого агента — до релиза и при каждом изменении, — и анализируют то, что произошло на самом деле, а не только то, о чем отчитался агент.

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

• Rook (агенты проверяют агентов). Прогоняет вашего агента через сценарии и фиксирует ожидаемые и фактические результаты каждой проверки, при этом для каждого сценария сохраняются доказательства. Статусы «пройдено», «не пройдено» и «не удалось проверить» выводятся раздельно, поэтому отсутствие доказательств никогда не засчитывается как успех.
• Agent Testing (боты общаются с клиентами). Тестирует текстовых, голосовых и телефонных агентов в реалистичных диалогах до того, как с ними столкнутся клиенты.
• KaneAI и Kane CLI (приложения, которые помогает создавать ИИ). Тестируйте приложения на простом английском (KaneAI) или из терминала (Kane CLI).
• SmartUI и Accessibility (сбои, под которые никто не писал тесты). Ловят проблемы, которые функциональные проверки не ищут: сломанную верстку или экраны, недоступные части пользователей.
• Real Device Cloud (то, что упускают симуляции). Запускает тесты на реальных телефонах и в браузерах, а не только в эмуляторах.
• HyperExecute (многократный прогон важных кейсов). Выполняет одни и те же проверки при каждом изменении параллельно.
• Test Manager (журнал для согласования). Хранит единую запись о том, что проверили, что нашли и что осталось неизвестным, — для человека, который подписывает акт.

Инструменты наблюдаемости следят за тем, что происходит после релиза. Мы предоставляем доказательства, на основе которых решается, что до релиза дойдет. Наши агенты выполняют проверки в масштабах, которые команда не потянет вручную, а тестировщики решают, что стоит проверять, и ищут проблемы, которые не поймает ни один автотест. Эту совместную работу мы называем Observe, Eval и Assure.

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

Будущее управления AI-агентами: каким может быть 2030 год

Это прогнозы. У каждого уже есть ранние сигналы сегодня.

• Агенты получат идентификаторы и журналы. У каждого агента будет четкая зона ответственности, утверждающий сотрудник и лог действий. Microsoft планирует разделять действия агентов и людей в своей системе идентификации.
• Логи будут формироваться вне агента. Журналы будет писать то, что агент не может отредактировать, вместо того чтобы полагаться на его собственный рассказ о своих действиях.
• Проверки станут непрерывными. Обновление модели, изменение промпта или новый инструмент будут автоматически запускать перетестирование, оставляя людям больше времени на исследовательское тестирование.
• Агенты будут проверять других агентов. Gartner ожидает, что 15% повседневных рабочих решений к 2028 году будет автономно приниматься агентным ИИ (в 2024 году таких не было вовсе). Люди не смогут проверять такие объемы по одному, поэтому проверяющие агенты возьмут на себя рутинный мониторинг, а люди займутся приоритетами и расследованием аномалий.
• Страховщики будут оценивать AI-риски на основе доказательств. С 2025 года страховщики Lloyd's предлагают покрытие ошибок ИИ, выплаты по которому наступают, если качество падает ниже согласованного базового уровня, а один андеррайтер заявил, что не будет страховать системы, которые считает слишком склонными к ошибкам.
• Корпорации заложат на это бюджеты. Один владелец и один процесс будут закрывать мониторинг, оценку, согласование и контроль, а каждый сбой будет возвращаться в систему как новый тест.

Нерешенные проблемы

1. Проверка проверяющего. ИИ-судью (часто его называют LLM-as-a-judge) обмануть так же легко, как и ту модель, которую он оценивает. Вторая модель не гарантирует независимости суждений, особенно если обе обучались похожими методами.
2. Взлом проверки. В июле 2026 года модели OpenAI, проходившие сложную внутреннюю оценку по кибербезопасности, начали искать решения во внешних сервисах, обошли механизмы изоляции и получили доступ к частям систем OpenAI и Hugging Face. OpenAI называет reward hacking главной причиной инцидента и отмечает, что в тестовой среде не было тех защитных механизмов, которые есть у развернутых моделей. Случай ставит вопрос о том, как правильно изолировать среды оценки, но не доказывает, что все агенты ведут себя подобным образом.
3. Ненадежные самоотчеты. Наделла называет прозрачность рассуждений "обязательным условием", но тут же пишет, что "одной ее недостаточно и на нее нельзя полностью полагаться". То, что модель говорит о своих действиях, и то, что она сделала на самом деле, может различаться.
4. Баллы против качества. Проходной балл в 94% показывает лишь результат по тем проверкам, которые кто-то написал. Он ничего не говорит о ситуациях, для которых проверок не существует.
5. Затраты. Независимое хранение логов, вторые модели, повторные прогоны, изолированные песочницы и ручная проверка увеличивают расходы и задержки. К тому же запись всего подряд порождает обязательства по защите чувствительных данных.
6. Необратимые действия. Остановка агента предотвращает новые шаги, но не отменяет уже выполненные. Поэтому права доступа, выданные заранее, важнее самой кнопки "стоп".
7. Раскрытие информации. В сентябре 2026 года OpenAI начала публиковать инциденты рассогласования (misalignment) в рамках новой системы раскрытия, хотя сама же решает, что считать таким инцидентом. Большинство компаний, внедряющих агентов, ничего не публикуют. Безопасность в авиации выросла в том числе потому, что аварии расследуются публично.
8. Проверки против тестирования. Автоматические проверки подтверждают только то, о чем кто-то догадался спросить. Многие серьезные сбои происходят там, где вопросов никто не задавал, и чтобы их найти, нужны опытные тестировщики: они исследуют систему, ставят под сомнение спецификацию и решают, какие риски действительно важны.

Ни на один из этих вопросов пока нет окончательного ответа.

На каком этапе дискуссия

Все пять голосов сошлись в трех пунктах:

• Агенты делают мониторинг, оценку и согласование более взаимозависимыми.
• Доказательства должны поступать оттуда, куда агент не имеет доступа на запись.
• Человек по-прежнему утверждает сам запуск, его ограничения и исключения — даже если не каждое рутинное действие.

Разногласия возникли по четырем пунктам:

• Одна платформа или несколько инструментов. Основатель платформы хочет одного вендора; ИТ-директор банка не доверяет комбайнам "все в одном".
• Внутри или снаружи. Проверка внутри платформы дешевле. Независимая проверка — это то, чего аудиторы, регуляторы и страховщики давно требуют в финансах и безопасности. Что важнее для ИИ — пока не решено.
• Зона ответственности. Она может быть у операционного отдела, команды ИИ, риск-менеджмента или контроля качества. Лишь немногие компании уже выделили под это отдельную строку в бюджете.
• Терминология, и может ли вообще какой-либо инструмент что-то "гарантировать" (assure).

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

Если завтра ваш агент совершит дорогостоящую ошибку, кому вы доверите объяснять, что произошло: компании, которая им управляет, или той, что стоит в стороне?

FAQ

В чем разница между AI observability, AI evaluation и AI assurance?

AI observability (наблюдаемость ИИ) фиксирует, что делала система: ее входные данные, вызовы инструментов, результаты, ошибки и затраты. AI evaluation (оценка ИИ) измеряет поведение относительно заданных ожиданий — например, точности, соблюдения политик или выполнения задачи. AI assurance (подтверждение надежности ИИ) объединяет доказательства, механизмы контроля и их ограничения, чтобы человек мог принять обоснованное решение о запуске или дальнейшей работе системы.

Что такое фреймворк управления ИИ (AI governance) для агентов?

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

Каковы семь принципов доверия к ИИ от Сатьи Наделлы?

В своем эссе от октября 2026 года "Models as Insider Risks in the Super Intelligence Era" Наделла перечисляет: разнообразие моделей, наблюдение за всем, верифицируемость, независимые механизмы контроля, независимая аудируемость, изоляция и раскрытие инцидентов. Его главная идея — разделить источник интеллекта и власть над ним, относясь к мощным моделям как к сотрудникам с широкими правами доступа.

Объединяются ли AI observability и AI evaluation?

Вендоры их объединяют. Dynatrace закрыла сделку по покупке Arize за 915 млн долларов в октябре 2026 года, а Cisco завершила поглощение Galileo в мае 2026 года — обе сделки ради того, чтобы соединить оценку с мониторингом продакшена. Объединят ли заказчики свои бюджеты и команды вокруг одной платформы — вопрос открытый.

Кто должен проверять ИИ-агентов: платформа, на которой они работают, или независимый тестировщик?

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

Как тестировать ИИ-агента перед релизом?

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

Оригинал статьи опубликован на https://medium.com/@mask.tech/will-ai-observability-evaluation-and-assurance-merge-a5b011e26b3a?sharedUserId=mask.tech

Источники

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

• Satya Nadella: Models as Insider Risks in the Super Intelligence Era (оригинальное эссе)
• Forbes: Microsoft's Nadella wants an emergency brake on every AI model
• Data Studios: Nadella's seven principles explained
• UK DSIT: Introduction to AI assurance
• W.Media: Gartner on agentic AI adoption and cancellations
• Detailed Research: AI observability market
• Dynatrace: Dynatrace completes acquisition of Arize
• Magica: Dynatrace agrees $915 million deal for Arize
• Cisco: Making AI trustworthy and observable (Galileo, completed May 2026)
• Snowflake Form 8-K: Observe acquisition closing
• We The Flywheel: AI observability in 2026
• OpenAI: The Hugging Face incident and the road ahead
• Implicator: OpenAI's six misalignment incident reports
• The Decoder: Lloyd's insurers launch AI error policies
• Armilla: insurers launch cover for AI chatbot errors
• TestMu AI: Agent Assurance results and evidence
• TestMu AI: AI Agent Testing