До запуска Dataiku Agent Management: как компании провести инвентаризацию AI Agent? Чек-лист 2026

Решение до запуска: начинайте инвентаризацию сейчас

В объявлении от 24 сентября 2026 года Dataiku сообщила, что планирует открыть Agent Management в октябре 2026 года. Если вы отвечаете за несколько сред и платформ, не ждите этой даты: уже сейчас соберите реестр Agent, назначьте владельцев и распределите риски, затем проверьте мониторинг, подтверждения безопасности и порядок пересмотра. Наблюдение за работой Agent не заменяет ограничение его полномочий и изоляцию среды исполнения.

Кому пригодится этот чек-лист

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

Последняя проверка: 26 сентября 2026 года. Сверено с официальным объявлением Dataiku и описанием продукта в блоге Dataiku. Указанный срок открытия и заявленные возможности отражают сведения компании; точная дата и поддерживаемые интеграции могут быть уточнены позднее.

Что подготовить до подключения платформы

Dataiku описывает Agent Management как продукт для обнаружения Agent в разных платформах, наблюдения за их работой и управления рисками. В описании компании упоминаются реестр, информация о работе и риск-записи. Это заявление о назначении продукта, а не независимая проверка того, что конкретная установка увидит все Agent вашей организации или остановит опасное действие.

Для подготовки важна граница охвата. Список названных интеграций — не доказательство поддержки любого сервиса, собственного фреймворка или внутреннего скрипта. Для пользовательских сред Dataiku указывает поддержку через OpenTelemetry. Однако наличие инструмента и его применимость — не одно и то же: нужно проверить, внедрена ли инструментализация, какие сигналы передаются, кто контролирует их полноту и можно ли связать записи с конкретной версией Agent. Документация OpenTelemetry по инструментализации объясняет роль инструментирования приложений; это техническая основа наблюдаемости, а не автоматическая сертификация произвольного Agent.

Реестр нужен не только для загрузки данных в будущую консоль. Без него вы рискуете пропустить Agent, который работает вне центральной платформы; перепутать технический аккаунт с бизнес-владельцем; принять наличие логов за достаточное основание для допуска к чувствительным операциям. Добавьте ещё две типичные проблемы: сведения о моделях и подключённых инструментах быстро устаревают, а затраты могут быть разделены между командой, облачным проектом и поставщиком модели. Если источники учёта не связаны, невозможно уверенно ответить, кто должен подтвердить риск или объяснить счёт.

В карточке Agent укажите как минимум:

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

Для статуса не нужно придумывать сложную таксономию. Важно отделить проверенное от предположения. Если команда не смогла определить, кто отвечает за Agent, не записывайте владельца по имени владельца облачного проекта или создателя учётной записи. Отметьте запись как неподтверждённую и назначьте ответственного за выяснение.

Платформенная команда: как собрать единый реестр

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

Для каждого найденного кандидата зафиксируйте происхождение записи. Например, «обнаружен в каталоге развёртываний» надёжнее, чем «сообщила команда», но оба свидетельства полезны и должны сохраняться отдельно. Если один Agent присутствует в нескольких окружениях, не объединяйте записи до проверки: тестовый экземпляр и рабочий могут иметь разные полномочия, модели и владельцев.

Для пользовательской телеметрии отдельно проверьте, какие сигналы действительно поступают. OpenTelemetry описывает три основных типа сигналов: traces, metrics и logs. Это не означает, что для каждого Agent уже доступны все три. Уточните, что именно передаёт ваша конфигурация, с каким идентификатором и с какой задержкой; проверьте, сохраняются ли записи при сбое отправки. Пустое поле нельзя интерпретировать как отсутствие риска или успешную работу.

Первый проход по реестру

• [ ] Составьте список платформ, облачных проектов, локальных сред и командных каталогов, где могут запускаться Agent.
• [ ] Найдите кандидатов по развёртываниям, расписаниям, репозиториям, обращениям к моделям и подключённым инструментам.
• [ ] Для каждой записи сохраните источник обнаружения и отметьте, проверен ли он владельцем системы.
• [ ] Разделите экземпляры, если у них различаются среда, доступы, версия или назначение.
• [ ] Проверьте наличие телеметрии и укажите, какие именно данные видны, а какие нужно собирать другим способом.
• [ ] Назначьте срок и ответственного для каждой неподтверждённой записи.
• [ ] Сверьте реестр с командами, но не заменяйте этим независимый поиск по техническим источникам.

Если какой-либо способ обнаружения недоступен, занесите пробел в журнал охвата. Иначе будущая панель создаст ложное впечатление, будто отсутствие записи означает отсутствие Agent.

Бизнес и разработка: кто отвечает и зачем нужен Agent

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

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

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

Безопасность и AI governance: приоритет по последствиям

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

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

NIST AI Risk Management Framework для генеративного ИИ и плейбук NIST AI RMF можно использовать как основу для организации оценки и управления рисками. В плейбуке работа структурирована вокруг четырёх функций — Govern, Map, Measure и Manage. Это структура процесса, а не готовый уровень допуска для конкретного Agent. Для контроля именно Agent дополнительно сопоставьте доступы и внешние действия с рекомендациями из OWASP AI Agent Security Cheat Sheet.

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

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

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

Мониторинг помогает замечать доступность, использование, стоимость и изменение поведения — если соответствующие сведения собираются и правильно связаны с Agent. Но видимость не равна контролю. Телеметрия может показать, что Agent вызвал инструмент; сама по себе она не запрещает вызов. Журнал может содержать результат, но не доказывает его корректность. Наличие трассировки не подтверждает, что код прошёл тесты или что задача безопасно завершилась.

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

Что вы проверяете	Какое доказательство нужно	Что делать, если доказательства нет
Обнаружение и охват	Источник записи, среда, дата сверки, непокрытые платформы	Не считать реестр полным; назначить владельца пробела
Ответственность и назначение	Подтверждение бизнес-владельца и операционной команды	Ограничить запуск до назначения ответственных
Доступ и побочные действия	Перечень данных, инструментов, полномочий и человеческих подтверждений	Уменьшить права или отключить опасный инструмент
Работа и стоимость	Телеметрия, данные об использовании и сверка затрат с выставлением счетов	Не прогнозировать экономию; собирать фактические данные
Качество и безопасность результата	Тесты, сценарии отказа, протокол ручной проверки	Не принимать логи как замену тестированию и приёмке

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

Риск-ответственные: как подтвердить допуск и пересмотр

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

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

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

Технические руководители и FinOps: как выбрать порядок работ

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

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

Для планирования удобно сравнить текущую картину с требуемым состоянием:

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

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

Как закрыть пробелы до подключения продукта

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

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

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

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