وزارة التنمية الرقمية الروسية والاتحاد الأوروبي وNIST يضعون قواعد جديدة لأمن AI وتنظيمه

Security Vision выпустила большой разбор о том, как вокруг ИИ быстро собирается новая система правил, стандартов и защитных практик. На первый план выходят не только законы, но и вполне прикладные вопросы: утечки данных, prompt injection, кража моделей и контроль над агентными системами.

Как регулируют ИИ В

России базовой точкой отсчёта остаётся указ № 490 от 10 октября 2019 года и обновлённая стратегия развития ИИ до 2030 года. Дальше появились экспериментальный режим в Москве, проект концепции регулирования ИИ до 2030 года от Минцифры и «Альянса в сфере ИИ», а также кодекс этики ЦБ для финансового рынка. Общий вектор понятен: стимулировать внедрение ИИ, но одновременно требовать прозрачности, защиты данных, управления рисками и человеческого контроля.

За рубежом рамка становится жёстче. В ЕС уже действует EU AI Act с делением систем на неприемлемый, высокий и обычный уровень риска: от прямых запретов для социального рейтинга и ряда биометрических практик до обязательных журналов, надзора человека и требований по кибербезопасности. США в 2025 году выпустили AI Action Plan с акцентом на ускорение инноваций, инфраструктуру и secure by design.

Китай усиливает маркировку AI-контента, Южная Корея и Казахстан приняли собственные законы, а ООН, ЮНЕСКО и БРИКС выстраивают международную площадку для общих правил.

Стандарты и контроль Параллельно с законами быстро растёт слой стандартов и фреймворков.

В ISO и IEC уже оформлены документы по терминологии, управлению рисками, жизненному циклу ИИ, оценке робастности и безопасности данных. В России им соответствуют новые ГОСТы, а в США NIST развивает AI Risk Management Framework, который стал одной из самых заметных практических схем для компаний. Логика у него простая: не спорить об ИИ в вакууме, а встраивать риски в обычное управление продуктом, безопасностью и разработкой.

Govern — назначить ответственных, политики и процессы по рискам ИИ Map — понять контекст, сценарии применения и потенциальный вред Measure — проверять надёжность, достоверность и эффективность защитных мер Manage — приоритизировать риски, снижать ущерб и документировать решения Отдельно формируется слой специализированных рамок: MITRE ATLAS каталогизирует тактики атак на ИИ, OWASP собирает критические риски для LLM и агентных систем, Google развивает SAIF, а крупные вендоры публикуют собственные safety- и preparedness-frameworks. Это важно по одной причине: безопасность ИИ больше не сводится к защите сервера или API. Теперь нужно оценивать поведение модели, качество данных, устойчивость к манипуляциям и последствия для пользователя.

Где ломают ИИ У ИИ своя поверхность атаки.

Большие языковые модели плохо различают данные и инструкции, поэтому вредоносный текст на веб-странице, в письме или документе может превратиться в команду для агента. Отсюда растут прямые и косвенные prompt injection-атаки, jailbreak, extraction и data poisoning. Если система подключена к почте, CRM, файловому хранилищу или внешним сервисам, цена ошибки резко растёт: атакующий может не просто получить странный ответ, а добраться до корпоративных данных или заставить агента выполнить нежелательное действие.

Вторая большая зона риска — сами данные. Компании всё чаще сталкиваются с Shadow AI, когда сотрудники без согласования загружают внутренние документы в публичные чат-боты. IBM приводила оценку, по которой 13% опрошенных компаний уже сообщали об утечках через ИИ.

Добавь сюда кражу API-ключей для LLM jacking, возможное копирование моделей через дистилляцию и проблему галлюцинаций на синтетических данных — и становится понятно, почему grounding, zero data retention, MLSecOps и DLP перестают быть опцией. Отдельный тренд — злоумышленники сами используют агентные инструменты для автоматизации взлома и снижения порога входа в киберпреступность.

Что это значит

Рынок ИИ входит в фазу, где выигрывает не тот, кто просто быстрее внедрил модель, а тот, кто умеет доказать её надёжность, объяснимость и безопасность. Для бизнеса это значит одну вещь: ИИ уже нельзя запускать как «ещё один SaaS-сервис» — ему нужны отдельные правила доступа, контроль данных, аудит интеграций и регулярная проверка на атаки.