71% сотрудников уже пользовались неутвержденными AI-инструментами на работе, а 51% делают это еженедельно. На этом фоне управление ИИ в облаке перестает быть темой для слайдов CISO и превращается в нормальную инженерную задачу: нужно понять, где у вас вообще живет ИИ, какие данные он ест и кто должен остановить его до того, как в модель улетит то, что туда улетать не должно.
Как пишет InfoQ, архитектор Dave Ward предлагает не очередной свод благих пожеланий, а вполне прикладную схему AI-governance для облака. Начинать он советует с инвентаризации реальных точек входа: CASB-системы вроде Microsoft Defender for Cloud Apps, Netskope и Prisma Access помогают увидеть обращения к OpenAI, Anthropic, Hugging Face и Azure OpenAI, а service mesh и API gateway дают картину по self-hosted моделям и внутренним сервисам. Логика простая: сначала перестать гадать, где именно в компании уже крутятся плагины, Copilot, LangChain-пилоты и «временные» ассистенты, которые незаметно стали частью продакшена.
Дальше начинается менее зрелищная, но куда более полезная часть. Ward прямо пишет: видимость еще не означает контроль. CASB покажет, что к api.openai.com вчера сходили 500 раз, но не скажет, какие данные ушли в запросах и какой сервис за это отвечал. Поэтому следующий слой — не запреты в стиле «всем нельзя», а обязательная классификация данных в момент создания. В статье перечислены нативные инструменты крупных облаков: AWS Macie, Microsoft Purview и Google DLP. Идея в том, что объект при записи сразу получает теги вроде DataClassification, ContainsPII, AIApproved и ComplianceScope. Тогда AI-сервис работает не с безымянным бакетом или таблицей, а с данными, у которых уже есть статус: публичные, внутренние, конфиденциальные, запрещенные для ИИ.
Это особенно важно не в теории, а в типичном корпоративном бардаке. Ночные batch-сканы, к которым многие привыкли в data governance, для AI-нагрузок уже не годятся: модель или пайплайн может начать читать данные раньше, чем классификатор до них доберется. Поэтому Ward делает акцент на классификации при записи и на автоматизации через события хранилища, Lambda-функции и DLP/PII-проверки. Если в файле нашлись персональные данные или чувствительный контент, он не просто получает красивую метку для аудитора, а помечается как неразрешенный для ИИ. Это тот редкий случай, когда «теги в облаке» действительно меняют поведение системы, а не украшают презентацию отдела безопасности.
Ключевая мысль статьи — ограничивать надо не модель как таковую, а путь данных к ней. Для этого автор предлагает опираться на IAM-политики и VPC-контроли. В примере с AWS доступ к объектам без тегов блокируется, чтение данных без признака AIApproved тоже блокируется, а отдельные категории вроде Restricted запрещены для AI-сервисов целиком. Дополнительно доступ можно разрешать только конкретной сервисной роли и только через нужный VPC endpoint. Для архитекторов и платформенных команд это важный разворот: вместо бесконечной охоты за каждым новым AI-эндпоинтом правила встраиваются в инфраструктурный слой, где их сложнее обойти «на пять минут ради эксперимента».
Поверх IAM Ward предлагает поднимать policy-as-code. В статье в качестве базового инструмента упоминается Open Policy Agent, а также AWS Cedar и Sentinel от HashiCorp. Их задача — описывать уже не простое «можно/нельзя», а более живые правила: модель зарегистрирована или нет, как давно проводился security scan, можно ли использовать данные определенного возраста, нужен ли отдельный approval для продакшена. По сути, управление ИИ в облаке переезжает в тот же CI/CD-контур, где у команды уже живут Terraform, тесты и ревью. Плохая новость для любителей ручных согласований в Excel: такой подход требует аккуратно настраивать правила, иначе можно либо устроить утечку, либо парализовать разработку. Хорошая новость в том, что политики становятся версионируемыми, тестируемыми и откатываемыми, как обычный код.
Наконец, автор разбирает операционный слой, и здесь статья попадает в нерв большинства крупных команд. Технологии сами по себе не спасают, если registry моделей никто не ведет, approval-процессы превращаются в очередь на неделю, а мониторинг живет отдельно от инцидентов. Ward предлагает делать registry полезным для инженеров, а не только для комплаенса: регистр модели должен хранить происхождение обучающих данных, статусы сканов, approvals, настройки мониторинга и историю инцидентов. При этом low-risk сценарии — например, модели с публичными данными в dev-среде — можно пропускать автоматически, а ручную проверку оставлять только для действительно чувствительных кейсов. Иначе теневой ИИ никуда не денется: люди просто пойдут в обход, как это уже происходит с shadow IT.
Для русскоязычной IT-аудитории здесь, пожалуй, самый неприятный, но полезный вывод такой: управление ИИ в облаке — это не покупка одного «AI security» продукта и не запрет на ChatGPT приказом по компании. Это скучная, но обязательная сборка из инвентаризации, тегирования, IAM, policy-as-code и наблюдаемости, встроенной в delivery pipeline. Вопрос теперь не в том, появится ли у компаний теневой ИИ, а в том, кто раньше превратит его из неконтролируемого зоопарка в управляемую часть платформы.