Как дать ИИ-агенту доступ к вашим системам

Доступ — это про действия, а не только про данные

Большинство разговоров о том, чтобы дать ИИ-системе доступ к системам компании, на деле про чтение: какие документы она видит, соблюдает ли права исходных файлов, куда уходят данные. Вопрос важный и хорошо разобранный. Этот материал — про другую половину, которая приходит вместе с агентами и планируется куда реже: что этой штуке позволено делать. Модель, которая умеет только читать, выдаёт неверный ответ. Модель, которая умеет действовать, выдаёт неверный счёт, неверное письмо клиенту или удалённую запись — на машинной скорости и без единого человека рядом.

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

Начните с разбора действий, а не систем

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

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

К средней категории относитесь скептически: обратимость протекает. Обновление обратимо, только если сохранено старое значение. Удаление обратимо, только пока не закрылось окно резервных копий. Изменение записи выглядит обратимым ровно до момента, когда вебхук разнёс его в три другие системы, у каждой из которых своя копия. Честная проверка — восстанавливал ли кто-нибудь такое на практике, а не задокументирована ли кнопка отмены.

Дайте агенту собственную идентичность

Удобный путь — пустить агента под сессией того, кто его запустил, или под давно живущим ключом, заведённым под другую задачу. И то и другое работает сразу и разрушает вашу способность отвечать на вопросы потом.

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

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

Ограничивайте не только технически, но и на языке бизнеса

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

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

Отрепетируйте до подключения к чему-то настоящему

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

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

Пусть журнал отвечает на тот вопрос, который вы зададите

Вопрос, когда он придёт, будет вариацией такого: что эта штука сделала со счётом того клиента в прошлый вторник и почему. Чтобы ответить, нужны последовательность вызовов инструментов с аргументами и результатами, идентичность, которая их совершила, запрос, запустивший прогон, и столько рассуждения, чтобы видеть, почему выбрана одна ветка, а не другая. Журнал итоговых ответов на это не отвечает; журнал, записавший человека, у которого просто была открыта сессия, — тоже.

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