Кибербезопас
ность
для бизнеса
в эпоху ИИ

Какие риски ИИ создает
внутри компании

Внутренние риски использования искусственного интеллекта редко обсуждаются так же громко, как внешние атаки, но на практике они встречаются намного чаще и приводят к вполне конкретному ущербу.

Утечки данных
через публичные
нейросети

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

ИИ как инструмент атакующих

Если внутренние риски связаны с тем, как сотрудники сами используют ИИ, то вторая сторона медали — то, как искусственный интеллект в кибербезопасности используется противоположной стороной, то есть атакующими.

Искусственный интеллект и кибербезопасность пересекаются здесь в нескольких конкретных сценариях:

• Фишинг нового поколения.ИИ генерирует персонализированные фишинговые письма, которые учитывают публичную информацию о конкретном сотруднике и компании, — без типичных ошибок, которые раньше помогали распознать подделку.
• Дипфейки.Синтезированные голос и видео используются для имитации руководителей компании — например, для запроса срочного перевода средств от имени директора в разговоре, который звучит абсолютно убедительно.
• Автоматизация и масштабирование атак.То, что раньше требовало ручной работы команды злоумышленников, теперь автоматизируется: ИИ в информационной безопасности работает и на стороне защиты, и на стороне нападения одновременно, а значит, сканирование инфраструктуры на уязвимости, подбор паролей и составление персонализированных сценариев атак происходит быстрее и в большем масштабе, чем раньше.

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

Особенность этих сценариев в том, что они целятся не в техническую инфраструктуру, а в человеческое доверие и привычные социальные паттерны — узнавание голоса руководителя, доверие к грамотно написанному письму, привычку быстро реагировать на просьбу коллеги. Технические средства защиты (спам-фильтры, антифишинговые системы) остаются нужными, но перестают быть достаточными сами по себе: без параллельного обучения сотрудников распознавать именно эти новые, более убедительные формы обмана, техническая защита закрывает только часть периметра.

Почему полный запрет ИИ не работает

Логичная на первый взгляд реакция руководства на перечисленные риски — просто запретить сотрудникам использовать нейросети в работе. На практике этот подход почти всегда дает обратный эффект.

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

Что делать
бизнесу —
от запрета
к управляемому
внедрению

Рабочая альтернатива запрету — не полная свобода, а управляемое внедрение с понятными правилами. Практический путь состоит из четырех шагов.

• Аудит используемых ИИ-инструментов.Прежде чем формулировать любые правила, нужно понять реальную картину: какие нейросети и ИИ-сервисы сотрудники уже используют в работе — легально через корпоративные инструменты или неофициально через личные аккаунты. Без этой картины любая политика строится на догадках.
• Политика использования.На основе аудита формулируются конкретные правила: какие категории данных запрещено передавать в публичные сервисы, какие инструменты одобрены компанией, какой процесс проверки нужен для кода, сгенерированного ИИ, перед тем как он попадет в продакшн.
• Контроль доступа ИИ-агентов к данным.Отдельная задача кибербезопасности — не только контроль людей, но и контроль самих ИИ-систем: если в компании внедрены автономные агенты, работающие с внутренними данными, им нужен такой же строгий контроль доступа, как и сотруднику — принцип минимальных прав применяется к ИИ ровно так же, как к любой учетной записи.
• Обучение сотрудников.Финальный и, возможно, самый важный элемент — люди должны понимать не абстрактную угрозу, а конкретные сценарии: почему нельзя вставлять данные клиента в чат-бота, как отличить сгенерированный ИИ фишинг, что делать при подозрении на дипфейк-звонок от «руководителя».

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

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

Как
безопасность
учитывается
при разработке
ИИ-решений

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

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