В компании появляются агенты разных команд и поставщиков
AI governance
Безопасность, контроль и аудит ИИ-агентов
Помогаю собственнику определить полномочия AI-систем, проверить источники, права и журналы, установить человеческое подтверждение и критерии безопасной остановки.
В интересах собственникаКонтроль данных и правИзмеримый результат
Личная ответственность за архитектуру
Виталий Дильдин — ИИ-архитектор и советник собственника
- В IT с 2003 годаCRM · ERP · WMS · BI · интеграции · прикладной AI
- На стороне результатаЗадача, данные, права, тесты, приёмка и промышленный переход
Прямой контакт
Опишите задачу одним выбором — отвечу лично
Достаточно выбрать ближайшую задачу, указать имя и один удобный контакт. Доступы, документы и конфиденциальные данные на этом шаге не нужны. Срок и точный объём подтверждаются после проверки систем, данных и границ доступа.
Разбор решения
Кто принимает решение, когда агент действует неправильно
Матрица прав описывает допустимое действие. Управление агентом дополнительно определяет владельцев, пересмотр изменений и восстановление после ошибки. Разберём учебный инцидент: агент создал две задачи по одному событию.
Отделите техническую остановку от решения по процессу
Владелец инструмента блокирует новые записи и подтверждает состояние очереди. Владелец процесса разбирает, какие задачи уже переданы сотрудникам и можно ли продолжать вручную. Ответственный за инцидент связывает входное событие, попытки и фактические объекты. Удалять всё созданное агентом без разбора нельзя: среди записей может быть уже выполненная сотрудником работа.
Проверьте масштаб и причину на доказательствах
Сравните устойчивые идентификаторы событий, версии сценария и результаты внешнего сервиса. Две строки журнала не обязательно означают два действия: это могут быть повторная попытка и подтверждение прежнего результата. И наоборот, одна строка «успех» не исключает дубль в принимающей системе. Для вывода нужны объекты назначения и связь с операцией, а не только ответ модели.
Возобновляйте работу по отдельному решению
Перед продолжением определите судьбу каждой незавершённой операции, исправьте причину и повторите тесты на дубль, тайм-аут и остановку. Технический специалист подтверждает исправление, владелец процесса — допустимый режим работы, уполномоченный руководитель — условия возобновления. Смена модели или нового инструмента после инцидента проходит через такую же проверку изменений.
Проверьте изменение по объектам и последствиям
Сравните версии инструмента, набор полей, получателей, используемые данные и права учётной записи. Владелец процесса подтверждает смысл действия, владелец интеграции — реальное ограничение инструмента. До проверки новая версия остаётся в тестовом контуре.
Образец карточки инцидента DEMO-INC-01
Учебный образец. Перенесите структуру в рабочий документ и замените исходные условия своими.
- Наблюдение
- По одному событию обнаружены две фактические задачи; границы затронутой очереди уточняются.
- Первое действие
- Новые записи остановлены, ручная очередь доступна; идентификаторы и версии сохранены.
- Ответственные
- Владелец инструмента — блокировка; владелец процесса — незавершённая работа; ответственный за инцидент — доказательства.
- Условие возврата
- Причина устранена, повторные проверки пройдены, спорные операции разобраны, решение о запуске записано.
Пересмотр разрешения после изменения инструмента
Учебная ситуация: агенту разрешено создавать внутреннюю задачу. В новой версии инструмента появился дополнительный получатель уведомления. Старое согласование не описывает этот новый эффект. Артефакт пересмотра содержит предыдущую и новую версии, разницу полномочий, тест запрета и решение владельца. Изменение промпта не заменяет проверку реальных прав инструмента.
| Проверка | Наблюдение в учебном примере | Решение и доказательство |
|---|---|---|
| Прежнее действие | Создаётся задача без внешнего уведомления. | Сохранить номер действующей политики и проверенный запрос. |
| Новый побочный эффект | Инструмент теперь отправляет уведомление внешнему адресату. | Старое разрешение недостаточно; запретить эффект или принять новую границу. |
| Проверка ограничения | Поле получателя убрано из интерфейса, но доступно в API. | Проверить серверное ограничение; скрытое поле не считается защитой. |
| Отзыв разрешения | Политика отозвана, часть заданий стоит в очереди. | Остановить ещё не выполненные действия и сверить уже выполненные отдельно. |
Коротко
Технология встроена в бизнес, а не существует отдельно
Контроль ИИ-агента начинается с явного описания его роли и допустимых действий. Чем выше автономность и цена ошибки, тем сильнее должны быть идентификация, журналирование, тестирование и подтверждение человеком. Одинаковый регламент для помощника, который только читает документы, и агента, который меняет данные в ERP, создаёт ложное чувство безопасности.
Открытый артефакт
Паспорт ограничивает роль агента до начала разработки
HTML-превью показывает состав документа. В проекте значения заполняются для конкретного процесса, систем и цены ошибки.
Паспорт AI-агентаШаблон · проверяется до пилота
- 01 · Задача и пользователь
- Какой процесс поддерживает агент и кто запускает сценарий
- 02 · Владелец результата
- Кто отвечает за бизнес-метрику и принимает работу
- 03 · Источники
- Какие данные разрешено читать, с какой версией и владельцем
- 04 · Инструменты и действия
- Какие API доступны, что можно записывать и где нужен человек
- 05 · Запреты
- Какие решения, данные и операции исключены из полномочий
- 06 · Контрольная выборка
- На каких примерах измеряются качество, отказ и цена ошибки
- 07 · Журналирование
- Какие шаги, источники, подтверждения и ошибки сохраняются
- 08 · Остановка и откат
- Как отключить агент, отменить действие и перейти на ручной маршрут
- 09 · Критерии приёмки
- Какие пороги качества, скорости и стоимости подтверждают этап
Кому подходит
Когда направление имеет практический смысл
Нужно принять существующий AI-проект или проверить подрядчика
Агент получает доступ к документам, CRM, финансам или другим критичным системам
Когда не подходит
- Нужен формальный документ без технической проверки
- Нет владельца риска и полномочий исправлять найденные проблемы
- Компания ожидает абсолютную безопасность без ограничений и наблюдаемости
Проблема
Почему простое подключение модели не становится внедрением
Непонятно, кто и за что отвечает при ошибке агента
Права доступа шире реальной задачи
Нет воспроизводимых тестов, журнала источников и способа остановить действия
Что входит в работу
От бизнес-задачи до контролируемой архитектуры
Классы автономности
Разделяю помощников, рекомендательные системы и действующих агентов по полномочиям и цене ошибки.
Права и идентичность
Проверяю учётные записи, секреты, минимальные права и разделение сред.
Тесты и наблюдаемость
Фиксирую набор проверок, источники, журналы, алерты и контроль изменений.
Остановка и ответственность
Определяю подтверждение, аварийную остановку, откат и владельцев решений.
Архитектура
Система целиком, а не только модель
Собственник должен видеть, где находятся данные, кто отвечает за результат, какие действия разрешены и как систему остановить или передать другой команде.
- 01Реестр AI-систем
- 02Роль и уровень автономности
- 03Идентичность и права
- 04Источники и инструменты
- 05Тесты и мониторинг
- 06Подтверждение, остановка и откат
Результат
Что получает собственник
Артефакты остаются у компании и позволяют независимо принять следующий этап.
- Реестр агентов и владельцев
- Матрица автономности, данных и рисков
- Проверка прав, секретов, журналов и источников
- Набор обязательных тестов и критериев приёмки
- План устранения рисков по приоритетам
Путь внедрения
Прототип доказывает возможность. Промышленная система обеспечивает результат
- 01
Инвентаризация
Собираем агентов, поставщиков и системы.
- 02
Классификация
Оцениваем автономность, данные и цену ошибки.
- 03
Проверка
Тестируем права, источники, журналы и остановку.
- 04
Регламент
Фиксируем владельцев и контроль жизненного цикла.
Границы ответственности
Что не обещаю без доказательств
- Аудит не заменяет юридическую экспертизу или аттестацию информационной безопасности
- Риски не скрываются общей оценкой: критические сценарии разбираются отдельно
- Безопасность поддерживается на всём жизненном цикле, а не проверяется один раз
Первый шаг
Запросить аудитАудит одного действующего AI-сценария
Проверим полномочия, источники, тесты и возможность безопасной остановки.
FAQ
Вопросы до старта
Что такое уровень автономности агента?
Это объём решений и действий, которые система может выполнять без подтверждения. Read-only помощник и агент с правом менять платежные данные требуют разных мер контроля.
Можно проверить решение подрядчика?
Да, если доступны архитектура, тестовый контур, журналы и договорённость о критериях. Результатом становится реестр рисков и требований к приёмке.
Достаточно ли запретить агенту опасные действия в промпте?
Нет. Ограничения должны обеспечиваться правами, кодом, инструментами и инфраструктурой, а не только текстовой инструкцией модели.
С чего начать управление ИИ в компании?
Управление ИИ в компании начинается с реестра систем, владельцев, данных и уровней автономности. Затем для каждого сценария фиксируются минимальные права, обязательные тесты, журналирование, подтверждение человеком и порядок остановки.
Предварительная диагностика
Начнём с одной проблемы и критерия результата
Если задачу рациональнее решить без ИИ, это будет зафиксировано до разработки.