ИИ вне периметра: новые риски для транспортных компаний
Транспортные компании приступили к активному внедрению генеративного искусственного интеллекта в повседневную работу. Он помогает автоматизировать составление заявок, обрабатывать данные пассажиров, прогнозировать нагрузку на маршруты, оптимизировать диспетчеризацию и координацию работы подрядчиков. Одновременно ИИ меняет привычную картину угроз для объектов транспортной отрасли включая объекты критической информационной инфраструктуры (КИИ). Об этом – в материале Айдара Фатыхова, владельца продукта Innostage AIDR «Защита ИИ»
Как ИИ меняет модель угроз
Глубина ИИ-интеграций растет. То, что начиналось как удобный помощник для оптимизации бизнес-процессов, быстро превращается в обширную зону рисков.
Генеративный ИИ меняет модель угроз. Раньше основные угрозы приходили извне, через взломы, вредоносное ПО или фишинг. Сейчас чувствительные данные могут уходить в процессе повседневной работы без какого-либо злого умысла. И здесь важно понимать, что чем выше автономность системы искусственного интеллекта, тем выше цена любой ошибки, неточности или утечки данных.
В транспортной сфере эта чувствительность особенно высока. Несанкционированное разглашение расписания движения, данных о грузах, персональной информации пассажиров, коммерческих условий сделок или метаданных заказов, все это может повлиять на операционные процессы и устойчивость объектов транспортной инфраструктуры.
Почему классический ИБ-контур не видит часть рисков
Классические инструменты информационной безопасности (DLP, NGFW, WAF, SIEM) хорошо справляются с файлами, очевидными шаблонами угроз и привычными каналами передачи данных. Проблема в другом. ИИ-модель создает новый тип движения информации, для анализа которого не хватает контекста.
Реальная картина риска остается размытой. В журналах системы мониторинга и анализа событий безопасности (SIEM) фиксируется штатный вызов, и трафик идет по HTTPS к разрешенному домену, что выглядит полностью легитимным. Система предотвращения утечек (DLP) способна отловить явные угрозы. Но промпт, контекстное окно, память ИИ-агента или сгенерированная сводка данных часто проходят мимо.
Например, запрос к ИИ-агенту «обобщи ситуацию по клиенту за квартал» может вызвать обращение к внешнему API и вынести часть контекста за периметр безопасности, или вернуть данные из CRM, почты и внутренних документов, которые в исходном виде были защищены метками конфиденциальности.
Поэтому нужны дополнительные механизмы, такие как ИИ-файрвол и гардрейлы на входе и выходе, которые анализируют смысл и содержание запроса, а не только его сигнатуры.
Реальные сценарии нарушений в транспортных компаниях
ИБ-инциденты возникают чаще всего потому, что ИИ стал рабочим инструментом раньше, чем компании успели описать правила его использования.
Первый сценарий — работа с публичными сервисами. Например, разработчик ПО для устранения бага копирует в запрос фрагмент кода. Вместе с ним в промпт попадают конфигурации, токены, параметры внутренних сервисов и логика авторизации. Или сотрудник юридического отдела просит ИИ сократить договор и вставляет его полностью, включая условия сделки, реквизиты и коммерческие договоренности.
Второй сценарий — корпоративный ИИ-ассистент. Сотрудник спрашивает: «Какие условия мы давали клиенту X в прошлом году?» Ассистент находит релевантный контекст в базе знаний компании и отвечает. Но вместе с ответом может отдать фрагмент закрытого регламента или персональные сведения.
Третий сценарий — автоматизация и ИИ-агент. Аналитик ставит задачу подготовить сводку перед встречей, а агент собирает и обобщает данные из разных систем. Внешне все выглядит как обычная автоматизация, но в процессе агент может обратиться к избыточным данным или отправить часть контекста через внешний API.
Отдельный слой рисков создают технологии, которые «подключают» искусственный интеллект к личным документам или закрытым базам данных (RAG-сценарии). А также векторные хранилища, где конфиденциальный документ может быть разбит на фрагменты, проиндексирован и сохранен. В таком виде данные уже не выглядят как исходный документ, но все равно остаются частью контура обработки чувствительной информации.
Для транспортной компании подобные утечки оборачиваются не только штрафами по Закону «О персональных данных» №152-ФЗ, но и проблемами с контрагентами, репутационными потерями и прямым влиянием на стоимость услуг и конкурентоспособность.
Регуляторный ландшафт
Приказ ФСТЭК №117 запрещает передавать разработчику ИИ информацию ограниченного доступа, требует определять допустимые тематики контента, а также настраивать правила детектирования нарушений во входящих и исходящих потоках данных ИИ-системы.
В дополнение, требования Росстандарта ПНСТ №1046-2026 задает для субъектов КИИ ориентир по оценке систем искусственного интеллекта: уровень критичности, степень автономности, глубина интеграции в критические процессы, мониторинг и реагирование.
Для транспортных компаний, работающих с государственными заказчиками, требования распространяются также и на подрядные организации.
Особенности расследование ИИ-инцидентов
Расследование в распределенной транспортной инфраструктуре имеет свои особенности. Инцидент нужно оценивать не только как утечку данных или ошибку модели, но и понимать, какую роль ИИ-система играет в бизнес-процессах. Например, дает рекомендации или уже влияет на диспетчеризацию, логистику, расписание, обработку персональных данных.
Без полной записи промпта, контекста, ответа модели и вызванных инструментов расследование часто сводится к версиям. Нужно понимать смысловой контекст обработки: кто отправил запрос, что было в контекстном окне, какие данные использовались, что модель вернула, какие инструменты вызвал агент и с какими параметрами. Семантический анализ событий здесь выходит на первый план. Он позволяет присваивать инциденту правильный уровень критичности. При этом информационный шум отсеивается, а скрытые вредоносные инструкции (prompt injection) или утечки конфиденциальных данных сразу попадают в зону внимания SOC-аналитика.
При расследовании нужно разделять причины. Если сотрудник нарушил явно установленную политику — это один сценарий. Если утечка произошла из-за архитектуры, избыточных прав агента, отсутствия фильтрации или неправильной настройки корпоративного ИИ — это вопрос к владельцу системы и процессу ее внедрения. В международной практике уже есть пример, когда канадская авиакомпания Air Canada была признана ответственной за предоставление недостоверных данных от чат-бота с искусственным интеллектом на своем веб-сайте.
Полный запрет на использование ИИ-моделей редко дает долгосрочный эффект. Под давлением сроков люди почти всегда переходят на личные аккаунты и мобильные приложения. Поэтому безопасный путь должен быть самым удобным для сотрудников и встроенным прямо в рабочие процессы. Эффективнее предоставить команде корпоративный ИИ-инструмент, желательно локальный, с полноценными средствами защиты. Для этого важно сформулировать политику допустимого использования, провести полную инвентаризацию сервисов и ИИ-агентов, обеспечить фильтрацию промптов и ответов, соблюдать принцип минимальных привилегий, организовать детальное логирование с передачей событий в SIEM и ввести отдельные плейбуки реагирования на ИИ-инциденты.