Александр Костин – ИИ на работе без рисков: корпоративные правила и проверка качества (страница 4)

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

Поэтому правильная мысль для команды звучит так: безопасность – это не «убрать имя», а убрать возможность связать текст с конкретной стороной и убрать то, что не нужно для выполнения задачи. Если задачу можно решить на уровне принципа, её нельзя решать на уровне оригинального документа.

Артефакт: классификация данных и разрешённые действия

Ниже – рабочая текстовая матрица, которую можно перенести в политику как приложение и использовать в обучении. Она построена так, чтобы сотрудник мог быстро выбрать класс и понять режим.

Публичные данные.

Что это: опубликованные материалы без внутренней конкретики.

Разрешено: черновики, структура, редактура, варианты формулировок.

Условия: сверка актуальности для меняющихся деталей; финальная вычитка человеком.

Запрещено: добавлять в промпт внутренние данные «для контекста».

Внутренние данные.

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

Разрешено: структурирование, редактура, подготовка инструкций, шаблонов, планов.

Условия: минимизация; обезличивание; выжимка вместо исходника; исключение уникальных идентификаторов.

Запрещено: вставлять целиком документы и переписки.

Конфиденциальные данные.

Что это: договорные условия, внутренние планы, чувствительная аналитика, условия с контрагентами.

Разрешено: ограниченно и только по утверждённым сценариям.

Условия: либо глубокое обезличивание и выжимка, либо работа в утверждённом инструменте с контролем; обязательная проверка и согласование.

Запрещено: передавать в открытые внешние сервисы в исходном виде.

Коммерческая тайна.

Что это: сведения, дающие конкурентное преимущество и защищаемые компанией.

Разрешено: только если предусмотрен специальный режим и доказана необходимость; чаще всего – через обобщение и обезличивание.

Условия: согласование; минимизация; контроль доступа; фиксация ответственности.

Запрещено: отправка конкретных прайсов, маржинальности, условий поставщиков и ключевых клиентов.

Персональные данные.

Что это: любая информация о определяемом человеке.

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

Условия: удаление прямых и косвенных идентификаторов; запрет на скриншоты и выгрузки; проверка перед отправкой.

Запрещено: ФИО, телефоны, e-mail, адреса, аккаунты, ID, история обращений в исходном виде.

Финансовые данные повышенного риска.

Что это: реквизиты, счета, платежи, зарплаты, бюджеты с детализацией.

Разрешено: обсуждение логики и структуры на уровне описания задачи; агрегированные показатели при необходимости.

Условия: исключение реквизитов и контрагентов; избегать детализации по людям; согласование для чувствительных материалов.

Запрещено: первичные документы, отчёты с детализацией, зарплатные ведомости, банковские данные.

Секреты доступа.

Что это: пароли, токены, ключи, конфиги с секретами, коды 2FA.

Разрешено: нет.

Условия: отсутствуют.

Запрещено: всегда и в любом инструменте без исключений.

Клиентские материалы.

Что это: договоры, базы, переписки, заявки, обращения, отчёты по проектам с конкретикой.

Разрешено: выжимка без идентификаторов; подготовка структуры ответа; редактура формулировок без обязательств.

Условия: обезличивание; минимизация; запрет на исходники; финальная проверка ответственным сотрудником; при необходимости точных данных – только утверждённый режим.

Запрещено: выгрузки CRM, переписки со подписями и контактами, договоры целиком без подготовки.

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

Глава 3. Доступы и инструменты: как выбрать «разрешённый ИИ» и не потерять контроль

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

Ключевая мысль: безопасность ИИ – это не «вежливость сотрудников», а архитектура доступа. Если архитектура правильная, сотрудник физически не может сделать большую часть ошибок. Если архитектуры нет, ошибки неизбежны, потому что людям нужно выполнять задачи быстро.

Почему «личные аккаунты» – главный источник риска

Личный аккаунт в ИИ-сервисе кажется безобидным: «я же просто спросил, как лучше сформулировать письмо». Но управленчески это сразу создаёт несколько проблем.

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

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

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

Четвёртое – неконтролируемые интеграции. Личные аккаунты часто позволяют подключать сторонние приложения, плагины, расширения и ботов. Это увеличивает поверхность атаки и делает невозможным единый стандарт безопасности.

Практическая позиция политики должна быть однозначной: работа с ИИ по рабочим задачам выполняется только через корпоративные аккаунты и утверждённые инструменты. Личные аккаунты либо запрещены для рабочих задач, либо разрешены только для «нулевого риска» сценариев (публичные данные и общие вопросы) – и это должно быть прописано чётко.

Модель управления инструментами: «белый список» вместо хаоса

Самый жизнеспособный подход – белый список инструментов. Компания утверждает перечень сервисов, которые разрешены для работы, и правила их использования. Всё остальное считается запрещённым по умолчанию, даже если «вроде бы удобно».

Белый список даёт управляемость:

– можно централизованно выдавать доступы и отзывать их;

– можно назначать администраторов;

– можно обучать сотрудников конкретному набору инструментов;

– можно описать режимы по уровням данных;

– можно внедрить минимальные контрольные меры.

Важно: белый список не обязан быть большим. Для большинства компаний достаточно 1–3 основных инструмента и 1–2 специализированных для отдельных задач. Чем больше зоопарк, тем выше риск и тем сложнее обучение.

Критерии выбора «разрешённого ИИ» для компании