Хранение корпоративных данных при использовании ИИ: защита и требования
Когда компания внедряет искусственный интеллект, возникает вопрос, который часто упускают на этапе планирования: куда девается информация, которую мы загружаем в ИИ-систему? Ответ на этот вопрос определяет не только безопасность данных, но и соответствие законодательству, репутацию компании и риск финансовых потерь. В этой части мы разберемся, почему проблема хранения данных при работе с ИИ отличается от традиционной защиты информации и какие угрозы она создает.
Почему корпоративные данные нуждаются в защите при использовании ИИ
На первый взгляд может показаться, что если компания использует облачный сервис с хорошей репутацией, данные находятся в безопасности. Это предположение ошибочно, и различие кроется в самой природе ИИ-систем.
Когда вы загружаете информацию на сервер компании, она хранится в защищенной базе данных. При работе с ИИ ситуация иная. Модель анализирует данные, обрабатывает их, иногда запоминает особенности информации. В некоторых случаях эти данные становятся частью процесса обучения или совершенствования модели. Даже если ваша компания — единственная, кто загружает информацию, она может влиять на поведение ИИ и косвенно становиться видимой в результатах работы системы.
Вторая проблема связана с тем, как устроены современные ИИ-сервисы. Многие из них работают по модели, где данные могут быть переданы между серверами, скопированы для создания резервных копий, проанализированы аналитиками компании-поставщика для улучшения сервиса. Пользовательское соглашение часто позволяет это делать, но об этом мало кто читает.
Компания, которая загружает квартальный отчет в публичный ИИ-сервис для анализа, фактически делает этот отчет потенциально доступным для обработки системой и аналитиков, которые улучшают модель. Это не значит, что конкурент получит документ целиком, но информация о его структуре, финансовых показателях, тенденциях может быть зафиксирована в моделях и использована.
Третья угроза — регуляторная. Российское законодательство требует, чтобы некоторые категории данных не покидали территорию страны. Если компания использует американский облачный сервис с ИИ, она может нарушить закон о защите персональных данных или требования ФСБ к критичной информации, даже если это не было сделано намеренно.
Чем работа с ИИ отличается от традиционной обработки данных
При работе с обычными IT-системами поток данных понятен. Информация загружается, обрабатывается, хранится в конкретном месте. Кто имеет доступ к серверам — обычно четко определено в контракте.
С ИИ-системами логика другая. Данные входят, система их анализирует, иногда обновляется на основе новых примеров, результаты выводятся. Кроме того, ИИ-модели часто работают в облаке, где они могут быть общими для многих пользователей. Даже если ваши данные не смешиваются физически, модель, которая обрабатывает вашу информацию, может содержать закономерности, изученные из информации других пользователей, включая конкурентов.
Еще одна особенность — сложность проверки. При традиционной защите компании могут провести аудит серверов, проверить логи доступа, убедиться, что данные шифруются. С ИИ-системами это намного сложнее, потому что часть обработки происходит в виде черного ящика, и компания не может четко проследить, как именно её информация использовалась.
Основные риски и угрозы при работе с ИИ-системами
Для компании, которая думает о том, как безопасно использовать ИИ, важно понять, какие именно угрозы реальны, а какие гипотетичны. Это помогает расставить приоритеты в защите.
Утечка конфиденциальной информации в публичных ИИ-сервисах
Риск здесь заключается не только в том, что кто-то украдет данные с сервера. Проблема часто в том, что информация становится видимой в результатах работы ИИ.
Представьте ситуацию: сотрудник компании Альфа загружает список клиентов в ChatGPT, чтобы система помогла сформировать предложение. Позже сотрудник компании Бета (конкурента) загружает в тот же сервис похожий запрос. Из-за того, как устроены ИИ-модели, она может неявно вспомнить особенности данных, которые видела ранее, и выдать результат, который содержит признаки, похожие на данные компании Альфа. Информация не просочилась явно, но она оказала влияние.
Кроме того, некоторые ИИ-сервисы позволяют компании-владельцу проверять запросы пользователей для улучшения модели. В этот процесс могут попасть конфиденциальные данные.
- Утечка через результаты работы ИИ, которые содержат косвенные признаки загруженной информации
- Доступ администраторов сервиса к текстам запросов и загруженным файлам
- Использование данных для обучения новых версий модели без явного согласия
- Архивирование и хранение истории взаимодействий дольше, чем об этом знает пользователь
Использование данных для обучения моделей третьих лиц
Это звучит как теория заговора, но это прописано в пользовательских соглашениях многих ИИ-сервисов. Когда вы используете сервис, компания может использовать ваши данные для улучшения своей модели, если вы не отключили эту опцию. Даже если отключили, гарантия может быть неполной.
Проблема в том, что компания, обучавшая модель на ваших данных, может продать доступ к этой модели другим организациям. Ваша информация не будет скопирована явно, но закономерности, которые в ней содержались, станут частью продукта, который будет использовать ваш конкурент.
Для финансовых компаний, разработчиков ПО и других организаций, работающих с критичной информацией, это риск высокого уровня.
Несанкционированный доступ к базам данных
Этот риск не специфичен для ИИ, но он усугубляется масштабом. Если ИИ-сервис обрабатывает данные тысяч компаний на одних и тех же серверах, успешная атака на них может затронуть множество организаций одновременно.
Кроме того, облачные серверы, которые используют ИИ-сервисы, часто находятся за границей. Это означает, что даже если произойдет взлом, компания может медленнее узнать об инциденте, а восстановление может быть осложнено различиями в законодательстве и юрисдикции.
В 2023 году произошла утечка данных, когда тысячи пользователей ИИ-сервиса получили доступ к истории запросов друг друга из-за ошибки в системе аутентификации. Многие не заметили этого месяцами. Это показывает, что даже авторитетные компании не всегда сразу обнаруживают и сообщают об инцидентах.
Передача информации регуляторам и третьим лицам
В некоторых случаях компания-владелец ИИ-сервиса может быть обязана передать данные государственным органам по запросу. Если сервис находится за границей, это может произойти по запросу иностранного правительства, о чем пользователь может узнать слишком поздно или не узнать вовсе.
Есть также риск продажи данных третьим лицам. Если компания-владелец ИИ-сервиса переживает финансовые сложности или её покупает другая организация, ваши данные могут перейти в новые руки.
Для компаний, работающих в России, это особенно актуально, потому что российское законодательство очень четко определяет, какие данные должны оставаться на территории страны и не должны передаваться иностранным компаниям.
Законодательные требования к хранению данных
Прежде чем выбирать способ хранения данных при работе с ИИ, нужно понять, какие требования закона вообще существуют. В России это не одна норма, а несколько взаимосвязанных требований.
Защита персональных данных (Федеральный закон 152-ФЗ)
Если в вашей компании есть информация о клиентах, сотрудниках, партнерах — это персональные данные. Закон требует защищать их и хранить с соблюдением определенных правил.
Ключевой момент для ИИ: если вы загружаете персональные данные в облачный сервис, расположенный вне России, вы потенциально нарушаете закон. Даже если сервис хорошо защищен, факт трансграничной передачи данных требует специального согласия субъектов данных и уведомления регулятора.
Многие компании этого не делают, потому что не знают о требовании или считают его формальностью. Но если произойдет проверка, штрафы могут быть существенными.
- Все персональные данные граждан России должны храниться на серверах на территории РФ
- Необходимо получить согласие на обработку персональных данных
- Компания должна сообщить субъектам данных, как их информация обрабатывается
- Если произойдет утечка, компания должна уведомить Роскомнадзор и потерпевших
Требования к защите коммерческой тайны
Отдельный уровень защиты требуется для информации, которая является коммерческой тайной компании. Это могут быть технологии, финансовые показатели, планы развития, списки ключевых клиентов.
Закон говорит просто: если информация является коммерческой тайной, компания должна принимать меры для её защиты. Если компания не принимает защитные меры, информация перестает считаться тайной и может свободно использоваться конкурентами.
Загрузка коммерческой тайны в публичный ИИ-сервис — это фактическое признание того, что компания не защищала информацию. В случае спора это может быть использовано против компании.
Что это означает практически? Если в вашей компании есть стратегический документ, финансовые модели, технические разработки — они не должны попадать в публичные системы. Точка.
Отраслевые стандарты и требования регуляторов
Кроме общих законов, есть отраслевые требования. Если компания работает в финансовом секторе, страховании, телекоммуникациях или критичной инфраструктуре, к ней применяются дополнительные правила.
Центральный банк России требует, чтобы финансовые организации использовали только одобренные системы для обработки критичной информации. Это означает, что банк не может просто взять и загрузить данные клиентов в ChatGPT, даже если это было бы технически удобно.
ФСБ имеет требования к защите информации, которая может быть важна для национальной безопасности. Это касается многих отраслей, включая критичную инфраструктуру, энергетику, транспорт и оборону.
ФМБА (когда-то Минатом) регулирует компании, работающие с ядерными технологиями и радиоактивными материалами. Любая информация в этой сфере требует максимальной защиты.
- Финансовые организации должны использовать одобренные регулятором системы
- Критичная инфраструктура не может использовать иностранные облачные сервисы без согласования
- Информация, касающаяся национальной безопасности, должна храниться в России и доступна только для граждан РФ
- Компании должны регулярно подтверждать соответствие этим требованиям при проверке регулятором
Часто компании преуменьшают важность этих требований, потому что проверки кажутся маловероятными. Но это ошибка. Если произойдет инцидент с утечкой данных, первое, что сделает регулятор — проверит, был ли нарушен закон при обработке информации. И если была, штрафы будут не единственным последствием.
Где и как хранить данные при работе с ИИ
Теперь, когда понятны риски и требования законодательства, встает практический вопрос: где именно должны храниться данные? У компании есть несколько вариантов, каждый с собственными преимуществами и недостатками.
Локальное развертывание корпоративного ИИ
Это означает, что компания устанавливает ИИ-модель на собственных серверах, обычно в своем офисе или в собственном дата-центре. Данные никогда не покидают компанию, обработка происходит локально.
Преимущества очевидны. Компания имеет полный контроль над данными. Никто кроме сотрудников компании не может получить доступ к информации. Нет риска утечки через облачный сервис, нет проблем с законодательством о трансграничной передаче данных. Если произойдет инцидент безопасности, компания узнает об этом первой и сможет быстро отреагировать.
Однако есть существенные затраты. Во-первых, нужно купить серверы или арендовать место в дата-центре. Во-вторых, нужны люди, которые будут поддерживать эту инфраструктуру — администраторы баз данных, специалисты по безопасности, инженеры-системотехники. В-третьих, модель нужно периодически обновлять, что требует определенных знаний и ресурсов.
Еще один минус — производительность. Если ИИ-модель требует мощных графических процессоров (GPU) для работы, их покупка и содержание будут дорогостоящими. Облачные сервисы могут амортизировать эти расходы между многими пользователями, но локальный сервер должен оплатить полную стоимость.
Локальное развертывание имеет смысл для компаний, которые:
- Работают с очень чувствительными данными, требующими максимальной защиты
- Имеют специалистов, которые могут поддерживать инфраструктуру
- Готовы потратить значительные ресурсы на покупку и содержание оборудования
- Работают в отраслях с жесткими регуляторными требованиями, которые практически исключают использование облака
Есть также компромиссный вариант. Компания может использовать открытые модели (например, LLaMA от Meta или различные модели на платформе Hugging Face) и развертывать их локально. Это дешевле, чем разработка собственной модели с нуля, но все еще требует инвестиций в инфраструктуру.
Изолированные облачные среды
Некоторые облачные провайдеры предлагают выделенные серверы или виртуальные машины, которые используются только одной компанией. Это средний путь между локальным развертыванием и полностью публичным сервисом.
Преимущество такого подхода в том, что компания не несет полной ответственности за обслуживание оборудования. Провайдер следит за безопасностью серверов, обновлением ПО, резервными копиями. При этом данные компании не смешиваются с данными других пользователей на одних и тех же машинах.
В России есть облачные провайдеры, которые предлагают такие услуги и гарантируют, что данные хранятся на территории страны. Это решает проблему с законодательством о трансграничной передаче персональных данных. Компания получает некоторые преимущества облака — не нужно самостоятельно покупать оборудование — и при этом сохраняет контроль над доступом к данным.
Недостаток в стоимости. Выделенные облачные ресурсы дороже, чем общий облачный сервис, но дешевле, чем собственная инфраструктура. Компания должна найти баланс между затратами и уровнем защиты.
Также остается риск, связанный с провайдером. Если администраторы облачного сервиса получат доступ к данным компании (даже случайно), информация может быть скомпрометирована. Поэтому важно включить в контракт четкие требования к защите данных и предусмотреть механизм аудита.
Компания, выбравшая изолированное облачное решение, должна убедиться, что в контракте прописано право на проведение аудитов безопасности, требование к шифрованию данных в покое и в движении, а также четкие сроки уведомления о любых инцидентах безопасности. Без этого выделенный облачный сервер предоставляет ложное ощущение защиты.
Изолированные облачные среды подходят для компаний, которые:
- Нуждаются в защите данных, но не готовы вкладывать огромные ресурсы в собственную инфраструктуру
- Требуют соответствия законодательству о локализации данных в России
- Хотят получить некоторые преимущества облака, не расставаясь с контролем
- Работают с чувствительными, но не критичными данными
Гибридный подход: комбинация локального и облачного хранения
Третий вариант — использовать комбинацию. Например, очень чувствительные данные хранятся локально и обрабатываются локальной моделью. Менее критичные данные могут отправляться в облачный сервис для обработки. Или компания использует локальное хранилище как основное, а облачное как резервное.
Гибридный подход дает гибкость. Компания может оптимизировать затраты, используя облако только для задач, которые не требуют максимальной защиты. При этом критичная информация остается на месте.
Недостаток в сложности. Нужно четко определить, какие данные идут куда, как они синхронизируются между локальной и облачной частями, как осуществляется контроль доступа через границы. Ошибка в этой логике может привести к тому, что конфиденциальные данные случайно попадут в облако.
Реальный пример гибридного подхода: компания разрабатывает продукт, используя ИИ для анализа отзывов клиентов. Сами отзывы содержат личную информацию — имена, города проживания, контактные данные. Они хранятся локально. Но компания может отправить в облачный ИИ-сервис анонимизированные версии отзывов (где удалены личные данные), чтобы использовать более мощную модель для анализа тональности. После анализа результаты возвращаются и сопоставляются с локальными данными.
Это требует хорошей организации процесса, но позволяет получить лучшее из обоих миров.
Технические методы защиты данных
Независимо от того, где хранятся данные, нужно применять технические меры защиты. Даже если данные находятся в выделенном облачном сервере, они должны быть защищены на нескольких уровнях.
Сквозное шифрование информации
Шифрование — это преобразование информации в код, который невозможно прочитать без специального ключа. Есть два важных момента: шифрование данных в движении и шифрование данных в покое.
Шифрование в движении означает, что когда данные передаются от компьютера пользователя к серверу, они передаются в зашифрованном виде. Если кто-то перехватит пакеты данных в сети, он не сможет прочитать информацию. Это обеспечивается протоколом HTTPS и TLS.
Шифрование в покое означает, что данные, хранящиеся на сервере, также находятся в зашифрованном виде. Даже если кто-то получит физический доступ к жесткому диску сервера или украдет резервную копию, информация остается нечитаемой без ключа.
Важный момент: ключи шифрования должны храниться отдельно от самих данных. Если ключ и данные находятся на одном сервере, нарушитель, получивший доступ к серверу, может получить и то, и другое. Поэтому ключи часто хранятся в отдельной системе, называемой хранилищем ключей (key management system). Только авторизованные системы могут запросить ключ для расшифровки данных.
Для ИИ-систем это создает вызов. Если данные зашифрованы, ИИ не может их обработать в зашифрованном виде. Данные должны быть расшифрованы в памяти сервера, затем обработаны, затем зашифрованы обратно. Это требует, чтобы память сервера была также защищена, и чтобы сам сервер находился в безопасной сети.
Анонимизация и псевдонимизация данных
Это методы, которые позволяют удалить или скрыть личную информацию из данных перед их использованием. Разница между ними важна с точки зрения законодательства.
Анонимизация означает полное удаление информации, которая позволяет идентифицировать человека. Если данные полностью анонимизированы, они больше не считаются персональными данными по закону. Компания может использовать анонимизированные данные более свободно, включая загрузку в публичные ИИ-сервисы, потому что нет риска раскрытия личной информации.
Псевдонимизация — это замена личных идентификаторов на условные коды. Например, вместо имени и номера телефона клиента используется ID "CLI_12345". На первый взгляд, это выглядит защитой, но если кто-то получит таблицу соответствия между реальными данными и псевдонимами, он сможет восстановить личную информацию. Поэтому псевдонимизированные данные все еще считаются персональными с точки зрения закона.
Однако псевдонимизация полезна. Она снижает риск случайного раскрытия данных. Если документ с отзывами клиентов содержит только ID клиента, телефон и текст отзыва, это менее чувствительно, чем если бы были указаны полные имена. ИИ может анализировать такие данные, не имея доступа к реальным личным идентификаторам.
На практике компания часто использует комбинацию. Для максимальной защиты данные анонимизируются перед отправкой в облачный сервис. Для задач, которые требуют какого-то минимума информации о пользователе, используется псевдонимизация с хранением таблицы соответствия в защищенном локальном хранилище.
Разделение доступа по ролям пользователей
Не все сотрудники компании должны иметь доступ ко всем данным. Один подход — разделить доступ на основе ролей (Role-Based Access Control, RBAC).
Например, аналитик может видеть агрегированные статистики, но не видеть личные данные клиентов. Менеджер проекта может видеть результаты анализа, но не видеть исходные данные. Администратор системы имеет полный доступ, но его действия логируются и проверяются.
Это снижает риск, что конфиденциальные данные будут случайно или намеренно скомпрометированы сотрудником. Даже если аккаунт сотрудника будет взломан, нарушитель получит только доступ, который имеет этот конкретный сотрудник, а не всю базу данных компании.
Для ИИ-систем это означает, что нужно четко определить, кто может загружать данные в систему, кто может видеть результаты обработки, кто может управлять системой. Эти роли должны быть отделены. Например, тот, кто загружает данные, может быть не тем, кто видит результаты.
Аудит и логирование всех операций
Даже при всех мерах защиты, компания должна знать, что происходит с её данными. Логирование означает запись всех действий в системе: кто, когда и что сделал с данными.
Если сотрудник загрузил набор данных в ИИ-систему, это должно быть залогировано. Если данные были скачаны, когда система выполнила запрос — всё это должно быть зафиксировано. Если произойдет инцидент, компания сможет посмотреть логи и понять, что именно произошло, кто был виноват, какие данные были затронуты.
Логи должны быть защищены так же хорошо, как сами данные. Если логи находятся в открытом виде, нарушитель может удалить записи о своих действиях, и компания не узнает об инциденте.
Компания должна периодически проверять логи, не ограничиваясь ожиданием инцидента. Иногда аномалии в логах — единственный признак того, что система была скомпрометирована. Если в логах внезапно появляются попытки доступа к данным в необычное время или с необычных IP-адресов, это сигнал к расследованию.
Для ИИ-систем логирование особенно важно, потому что часть операций может быть непрозрачной. Логи помогают понять, какие данные были обработаны, какие результаты были выданы, были ли ошибки. Это также помогает отследить, если модель начнет вести себя странно — например, если вдруг начнет выдавать результаты, которые раскрывают личную информацию. Это может быть признаком того, что система была атакована или модель была отравлена (poisoned) через загрузку специально подготовленных данных.
Длительное хранение логов — еще один важный момент. Компания должна хранить логи достаточно долго, чтобы иметь возможность провести расследование даже через несколько месяцев после инцидента. Рекомендуется хранить логи не менее одного года, а для критичных систем — несколько лет.
Как выбрать ИИ-решение с безопасным хранением
Когда компания начинает искать ИИ-решение для своих задач, нужно понимать, какие вопросы задавать поставщику, чтобы убедиться, что данные будут в безопасности.
Наличие сертификатов соответствия стандартам
ISO 27001 — международный стандарт управления информационной безопасностью. Если компания получила сертификат ISO 27001, это означает, что она прошла проверку независимыми аудиторами и соответствует определенным требованиям к защите данных. Это не гарантия абсолютной безопасности, но это хороший знак.
SOC 2 — стандарт, который проверяет, насколько хорошо компания управляет доступом, безопасностью и конфиденциальностью данных. Многие крупные облачные провайдеры имеют сертификат SOC 2.
Для российских компаний важны сертификаты ГОСТР и одобрение ФСБ для использования в критичных инфраструктурах. Если компания работает в финансовом секторе, нужно проверить, одобрена ли система Центральным банком.
Нужно уточнить, какие именно части системы сертифицированы. Иногда только центр обработки данных имеет сертификат, а приложение, которое работает на нем, нет. Или сертификат есть на основной систему, но не на дополнительные сервисы.
Явный отказ от использования данных для обучения
Это критичный вопрос. Компания должна задать поставщику ИИ-решения прямо: используются ли данные, которые я загружаю, для обучения или улучшения вашей модели?
Ответ должен быть однозначным. Если поставщик говорит, что может использовать данные, но вы можете отключить эту опцию, нужно убедиться, что это действительно так, и получить письменное подтверждение.
Есть ИИ-сервисы, которые изначально разработаны так, чтобы не использовать данные пользователей для обучения. Например, если компания развертывает открытую модель локально, она полностью контролирует процесс обучения. Или если она использует облачный сервис специально разработанный для корпоративного использования, такой сервис может гарантировать, что ваши данные не будут использованы для обучения их или чужих моделей.
Возможность локального или на-премис развертывания
Хорошее ИИ-решение должно предлагать несколько вариантов развертывания. Если поставщик предлагает только облачный вариант, компания теряет гибкость. Если есть возможность развернуть систему локально, это дает больше контроля.
Некоторые поставщики предлагают модель, где компания может выбрать: использовать облако для экспериментов, а затем развернуть критичные системы локально. Это хороший подход.
Открытая политика обработки информации
Пользовательское соглашение должно быть понятным и четким относительно того, как обрабатываются данные. Не должно быть туманных формулировок типа "мы можем использовать ваши данные для улучшения сервиса" без четкого определения, что это означает.
Компания должна иметь возможность получить ответы на конкретные вопросы. Например: кто имеет доступ к моим данным? Как долго хранятся логи доступа? Если произойдет утечка, как вы меня уведомите? Могу ли я удалить свои данные, и если да, когда они будут полностью удалены? Что произойдет с моими данными, если я прекращу использовать ваш сервис?
Если поставщик не может или не хочет ответить на эти вопросы, это красный флаг.
Типичные ошибки при работе с данными в ИИ
Большинство проблем с безопасностью данных при использовании ИИ происходят не из-за технических недостатков, а из-за ошибок в процессе и отсутствия четкой политики. Знание типичных ошибок помогает их избежать.
Загрузка конфиденциальной информации в публичные сервисы
Это самая распространенная ошибка. Сотрудник сталкивается с задачей, для которой ему нужна помощь ИИ. Он берет первый попавшийся сервис — обычно это бесплатный ChatGPT или аналогичный — и загружает туда финансовый отчет, список клиентов, исходный код или другую конфиденциальную информацию.
Сотрудник может делать это в лучших намерениях, не понимая, что это нарушение политики безопасности. Он может думать, что это только для быстрого анализа, что информация не будет сохранена. Но на самом деле данные загружены в облако, они обрабатываются на серверах поставщика, могут быть использованы для обучения моделей, могут быть доступны администраторам сервиса.
Результат может быть серьезным. Компания может нарушить закон о защите персональных данных, если загружала информацию о клиентах. Конкуренты могут получить информацию о стратегии развития. Инвесторы узнают о проблемах компании раньше времени. Регулятор может провести проверку.
Как это предотвратить? Во-первых, нужна политика, которая четко запрещает загружать конфиденциальную информацию в публичные сервисы. Во-вторых, нужно обучить сотрудников этой политике. В-третьих, можно использовать технические средства — например, блокировать доступ к определенным сайтам из корпоративной сети, или использовать DLP-системы (Data Loss Prevention), которые автоматически обнаруживают попытки загрузки конфиденциальной информации.
Отсутствие корпоративной политики использования ИИ
Если в компании нет четкой политики относительно того, как использовать ИИ-системы, сотрудники будут делать это по своему усмотрению. Одни будут осторожны, другие — нет. Результат — хаос и риск для компании.
Политика должна определить, какие сотрудники могут использовать ИИ-системы, для каких задач, какие данные можно загружать, какие нельзя. Она должна содержать примеры нарушений и последствия. Политика должна быть доступна всем сотрудникам и периодически обновляться.
Без политики даже при лучших намерениях компания не может быть уверена, что её данные защищены. При проверке регулятора компания не может показать, что она принимала меры для защиты информации.
Игнорирование требований законодательства
Некоторые компании действуют так, как если бы требования законодательства не существовали. Они используют зарубежные облачные сервисы для обработки персональных данных, не задумываясь о том, что это нарушает закон. Они не сообщают Роскомнадзору об использовании ИИ-систем для обработки персональных данных.
Это может быть связано с незнанием требований, с недооценкой рисков, или с надеждой, что проверка не произойдет. Но если проверка произойдет, штрафы будут значительными. Для физических лиц штраф может быть до 6 тысяч рублей, для компаний — до 75 тысяч рублей за нарушение закона о защите персональных данных.
Кроме того, если произойдет утечка данных, компания будет в еще более плохой позиции, если докажут, что она нарушала закон при их обработке. Это может быть использовано против компании в судебном разбирательстве.
Как избежать этого? Компания должна провести аудит своих процессов и убедиться, что она соответствует законодательству. Если необходимо, нужно привлечь специалиста по юридическим вопросам, который разберется в требованиях.
Недостаточное обучение сотрудников правилам защиты
Даже если компания разработала хорошую политику, если сотрудники не знают об этой политике или не понимают, почему нужно её соблюдать, она не будет работать.
Обучение должно быть регулярным, не только один раз в год. Оно должно быть практическим — не просто рассказать о политике, но показать примеры, как правильно использовать ИИ, какие задачи безопасно передавать ИИ-системам, какие нет.
Обучение должно охватывать не только IT-специалистов, но и обычных сотрудников. Финансист, который анализирует квартальный отчет, должен знать, что нельзя загружать этот отчет в публичный ИИ-сервис. Разработчик, который пишет код, должен знать, что нельзя загружать исходный код компании в ИИ-сервис для получения советов по оптимизации.
Компания также должна создать канал обратной связи, где сотрудники могут задать вопросы о том, безопасно ли использовать ИИ для конкретной задачи. Например, можно иметь специалиста по информационной безопасности, который отвечает на такие вопросы.
Внедрение политики безопасности в компании
Создание и поддержание политики безопасности при использовании ИИ — это не одноразовая задача, а процесс, требующий постоянного внимания и обновления.
Разработка и утверждение политики ИИ
Политика должна быть разработана совместно несколькими людьми. Нужен представитель руководства — чтобы политика была поддержана на высоком уровне. Нужен специалист по информационной безопасности — чтобы политика была технически обоснована. Нужен представитель юридического отдела — чтобы политика соответствовала законодательству. Нужны представители разных отделов — чтобы политика была практичной и применима к реальным задачам.
При разработке политики нужно учесть:
- Какие данные компания считает конфиденциальными и требующими защиты
- Какие ИИ-системы разрешается использовать, а какие запрещены
- Какие задачи можно передавать ИИ-системам, а какие нельзя
- Какие данные можно загружать в ИИ-системы, а какие нельзя
- Кто отвечает за обучение сотрудников
- Как сотрудники могут получить разрешение на использование ИИ для задачи, которая не описана в политике
- Какие последствия ждут тех, кто нарушает политику
После разработки политика должна быть утверждена руководством компании. Это гарантирует, что политика будет поддерживаться на всех уровнях организации и что ресурсы будут выделены на её реализацию.
Обучение команды правилам работы с данными
После утверждения политики её нужно довести до всех сотрудников. Это должно быть обязательным обучением, не факультативным. Сотрудник должен подтвердить, что он ознакомился с политикой и согласен её соблюдать.
Обучение не должно быть скучным лекцией. Оно должно быть интерактивным, с примерами и практическими заданиями. Например, можно показать сценарии — "Сотрудник получил задание анализировать список клиентов с помощью ИИ. Какие данные он может загружать? Какие нет?" — и попросить сотрудников ответить.
Обучение должно быть периодическим. Рекомендуется повторять основные моменты политики два раза в год, а новые сотрудники должны проходить обучение как часть программы онбординга.
Кроме того, нужно создать доступные ресурсы, к которым сотрудники могут обратиться при возникновении вопроса. Это может быть внутренняя вики, часто задаваемые вопросы, или контактные данные специалиста, который может ответить на вопрос.
Регулярная проверка соответствия стандартам
Компания должна периодически проверять, что процессы соответствуют политике и требованиям законодательства. Это может быть внутренний аудит, проводимый специалистами компании, или внешний аудит, проводимый независимой компанией.
При проверке нужно убедиться, что:
- ИИ-системы, которые использует компания, соответствуют политике
- Сотрудники соблюдают политику в своей работе
- Данные защищены надлежащим образом
- Логи доступа ведутся и периодически проверяются
- Не произошло утечек конфиденциальной информации
- Компания соответствует требованиям законодательства
На основе результатов проверки нужно внести коррективы в процессы, если это необходимо. Если выявлены нарушения, нужно разобраться, почему они произошли, и принять меры, чтобы они не повторялись. Это может быть дополнительное обучение сотрудников, изменение технических настроек системы, или обновление политики.
Проверка безопасности не должна восприниматься как наказание за нарушения. Её цель — помочь компании улучшить защиту данных. Компания должна создать культуру, где сотрудники не боятся сообщить о потенциальной проблеме с безопасностью.
Публичные ИИ-сервисы vs. корпоративные платформы
Когда компания выбирает ИИ-решение, она часто стоит перед выбором: использовать публичный сервис, который доступен всем, или инвестировать в корпоративное решение, которое используется только её компанией. Каждый подход имеет преимущества и недостатки.
Когда использовать публичные сервисы
Публичные ИИ-сервисы имеют преимущество простоты и доступности. Сотруднику достаточно пройти регистрацию, и он может сразу начать использовать ИИ-систему. Нет необходимости в специальной инфраструктуре, в команде, которая поддерживает систему.
Публичные сервисы часто имеют лучшие модели, потому что они финансируются мощными компаниями и обучены на огромных объемах данных. Они постоянно улучшаются, и пользователь получает новые функции без необходимости их самостоятельно разрабатывать.
Публичные сервисы имеют смысл для задач, которые не требуют защиты конфиденциальных данных. Например, для написания маркетингового текста, для мозгового штурма, для получения общей информации по какой-то теме. В этих случаях риск утечки данных минимален, потому что загружаемые данные не содержат конфиденциальной информации.
Также публичные сервисы подходят для экспериментов. Если компания только начинает использовать ИИ и не знает, какие задачи ей подойдут, есть смысл сначала поэкспериментировать с публичными сервисами, а затем, если появится необходимость работать с конфиденциальными данными, перейти на корпоративное решение.
Однако нужно помнить, что даже при использовании публичных сервисов только для некритичных задач, нужна политика, которая четко определяет, что можно и что нельзя загружать. Сотрудник может ошибиться или забыть про ограничения, если они не четко определены.
Когда переходить на закрытые корпоративные решения
Если компания работает с конфиденциальными данными — персональными данными клиентов, финансовыми показателями, исходным кодом, интеллектуальной собственностью — она должна использовать закрытые корпоративные решения.
Корпоративное решение может быть развернуто локально (на собственных серверах компании), в выделенном облаке (на выделенных серверах облачного провайдера) или в гибридной конфигурации (часть локально, часть в облаке).
Преимущество корпоративного решения в том, что компания имеет полный контроль над данными. Данные не используются для обучения других моделей, не видны администраторам других организаций, не передаются третьим лицам.
Корпоративное решение имеет смысл также для компаний, которые часто используют ИИ. Если сотрудники используют ИИ каждый день для выполнения критичных бизнес-задач, стоимость разработки или лицензирования корпоративного решения может быть оправдана экономией времени и снижением рисков.
Есть гибридный подход, который становится все более популярным. Компания использует публичные сервисы для некритичных задач, но при этом использует корпоративное решение для работы с конфиденциальными данными. Это позволяет получить лучшее из обоих миров — гибкость и доступность публичных сервисов, и безопасность корпоративного решения.
При переходе на корпоративное решение нужно учесть затраты на разработку или лицензирование, на инфраструктуру, на обслуживание системы. Нужна команда специалистов, которая будет поддерживать систему, обновлять её, следить за безопасностью. Эти затраты должны быть предусмотрены в бюджете компании.
Также нужно учесть время на внедрение. Переход на новую систему требует обучения сотрудников, адаптации процессов, тестирования. Это может занять несколько месяцев, в течение которых может быть период неопределенности, когда старая система еще используется, а новая еще не полностью готова.
Несмотря на эти сложности, инвестиция в корпоративное решение часто окупается. Компания получает уверенность в том, что её данные защищены, соответствуют требованиям законодательства, и могут быть использованы для решения критичных бизнес-задач без риска утечки конфиденциальной информации.
Путь вперед: практические шаги для вашей компании
Если вы дочитали до этой точки, вы имеете хорошее представление о том, как должны храниться и защищаться корпоративные данные при использовании ИИ. Теперь возникает вопрос: как начать?
Первый шаг — провести аудит текущей ситуации в компании. Какие ИИ-системы сейчас используют сотрудники? Какие данные загружаются? Есть ли уже какая-то политика? Какие требования законодательства должны соблюдаться?
Второй шаг — определить приоритеты. Какие данные являются наиболее критичными и требуют наибольшей защиты? Какие ИИ-системы используются наиболее часто? На какие проблемы нужно обратить внимание в первую очередь?
Третий шаг — разработать или обновить политику использования ИИ, как описано выше. Эта политика должна быть специфична для вашей компании, учитывать её особенности, отрасль, тип данных, которые она обрабатывает.
Четвертый шаг — выбрать ИИ-решение, которое соответствует требованиям политики. Это может быть комбинация публичных и корпоративных решений, в зависимости от задач.
Пятый шаг — обучить сотрудников. Убедитесь, что каждый сотрудник понимает политику и знает, как её соблюдать.
Шестой шаг — периодически проверять соответствие. Не один раз разработать политику, а постоянно её совершенствовать, обновлять, следить за тем, что сотрудники её соблюдают.
Безопасность данных при использовании ИИ — это не бремя, а конкурентное преимущество. Компания, которая надежно защищает данные, может использовать ИИ более смело, не боясь последствий утечек. Это позволяет ей получать большую ценность от ИИ-систем, чем конкуренты, которые рискуют своими данными.
Вопросы хранения и защиты корпоративных данных при использовании ИИ — это не один раз решенная проблема. Технология развивается, появляются новые угрозы, изменяется законодательство. Компания должна быть готова адаптироваться, учиться на опыте других, постоянно совершенствовать свои процессы. Но если компания будет следовать принципам, описанным в этой статье, она будет на правильном пути к безопасному и эффективному использованию ИИ-систем в своей работе.
