Технологии

Даже Google не успевает за рисками ИИ: что вскрыл новый спор вокруг безопасности

RusPhotoBank

ИИ меняет безопасность быстрее, чем компании успевают перестраиваться

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

COO Google Cloud Фрэнсис де Соуза в беседе с TechCrunch обозначил главный принцип, который бизнесу придется принять без отсрочек: безопасность нельзя добавлять к ИИ-проектам после запуска. По его словам, компаниям нужен платформенный подход, при котором защита, управление и возможность аудита закладываются с самого начала.

«Теневой ИИ» становится новой зоной риска

Одной из проблем де Соуза назвал так называемый shadow AI — ситуацию, когда сотрудники используют потребительские ИИ-инструменты без контроля со стороны организации. В таких условиях компания теряет понимание того, какие данные куда попадают и кто отвечает за безопасность процессов.

Логика Google Cloud здесь проста: ИИ-стратегия не может существовать отдельно от стратегии работы с данными и кибербезопасности. Эти направления должны развиваться вместе, иначе бизнес рискует получить мощные инструменты без достаточного контроля над ними.

Один облачный провайдер — иллюзия для большинства компаний

При этом де Соуза подчеркивает, что речь не только о продвижении Google Cloud. Он говорит о мультиоблачной реальности: даже если компания формально выбирает одного поставщика, она всё равно пользуется SaaS-сервисами, взаимодействует с партнерами и зависит от систем, которые могут работать в других облаках.

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

Атаки ускорились до машинной скорости

По оценке де Соузы, старые модели защиты уже не соответствуют темпу современных атак. Он привел пример: среднее время между первичным взломом и передачей атаки на следующий этап сократилось с восьми часов до 22 секунд.

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

Старые данные могут внезапно стать видимыми

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

Теперь такие активы могут быть обнаружены автоматически. И если права доступа давно не обновлялись, ИИ-инструменты способны вывести на поверхность данные, которые организация считала фактически недоступными.

Защита тоже становится агентной

Ответом на машинную скорость атак де Соуза считает машинную скорость защиты. По его словам, компании уже движутся к AI-native и полностью агентным системам обороны, где люди не управляют каждым действием вручную, а контролируют работу автоматизированной защиты.

Это меняет и уровень ответственности. Безопасность ИИ перестает быть задачей только профильной команды: она становится вопросом для руководства и совета директоров.

Дефицит специалистов и «bug-pocalypse»

Даже если ИИ берет на себя часть оборонительной работы, людей, способных правильно контролировать такие системы, не хватает. На это указывает и CISO LinkedIn Ли Кисснер, которая в комментарии The New York Times предупредила, что индустрии понадобятся специалисты для работы с волной уязвимостей, а устойчивое понимание ИИ-безопасности может формироваться еще несколько лет.

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

Случаи с Gemini и API-ключами ударили по разработчикам

Эксперты TechCrunch ссылаются на серию публикаций The Register о разработчиках Google Cloud, которые получили крупные счета после несанкционированных API-запросов к моделям Gemini. В ряде случаев речь шла о сервисах, которые пользователи не применяли намеренно и не считали включенными.

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

Один из пострадавших, глава платформы Prentus Род Данан, получил счет на $10 138 примерно за 30 минут после эксплуатации скомпрометированного ключа. Другой разработчик, Исури Фонсека из Сиднея, столкнулся с начислениями примерно на 17 000 австралийских долларов, хотя считал, что у него действует лимит расходов в $250.

Автоматические лимиты и спор о приоритетах

Оба разработчика, по данным статьи, не знали, что автоматические системы Google могли повысить их биллинговые уровни на основе истории аккаунта — вплоть до эффективного потолка в $100 000 без явного согласия.

После публикации The Register Google вернула деньги обоим пользователям. Но компания также сообщила, что не планирует менять политику автоматического повышения уровней, объясняя это приоритетом бесперебойной работы сервисов над жестким соблюдением заявленных бюджетных предпочтений.

Удаленный ключ не всегда сразу перестает работать

Еще одна проблема касается скорости отзыва скомпрометированных ключей. The Register сообщил об исследовании компании Aikido, согласно которому даже после удаления ключа злоумышленники могут продолжать использовать его до 23 минут, пока отзыв постепенно распространяется по инфраструктуре Google.

Исследователь Aikido Джозеф Леон отметил, что в отдельные минуты этого окна более 90% запросов всё еще могли проходить аутентификацию. По его оценке, это время можно использовать для вывода файлов и кэшированных данных разговоров из Gemini. Он также указал, что более новые форматы учетных данных Google отзываются быстрее: service account API credentials — примерно за пять секунд, а новые Gemini-ключи с префиксом AQ — около минуты.

Главный вывод: советы верные, но разрыв остается

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

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