Если вы отвечаете за безопасность данных, вы прямо сейчас сталкиваетесь с подобной проблемой. Сотрудники передают контент ИИ-ассистентам, подключают ИИ-инструменты к общим дискам и встраивают ИИ-функции в продукты — зачастую быстрее, чем вы успеваете это проверить, если вас вообще просят об этом. Вы хотите поддержать внедрение ИИ, а не блокировать его. Но вы также не можете отвечать согласием на каждый запрос, не зная, какие конфиденциальные данные могут быть раскрыты.
Именно в таком положении сегодня оказываются многие команды по безопасности и конфиденциальности данных.
Откуда на самом деле берется ваш риск
Риск утечки данных — это не всегда одна большая ошибка. Скорее, это похоже на вазу с мелкими трещинами: ни одна трещина сама по себе не разобьет ее, но достаточное количество мелких — да. Например, экспорт службы поддержки с личными данными, вставленный в чат-бот для быстрого создания резюме, общий диск с контрактами, подключенный к инструменту поиска на основе ИИ, который никто полностью не проверял, или обучающий набор данных, содержащий информацию, которую никто не пометил как конфиденциальную.
Вам не нужно, чтобы каждый сценарий использования ИИ превращался в инцидент безопасности данных, чтобы столкнуться с реальной проблемой экспозиции. Если вы не можете с уверенностью ответить, какие конфиденциальные данные существуют в вашей среде и где ИИ-инструменты могут получить к ним доступ, вы уже несете риски, которые невозможно оценить количественно, не говоря уже об их управлении.
Почему отказ на каждый запрос — это не стратегия
Блокировка или затягивание каждого ИИ-запроса соблазнительна, потому что кажется более безопасной. Но обычно это дает обратный результат. Когда согласование занимает слишком много времени, сотрудники не перестают использовать ИИ. Они просто перестают спрашивать. Теневой ИИ, включая инструменты и интеграции, о которых вы не знаете, часто является результатом процесса проверки, который не поспевал за событиями или вообще никогда не существовал.
Если ваша цель — защитить конфиденциальные данные, то роль отдела, который говорит «нет» всему, приводит к противоположному результату: снижению прозрачности, а не ее повышению. Эффективная безопасность данных ИИ зависит от этой прозрачности — нельзя защитить то, чего вы не видите.
Что необходимо подготовить, прежде чем вы сможете давать согласие быстрее
Быстрое и безопасное утверждение сценариев использования ИИ сводится к знанию ответов на несколько вопросов до того, как запрос поступит в вашу команду:
- Где хранятся конфиденциальные данные? Вам необходима прозрачность в отношении структурированных и неструктурированных данных, включая облачные приложения, общие диски и репозитории, которые ваши команды уже используют, а не только те системы, под которые вы изначально разрабатывали политики.
- Что это за данные? Классификация говорит вам, содержит ли конкретный набор данных персональные данные, финансовые записи, медицинскую информацию или интеллектуальную собственность. Таким образом, вы не будете относиться к таблице с контактами для прессы так же, как к базе данных клиентских записей.
- Кто и что имеет к ним доступ? Контроль доступа должен напрямую учитывать ИИ-инструменты и интеграции, а не только пользователей-людей, так как именно здесь часто возникает брешь.
- Меняется ли что-нибудь? Постоянно появляются новые файлы, новые репозитории и новые ИИ-подключения. Разовый аудит говорит вам о том, что было актуально шесть месяцев назад, а не о том, что происходит сегодня.
Когда вы можете ответить на эти вопросы до поступления запроса, команды могут быстрее оценивать многие сценарии использования ИИ, поскольку вам не нужно начинать расследование с самого начала.
Как это выглядит на практике
Допустим, ваша маркетинговая команда хочет подключить инструмент для написания текстов на базе ИИ к вашей системе управления контентом. Без видимости того, что там хранится, этот запрос застревает — ни у кого нет времени проверять его вручную. Если же обнаружение и классификация данных уже настроены, вы можете оценить репозиторий более эффективно и соответственно одобрить или скорректировать запрос.
В этом разница между безопасностью данных как узким местом и безопасностью данных как драйвером. Это означает поддержание ваших стандартов при одновременном получении прозрачности для их быстрого применения.
Начните с прозрачности, а не с дополнительных согласований
Если вы пытаетесь защитить конфиденциальные данные, не становясь причиной пробуксовки ИИ-проектов, решением проблемы обычно является не более длительный процесс проверки. Это лучшая видимость ваших данных до того, как эти запросы вообще поступят. Начните с понимания того, какие конфиденциальные данные у вас есть, где они хранятся и где они сегодня подвержены рискам со стороны ИИ-инструментов. Это фундамент, который позволяет вам защитить то, что важно, и идти в ногу с командами, которые рассчитывают на ваше согласие.
Надежная безопасность данных ИИ заключается не в замедлении работы команд, а в наличии прозрачности, позволяющей быстро сказать «да» и отвечать за свои слова.
Мутахарра Миан
Мутахарра Миан — менеджер по продуктовому маркетингу в компании OpenText, специализирующаяся на безопасности данных, конфиденциальности и анализе рисков. В настоящее время она руководит продуктовым маркетингом OpenText Voltage DSP, помогая организациям обнаруживать конфиденциальные данные, оценивать риски и усиливать инициативы по обеспечению соответствия требованиям. Учитывая растущую важность управления и защиты данных, Мутахарра стремится помочь клиентам получить видимость и аналитическую информацию, необходимую для принятия обоснованных решений по безопасности и снижения организационных рисков.
