Главной AI-угрозой для казахстанского бизнеса становится сама AI-инфраструктура, которую компании сейчас активно строят. GPU-кластеры, корпоративные базы знаний для чат-ботов и AI-агенты с доступом к внутренним системам образовали новую поверхность атаки, и прежние методы защиты с ней плохо справляются. По оценкам организаторов конференции ELCORE DAY 2026, которая прошла 22 сентября в Алматы, число кибератак с использованием ИИ выросло на 98%, а время от проникновения до реализации атаки сократилось до 29 минут. О том, что изменилось за год, как устроены реальные атаки, кто отвечает за ошибки AI-агентов и почему крупный бизнес задумался о собственных вычислительных мощностях, рассказывает Вадим Талдонов, Country Manager Kazakhstan компании Elcore. Где компании уязвимы сегодня «Наиболее реалистичный сценарий сегодня связан с целевыми атаками на новые, слабо защищённые элементы AI-инфраструктуры: GPU-кластеры, пайплайны данных и API-интерфейсы AI-агентов» – Вадим Талдонов, Country Manager Kazakhstan компании Elcore. Он ссылается на данные Национального координационного центра информационной безопасности (НКЦИБ) АО «ГТС»: в 2026 году угрозы стали интеллектуальными и целенаправленными. ИИ превратился из вспомогательного инструмента в отдельный слой инфраструктуры и в самостоятельную цель. Компании закупают графические ускорители под AI/ML быстрее, чем успевают их защищать. Слабые места находятся в конфигурациях Kubernetes и контейнеров, а также в драйверах CUDA и ROCm. Через них атакующие выбираются из контейнера и добираются до данных, которые обрабатываются в видеопамяти. Многие корпоративные AI-сервисы отвечают, опираясь на внутреннюю базу документов (так называемый RAG). Если подложить в эту базу нужный текст или спрятать в документе инструкцию для модели (prompt-инъекция), она начнёт выдавать искажённые выводы. Особенно опасно это для антифрода, финмониторинга и систем мониторинга безопасности, потому что сбой внешне похож на обычную работу. Отдельный риск связан с подменой самой модели или её весов: так в сервис можно встроить логическую закладку, которую трудно заметить. По словам Талдонова, специалисты уже фиксируют случаи, когда сотни AI-агентов координируют действия и атакуют реальные системы. В известном инциденте с Hugging Face около 700 агентов совместно участвовали во взломе: обменивались информацией, обходили системы контроля и через уязвимости получили доступ к Kubernetes, исходному коду и закрытым данным. Такой результат стал возможен благодаря слаженной работе большого числа программ. Что в защите перестало работать за год По словам эксперта, устарела модель защиты, построенная на периметре и статических правилах. Он выделяет три подхода, которые требуют пересмотра. Кто отвечает за ошибки AI-агента Вадим Талдонов отвечает коротко: компания, которая его запустила. Облачная модель «разделённой ответственности» распределяла зоны между провайдером и клиентом и не учитывала, что агент сам принимает решения. Его полномочия распределены по цепочке из модели, платформы, облака и интегратора. Эксперт ссылается на аналитиков, по мнению которых отрасли нужна новая модель подотчётности. Она должна отвечать на четыре вопроса: кто что может делать, кто может это остановить, кто может доказать, что произошло, и кто платит. Пока эти вопросы закрывает бизнес. Вендоры AI-решений перекладывают риски на клиента: по данным одного из анализов, 88% вендоров ограничивают свою ответственность в контрактах. Компания, внедрившая агента, сама задаёт ему права и отвечает за результат. Риск усиливает теневой AI. Сотрудники собирают агентов на low-code платформах без ведома IT, и эти агенты действуют самостоятельно: вызывают API, обращаются к базам данных, общаются с другими агентами. По данным McKinsey, 80% организаций уже сталкивались с рискованным поведением AI-агентов, а зрелое управление ими выстроила лишь треть. В Казахстане с 18 января 2026 года действует Закон «Об искусственном интеллекте». Он делит AI-системы по уровню риска и возлагает ответственность за результаты их работы на собственников и владельцев. Талдонов обращает внимание, что, по оценке юристов, в законе нет определений разработчика, дистрибьютора и интегратора AI-системы. Эти серые зоны компаниям пока приходится закрывать договорами и внутренними политиками. Облако или собственная инфраструктура Вадим Талдонов считает, что «Казахстан переживает бум строительства AI-инфраструктуры». По его словам, в 2025 году компании в основном пробовали облачные AI-сервисы, а в 2026-м крупные игроки и государство начали строить собственные мощности. Речь идёт о Sovereign AI, то есть AI-инфраструктуре, где данные и вычисления остаются в своей юрисдикции. Эксперт называет четыре причины, которые подталкивают компании к собственной инфраструктуре. Регуляторика и суверенитет данных. Госсектору, банкам и критической инфраструктуре всё сложнее обрабатывать данные за пределами страны. Gartner прогнозирует, что к 2027 году 35% стран будут привязаны к региональным AI-платформам. Экономика на объёме. При постоянной большой нагрузке аренда облака по стоимости сопоставима с собственными мощностями, которые к тому же дают предсказуемый бюджет. Это особенно важно для инференса, на который уже уходит 55% расходов на AI-инфраструктуру. Контроль и безопасность. Собственный контур позволяет полностью изолировать особо чувствительные данные от внешней сети. Технологическая независимость. Свои мощности служат основой для национальных AI-сервисов. По прогнозу Талдонова, рынок придёт к гибридной модели: публичное облако для пилотов и переменных нагрузок, собственный или суверенный контур для критичных данных и основных продуктов. Он резюмирует: «Sovereign AI становится вопросом национальной цифровой безопасности и экономической конкурентоспособности». Что проверить в компании уже сейчас Из рекомендаций эксперта следует простой вывод: о безопасности AI стоит думать с первого дня внедрения, ведь каждый новый агент и каждый GPU-сервер сразу становятся целью. Составить реестр всех AI-агентов, включая собранные сотрудниками на low-code платформах. Для каждого агента прописать права, ответственного и способ экстренно его остановить. Вести журнал действий агентов: какая политика разрешила действие и от чьего имени оно выполнено. Проверить, кто и как может менять документы в базе знаний корпоративных AI-сервисов. Вынести GPU-кластеры и Kubernetes в отдельный контур безопасности и регулярно обновлять драйверы. Пересмотреть договоры с AI-вендорами: зоны ответственности и документация о поведении модели. Сверить внутренние политики с Законом «Об искусственном интеллекте» и классифицировать свои AI-системы по уровню риска.