1. Определить решение совета директоров как делегированные полномочия
Агент AI следует рассматривать как делегированную операционную возможность. Решение совета директоров касается того, каких целей может добиваться система, какие сведения она может использовать, какие инструменты может вызывать, какие обязательства может создавать и какие действия по-прежнему требуют одобрения. Лицензия на использование модели или успешная демонстрация не дают ответов на эти вопросы.
Экономическое обоснование может быть привлекательным. В бэк-офисах есть повторяющиеся поиски, сверки, обработка документов, триаж исключений, последующие действия и обновления статусов. Агент может связать эти шаги между системами и во времени. Он может подготовить пакет для подключения поставщика, отследить спорный счёт, собрать прогноз денежных потоков или координировать обращение клиента в службу поддержки. Ценность возникает, когда компания устраняет задержки, повторную работу и фрагментированное распределение ответственности, сохраняя надёжные доказательства.
Подверженность контрольным рискам также расширяется. Агент может выбрать неверную запись, последовать инструкции, встроенной в недоверенный документ, использовать учётные данные за пределами предполагаемой цели, раскрыть персональные данные, создать дублирующий платёж, применить устаревшую политику или продолжить работу после изменения бизнес-контекста. Последствие может пройти через несколько систем, прежде чем его увидит человек.
Мандат совета директоров должен поэтому определять четыре границы. Граница результата определяет, чего агент может достичь. Граница ресурсов определяет, какие данные, приложения, идентичности, бюджет и время он может использовать. Граница действий определяет, какие действия он может выполнять и какие требуют одобрения. Граница сбоя определяет, как система останавливается, локализует ущерб, сохраняет доказательства и возвращает работу человеку.
Первое решение по политике должно определить запрещённые действия. Примеры могут включать высвобождение денежных средств, изменение банковских реквизитов, прекращение трудовых отношений, принятие договорной ответственности, подачу регуляторной отчётности, обход разделения обязанностей или сообщение окончательного неблагоприятного решения физическому лицу. Точный перечень зависит от юридических обязательств компании, операционной модели и склонности к риску.
Цель, идентичность, инструменты и результат остаются в пределах явных границ политики, одобрения и доказательств.
2. Обоснуйте программу актуальными данными по разным рынкам
Официальные рамки сходятся в вопросах управления жизненным циклом, подотчётности, тестирования и способности вмешаться. Рамочная основа управления рисками AI NIST организует работу через руководство, картирование, измерение и управление. Её профиль генеративного AI определяет риски, которые могут быть новыми или усиленными генеративными системами, и предлагает действия на протяжении жизненного цикла. В феврале 2026 года NIST запустила Инициативу по стандартам для агентов AI с отдельными направлениями по безопасности агентов, идентичности, авторизации, интероперабельности и оценке. Инициатива подтверждает, что контроль предприятий за агентами остаётся активно развивающейся областью стандартов.
DIFC внёс поправки в свои Правила защиты данных в 2023 году, включив Положение 10 об обработке персональных данных через автономные и полуавтономные системы. Положение и связанные с ним руководства помещают использование персональных данных, подотчётность и затронутых лиц в контрольную среду, ориентированную на результаты. Компании среднего сегмента, работающей в DIFC или через DIFC, следует сопоставить это положение с каждым агентом, который обрабатывает персональные данные, и получить актуальную консультацию о сфере действия и обязательствах.
Международное руководство UK NCSC по безопасному применению AI охватывает безопасное проектирование, разработку, развёртывание, эксплуатацию и сопровождение. Оно требует моделирования угроз, дью-дилидженса цепочки поставок, защищённой инфраструктуры, журналирования, мониторинга, управления инцидентами и ответственного выпуска. Эти меры контроля важны, когда бэк-офисный агент зависит от внешних моделей, коннекторов, библиотек или интерфейсов прикладного программирования.
Европейская комиссия заявляет, что обязательства по прозрачности согласно статье 50 Закона AI начали применяться 2 августа 2026 года. Материалы Комиссии по внедрению на 2026 год также отражают пересмотренные сроки для правил в отношении высокого риска. Компании следует подтвердить, действует ли она как провайдер, развёртывающая организация, импортёр или иной оператор, и оценить каждый сценарий использования по актуальному официальному тексту и применимому отраслевому законодательству.
Данные финансового сектора дают полезный контрольный сигнал. Совместный опрос Банка Англии и Управления по финансовому регулированию и надзору 2024 года показал, что 75 процентов респондентов использовали AI, 33 процента сценариев использования включали третьи стороны, 55 процентов предполагали некоторое автоматизированное принятие решений и только 2 процента были полностью автономными. В нём также сообщалось, что кибербезопасность была наиболее воспринимаемым риском, а полное понимание развёрнутого AI было ограниченным. Данные опроса не определяют правильную архитектуру для отдельной компании; они показывают важность подотчётного владения, прозрачности третьих сторон и выверенной автономности.
Таблица 1. Официальные данные и последствия для контроля
| Полномочия | Текущий сигнал | Последствия для контроля | Граница управленческой ответственности |
|---|---|---|---|
| NIST AI RMF и инициативность агента | управление рисками на протяжении жизненного цикла; работа по идентификации, авторизации и безопасности продолжается | вести реестр агентов, контур полномочий и журнал оценок | добровольные рекомендации должны быть соотнесены с конкретным сценарием использования |
| Регламент DIFC 10 | автономная и полуавтономная обработка персональных данных прямо урегулирована | комплексный анализ данных, воздействия на отдельных лиц и подотчётности | территориальный охват и охват обработки требуют юридической проверки |
| NCSC Великобритании | безопасность от проектирования до эксплуатации; контроль цепочки поставок и инцидентов | моделирование угроз для инструментов, коннекторов, учётных данных и сценариев отказов | рекомендации дополняют применимое законодательство и обязанности в сфере кибербезопасности |
| Европейская комиссия | Обязанности по прозрачности согласно статье 50 применяются с 2 августа 2026 года; сроки различаются в зависимости от конкретного правила | классифицировать роль, систему и взаимодействие; сохранить текущую карту соответствия | официальный текст и поправки имеют преимущественную силу |
| FCA и Банк Англии | использование третьими сторонами, неполное понимание и киберриск — существенные темы | документировать зависимости от поставщиков, ответственных владельцев и мониторинг | результаты опроса описывают респондентов, а не каждую компанию |
| ОЭСР, Сингапур и ISO | повторяются темы человеческого надзора, прослеживаемости, робастности и непрерывного улучшения | интегрировать AI в корпоративное управление и внутренний контроль | добровольные рамки требуют соразмерного применения |
Применимость, определения и обязанности требуют актуального подтверждения применительно к конкретной компании.
3. Разграничивайте автоматизацию, содействие и агентность
Слово «автоматизация» скрывает три разные операционные модели. Детерминированная автоматизация следует закодированным правилам: сопоставить заказ на закупку, проверить поле, направить документ или рассчитать пороговое значение. Ассистирование AI формирует для человека черновик, классификацию, резюме или рекомендацию. Ограниченная агентность выбирает и выстраивает последовательность действий в рамках заданной цели и может продолжаться на нескольких шагах.
Эти модели не должны иметь один общий стандарт утверждения. Детерминированную автоматизацию часто можно проверить на известных входных и выходных данных. Поддержка AI требует контроля над обоснованием, проверкой и использованием. Агентность требует всех этих средств контроля, а также полномочий, идентичности, доступа к инструментам, памяти, завершения, обработки исключений и доказательств каждого промежуточного действия.
Автономию следует декомпозировать, а не описывать одним ярлыком. Агент может иметь свободу планирования, не имея прав на исполнение. Он может выполнять внутренние обновления с низкими последствиями, но требовать одобрения перед внешней коммуникацией. Он может работать только с указанным кейсом, в пределах заданного лимита стоимости, в течение короткого временного окна и с ограниченным числом вызовов инструментов.
Компания должна выбирать самый низкий уровень агентности, который способен обеспечить желаемый экономический результат. Многие процессы существенно улучшаются благодаря лучшим данным, детерминированным средствам контроля и подготовке с поддержкой AI. Полностью безлюдное исполнение подходит только там, где процесс хорошо понятен, действие обратимо, полномочия можно строго ограничить, доказательства полны, а сбой можно локализовать.
Лестница автономии делает продвижение наблюдаемым. Сценарий использования переходит на следующий уровень только после прохождения определённых контрольных точек подтверждения на текущем уровне. Производственные инциденты, существенные изменения процесса, новые инструменты, изменения моделей или слабый мониторинг должны запускать переоценку или возврат на более низкий уровень.
Полномочия расширяются только после того, как на предыдущем уровне продемонстрированы доказательства, обратимость и возможность локализации.
4. Составьте реестр процессов и решений
Внедрение агентов должно начинаться с процесса, решения и цепочки доказательств. Каталог привлекательных демонстраций может упускать операционные причины затрат и задержек. Компания должна провести инвентаризацию бэк-офиса по потокам создания стоимости: от заказа до оплаты, от закупки до платежа, от учёта до отчётности, от найма до выхода на пенсию, от обращения до решения, регуляторная отчётность и управленческая информация.
Каждый процесс следует декомпозировать на триггеры, входные данные, решения, действия, системы, владельцев, передачи, средства контроля, исключения и выходные данные. Менеджмент должен измерять объём, время цикла, ошибки, переделки, бэклог, стоимость, денежную подверженность риску, чувствительность данных и последствия для обслуживания. Реестр должен выявлять, где действительно требуется суждение и где отсутствующие данные или непоследовательная политика создают видимость суждения.
Реестр решений особенно важен. Решение может утверждать платёж, разрешать выпуск заказа клиента, классифицировать жалобу, изменять запись поставщика, признавать журнальную проводку, выбирать кандидата или сообщать вывод. Запись должна определять, кто затронут, какие доказательства требуются, какая политика применяется, какое усмотрение разрешено, каков путь апелляции или исправления и каковы правовые последствия или последствия для контроля.
Приоритизация должна сочетать экономическую ценность и реализуемость контроля. Работа с большим объёмом, низкими последствиями и богатой доказательной базой может быть привлекательной отправной точкой. Работа с высокими последствиями, неоднозначная или слабо подтверждённая доказательствами должна сначала пройти восстановление процесса и усиление контроля данных. Компании следует избегать автоматизации сломанного процесса обработки исключений, первопричина которого остаётся нерешённой.
Реестр становится руководящим источником для утверждения сценариев использования. Он связывает заявленную ценность с измеримым базовым уровнем и не позволяет технологической команде предоставлять полномочия без согласования проекта с владельцем процесса, владельцем риска, владельцем данных и владельцем контроля.
Таблица 2. Реестр процессов и решений
| Поле реестра | Ключевой вопрос | Подтверждающие материалы | Использование для принятия решений |
|---|---|---|---|
| Триггер и цель | Что запускает работу и какой результат её завершает? | Событие-источник, стандарт обслуживания и запись о завершении | Определение охвата и правила остановки |
| Входные данные и решение | Какие факты и политика определяют следующий шаг? | Документы, мастер-данные, политика и запись об утверждении | Проверка обоснованности и допустимая свобода усмотрения |
| Действие и последствие | Что может измениться в бизнесе или повлиять на человека? | Системная транзакция, коммуникация и подверженность стоимостному риску | Установление полномочий и уровня утверждения |
| Исключение и сбой | Где нарушается нормальная обработка? | Коды ошибок, накопившиеся задачи, споры и инциденты | проектирование эскалации и безопасного отказа |
| контроль и владелец | кто остаётся подотчётным и какой контроль должен действовать? | матрица контроля, разделение обязанностей и описание роли | назначить ответственного за управление и доказательную базу |
| исходные показатели и ценность | что можно улучшить в части затрат, задержек, ошибок или денежного риска? | показатели объёма, времени, качества, денежных средств и обслуживания | построить бизнес-кейс и систему показателей |
Показатели выбираются с учётом операционного контекста и должны основываться на сверенных доказательствах.
5. Определите контур полномочий
Контур полномочий переводит политику в машиноисполнимые ограничения. В нём должны быть указаны цель, разрешённые данные, разрешённые инструменты, действия, значения, контрагенты, юрисдикции, рабочие часы, продолжительность, количество вызовов, точки утверждения и условия остановки. Одной инструкции на естественном языке недостаточно, поскольку её можно интерпретировать по-разному при изменении контекста.
По умолчанию полномочия должны быть узкими. Агент по счетам-фактурам может читать утверждённые счета-фактуры и заказы на закупку, запрашивать отсутствующие внутренние доказательства, готовить предложение по платежу и обновлять запись дела. Он не должен иметь постоянного права изменять банковские реквизиты поставщика или инициировать платёж. Агент по взысканию задолженности может подготовить напоминание на основе утверждённых фактов и условий, тогда как человек утверждает внешнюю коммуникацию выше определённого уровня чувствительности или категории клиента.
Контур должен быть привязан к указанному бизнес-владельцу и уровню риска. Временные полномочия должны истекать. Лимиты по стоимости и объёму должны быть как кумулятивными, так и транзакционными, чтобы множество мелких действий не могло обойти дневной лимит или лимит на уровне дела. Ограничения по географии, юридическим лицам и валюте должны соответствовать правовому и операционному периметру.
Обеспечение соблюдения политики должно происходить вне модели рассуждений. Детерминированный сервис должен проверять каждый предлагаемый вызов инструмента на соответствие идентичности, цели, разрешениям, стоимости, статусу дела и утверждению. Модель может объяснить, почему она предлагает действие; движок политики решает, может ли действие быть выполнено.
Каждый отказ должен создавать структурированные доказательства. Повторные отказы могут выявлять неудачный промпт, слабый дизайн процесса, зарождающееся злоупотребление или контур полномочий, требующий пересмотра. Изменения контура полномочий должны проходить через контроль версий, тестирование и утверждение с сохранением предыдущей версии.
Каждое предлагаемое действие до выполнения должно пройти проверку на соответствие совокупным лимитам, политике и требованиям утверждения.
6. Наделите каждого агента отдельной идентичностью
Агент не должен работать через общую учётную запись сотрудника или неограниченные сервисные учётные данные. Ему нужна уникальная машинная идентичность, связанная с назначенным владельцем, определённой целью, уровнем риска, версией и сроком действия. Это обеспечивает соблюдение принципа наименьших привилегий, атрибуцию, ротацию учётных данных, отзыв и надёжный аудит.
Разрешения должны зависеть от задачи. Право на чтение, право предлагать и право исполнять — это разные права. Агент должен получать краткосрочные учётные данные в момент необходимости после того, как сервис политик проверит кейс и статус утверждения. Секреты должны храниться в управляемом хранилище и никогда не попадать в промпты, память, журналы или документы.
Архитектура идентичности должна обеспечивать разделение обязанностей. Агент, создающий поставщика, не должен утверждать этого поставщика или инициировать платёж. Агент, готовящий проводку, не должен проводить и утверждать ту же проводку. Утверждение человеком не устраняет конфликт, если у утверждающего нет независимости, доказательств или достаточного времени.
Вызовы между агентами требуют такой же дисциплины. Принимающий агент должен аутентифицировать вызывающего, проверить делегированный объём полномочий и отказать в полномочиях, которые нельзя проследить до исходного принципала. Цепочки делегирования должны иметь максимальную глубину и сохранять исходного владельца, кейс и совокупные лимиты.
Экстренный отзыв должен быть практичным. Компания должна иметь возможность отключить идентичность, отозвать активные токены, остановить поставленные в очередь действия и изолировать кейс, не дожидаясь поставщика модели. Повторная сертификация доступа должна проводиться после существенных изменений процессов или ролей, а также периодически с частотой, соразмерной риску.
7. Контролируйте данные, промпты, инструменты и память
Фактическая среда работы агента включает не только модель. Она включает системные инструкции, пользовательские инструкции, извлечённые документы, память, описания инструментов, ответы приложений и контент третьих сторон. Любой из этих элементов может быть неточным, вредоносным, устаревшим или выходить за пределы разрешённой цели.
Доступ к данным должен соответствовать классификации, цели и принципу минимальной необходимости. Компания должна составить карту персональных данных, конфиденциальной коммерческой информации, платёжных данных, кадровых данных и материалов, защищённых юридической привилегией. Извлечение данных должно обеспечивать соблюдение границ сущности, кейса и пользователя. Чувствительные поля можно маскировать, пока задача и утверждение не потребуют их раскрытия.
Недоверенный контент следует рассматривать как данные, а не как инструкцию. Сообщение во вложении к счёту, которое просит агента игнорировать политику или отправить информацию в другое место, не должно иметь полномочий. Архитектура должна отделять доверенные управляющие инструкции от извлечённого контента, при необходимости очищать выходные данные инструментов и тестировать сценарии инъекции промптов.
Инструменты требуют списков разрешённых элементов и контроля параметров. Универсальный запрос к базе данных, командная оболочка или неограниченный браузер могут дать агенту более широкую поверхность работы, чем требует бизнес-цель. Специализированные инструменты с типизированными входными данными, узкими действиями, детерминированной проверкой и идемпотентностью обеспечивают более прочную границу.
Память должна иметь определённую цель, срок хранения и путь удаления. Компания должна различать временное состояние кейса, утверждённые справочные знания и изученные предпочтения. Постоянная память может переносить устаревшие факты, несанкционированные персональные данные или инструкции одного кейса в другой. Записи в память должны быть явными, атрибутируемыми и проверяемыми.
Таблица 3. Реестр мер контроля для операционной среды агента
| Среда | Основной риск | Превентивный контроль | Выявляющий или восстановительный контроль |
|---|---|---|---|
| системные и пользовательские инструкции | неоднозначные или конфликтующие полномочия | подписанный и версионированный управляющий промпт и правила приоритета | трассировка инструкций и проверка отклонённых действий |
| извлечённые документы | инъекция промпта, устаревшие факты или неверная сущность | классы доверенных источников, фильтры по кейсам и изоляция контента | журнал происхождения и тесты на состязательный контент |
| инструменты и коннекторы | избыточные полномочия или небезопасные параметры | узкоспециализированные типизированные инструменты, список разрешённых, проверка политик и идемпотентность | телеметрия вызовов инструментов, сверка и отзыв доступа |
| учётные данные и секреты | раскрытие, повторное использование или повышение привилегий | хранилище секретов, краткоживущий токен и минимальные привилегии | сканирование секретов, ротация и оповещения о доступе |
| рабочая память | утечка между кейсами или устаревший контекст | изоляция кейсов, правило хранения и явное разрешение на запись | аудит памяти, истечение срока действия и доказательства удаления |
| внешние модели и сервисы | риск передачи, изменения или концентрации данных | договор, конфигурация, минимизация данных и резервный сценарий | мониторинг провайдера, тестирование версий и план выхода |
Техническая реализация должна быть валидирована ответственными за безопасность, конфиденциальность и контроль в компании.
8. Обеспечьте детерминированный контроль вероятностных процессов
Агент может помогать интерпретировать неструктурированную информацию, тогда как детерминированные механизмы контроля должны управлять фактами, которые должны быть точными. Форматы банковских счетов, налоговые идентификаторы, расчёты по счетам, валюта, выявление дублей, лимиты одобрения, периоды бухгалтерского учёта, санкционный статус и правила разделения обязанностей должны проверяться через контролируемые данные и код.
Рабочий процесс может использовать модель, чтобы найти вероятный номер счёта-фактуры, объяснить расхождение или предложить категорию. Затем детерминированный сервис должен проверить идентификатор в системе-источнике, рассчитать сумму, проверить правило и вернуть статус «успех», «ошибка» или «исключение». Агент не должен превращать интерпретацию с низкой степенью уверенности в исполненную транзакцию.
Сверка имеет центральное значение. Компания должна сравнивать запрошенные, одобренные, исполненные и учтённые действия. Каждой транзакции нужен ключ идемпотентности, чтобы повторная попытка не создала дубль. Итоги пакетов, контрольные счета и очереди исключений должны сверяться с системами-источниками и системами назначения. Успешный ответ инструмента — это свидетельство вызова, а не доказательство предполагаемого бухгалтерского или операционного результата.
Уверенность не должна заменять полномочия. Модель с высокой уверенностью всё равно может ошибаться, а результат с низкой уверенностью может быть полезен, если его чётко направить человеку. Правила принятия решений должны учитывать последствия, полноту доказательств, политику и обратимость наряду с любой оценкой модели.
Дизайн должен обеспечивать плавную деградацию. Если модель, коннектор или источник данных недоступны, процесс должен приостановиться, вернуться к более простому правилу или передать работу человеку согласно задокументированному плану обслуживания. Компания должна знать, какие операционные обязательства зависят от агента и как долго она может терпеть перерыв.
9. Выстраивайте процесс одобрения человеком с учётом последствий и обратимости
Участие человека создаёт контроль только тогда, когда проверяющий получает правильные доказательства, понимает решение, обладает полномочиями и имеет время оспорить его. Очередь из сотен рутинных одобрений может стать формальностью. Дизайн должен концентрировать человеческое суждение на существенных, необычных или необратимых действиях.
Уровни одобрения должны отражать последствия. Классификацию внутренних операций с низкой стоимостью можно проверять выборочно. Коммуникация с клиентом может требовать одобрения, если она меняет договорное положение или касается уязвимого лица. Платёж, изменение банковских реквизитов, бухгалтерская проводка, кадровое действие или регуляторная подача могут требовать двойного контроля или проверки специалистом.
Пакет одобрения должен показывать предлагаемое действие, цель, исходные доказательства, правило политики, существенные допущения, исключения, сумму, затронутую сторону, альтернативы и последствия для последующих этапов. Проверяющий должен иметь возможность одобрить, изменить, отклонить или вернуть кейс. Причина отклонения должна способствовать улучшению процесса, но не должна автоматически обучать систему.
Обратимость влияет на контрольную точку. Обновить статус внутренней задачи легче обратить, чем отправить средства, раскрыть данные или вынести окончательное решение. Временная чувствительность также важна. Система должна эскалировать до наступления срока, а не давить на проверяющего, вынуждая его принять слабое решение в последний момент.
За эффективностью работы людей необходимо следить. Повторяющиеся быстрые одобрения, высокий процент переопределений, частые исправления после одобрения или большие различия между проверяющими могут указывать на слабые доказательства, недостаточное обучение или предвзятость в пользу автоматизации. Ответственность остаётся за назначенным ответственным, даже если агент подготовил работу.
Более серьезные последствия и меньшая обратимость требуют более веских доказательств и независимого утверждения.
10. Управление мультиагентными зависимостями и зависимостями от третьих сторон
Агент редко работает в одиночку. Он может зависеть от поставщика модели, облачной платформы, слоя оркестрации, векторной базы данных, коннектора, службы идентификации и бизнес-приложения. Мультиагентная архитектура добавляет делегированные задачи и коммуникации между системами с разными владельцами и возможностями.
Реестр зависимостей должен указывать поставщика, услугу, местоположение данных, модель или версию, критичность, договорные права, субпроцессоров, срок хранения, уведомление об инцидентах, уровень обслуживания, аудиторские доказательства, процесс изменений и путь выхода. Концентрация должна быть видна там, где несколько критических рабочих процессов зависят от одного поставщика или контура учетных данных.
Компания должна тестировать изменения у поставщиков. Поведение модели, схемы инструментов, ограничения частоты, настройки безопасности и условия обработки данных могут меняться. Выпуск должен проходить через контролируемую среду с регрессионными тестами до вывода в производство. Экстренные изменения у поставщика должны запускать определенный путь сдерживания и резервный сценарий.
Сообщения между агентами должны использовать аутентифицированные, типизированные и ограниченные протоколы. Принимающая система должна рассматривать неструктурированное содержимое как недоверенное до проверки. Каждая задача должна содержать цель, исходный принципал, делегированную область полномочий, срок действия и требования к доказательствам. Дочерний агент не должен получать больше полномочий, чем родительский.
Договоры должны охватывать использование данных, конфиденциальность, безопасность, интеллектуальную собственность, аудит, инциденты, изменения, непрерывность обслуживания, переносимость и прекращение. Требуется юридическая консультация для соответствующей юрисдикции и операционной модели. Технические меры защиты остаются необходимыми, поскольку договорное средство правовой защиты наступает после инцидента и может не восстановить данные или доверие клиентов.
11. Сохраняйте финансовый и закупочный контроль
Финансы и закупки предлагают ценные сценарии использования агентов, поскольку в них есть повторяющийся сбор доказательств и урегулирование исключений. Они также содержат прямые риски в отношении денежных средств, отчетности, мошенничества и поставщиков. Архитектура агентов должна расширять существующую среду внутреннего контроля, а не создавать параллельный обходной путь вокруг нее.
В процессе «закупки — оплата» (procure to pay) агенты могут проверять полноту онбординга, сопоставлять доказательства по счету-фактуре и заказу на покупку, выявлять дубликаты, готовить описания исключений и направлять заявки на утверждение. Создание или изменение банковских реквизитов должно по-прежнему подлежать независимой проверке вне канала связи, использованного для запроса. Платежные предложения должны сверяться с утвержденными счетами-фактурами и выпускаться через установленные полномочия казначейства.
В процессе «учет — отчетность» (record to report) агенты могут собирать сверки, отслеживать отклонения, готовить обоснование проводок и проект комментариев. Статус периода, ответственность за счет, доказательства и утверждение должны проверяться машиной. Существенные или необычные проводки должны проходить независимую проверку. Система должна сохранять точный источник, преобразование и цепочку решений, использованные для каждой предлагаемой записи.
В процессе «от заказа до оплаты» (order to cash) агенты могут выявлять пробелы в документации, классифицировать споры, готовить меры по взысканию и координировать внутренних ответственных. Внешние коммуникации должны использовать утвержденные факты и полномочия. Изменения кредитных лимитов, уступки, списания и юридически чувствительная эскалация должны следовать существующим процедурам утверждения.
Архитектура должна избегать размывания контроля из-за объема. Агент может создавать больше предложений, чем проверяющие способны оценить. Ограничения пропускной способности, маршрутизация с учетом риска и старение очереди должны быть частью решения о выпуске. Финансовую выгоду следует измерять через время цикла, переработку, ошибки, сроки движения денежных средств и высвобожденную пропускную способность, а рядом с ними должны быть показатели обслуживания и контроля.
Таблица 4. Матрица контроля финансов и закупок
| Сценарий использования | Вклад агента | Детерминированный контроль | Контроль со стороны человека или независимой стороны |
|---|---|---|---|
| Подключение поставщиков | Собрать подтверждающие документы и выявить пробелы | Проверки обязательных полей, дубликатов, налоговых данных и счетов | Утверждение владельцем; независимая проверка банковских реквизитов |
| Исключение по счёту | Сравнить документы и объяснить расхождение | Правила проверки арифметики, валюты, дублей и допусков | Владелец исключения утверждает решение |
| Платёжное предложение | Сгруппировать утверждённые позиции с наступившим сроком оплаты и спрогнозировать денежные потоки | Статус утверждения, сумма, срок оплаты и идемпотентность | Проведение платежа казначейством в рамках действующего мандата |
| Сверка | сопоставлять записи и готовить анализ расхождений | проверка контрольной суммы, периода и источника | владелец счёта заверяет неурегулированные позиции |
| подготовка проводок | собрать подтверждающие документы и предлагаемую проводку | правила по периоду, счёту, балансу и разделению обязанностей | уполномоченный проверяющий утверждает и проводит |
| дело о взыскании | найти доказательства и подготовить следующее действие | клиент, сумма, срок оплаты и правило коммуникации | владелец утверждает чувствительное или обязывающее действие |
Матрица дополняет действующие политики компании в области полномочий, бухгалтерского учёта и казначейства.
12. Защита клиентов, сотрудников и затронутых лиц
Агенты бэк-офиса могут влиять на людей, даже если сценарий использования кажется административным. Клиент может получить эскалацию взыскания. Поставщик может быть заблокирован. Сотрудник может быть ранжирован, в отношении него может быть проведено расследование или ему может быть отказано в льготе. Жалоба может быть классифицирована так, что изменится подход к её рассмотрению. Компания должна оценивать последствия каждого решения для отдельного человека и отношений с ним.
Оценка должна определить затронутую группу, используемые данные, цель, правовое основание, потенциальный вред, проблему справедливости, обязанность обеспечивать прозрачность, проверку человеком и путь обжалования. Персональные данные должны ограничиваться авторизованной целью. Данные особых категорий или конфиденциальные данные требуют усиленного анализа и мер защиты в соответствии с применимым законодательством.
Коммуникации должны точно описывать роль автоматизации там, где это необходимо, и обеспечивать практический способ обратиться к человеку. Затронутые лица не должны оказываться в цикле, где один агент проверяет решение другого агента без значимого независимого вмешательства. Жалобы и апелляции должны сохранять исходные доказательства, путь принятия решения и использованные версии.
Сценарии использования в сфере занятости требуют особой осторожности. Скрининг кандидатов, анализ эффективности, управление отсутствиями, дисциплинарные меры и увольнение могут иметь существенные правовые и человеческие последствия. Компании следует получить актуальные консультации по трудовому праву и защите данных, привлечь квалифицированных владельцев HR-процессов и обеспечить независимую проверку.
Справедливость следует проверять в контексте. Совокупная точность может скрывать неравномерную ошибку или нагрузку по группам, географиям, языкам или клиентским сегментам. Компания должна определить соответствующие показатели результатов, изучить паттерны ошибок и отслеживать изменения после внедрения. Проверка справедливости должна также учитывать, подходит ли сам процесс для использования агентом.
13. Проектирование с учётом кибербезопасности и безопасного отказа
Модель угроз должна охватывать всю агентную систему. Злоумышленники могут манипулировать промптами, документами, выходными данными инструментов, памятью, коннекторами, учётными данными и зависимостями. Они могут добиваться доступа к данным, деньгам, закрепления, нарушения работы или влияния на бизнес-решения. Обычная ошибка конфигурации может привести к аналогичным последствиям без злого умысла.
Безопасный дизайн начинается с узкоспециализированных инструментов, изолированных сред, минимальных привилегий, контроля входных и выходных данных, защищённых секретов и явных границ доверия. При разработке следует использовать контролируемые репозитории, проверенные зависимости, воспроизводимые сборки и тестирование. При развёртывании следует защищать инфраструктуру, конфигурацию и доступ к модели. При эксплуатации следует отслеживать поведение, уязвимости, изменения у провайдеров и инциденты.
Проект безопасного отказа должен описывать, что происходит, когда доказательства противоречат друг другу, инструмент возвращает неожиданную структуру, достигнут лимит, отказывают учётные данные, модель изменилась, зависимость недоступна или агент ведёт себя за пределами протестированного распределения. Предпочтительная реакция обычно — приостановить работу, сохранить состояние, изолировать отложенные действия и передать дело человеку.
Функция экстренного отключения должна быть независимой от агента. Операторы должны иметь возможность отключить учётную запись, коннектор, сценарий использования, модель или весь слой оркестрации. Для поставленных в очередь задач и частично выполненных транзакций нужна процедура восстановления. Обеспечение непрерывности бизнеса должно охватывать ручной или упрощённый процесс, необходимый на время прерывания.
Реагирование на инциденты должно сохранять промпты, извлечённые доказательства, вызовы инструментов, согласования, версии модели и конфигурации, отметки времени и выполненные транзакции. Команда должна определить масштаб, ограничить действующие полномочия, уведомить соответствующих владельцев и консультантов, сверить результаты, исправить затронутые записи и решить, требуется ли уведомление регулирующих органов или по договору.
Безопасный отказ сохраняет доказательства, ограничивает полномочия и передаёт нерешённую работу ответственному владельцу.
14. Обеспечьте возможность восстановить каждое существенное действие
Аудируемость требует большего, чем стенограмма. Запись доказательств должна позволять восстановить, кто или что инициировал(о) дело, какие полномочия применялись, какие версии данных и документов были извлечены, какая модель и конфигурация использовались, какие промежуточные решения были приняты, какие инструменты вызывались, какие проверки политик выполнялись, кто одобрил действие и что зафиксировала целевая система.
Журналы должны быть структурированными, синхронизированными по времени, с контролем доступа и защитой от несанкционированного изменения. Они не должны содержать излишних секретов и персональных данных. Сроки хранения должны соответствовать правовым, регуляторным, договорным и операционным требованиям. Компания должна иметь возможность объединять журналы идентификации, агента, приложений и транзакций с помощью общего идентификатора дела и действия.
Происхождение данных должно отличать исходные факты от интерпретации, сгенерированной моделью. Проверяющий должен иметь возможность открыть основной инвойс, договор, политику или системную запись. Если агент объединил несколько источников, доказательства должны показывать, какое утверждение из какого источника взято и был ли источник актуален на момент принятия решения.
Мониторинг должен охватывать не только техническую активность, но и результаты. Компания должна сверять исполненные транзакции, коммуникации с клиентами, записи в реестре, изменения доступа и решения по исключениям. Выборочная проверка должна охватывать рутинные случаи, тогда как существенные действия могут проверяться полностью.
Доступ к самим доказательствам является чувствительным. Журналы аудита могут содержать бизнес-процессы, сведения о безопасности и персональные данные. Требуются ролевой доступ, ограничения по цели и независимый мониторинг. Компания должна проверить, может ли она восстановить кейс, прежде чем полагаться на схему доказательств в продуктивной среде.
15. Тестируйте систему до предоставления права на продуктивную эксплуатацию
Тестирование следует начинать с проектирования процесса и средств контроля. Команда должна подтвердить, что цель ясна, исходные данные надёжны, политика может быть формализована, полномочия узки, а сценарий отказа практичен. Бенчмарк модели не может компенсировать неоднозначный процесс или отсутствующие доказательства.
Набор тестов должен включать обычные случаи, редкие, но важные случаи, неполные записи, противоречивые доказательства, устаревшие документы, дублирующиеся запросы, враждебные инструкции, несанкционированные вызовы инструментов, нарушения лимитов сумм, недоступные зависимости, задержанные согласования и попытки пересечь границы юридических лиц или кейсов. Команда должна тестировать многошаговое накопление, поскольку последовательность по отдельности правдоподобных действий может создать существенный риск.
Оценка должна измерять результат задачи, фактическую обоснованность, соблюдение политик, корректность инструментов, предотвращение дублирования, качество эскалации, полноту доказательств, задержку и стоимость. Тесты безопасности должны охватывать инъекции промптов, утечку данных, повышение привилегий, компрометацию зависимостей и отказ в обслуживании. Тесты конфиденциальности и справедливости должны отражать затронутую популяцию и правовой контекст.
Выпуск должен проходить через офлайн-оценку, песочницу, теневой режим, продуктивную эксплуатацию с одобрением человеком и ограниченную работу без участия человека. Каждый этап должен иметь критерии входа и выхода. Теневой режим сравнивает рекомендации с фактическими результатами процесса, не предоставляя прав на исполнение. Ограниченная продуктивная эксплуатация должна ограничивать контрагентов, суммы, пользователей, объём и время.
Регрессионное тестирование требуется после изменений модели, промпта, источника данных, инструмента, политики, коннектора или существенного бизнес-процесса. Запись о выпуске должна показывать утверждённую версию и доказательства. Компания должна сохранять возможность откатить изменения или лишить полномочий при ухудшении результатов.
Таблица 5. Контрольные точки тестирования и выпуска
| Контрольная точка | Требуемые доказательства | Разрешение на продуктивную эксплуатацию | Реакция на непрохождение |
|---|---|---|---|
| проверка проектирования | карты процессов, решений, данных, угроз и полномочий | сборка в изолированной среде | исправить процесс или сузить сценарий использования |
| офлайн-оценка | репрезентативные и состязательные результаты тестирования | отсутствие полномочий в рабочей среде | корректное проектирование модели, данных, инструментов или политик |
| песочница | сквозные доказательства по инструментам и контролю | синтетические или непроизводственные действия | локализовать и повторно протестировать |
| теневой режим | сравнение с реальными случаями и решениями владельцев | производственный контекст только для чтения | устранить пробелы в результатах и доказательствах |
| промышленная эксплуатация с одобрения человека | стабильные метрики, качество одобрений и сверка | ограниченные предложения и одобренные действия | сократить область применения или вернуться в теневой режим |
| ограниченная работа без участия оператора | доказательства устойчивого контроля, мониторинга и безопасного отказа | обратимые действия в строгих пределах | отозвать полномочия и активировать восстановление |
Пороговые значения и размеры выборок должны учитывать риск сценария использования, объём и применимые требования к обеспечению уверенности.
16. Сформируйте операционную модель с чёткой подотчётностью
Операционная модель должна закреплять бизнес-ответственность до технической реализации. Владелец бизнес-процесса отвечает за результат и операционную политику. Владелец риска утверждает меры обработки риска. Владелец данных управляет качеством источников и разрешённым использованием. Служба безопасности отвечает за модель угроз и архитектуру доступа. Технологическая функция отвечает за надёжную платформу. Внутренний аудит или независимая функция обеспечения уверенности оценивает дизайн и функционирование в соответствии со своим мандатом.
Форум по управлению AI может утверждать сценарии использования, уровни риска, контуры полномочий, релизы и существенные изменения. В состав форума должны входить представители бизнеса, технологий, безопасности, защиты конфиденциальности, юридической службы, комплаенса, финансов, HR и других функций в зависимости от сценария использования. Совет директоров или соответствующий комитет должен утверждать аппетит к риску и получать краткий обзор портфеля.
Реестр агентов должен содержать владельца, назначение, процесс, затронутые стороны, данные, модель, инструменты, идентичность, полномочия, уровень риска, утверждения, доказательства тестирования, релиз, мониторинг, инциденты, зависимости и статус вывода из эксплуатации. Реестр должен различать эксперименты и производственные системы, при этом применяя надлежащие меры контроля к экспериментам, которые используют чувствительные данные или инструменты, работающие в реальной среде.
Управление изменениями должно охватывать работу с персоналом. Сотрудникам необходимо обучение по возможностям агентов, ограничениям, эскалации, проверке доказательств и запрещённому использованию. Дизайн ролей должен определять, какая работа устраняется, какое суждение сохраняется и какие новые обязанности по контролю возникают. Высвобожденные ресурсы должны целенаправленно перераспределяться, а не приниматься как должное.
Независимая проверка должна фокусироваться на доказательствах. Владельцы должны демонстрировать контроль и результат, а не полагаться на заявления о политике. Если навыков недостаточно, компания может привлекать внешних специалистов по архитектуре, кибербезопасности, конфиденциальности, праву, аудиту или дизайну процессов, сохраняя внутреннюю подотчётность.
17. Реализуйте в рамках 120-дневной последовательности
Первые 30 дней устанавливают достоверную картину и границы. Руководство выбирает узкий поток создания ценности, описывает процесс и решения, сверяет базовый уровень, классифицирует данные, выявляет затронутые стороны, назначает владельцев, завершает модель угроз и готовит проект контура полномочий. Ручной прототип или прототип с поддержкой AI может проверить, существует ли предполагаемая ценность, прежде чем будет предоставлено право на выполнение в промышленной эксплуатации.
Дни с 31 по 60 — построение контролируемого пути. Команда создаёт уникальную идентичность агента, узкий набор инструментов, шлюз политик, модель доказательств по кейсу, пакет утверждений, журналирование, процедуру безопасной остановки и тестовый набор. Офлайн- и состязательная оценка должны устранить дефекты в обработке инструкций, привязке к источникам, параметрах инструментов и маршрутизации исключений.
Дни 61–90 проходят через песочницу и теневой режим. Команда сравнивает предложения агентов с реальными результатами процессов, измеряет базовые и контрольные показатели, тестирует процедуры непрерывности и инцидентов, завершает дью-дилидженс третьих сторон и обучает проверяющих. Промышленный контур остаётся доступным только для чтения или с утверждением человеком до выполнения критериев выхода.
Дни 91–120 предполагают ограниченную промышленную эксплуатацию. Компания ограничивает стоимость, объём, юридические лица, контрагентов, действия и время. Она сверяет каждое выполненное действие, отслеживает исключения и поведение проверяющих, а также подтверждает заявленную операционную выгоду. Форум по управлению решает, сохранить, расширить, сузить или отозвать полномочия.
При расширении следует повторно использовать контур управления, одновременно повторяя анализ сценариев использования. Общая архитектура идентификации, политик, доказательств и мониторинга может снизить предельные затраты на внедрение. Для каждого нового процесса по-прежнему нужны собственная оценка решений, данных, последствий и юридических аспектов.
Полномочия расширяются через контрольные точки на основе доказательств — от достоверного понимания процесса к ограниченной промышленной эксплуатации.
18. Оценивайте контроль, операционную ценность и стоимость предприятия
Карта показателей должна отличать техническую активность от бизнес-результата. Вызовы инструментов, токены и задержка модели могут помочь в планировании мощностей. Они не доказывают, что процесс улучшился. Совету директоров нужны доказательства по времени цикла, объёму незавершённой работы, ошибкам, переделкам, срокам движения денежных средств, качеству обслуживания, исключениям контроля, инцидентам и высвобожденной мощности.
Показатели контроля должны включать отказы при попытках несанкционированных действий, частоту эскалации, полноту доказательств, предотвращение дублей, расхождения при сверке, обходы согласований, исправления после действий, события безопасности, события конфиденциальности, изменения поставщиков и время восстановления. Низкая частота отказов полезна только при эффективных полномочиях и мониторинге.
Ценность следует измерять относительно сверенной базовой линии. Трудовую мощность можно оценить по наблюдаемому объёму и времени обработки, а затем подтвердить фактическими изменениями ролей и рабочей нагрузки. Денежные эффекты должны сверяться с транзакциями и банковскими или учётными данными. Предотвращённые потери следует указывать осторожно и подкреплять наблюдаемыми инцидентами или документально оформленной моделью рисков.
Стоимость предприятия может расти за счёт устойчивой экономии затрат, ускорения конверсии денежных средств, лучшего обслуживания клиентов или поставщиков, более сильного контроля, более масштабируемых операций и снижения операционного риска. Доказательства по сделкам должны показывать, что выгода сохраняется, зависит от контролируемой инфраструктуры и выдерживает смену ключевых сотрудников или поставщиков. Покупатели и кредиторы могут дисконтировать выгоду, которая опирается на непрозрачную систему или слабые доказательства.
Коммерческая реализация должна связывать диагностику с исполнением. Внешние консультанты могут поддерживать картирование процессов, разработку бизнес-кейса, архитектуру контроля, управление внедрением, выбор поставщиков, финансовое моделирование и отчётность для совета директоров. Специализированные юридические вопросы, защита данных, кибербезопасность, аудит, трудовые отношения, бухгалтерский учёт и регуляторные вопросы должны выполняться квалифицированными консультантами. Успех должен подтверждаться принятыми результатами, подписанными мандатами, полученными вознаграждениями и устойчивыми результатами клиентов.
Таблица 6. Карта показателей совета директоров по контролируемому внедрению агентов
| Аспект | Основные доказательства | Показатель для совета директоров | Триггер эскалации |
|---|---|---|---|
| операционный результат | документирование процесса и транзакций | время цикла, бэклог, ошибки, переделки и обслуживание | результат ухудшается сверх установленного допуска |
| полномочия и политика | журналы идентификации, политик и вызовов инструментов | отклонённые, одобренные и выполненные действия по уровням риска | действие выходит за пределы допустимого |
| доказательства и одобрение | досье и решение проверяющего | полнота, переопределение, исправление и давность | существенное действие не имеет доказательств, позволяющих восстановить его |
| безопасность и конфиденциальность | оповещения, инциденты и журнал доступа | события, подверженность, локализация и время восстановления | предполагаемая компрометация данных, учётных данных или целостности |
| финансовая ценность | доказательства по базовому уровню, реестру, денежным средствам и ресурсным возможностям | регулярная выгода, сроки денежных потоков и стоимость эксплуатации | заявленная выгода не может быть сверена |
| устойчивость и зависимость | записи о поставщике, непрерывности и изменениях | концентрация, сбои при изменениях и готовность к резервному варианту | критически важная услуга не имеет действенных механизмов локализации или резервного варианта |
Целевые показатели представляют собой примеры управленческих решений и подлежат утверждению для каждого процесса и уровня риска.
Вывод по внедрению
AI агенты могут улучшить бэк-офис компаний среднего рынка, если полномочия спроектированы с той же тщательностью, что и рабочий процесс. Практическая последовательность начинается со сверенной инвентаризации процессов и решений, выбирает минимально полезный уровень автономности, определяет явный контур полномочий и наделяет каждого агента отдельной идентичностью. Вероятностная интерпретация окружена детерминированной политикой, валидацией и сверкой.
Утверждение человеком сосредоточено на последствиях и обратимости. Данные, инструменты, промпты, память и поставщики остаются в пределах установленных границ доверия. Тестирование развивается от офлайн-доказательств через песочницу, теневой режим и ограниченную промышленную эксплуатацию. Журналирование позволяет восстанавливать ход существенных действий, а независимые механизмы аварийной остановки и восстановления локализуют сбои.
120-дневная программа может создать контур управления и продемонстрировать операционную ценность в одном узком процессе. Расширение следует тем же контрольным точкам для каждого дополнительного сценария использования. Это даёт совету директоров доказательства как по производительности, так и по риску, и создаёт более надёжную основу для масштабируемой, готовой к сделкам стоимости предприятия.
Источники
- Национальный институт стандартов и технологий. AI Структура управления рисками, включая AI RMF 1.0, Плейбук и Профиль генеративного искусственного интеллекта. https://www.nist.gov/itl/ai-risk-management-framework
- Национальный институт стандартов и технологий. Структура управления рисками искусственного интеллекта: Профиль генеративного искусственного интеллекта, NIST AI 600-1, июль 2024 г. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- Национальный институт стандартов и технологий. AI Инициатива по стандартам для агентов, создана 17 февраля 2026 г. и обновлена 20 апреля 2026 г. https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
- Дубайский международный финансовый центр. Регламент 10 об обработке персональных данных с использованием автономных и полуавтономных систем. https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/regulation-10
- Дубайский международный финансовый центр. Руководство по защите данных для целей соответствия, включая обработку персональных данных с использованием автономных и полуавтономных систем. https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/guidance
- Национальный центр кибербезопасности Великобритании. Руководящие указания по безопасной разработке систем AI, 27 ноября 2023 г. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
- Европейская комиссия. Нормативно-правовая база Закона AI и график его применения, обновлено в июле 2026 г. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- Европейская комиссия. Обязательства по обеспечению прозрачности для поставщиков и развёртывающих организаций определённых систем AI, 20 июля 2026 г. https://digital-strategy.ec.europa.eu/en/news/commission-publishes-guidelines-transparency-obligations-providers-and-deployers-certain-ai-systems
- Управление по финансовому регулированию и надзору и Банк Англии. Искусственный интеллект в финансовых услугах Великобритании: результаты опроса 2024 года. https://www.fca.org.uk/publications/research-notes/ai-uk-financial-services
- ОЭСР. Принципы ОЭСР по AI, приняты в 2019 г. и обновлены в 2024 г. https://www.oecd.org/en/topics/ai-principles.html
- Комиссия Сингапура по защите персональных данных. Подход Сингапура к управлению AI и типовая модель управления AI. https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
- Международная организация по стандартизации. ISO/IEC 42001:2023, системы менеджмента искусственного интеллекта. https://www.iso.org/standard/42001
- Агентство по кибербезопасности и защите инфраструктуры. CISA и NCSC Великобритании представили совместные руководящие указания по безопасной разработке систем AI, 26 ноября 2023 г. https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development
Об авторе
Ченнакешав Адья — независимый исследователь и управляющий партнёр в Matchpoint Partners. Его работа сосредоточена на корпоративных финансах, стратегии капитала, исполнении сделок и операционных системах, которые связывают финансовые подтверждения, решения совета директоров и измеримые показатели деятельности предприятия.
