Александр Костин – ИИ на работе без рисков: корпоративные правила и проверка качества (страница 5)
Выбор инструмента нельзя строить только на качестве ответов. Нужны управленческие и технические критерии, иначе вы получите «лучший ИИ» без контроля.
Набор практичных критериев:
Корпоративное управление аккаунтами. Возможность создавать корпоративные учётные записи, управлять пользователями, группами и правами, отключать доступ, иметь отдельные рабочие пространства.
Контроль доступа и аутентификация. Поддержка SSO (если есть), обязательная MFA, политика паролей, управление сессиями.
Настройки приватности и использования данных. Возможность настроить, как обрабатываются запросы и сохраняется ли история. Даже если компания не может контролировать всё, должна быть возможность зафиксировать режим и обучить сотрудников его понимать.
Работа с файлами и ограничениями. Если инструмент позволяет загружать файлы, нужно понимать, где они хранятся, кто имеет доступ, можно ли ограничить загрузку для определённых групп.
Интеграции и плагины. Возможность отключить или ограничить внешние интеграции. Чем больше свободы у пользователей в подключении сторонних сервисов, тем выше риск.
Логи и аудит. Даже минимальные журналы активности (кто входил, когда, с каких устройств) полезны. Если инструмент вообще не даёт никакой наблюдаемости, он подходит только для низкорисковых сценариев.
Юрисдикция и соответствие требованиям компании. Не всегда это решающий фактор, но для некоторых отраслей критично, где хранится информация и как поставщик описывает обработку данных.
Политика не обязана включать технические детали по каждому пункту, но должна фиксировать, что инструмент допускается в белый список только после оценки по критериям, и кто эту оценку проводит.
Роли и доступы: как выдавать права, чтобы не «все админы»
Типовая ошибка маленьких компаний: либо вообще нет админов (все сами как-то пользуются), либо «все админы», потому что так проще. Оба варианта плохи.
Рабочая схема обычно включает три уровня:
Пользователь. Может использовать инструмент в рамках разрешённых сценариев. Не может подключать плагины, менять настройки приватности, приглашать внешних пользователей, расшаривать пространства, выгружать журналы, экспортировать истории.
Руководитель/тимлид (расширенный пользователь). Может управлять библиотеками шаблонов, утверждать использование для задач своего отдела, видеть материалы, которые команда готовит к публикации (если это встроено в процесс), но не управляет системными настройками.
Администратор. Управляет доступами, настройками рабочего пространства, политиками хранения, интеграциями, устройствами (если поддерживается). Администраторов должно быть минимально необходимое число, а их действия должны быть регламентированы.
Отдельно следует выделить владельца политики (из предыдущей главы). Он не всегда администратор инструмента, но он отвечает за то, какие роли существуют и какие права им доступны.
MFA, SSO, корпоративная почта: минимальный стандарт
Даже если компания небольшая, минимальный стандарт должен быть одинаковым:
Корпоративная почта как единственный способ регистрации. Никаких личных Gmail/Яндекс для рабочих аккаунтов. Это упрощает контроль и отзыв доступа.
Обязательная двухфакторная аутентификация. Не «по желанию», а обязательная. Это один из самых дешёвых способов снизить риск компрометации.
Единый способ входа (SSO), если он есть. Если SSO нет, достаточно корпоративной почты + MFA + политика паролей. Главное – чтобы у компании была возможность быстро отключить доступ сотруднику.
Политика должна прямо описывать: если сотрудник не включил MFA, доступ к инструменту не предоставляется. Это не «бюрократия», это защита от банальных взломов.
История, экспорт, файлы: контроль того, что остаётся после работы
Большая часть чувствительных утечек происходит не в момент запроса, а потом – когда история чатов сохраняется, экспортируется или пересылается.
Политика должна зафиксировать три вещи.
История. Сохраняется ли она по умолчанию, кто имеет к ней доступ, можно ли её удалять, как поступать при увольнении сотрудника. Даже если инструмент не позволяет централизованно управлять всем, политика должна предписывать регулярную чистку историй и запрет на хранение конфиденциальных данных в чате.
Экспорт. Запрет или ограничение экспорта переписок и результатов, если в них могут быть внутренние детали. Там, где экспорт нужен, он делается в утверждённое хранилище компании (корпоративный диск/внутренний wiki), а не «на рабочий стол» и не в личные мессенджеры.
Файлы. Загрузка файлов в ИИ – отдельный риск. Политика должна либо запретить загрузку файлов для большинства сотрудников, либо разрешить только для публичных и обезличенных материалов. Если файл содержит внутренние или клиентские данные – он не должен загружаться без специального режима.
Если компания ничего из этого не прописывает, реальная практика будет такой: сотрудники начнут хранить «удобные» ответы в чатах, отправлять ссылку коллегам, пересылать выдержки в мессенджерах, и через месяц возникнет сеть неконтролируемых копий.
Расширения, плагины, боты: почему они опаснее, чем кажется
Расширения браузера и боты – это «непредсказуемый слой». Они часто требуют доступ к страницам, вводимым данным, вкладкам, иногда к буферу обмена. Для ИИ-инструментов они добавляют ещё одну проблему: передача контента может происходить автоматически, без явного действия пользователя.
Типовые риски:
– расширение считывает содержимое страниц и отправляет в обработку без осознания пользователя;
– бот в мессенджере получает доступ к рабочим перепискам;
– плагин получает доступ к корпоративному диску или почте;
– интеграция «для удобства» открывает дверь к данным, которые не должны покидать контур.
Политика должна занять жёсткую позицию: любые расширения, плагины, боты и интеграции допускаются только после утверждения администратором и владельцем политики. Самостоятельная установка запрещена. Для большинства сотрудников – запрет по умолчанию.
Даже если это выглядит строгим, это единственный способ сохранить контроль. Иначе белый список инструментов превращается в фикцию: формально вы используете «разрешённый ИИ», но фактически через плагины и ботов данные уходят неизвестно куда.
Рабочие пространства и отдельные «контуры»: разделяем задачи по риску
Практичный способ не тормозить команду – разделить работу на контуры по уровню риска.
Контур А: общие задачи и публичные данные. Здесь максимальная скорость, минимум ограничений, но всё равно корпоративный аккаунт и запрет на персональные данные.
Контур B: внутренние обезличенные материалы. Здесь нужны шаблоны обезличивания, обязательная проверка и запрет на загрузку исходников.
Контур C: конфиденциальные сценарии. Здесь доступ ограничен, инструмент может быть отдельным, правила строже, включён контроль, возможно журналирование и обучение. В некоторых компаниях этот контур вообще реализуется не через универсальный чат, а через специализированные корпоративные решения.
Это позволяет избежать крайностей. Если компания делает один общий контур, она либо будет слишком мягкой (и риски высокие), либо слишком жёсткой (и сотрудники уйдут в «теневой ИИ»).
Управление подключением новых инструментов: процесс, а не разовое решение
ИИ-инструменты меняются быстро. Если политика фиксирует раз и навсегда конкретный сервис без процесса добавления новых, она устареет. Поэтому важно описать простой цикл «появился новый инструмент – как мы решаем, можно ли его использовать».
Минимальный рабочий процесс:
Инициатор (сотрудник/руководитель) подаёт запрос на добавление инструмента с описанием задач: зачем нужен, какие данные будут использоваться, есть ли интеграции, какие альтернативы уже есть.
Администратор/ИТ оценивает техническую часть: управление аккаунтами, доступы, MFA, ограничения, интеграции, возможность контроля.
Владелец политики и ИБ/юрист (если требуется) оценивают риски по данным и соответствие правилам компании.
Решение: добавить в белый список, добавить с ограничениями (только контур А/только определённые роли), или запретить.
Обновление приложений к политике: инструмент появляется в списке разрешённых, появляются правила использования и краткая инструкция.
Обучение: короткое уведомление команде, что появилось, что можно, что нельзя.
Этот процесс не должен быть тяжёлым. Но он должен существовать. Иначе «разрешённый ИИ» будет жить на бумаге, а реальный набор инструментов – в браузерах сотрудников.
Артефакт: приложение к политике «Инструменты и доступы» (шаблон)
Ниже – шаблон, который можно вставить в политику как приложение. Он задаёт структуру и снижает риск «дыр».
Белый список инструментов
– Инструмент 1: название, ссылка на внутреннюю инструкцию, разрешённые контуры (А/В/С), разрешённые роли (базовый/расширенный/спец), запреты (файлы/плагины/экспорт).
– Инструмент 2: аналогично.
– Инструмент 3: аналогично.
Общие требования к аккаунтам
– Используется только корпоративная почта.
– Обязательная MFA.
– Запрещено использование личных аккаунтов для рабочих задач (кроме публичных и общих вопросов, если компания это допускает, но тогда нужно прямо прописать границу).