Автор темы
Сотруднику банка не обязательно взламывать сервер, чтобы создать киберугрозу. Порой достаточно загрузить клиентскую таблицу в публичный чат‑бот и попросить его подготовить выводы. Так возникает теневой ИИ — сотрудники используют генеративные модели, AI‑сервисы и плагины без согласования с ИТ‑службой, информационной безопасностью и комплаенс‑подразделением. Внешне это кажется обычной оптимизацией рабочих процессов.
Однако вместе с промптом за пределы корпоративного контура могут уйти персональные данные, платёжные реквизиты, сведения о кредитной истории, внутренний код или детали сделки. Для банков и финтех‑компаний проблема особенно актуальна: они работают с большими объёмами чувствительной информации и при этом стремятся ускорить операции, аналитику и обслуживание клиентов.
Просто запретить все внешние инструменты недостаточно: сотрудники всё равно будут искать удобные решения. В результате корпоративные правила рискуют стать формальностью, не имеющей реального влияния. Поэтому бизнесу важно не бороться с ИИ, а выстроить контролируемую среду.
В такой среде разрешённые модели, системы предотвращения утечек данных, разграничение доступа и обучение сотрудников действуют как единая система. Их совместная работа должна быть реальной, а не сводиться к имитации активности каждого элемента по отдельности.
Проблема начинается тогда, когда компания не знает, какой инструмент используется, какие данные в него передаются и что происходит с ними после обработки. К теневому ИИ относятся публичные чат-боты, личные аккаунты в корпоративной работе, сервисы для расшифровки звонков, генераторы презентаций и документов, инструменты анализа таблиц, браузерные плагины и расширения.
В эту же категорию попадают ИИ-помощники, подключённые к корпоративным системам, внешние программные интерфейсы и локальные модели, которые не прошли проверку ИТ и информационной безопасности. Даже технически надёжный и легальный сервис остаётся теневым ИИ, если организация не контролирует его использование.
Это касается прав доступа, настроек хранения данных и возможных интеграций с другими системами. Когда ни один из этих параметров не отслеживается, даже безобидный на первый взгляд инструмент превращается в неконтролируемый канал утечки информации.
Ситуация примечательна отсутствием типичных признаков кибератаки: не было внешнего взлома, вредоносного кода и сбоев в работе сервисов. Клиенты сохраняли доступ к счетам и платёжным инструментам, основная ИТ‑инфраструктура функционировала в штатном режиме. При этом 7 мая материнская компания CB Financial Services признала инцидент существенным — из‑за объёма и чувствительности переданных данных.
11 мая CB Financial Services раскрыла сведения в форме 8‑K, направив уведомление в Комиссию по ценным бумагам и биржам США. Компания запустила расследование, провела оценку затронутых данных и начала информировать клиентов и регуляторов. Этот случай стал наглядным примером рисков эпохи теневого ИИ.
Два дня спустя компания признала инцидент существенным, а 11 мая направила раскрытие регулятору. Форма 8-K была подана по пункту, который применяется к значительным инцидентам информационной безопасности. Ключевая деталь: решение о существенности основывалось на объёме и чувствительности данных.
Это не связано с остановкой операций или доказанным финансовым ущербом. В переданной информации фигурировали имена клиентов, даты рождения и номера Social Security. Конкретное AI-приложение и число затронутых людей компания не раскрыла. Этот случай меняет привычное представление о том, что именно требует раскрытия через SEC.
Существенным может оказаться инцидент без взлома сети, шифровальщика и отключения платежей — достаточно неконтролируемой передачи чувствительных данных внешнему сервису. Для публичных компаний это означает необходимость оценивать теневой ИИ в рамках общей программы управления киберрисками. Четырёхдневный срок раскрытия начинается с момента определения существенности, а не с даты обнаружения проблемы.
Сотрудник не преследовал цели нанести ущерб банку — он просто выбрал удобный внешний инструмент для решения рабочей задачи. В результате рядовая операция неожиданно переросла в событие, требующее публичного раскрытия и масштабного реагирования.
Для банка данные — не побочный продукт работы, а один из главных активов и одновременно зона повышенной ответственности. В запрос к модели могут попасть сведения о клиентах, платежах, кредитах, инвестициях, проверках личности, подозрительных операциях и санкционном контроле. Если сотрудник отправляет такую информацию в несанкционированный сервис искусственного интеллекта, организация теряет контроль над тем, где она хранится и кто имеет к ней доступ.
Национальный институт стандартов и технологий отдельно отмечает, что генеративный ИИ способен раскрывать, воспроизводить и даже выводить чувствительную информацию о людях. Риск не ограничивается утечкой: ответ модели может повлиять на кредитный скоринг, проверку на отмывание денег, инвестиционную рекомендацию или обработку платежей. При этом происхождение вывода и качество исходных данных не всегда удаётся проверить.
Ещё опаснее становятся ИИ-агенты, подключённые к системам управления клиентскими отношениями, программным интерфейсам и внутренним базам. При чрезмерных правах доступа они способны не только прочитать данные, но и передать их не тому пользователю или инициировать ошибочное действие. Для банка это сочетание риска утечки, нарушения требований, финансового ущерба и потери доверия клиентов.
Отдельный риск возникает у компаний, которые передают сервисам искусственного интеллекта функции скоринга, противодействия мошенничеству, поддержки клиентов или подготовки регуляторной отчётности. Проблема актуальна и за пределами финансового сектора. Под угрозой находятся медицинские организации, юридические фирмы, государственные учреждения, телеком-компании, торговые площадки, промышленные предприятия и разработчики программного обеспечения.
Чем больше организация зависит от персональных данных, коммерческой тайны, критической инфраструктуры или внешних подрядчиков, тем дороже ей обойдётся бесконтрольный ИИ. Логика здесь простая: если файл нельзя отправить неизвестному адресату по электронной почте, его не стоит загружать и в случайный чат-бот. Даже если тот очень убедительно обещает ничего не запоминать.
Следующий шаг — классифицировать данные и прямо определить, что можно передавать в сервис искусственного интеллекта, а что нельзя. Публичные материалы и обезличенные примеры обычно относятся к низкому риску, а персональные данные, реквизиты, кредитные истории, исходный код и сведения о подозрительных операциях должны оставаться внутри защищённого контура. Внешние сервисы необходимо проверять по условиям хранения данных, возможности их удаления и использованию запросов для обучения моделей.
Также важны доступ подрядчиков и процедуры реагирования на инциденты. Национальный институт стандартов и технологий отдельно выделяет для генеративного ИИ защиту данных, контроль сроков хранения, мониторинг, обучение сотрудников и план реагирования. Одних правил недостаточно: сотруднику нужна безопасная альтернатива, которая не проигрывает публичному чат-боту по удобству.
Организация может предоставить корпоративный шлюз или внутренний сервис с разграничением доступа, журналированием, маскированием персональных данных и системой предотвращения утечек данных. На уровне сети и устройств полезны списки разрешённых сервисов, блокировка личной аутентификации на рабочих компьютерах, проверка расширений браузера и контроль исходящих соединений. Такие меры позволяют не просто запрещать неизвестное, а видеть, что именно происходит с данными.
Особого внимания требуют ИИ-агенты, которым разрешено обращаться к системам управления клиентскими отношениями, хранилищам, платёжным интерфейсам или внутренним базам. Для них нужны принцип наименьших привилегий, отдельные учётные записи, регулярный пересмотр разрешений, подтверждение критических операций человеком и постоянный мониторинг поведения. Все события — необычные запросы, массовая выгрузка данных, попытка подключить новый сервис или передача файла наружу — должны попадать в центр мониторинга информационной безопасности. Иначе организация получит не управляемый ИИ, а очень исполнительного сотрудника без трудового договора и чувства меры.
Такой подход соответствует рекомендациям по безопасному развёртыванию ИИ, где акцент сделан на сегментации сети, изоляции моделей и строгом контроле доступа. В центре контура обычно находится шлюз — прослойка между пользователем и моделью. Он проверяет запросы и загружаемые файлы, обнаруживает персональные данные, номера карт, реквизиты и другие чувствительные сведения, а затем блокирует их или заменяет масками.
Через шлюз также задаются разрешённые модели, лимиты, сроки хранения и правила использования плагинов. Например, сотруднику можно разрешить анализ обезличенной таблицы, но запретить загрузку клиентского реестра или подключение личного аккаунта. Подобный контроль должен работать не только на входе: ответы модели тоже нужно проверять на случай раскрытия информации из контекста или базы знаний.
Клиентские данные следует изолировать на уровне хранилищ, сетей и прав доступа. Для этого применяют сегментацию, шифрование при передаче и хранении, отдельные ключи, защищённые хранилища секретов и ролевое управление доступом. Модель должна получать только тот контекст, который необходим конкретному сотруднику и разрешён его ролью: оператор колл-центра не должен видеть кредитное досье клиента, доступное аналитику рисков.
В системе генерации с поиском по внутренним данным это означает фильтрацию документов до передачи их модели, а не после красивого, но уже бесполезного ответа. Каждый запрос, вызов инструмента и ответ необходимо журналировать, но сами журналы тоже нужно считать чувствительными данными. В них могут оказаться фрагменты клиентских документов, поэтому требуются маскирование, ограничение доступа и понятные сроки хранения.
Для ИИ-агентов нужны отдельные идентификаторы, краткоживущие учётные данные и минимальные полномочия. Операции с платежами, изменением лимитов или доступом к персональным данным должны требовать подтверждения человека. Иначе банк построит не собственный контур ИИ, а аккуратно изолированный способ дать случайному боту ключи от бухгалтерии.
Национальный институт стандартов и технологий рекомендует использовать минимизацию, агрегацию и обезличивание данных, но предупреждает: сама по себе такая обработка не гарантирует невозможности повторной идентификации. Полезно различать анонимизацию и псевдонимизацию. При первой восстановить личность на практике уже нельзя; при второй идентификаторы заменяются условными значениями, но связать их с конкретным человеком всё ещё возможно с помощью отдельного ключа.
Например, имя клиента можно заменить на «Клиент047», а номер договора — на «ДоговорА12». Однако файл с соответствиями должен оставаться вне сервиса искусственного интеллекта и под контролем организации. Псевдонимизированные сведения всё ещё считаются персональными данными, поэтому простой заменой имени ответственность не устраняется.
Перед отправкой информации во внешний сервис данные можно обобщать: заменить точный возраст возрастной группой, адрес — регионом, дату операции — месяцем, сумму — диапазоном. Для тестирования и обучения лучше использовать синтетические записи, созданные без копирования реальных клиентов. Но обезличивание нужно проверять отдельно: редкое сочетание профессии, города, суммы кредита и даты сделки иногда идентифицирует человека не хуже фамилии.
Рекомендуется заранее оценивать риск повторной идентификации и учитывать дополнительные источники, с которыми данные могут быть сопоставлены. Если задача не требует реальных данных, ИИ можно использовать для создания шаблонов, классификации открытых документов, генерации тестовых сценариев, подготовки вопросов к интервью или анализа полностью открытой отчётности.
Для работы с внутренними материалами допустим промежуточный вариант: сотрудник вручную копирует только небольшой обезличенный фрагмент, а финальный документ собирает внутри корпоративного хранилища. Не следует загружать в публичный сервис целые базы, снимки экрана системы управления клиентскими отношениями, выгрузки из электронных таблиц и переписку с клиентами — даже если сервис обещает не использовать запросы для обучения.
Наконец, нужны недорогие организационные меры: короткая политика использования ИИ, список разрешённых сервисов, запрет на личные аккаунты для рабочих задач, обязательная проверка договоров и настроек хранения данных, обучение сотрудников и простой канал для сообщения об ошибке. Запросы, ответы и журналы следует считать такими же чувствительными, как исходные документы: они тоже могут содержать персональные данные и коммерческую тайну.
Такой подход не заменяет контур искусственного интеллекта, но заметно снижает вероятность сценария, когда сотрудник загрузил файл на минутку, а потом объясняется со службой информационной безопасности.
Полный запрет ИИ проблему не решит. Сотрудники все равно будут искать удобные инструменты, а неформальное использование лишь уйдет из поля зрения ИТ и службы информационной безопасности. Практичнее предложить безопасную альтернативу: корпоративный AI-контур, изоляцию клиентских данных, разграничение доступа, журналирование запросов и проверку интеграций.
Если средств на собственную платформу пока нет, минимальный уровень защиты можно построить на деидентификации, псевдонимизации, синтетических данных, запрете персональных аккаунтов и четком списке разрешенных сценариев. Но эти меры требуют дисциплины: маскирование имени не поможет, если клиента легко узнать по сочетанию редких признаков.
Главный принцип прост: ИИ должен ускорять работу, а не сокращать путь данных за пределы компании. Сначала организация определяет, какие сведения можно передавать модели, кто контролирует доступ и что происходит с результатом, — и только потом масштабирует использование технологии.
Однако вместе с промптом за пределы корпоративного контура могут уйти персональные данные, платёжные реквизиты, сведения о кредитной истории, внутренний код или детали сделки. Для банков и финтех‑компаний проблема особенно актуальна: они работают с большими объёмами чувствительной информации и при этом стремятся ускорить операции, аналитику и обслуживание клиентов.
Просто запретить все внешние инструменты недостаточно: сотрудники всё равно будут искать удобные решения. В результате корпоративные правила рискуют стать формальностью, не имеющей реального влияния. Поэтому бизнесу важно не бороться с ИИ, а выстроить контролируемую среду.
В такой среде разрешённые модели, системы предотвращения утечек данных, разграничение доступа и обучение сотрудников действуют как единая система. Их совместная работа должна быть реальной, а не сводиться к имитации активности каждого элемента по отдельности.
Что такое Shadow AI
Теневой ИИ — это использование сотрудниками искусственного интеллекта без официального разрешения, проверки безопасности и контроля со стороны ИТ-службы, подразделения информационной безопасности или комплаенса. Сотрудник может применять такой сервис вполне легально: например, попросить чат-бота сократить отчёт, расшифровать звонок или найти ошибку в коде.Проблема начинается тогда, когда компания не знает, какой инструмент используется, какие данные в него передаются и что происходит с ними после обработки. К теневому ИИ относятся публичные чат-боты, личные аккаунты в корпоративной работе, сервисы для расшифровки звонков, генераторы презентаций и документов, инструменты анализа таблиц, браузерные плагины и расширения.
В эту же категорию попадают ИИ-помощники, подключённые к корпоративным системам, внешние программные интерфейсы и локальные модели, которые не прошли проверку ИТ и информационной безопасности. Даже технически надёжный и легальный сервис остаётся теневым ИИ, если организация не контролирует его использование.
Это касается прав доступа, настроек хранения данных и возможных интеграций с другими системами. Когда ни один из этих параметров не отслеживается, даже безобидный на первый взгляд инструмент превращается в неконтролируемый канал утечки информации.
Кейс Community Bank
В мае 2026 года американский Community Bank зафиксировал внутренний инцидент из‑за использования несанкционированного AI‑приложения. Один из сотрудников передал в сервис непубличные сведения о клиентах — имена, даты рождения и номера Social Security. Банк не обнародовал название платформы, число затронутых клиентов и технические подробности. Поэтому однозначно связывать происшествие с ChatGPT некорректно.Ситуация примечательна отсутствием типичных признаков кибератаки: не было внешнего взлома, вредоносного кода и сбоев в работе сервисов. Клиенты сохраняли доступ к счетам и платёжным инструментам, основная ИТ‑инфраструктура функционировала в штатном режиме. При этом 7 мая материнская компания CB Financial Services признала инцидент существенным — из‑за объёма и чувствительности переданных данных.
11 мая CB Financial Services раскрыла сведения в форме 8‑K, направив уведомление в Комиссию по ценным бумагам и биржам США. Компания запустила расследование, провела оценку затронутых данных и начала информировать клиентов и регуляторов. Этот случай стал наглядным примером рисков эпохи теневого ИИ.
Первый SEC-доклад о Shadow AI
Случай Community Bank привлёк особое внимание, поскольку его материнская компания CB Financial Services впервые подала широко освещённый отчёт в Комиссию по ценным бумагам и биржам США по форме 8-K. Причиной стал не внешний взлом, а несанкционированное использование AI-инструмента. 5 мая 2026 года банк обнаружил обработку непубличных сведений о клиентах через стороннее приложение.Два дня спустя компания признала инцидент существенным, а 11 мая направила раскрытие регулятору. Форма 8-K была подана по пункту, который применяется к значительным инцидентам информационной безопасности. Ключевая деталь: решение о существенности основывалось на объёме и чувствительности данных.
Это не связано с остановкой операций или доказанным финансовым ущербом. В переданной информации фигурировали имена клиентов, даты рождения и номера Social Security. Конкретное AI-приложение и число затронутых людей компания не раскрыла. Этот случай меняет привычное представление о том, что именно требует раскрытия через SEC.
Существенным может оказаться инцидент без взлома сети, шифровальщика и отключения платежей — достаточно неконтролируемой передачи чувствительных данных внешнему сервису. Для публичных компаний это означает необходимость оценивать теневой ИИ в рамках общей программы управления киберрисками. Четырёхдневный срок раскрытия начинается с момента определения существенности, а не с даты обнаружения проблемы.
Сотрудник не преследовал цели нанести ущерб банку — он просто выбрал удобный внешний инструмент для решения рабочей задачи. В результате рядовая операция неожиданно переросла в событие, требующее публичного раскрытия и масштабного реагирования.
Почему проблема особенно опасна для банков?
В первую очередь теневой ИИ опасен для банков, платёжных систем, финансовых технологических платформ, страховых компаний, брокеров, инвестиционных фондов и микрофинансовых организаций. Все они работают с персональными данными, финансовыми профилями, реквизитами, документами проверки клиентов и коммерчески чувствительной информацией.Для банка данные — не побочный продукт работы, а один из главных активов и одновременно зона повышенной ответственности. В запрос к модели могут попасть сведения о клиентах, платежах, кредитах, инвестициях, проверках личности, подозрительных операциях и санкционном контроле. Если сотрудник отправляет такую информацию в несанкционированный сервис искусственного интеллекта, организация теряет контроль над тем, где она хранится и кто имеет к ней доступ.
Национальный институт стандартов и технологий отдельно отмечает, что генеративный ИИ способен раскрывать, воспроизводить и даже выводить чувствительную информацию о людях. Риск не ограничивается утечкой: ответ модели может повлиять на кредитный скоринг, проверку на отмывание денег, инвестиционную рекомендацию или обработку платежей. При этом происхождение вывода и качество исходных данных не всегда удаётся проверить.
Ещё опаснее становятся ИИ-агенты, подключённые к системам управления клиентскими отношениями, программным интерфейсам и внутренним базам. При чрезмерных правах доступа они способны не только прочитать данные, но и передать их не тому пользователю или инициировать ошибочное действие. Для банка это сочетание риска утечки, нарушения требований, финансового ущерба и потери доверия клиентов.
Отдельный риск возникает у компаний, которые передают сервисам искусственного интеллекта функции скоринга, противодействия мошенничеству, поддержки клиентов или подготовки регуляторной отчётности. Проблема актуальна и за пределами финансового сектора. Под угрозой находятся медицинские организации, юридические фирмы, государственные учреждения, телеком-компании, торговые площадки, промышленные предприятия и разработчики программного обеспечения.
Чем больше организация зависит от персональных данных, коммерческой тайны, критической инфраструктуры или внешних подрядчиков, тем дороже ей обойдётся бесконтрольный ИИ. Логика здесь простая: если файл нельзя отправить неизвестному адресату по электронной почте, его не стоит загружать и в случайный чат-бот. Даже если тот очень убедительно обещает ничего не запоминать.
Как защититься от рисков теневого ИИ?
Защита начинается не с тотальной блокировки чат-ботов, а с инвентаризации. Компания должна понять, какие сервисы искусственного интеллекта уже используют сотрудники, к каким данным они подключены и какие права получили через программные интерфейсы, плагины и сторонние учетные записи. Для этого проверяют сетевой трафик, расширения браузеров, облачные интеграции, корпоративные платежи и локально запущенные модели. Альянс облачной безопасности рекомендует включать в реестр не только официальные решения, но и инструменты, которыми сотрудники пользуются через личные аккаунты.Следующий шаг — классифицировать данные и прямо определить, что можно передавать в сервис искусственного интеллекта, а что нельзя. Публичные материалы и обезличенные примеры обычно относятся к низкому риску, а персональные данные, реквизиты, кредитные истории, исходный код и сведения о подозрительных операциях должны оставаться внутри защищённого контура. Внешние сервисы необходимо проверять по условиям хранения данных, возможности их удаления и использованию запросов для обучения моделей.
Также важны доступ подрядчиков и процедуры реагирования на инциденты. Национальный институт стандартов и технологий отдельно выделяет для генеративного ИИ защиту данных, контроль сроков хранения, мониторинг, обучение сотрудников и план реагирования. Одних правил недостаточно: сотруднику нужна безопасная альтернатива, которая не проигрывает публичному чат-боту по удобству.
Организация может предоставить корпоративный шлюз или внутренний сервис с разграничением доступа, журналированием, маскированием персональных данных и системой предотвращения утечек данных. На уровне сети и устройств полезны списки разрешённых сервисов, блокировка личной аутентификации на рабочих компьютерах, проверка расширений браузера и контроль исходящих соединений. Такие меры позволяют не просто запрещать неизвестное, а видеть, что именно происходит с данными.
Особого внимания требуют ИИ-агенты, которым разрешено обращаться к системам управления клиентскими отношениями, хранилищам, платёжным интерфейсам или внутренним базам. Для них нужны принцип наименьших привилегий, отдельные учётные записи, регулярный пересмотр разрешений, подтверждение критических операций человеком и постоянный мониторинг поведения. Все события — необычные запросы, массовая выгрузка данных, попытка подключить новый сервис или передача файла наружу — должны попадать в центр мониторинга информационной безопасности. Иначе организация получит не управляемый ИИ, а очень исполнительного сотрудника без трудового договора и чувства меры.
Безопасная альтернатива: собственный AI-контур
Для банка безопасная альтернатива теневому ИИ — не просто корпоративная подписка на популярный чат-бот. Нужен собственный контур: управляемая среда, в которой модели, данные, интеграции и действия пользователей подчиняются единым правилам безопасности. Она может работать в локальной инфраструктуре, частном облаке или через изолированные корпоративные сервисы. Принцип остаётся тем же: клиентские данные, запросы и ответы не должны бесконтрольно уходить в публичный интернет.Такой подход соответствует рекомендациям по безопасному развёртыванию ИИ, где акцент сделан на сегментации сети, изоляции моделей и строгом контроле доступа. В центре контура обычно находится шлюз — прослойка между пользователем и моделью. Он проверяет запросы и загружаемые файлы, обнаруживает персональные данные, номера карт, реквизиты и другие чувствительные сведения, а затем блокирует их или заменяет масками.
Через шлюз также задаются разрешённые модели, лимиты, сроки хранения и правила использования плагинов. Например, сотруднику можно разрешить анализ обезличенной таблицы, но запретить загрузку клиентского реестра или подключение личного аккаунта. Подобный контроль должен работать не только на входе: ответы модели тоже нужно проверять на случай раскрытия информации из контекста или базы знаний.
Клиентские данные следует изолировать на уровне хранилищ, сетей и прав доступа. Для этого применяют сегментацию, шифрование при передаче и хранении, отдельные ключи, защищённые хранилища секретов и ролевое управление доступом. Модель должна получать только тот контекст, который необходим конкретному сотруднику и разрешён его ролью: оператор колл-центра не должен видеть кредитное досье клиента, доступное аналитику рисков.
В системе генерации с поиском по внутренним данным это означает фильтрацию документов до передачи их модели, а не после красивого, но уже бесполезного ответа. Каждый запрос, вызов инструмента и ответ необходимо журналировать, но сами журналы тоже нужно считать чувствительными данными. В них могут оказаться фрагменты клиентских документов, поэтому требуются маскирование, ограничение доступа и понятные сроки хранения.
Для ИИ-агентов нужны отдельные идентификаторы, краткоживущие учётные данные и минимальные полномочия. Операции с платежами, изменением лимитов или доступом к персональным данным должны требовать подтверждения человека. Иначе банк построит не собственный контур ИИ, а аккуратно изолированный способ дать случайному боту ключи от бухгалтерии.
Если собственного контура искусственного интеллекта пока нет
Собственный контур — надёжный, но не единственный способ снизить риски. Если бюджет ограничен, организации стоит начать с простого правила: внешний ИИ не получает исходные клиентские данные. Сотрудник сначала удаляет имена, телефоны, адреса, номера документов, реквизиты, даты рождения и другие прямые идентификаторы. Затем проверяет, не складывается ли личность из косвенных признаков.Национальный институт стандартов и технологий рекомендует использовать минимизацию, агрегацию и обезличивание данных, но предупреждает: сама по себе такая обработка не гарантирует невозможности повторной идентификации. Полезно различать анонимизацию и псевдонимизацию. При первой восстановить личность на практике уже нельзя; при второй идентификаторы заменяются условными значениями, но связать их с конкретным человеком всё ещё возможно с помощью отдельного ключа.
Например, имя клиента можно заменить на «Клиент047», а номер договора — на «ДоговорА12». Однако файл с соответствиями должен оставаться вне сервиса искусственного интеллекта и под контролем организации. Псевдонимизированные сведения всё ещё считаются персональными данными, поэтому простой заменой имени ответственность не устраняется.
Перед отправкой информации во внешний сервис данные можно обобщать: заменить точный возраст возрастной группой, адрес — регионом, дату операции — месяцем, сумму — диапазоном. Для тестирования и обучения лучше использовать синтетические записи, созданные без копирования реальных клиентов. Но обезличивание нужно проверять отдельно: редкое сочетание профессии, города, суммы кредита и даты сделки иногда идентифицирует человека не хуже фамилии.
Рекомендуется заранее оценивать риск повторной идентификации и учитывать дополнительные источники, с которыми данные могут быть сопоставлены. Если задача не требует реальных данных, ИИ можно использовать для создания шаблонов, классификации открытых документов, генерации тестовых сценариев, подготовки вопросов к интервью или анализа полностью открытой отчётности.
Для работы с внутренними материалами допустим промежуточный вариант: сотрудник вручную копирует только небольшой обезличенный фрагмент, а финальный документ собирает внутри корпоративного хранилища. Не следует загружать в публичный сервис целые базы, снимки экрана системы управления клиентскими отношениями, выгрузки из электронных таблиц и переписку с клиентами — даже если сервис обещает не использовать запросы для обучения.
Наконец, нужны недорогие организационные меры: короткая политика использования ИИ, список разрешённых сервисов, запрет на личные аккаунты для рабочих задач, обязательная проверка договоров и настроек хранения данных, обучение сотрудников и простой канал для сообщения об ошибке. Запросы, ответы и журналы следует считать такими же чувствительными, как исходные документы: они тоже могут содержать персональные данные и коммерческую тайну.
Такой подход не заменяет контур искусственного интеллекта, но заметно снижает вероятность сценария, когда сотрудник загрузил файл на минутку, а потом объясняется со службой информационной безопасности.
Подводя итог
Shadow AI уже нельзя считать безобидной инициативой сотрудников, которые просто хотят работать быстрее. Для банков и финтех-компаний это полноценный риск утечки персональных данных, нарушения требований комплаенса, ошибок в финансовых решениях и потери доверия клиентов. Причем инцидент может произойти без взлома: достаточно передать чувствительный документ внешнему AI-сервису, который организация не контролирует.Полный запрет ИИ проблему не решит. Сотрудники все равно будут искать удобные инструменты, а неформальное использование лишь уйдет из поля зрения ИТ и службы информационной безопасности. Практичнее предложить безопасную альтернативу: корпоративный AI-контур, изоляцию клиентских данных, разграничение доступа, журналирование запросов и проверку интеграций.
Если средств на собственную платформу пока нет, минимальный уровень защиты можно построить на деидентификации, псевдонимизации, синтетических данных, запрете персональных аккаунтов и четком списке разрешенных сценариев. Но эти меры требуют дисциплины: маскирование имени не поможет, если клиента легко узнать по сочетанию редких признаков.
Главный принцип прост: ИИ должен ускорять работу, а не сокращать путь данных за пределы компании. Сначала организация определяет, какие сведения можно передавать модели, кто контролирует доступ и что происходит с результатом, — и только потом масштабирует использование технологии.
