Самый большой риск ИИ не в модели, а в неконтролируемом внедрении

Использование и внедрение ИИ может быть подобно Дикому Западу, если оставить его без контроля в организации.

Эта проблема стала все более серьезной, поскольку внедрение продолжает ускоряться быстрее, чем большинство циклов управления. Вызов для команд ИТ и соблюдения правил заключается в том, что новые инструменты могут быть развернуты за несколько дней, в то время как политики и контроли часто требуют месяцев для разработки и распространения. Многие предприятия считают, что они справились с риском ИИ, одобрив короткий список санкционированных инструментов, но есть многое другое, чтобы обеспечить, что ИИ можно использовать, контролировать и измерять с защитой конфиденциальности и безопасности. Примеры такого сценария “теневого ИТ” включают в себя принятие бизнес-единицами дополнительных платформ без рассмотрения, запуск разработчиками моделей на местном уровне и вставку сотрудниками конфиденциальных данных в открытые системы или системы с неясными правами на данные. Результат не является теоретическим; это утечка данных, раскрытие интеллектуальной собственности и, в худшем случае, случайная передача прав через условия поставщика.

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

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

Рабочая группа по надзору за ИИ помогает закрыть этот разрыв в видимости, действуя как “ворота” управления организацией. Вместо того, чтобы разрешать инструментам и случаям ИИ распространяться без рассмотрения, комитет устанавливает процессы подачи заявок, рассмотрения и утверждения для новых технологий ИИ, оценивает риски и определяет соответствующие контроли на основе бизнес-потребностей и чувствительности данных.

Как списки одобренных инструментов терпят неудачу в практике

Списки одобренных инструментов ломаются, когда трение толкает людей к альтернативным инструментам, поскольку реальный риск заключается в использованных данных и рабочем процессе. Если санкционированный путь требует тикетов, VPN, более медленной производительности или ограниченных функций, команды будут обходить его. Тем временем услуги ИИ могут быть приняты по электронной почте и клику, часто без закупок, проверки безопасности или ясной видимости для ИТ. Самое главное, копирование исходного кода, данных клиентов или языка контракта в любую непроверенную систему может создать уязвимость и риск безопасности, независимо от того, является ли инструмент популярным или готовым для предприятия.

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

Связать допустимое использование ИИ с классификацией данных, а не с предпочтением инструмента

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

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

Это меняет разговор от “Этот инструмент в списке?” до “Какие данные вы вставляете в него, и какие последствия для прав, хранения и обучения?” Даже упрощенная модель достаточно, чтобы стимулировать последовательное поведение, если она сочетается с ясными примерами и подкрепляется ежедневно.

Сделать теневой ИИ видимым с помощью механизмов аудита, которые работают

Вы не можете управлять тем, что не видите. Видимость требует нескольких последовательных сигналов: контроли Cloud Access Security Broker (CASB) или Security Service Edge (SSE) для общих конечных точек ИИ, механизмы предотвращения утечки данных (DLP), настроенные на шаблоны вставки и загрузки ИИ, и контроли, основанные на идентификации, требующие единого входа (SSO), где это возможно, и флаги корпоративных идентификаторов, использующих несанкционированные услуги. В средах разработки добавьте телеметрию конечных точек, поскольку местное использование моделей может обойти веб-контроли. Дополните контроли легкими квартальными оценками того, какие инструменты используются, для каких рабочих процессов и какие типы данных они затрагивают.

Цель не состоит в том, чтобы достичь идеального покрытия или наказать эксперименты. Это выявить рискованные рабочие процессы на ранней стадии, расставить приоритеты и создать более безопасные альтернативы до того, как небезопасные модели станут нормальными операциями.

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

Ограничения, которые позволяют достичь скорости без ущерба для безопасности

Управление терпит неудачу, когда единственным ответом является “нет”. Зрелое управление создает быстрые пути и безопасные варианты: сценарное обучение с реальными примерами, ясные пути эскалации с соглашениями об уровне обслуживания (SLA), и короткая библиотека предварительно утвержденных случаев использования с примерами “что делать” и “что не делать”. Эти элементы снижают неоднозначность для сотрудников и снижают принятие решений на основе интуиции для команд управления.

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

Обоснованный подход начинается с повторяющихся основ

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

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

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

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