Как регулировать доступ ИИ к ERP-системам и финансовым системам

Основная проблема

ИИ-агенты и копилоты получают беспрецедентный доступ к данным ERP и финансовых систем, действуя с «машинной скоростью». Традиционные модели контроля, рассчитанные на людей, не работают.

Отсутствие управления создает риски: непрозрачные потоки данных, скрытые нарушения разделения обязанностей (SoD) и появление «призрачных» машинных идентификаторов, которые не отслеживаются и живут дольше проектов или сотрудников.

Три пути проникновения ИИ в ERP

• Встроенные копилоты ERP (например, от SAP или Oracle). Риск: они часто наделяются избыточными правами, а их активность не отделяется в логах от действий человека.
• Внешние ИИ-агенты через API. Риск: используют долгоживущие ключи и общие служебные учетные записи, что не позволяет атрибутировать действия и соблюдать SoD.
• Теневой ИИ (Shadow AI). Риск: выгрузка данных в Excel или BI-инструменты с последующим использованием в неконтролируемых ИИ-сервисах, что обходит все официальные каналы мониторинга.

Общий корень проблемы

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

Три принципа правильного управления (что такое «хорошо»)

• ИИ-агенты как полноценные идентификаторы (first-class identities). У каждого должен быть владелец, бизнес-цель и профиль риска, а не общая техническая учетка.
• Доступ на основе политик, а не разовых заявок. Выдача прав должна проходить через стандартные рабочие процессы с проверкой SoD.
• Сквозные, готовые к аудиту треки. Возможность в любой момент показать, где живет ИИ, к чему имеет доступ, кто одобрил и когда проводился последний обзор.

Жизненный цикл ИИ (JML — Joiner, Mover, Leaver)

• Joiner (Присоединение). Новый ИИ-кейс проходит предсказуемый путь: сбор требований, назначение ответственного владельца и классификация риска, выдача доступа строго по политике.
• Mover (Изменение). Любое расширение прав (новые коды компаний, доступ к проводкам) автоматически запускает переоценку рисков и новые согласования, не позволяя правам накапливаться.
• Leaver (Увольнение). При завершении проекта или истечении срока контракта все учетные данные ИИ (ключи, токены, роли) должны автоматически отзываться, а доказательства активности — сохраняться для аудита.

Практические шаги: чек-лист из 10 пунктов (краткое резюме для руководителей CISO, CFO)

• Создать единый реестр всех ИИ-идентификаторов.
• Назначить каждому владельца и категорию риска.
• Встроить ИИ в стандартные процессы JML.
• Определить политики доступа и правила SoD для ИИ.
• Заменить общие служебные аккаунты на управляемые ИИ-идентичности.
• Требовать согласования доступа ИИ к чувствительным данным по политике.
• Включить ИИ в регулярные кампании по ресертификации доступов.
• Включить непрерывный мониторинг активности ИИ и аномалий.
• Автоматически отзывать доступ при завершении проектов.
• Регулярно отчитываться перед комитетами по аудиту о метриках доступа ИИ.

Ключевая мысль: Управление доступом ИИ к ERP должно рассматриваться не как техническая проблема безопасности, а как проблема управления идентификациями (identity governance). Решение — распространить дисциплину, применяемую к привилегированным пользователям, на мир нечеловеческих и ИИ-идентичностей.

Источник - телеграмм-канал Data secrets