Бесплатный фрагмент - ИИ на работе без рисков: корпоративные правила и проверка качества

Глава 1. Зачем компании политика ИИ: управляемая безопасность и качество вместо хаоса

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

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

Ниже — зачем политика действительно нужна и как сделать её рабочей, а не декоративной.

Почему хаотичное использование ИИ опасно: утечки, ошибки, репутационные риски

Хаос с ИИ опасен не тем, что «кто-то где-то использует нейросеть», а тем, что компания теряет управляемость на трёх уровнях: данные, качество, ответственность.

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

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

Третий уровень — ответственность. При хаосе возникает опасная психологическая подмена: «так написала модель». Сотрудник начинает относиться к результату как к внешнему источнику, а не как к собственному продукту. Это разрушает дисциплину управления качеством: непонятно, кто проверял, кто утверждал, кто подписал. В момент инцидента выясняется, что «никто не отвечал», потому что никто не знал, где граница ответственности.

Политика ИИ закрывает все три уровня одним принципом: ИИ — инструмент, а не автор и не источник истины; данные — ресурс компании, а не расходный материал; ответственность — всегда на человеке и системе контроля.

Цель политики: безопасно ускорять работу, а не тормозить команду

Хорошая политика ИИ не воспринимается как «свод запретов». Она воспринимается как ускоритель. Если документ делает работу медленнее, его начнут обходить, и вы получите «теневое использование». Поэтому цель политики формулируется так, чтобы команда видела выгоду.

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

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

Что покрывает документ: люди, данные, доступы, инструменты, процессы, контроль

Чтобы политика работала, она должна охватывать весь контур, а не только «что можно писать в чат». Практически полезный документ всегда включает пять блоков.

Люди и роли. Кто отвечает за правила, кто администрирует инструменты, кто обучает, кто контролирует соблюдение, кто разбирает инциденты.

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

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

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

Контроль и метрики. Что логируется минимально, как фиксируются ошибки и инциденты, какие показатели смотрит руководство, как пересматриваются правила.

Если вы пропустите хотя бы один блок, политика будет «дырявой». Например, можно описать, что нельзя отправлять персональные данные, но если не определить инструменты и доступы, сотрудник всё равно будет пользоваться любым сервисом и считать, что «если я осторожно, то можно».

Что политика не делает: не заменяет ИБ и юриста, но задаёт правила поведения

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

Политика не заменяет: — требования ИБ к устройствам, паролям, корпоративным системам; — юридическую экспертизу договоров, претензий, документов; — внутренние регламенты по коммерческой тайне и персональным данным.

Но политика делает то, что часто отсутствует даже при сильной ИБ: переводит принципы в ежедневное поведение сотрудников. Она отвечает на вопросы «что делать в конкретной ситуации», «как безопасно ускорить задачу», «что точно нельзя», «кто должен проверить», «что делать при сомнении». Это мост между теорией и практикой.

Основные принципы: минимизация данных, ответственность человека, проверка фактов

У политики должно быть короткое ядро — несколько принципов, которые не меняются от отдела к отделу и от инструмента к инструменту. Практически применимы три.

Принцип минимизации данных. В ИИ отправляется только то, что необходимо для выполнения задачи. Не «всё письмо целиком», а выжимка. Не «полный договор», а пункт и контекст. Не «таблица с клиентами», а агрегированные показатели. Чем меньше данных уходит наружу, тем меньше поверхность риска.

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

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

Эти три принципа и создают ту самую «управляемую безопасность», которая не парализует работу.

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

Чтобы политика не была бумажной, у неё должен быть владелец. Владелец политики — это не обязательно ИБ или юрист. Это человек, который отвечает за то, что документ живёт, обновляется и реально применяется.

Минимальный набор ролей:

Владелец политики. Определяет рамки, запускает обновления, собирает обратную связь, утверждает изменения, ведёт реестр правил и приложений. Обычно это операционный руководитель, руководитель комплаенса, руководитель ИБ или выделенный ответственный за AI governance, если компания крупная.

Администратор инструментов. Управляет корпоративными аккаунтами, доступами, настройками, хранением истории, списком интеграций, запретом расширений, если это требуется. В небольших компаниях это часто ИТ-администратор.

Руководители подразделений. Переводят общие правила в практику отдела: определяют разрешённые сценарии, вводят обязательные проверки, назначают тех, кто утверждает материалы, и несут ответственность за соблюдение командой.

Дополнительно полезны: ответственный за обучение (может быть HR/внутренний тренер), ответственный за инциденты (часто ИБ), редактор/фактчекер для публичных материалов (маркетинг/PR).

Уровни допуска: кто и что может делать с ИИ

Одинаковая политика для всех сотрудников часто не работает. Разным ролям нужны разные режимы. Поэтому вводятся уровни допуска, которые привязаны к типам данных и видам задач.

Простой и практичный подход — три уровня:

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

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

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

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

Быстрый эффект: снижение самодеятельности и унификация промптов

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

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

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

Отдельная ценность — управляемый язык. В промптах появляются замены: CLIENT_A, PROJECT_B, CITY_X, BUDGET_X, DATE_RANGE. Люди перестают «сливать» конкретику, потому что им дали привычный шаблон.

Показатели эффективности: инциденты, скорость задач, качество

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

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

Скорость. Время на типовые задачи до и после внедрения: подготовка черновика письма, план документа, редактирование текста, подготовка инструкций, резюме встреч, анализ обращений. Здесь цель — не максимальная скорость любой ценой, а ускорение в разрешённом контуре.

Качество. Процент возвратов на доработку, число замечаний руководителя/редактора, доля материалов, прошедших проверку без правок, число ошибок в публичных текстах, уровень соответствия стандартам.

Дополнительно можно смотреть охват обучения: сколько сотрудников прошли вводный модуль и тест на понимание «красных линий». Но ключевое — инциденты, скорость и качество, потому что они отражают реальную управляемость.

Артефакт: одностраничная карта «что разрешено / что запрещено / как проверяем»

Чтобы политика стала частью ежедневной работы, ей нужен простой «передний лист», который можно открыть за минуту. Ниже — формат такой карты. Это не замена политики, а оперативная памятка.

Что разрешено

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

Что запрещено

Запрещено передавать в ИИ и использовать ИИ для действий, связанных с критическими данными и обходом контроля: — пароли, ключи, токены, конфигурации доступа, коды подтверждения; — персональные данные клиентов и сотрудников: ФИО, телефоны, e-mail, адреса, паспортные данные, идентификаторы, аккаунты; — клиентские базы, выгрузки CRM, списки контактов, скриншоты с персональными данными; — коммерческую тайну и внутренние финансовые детали в разрезе людей/клиентов/зарплат/платежей без утверждённого безопасного режима; — договоры и юридические документы целиком без обезличивания и без согласованного инструмента; — просьбы к ИИ о том, как обойти ограничения безопасности, скрыть следы или нарушить правила.

Как проверяем результат

Минимальная проверка перед использованием результата ИИ в работе: — Факты: каждое утверждение, которое влияет на решение, подтверждается исходными данными компании или надёжным источником внутри контуров компании. — Цифры: пересчёт, проверка единиц измерения, сверка с исходной таблицей, исключение «красивых» округлений без основания. — Логика: проверка причинно-следственных связей, отсутствие подмены понятий, корректность выводов. — Риски: нет ли случайного раскрытия данных, нет ли формулировок, которые могут быть трактованы как обязательство компании. — Ответственность: сотрудник указывает, что материал подготовлен с помощью ИИ, и подтверждает, что проверил; руководитель утверждает там, где требуется.

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

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

83

Глава 2. Классификация данных: что можно давать ИИ, а что нельзя никогда

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

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

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

Публичные данные: можно, но проверяем актуальность

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

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

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

Практическое правило для команды: публичные данные подходят для «упаковки» и редакторики, но не освобождают от сверки того, что может измениться.

Внутренние данные: можно с ограничениями и обезличиванием

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

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

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

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

Конфиденциальные: только в утверждённых режимах или нельзя

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

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

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

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

Коммерческая тайна: критерии, примеры, ответственность

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

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

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

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

Персональные данные: что считать ПДн и почему риск высокий

Персональные данные — одна из самых опасных зон для импровизации. Проблема в том, что сотрудники часто воспринимают персональные данные как «паспорт и СНИЛС», а реальность шире. Персональные данные — это любая информация, которая относится к определённому или определяемому человеку. Определяемость возникает не только по ФИО, но и по сочетанию признаков: телефон, e-mail, никнейм, аккаунт, адрес, фотография, идентификаторы устройства, данные заказов, история обращений, должность в маленькой команде, уникальная комбинация обстоятельств.

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

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

Финансовые данные: счета, обороты, зарплаты — особый режим

Финансовые данные опасны не только сами по себе, но и из-за их концентрации: один файл или один фрагмент переписки может содержать одновременно суммы, реквизиты, контрагентов, сроки, условия и внутренние комментарии. Даже если это не «коммерческая тайна» в строгом смысле, последствия утечки или неправильной трактовки могут быть тяжёлыми.

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

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

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

Доступы и секреты: пароли, ключи, токены — абсолютный запрет

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

Причина проста: секрет — это не «информация», это «ключ от двери». Утечка ключа превращает любой другой контроль в бессмысленный.

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

Клиентские материалы: договоры, базы, переписки — по правилам

Клиентские материалы — самый частый источник ошибок, потому что команда работает с ними ежедневно и привыкает к деталям. Договор, коммерческое предложение, переписка, заявки, обращения в поддержку, выгрузки из CRM, отчёты по проекту — всё это может включать персональные данные, коммерческую тайну клиента, финансовые детали и юридические обязательства.

Политика должна вводить для клиентских материалов правило повышенной осторожности: по умолчанию такие данные не уходят в ИИ. Допустимость появляется только после подготовки материала и по понятным сценариям.

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

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

Ошибка: считать, что «если удалить имя — уже безопасно»

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

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

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

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

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

Публичные данные. Что это: опубликованные материалы без внутренней конкретики. Разрешено: черновики, структура, редактура, варианты формулировок. Условия: сверка актуальности для меняющихся деталей; финальная вычитка человеком. Запрещено: добавлять в промпт внутренние данные «для контекста».

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

Конфиденциальные данные. Что это: договорные условия, внутренние планы, чувствительная аналитика, условия с контрагентами. Разрешено: ограниченно и только по утверждённым сценариям. Условия: либо глубокое обезличивание и выжимка, либо работа в утверждённом инструменте с контролем; обязательная проверка и согласование. Запрещено: передавать в открытые внешние сервисы в исходном виде.

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

Персональные данные. Что это: любая информация о определяемом человеке. Разрешено: только обезличенные агрегаты и выжимки, в которых исключена идентификация; сценарии должны быть заранее описаны. Условия: удаление прямых и косвенных идентификаторов; запрет на скриншоты и выгрузки; проверка перед отправкой. Запрещено: ФИО, телефоны, e-mail, адреса, аккаунты, ID, история обращений в исходном виде.

Финансовые данные повышенного риска. Что это: реквизиты, счета, платежи, зарплаты, бюджеты с детализацией. Разрешено: обсуждение логики и структуры на уровне описания задачи; агрегированные показатели при необходимости. Условия: исключение реквизитов и контрагентов; избегать детализации по людям; согласование для чувствительных материалов. Запрещено: первичные документы, отчёты с детализацией, зарплатные ведомости, банковские данные.

Секреты доступа. Что это: пароли, токены, ключи, конфиги с секретами, коды 2FA. Разрешено: нет. Условия: отсутствуют. Запрещено: всегда и в любом инструменте без исключений.

Клиентские материалы. Что это: договоры, базы, переписки, заявки, обращения, отчёты по проектам с конкретикой. Разрешено: выжимка без идентификаторов; подготовка структуры ответа; редактура формулировок без обязательств. Условия: обезличивание; минимизация; запрет на исходники; финальная проверка ответственным сотрудником; при необходимости точных данных — только утверждённый режим. Запрещено: выгрузки CRM, переписки со подписями и контактами, договоры целиком без подготовки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор инструмента нельзя строить только на качестве ответов. Нужны управленческие и технические критерии, иначе вы получите «лучший ИИ» без контроля.

Набор практичных критериев:

Корпоративное управление аккаунтами. Возможность создавать корпоративные учётные записи, управлять пользователями, группами и правами, отключать доступ, иметь отдельные рабочие пространства.
Контроль доступа и аутентификация. Поддержка SSO (если есть), обязательная MFA, политика паролей, управление сессиями.
Настройки приватности и использования данных. Возможность настроить, как обрабатываются запросы и сохраняется ли история. Даже если компания не может контролировать всё, должна быть возможность зафиксировать режим и обучить сотрудников его понимать.
Работа с файлами и ограничениями. Если инструмент позволяет загружать файлы, нужно понимать, где они хранятся, кто имеет доступ, можно ли ограничить загрузку для определённых групп.
Интеграции и плагины. Возможность отключить или ограничить внешние интеграции. Чем больше свободы у пользователей в подключении сторонних сервисов, тем выше риск.
Логи и аудит. Даже минимальные журналы активности (кто входил, когда, с каких устройств) полезны. Если инструмент вообще не даёт никакой наблюдаемости, он подходит только для низкорисковых сценариев.
Юрисдикция и соответствие требованиям компании. Не всегда это решающий фактор, но для некоторых отраслей критично, где хранится информация и как поставщик описывает обработку данных.

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

Роли и доступы: как выдавать права, чтобы не «все админы»

Типовая ошибка маленьких компаний: либо вообще нет админов (все сами как-то пользуются), либо «все админы», потому что так проще. Оба варианта плохи.

Рабочая схема обычно включает три уровня:

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

Руководитель/тимлид (расширенный пользователь). Может управлять библиотеками шаблонов, утверждать использование для задач своего отдела, видеть материалы, которые команда готовит к публикации (если это встроено в процесс), но не управляет системными настройками.

Администратор. Управляет доступами, настройками рабочего пространства, политиками хранения, интеграциями, устройствами (если поддерживается). Администраторов должно быть минимально необходимое число, а их действия должны быть регламентированы.

Отдельно следует выделить владельца политики (из предыдущей главы). Он не всегда администратор инструмента, но он отвечает за то, какие роли существуют и какие права им доступны.

MFA, SSO, корпоративная почта: минимальный стандарт

Даже если компания небольшая, минимальный стандарт должен быть одинаковым:

Корпоративная почта как единственный способ регистрации. Никаких личных Gmail/Яндекс для рабочих аккаунтов. Это упрощает контроль и отзыв доступа.

Обязательная двухфакторная аутентификация. Не «по желанию», а обязательная. Это один из самых дешёвых способов снизить риск компрометации.

Единый способ входа (SSO), если он есть. Если SSO нет, достаточно корпоративной почты + MFA + политика паролей. Главное — чтобы у компании была возможность быстро отключить доступ сотруднику.

Политика должна прямо описывать: если сотрудник не включил MFA, доступ к инструменту не предоставляется. Это не «бюрократия», это защита от банальных взломов.

История, экспорт, файлы: контроль того, что остаётся после работы

Большая часть чувствительных утечек происходит не в момент запроса, а потом — когда история чатов сохраняется, экспортируется или пересылается.

Политика должна зафиксировать три вещи.

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

Экспорт. Запрет или ограничение экспорта переписок и результатов, если в них могут быть внутренние детали. Там, где экспорт нужен, он делается в утверждённое хранилище компании (корпоративный диск/внутренний wiki), а не «на рабочий стол» и не в личные мессенджеры.

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

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

Расширения, плагины, боты: почему они опаснее, чем кажется

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

Типовые риски: — расширение считывает содержимое страниц и отправляет в обработку без осознания пользователя; — бот в мессенджере получает доступ к рабочим перепискам; — плагин получает доступ к корпоративному диску или почте; — интеграция «для удобства» открывает дверь к данным, которые не должны покидать контур.

Политика должна занять жёсткую позицию: любые расширения, плагины, боты и интеграции допускаются только после утверждения администратором и владельцем политики. Самостоятельная установка запрещена. Для большинства сотрудников — запрет по умолчанию.

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

Рабочие пространства и отдельные «контуры»: разделяем задачи по риску

Практичный способ не тормозить команду — разделить работу на контуры по уровню риска.

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

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

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

Это позволяет избежать крайностей. Если компания делает один общий контур, она либо будет слишком мягкой (и риски высокие), либо слишком жёсткой (и сотрудники уйдут в «теневой ИИ»).

Управление подключением новых инструментов: процесс, а не разовое решение

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

Минимальный рабочий процесс:

Инициатор (сотрудник/руководитель) подаёт запрос на добавление инструмента с описанием задач: зачем нужен, какие данные будут использоваться, есть ли интеграции, какие альтернативы уже есть.
Администратор/ИТ оценивает техническую часть: управление аккаунтами, доступы, MFA, ограничения, интеграции, возможность контроля.
Владелец политики и ИБ/юрист (если требуется) оценивают риски по данным и соответствие правилам компании.
Решение: добавить в белый список, добавить с ограничениями (только контур А/только определённые роли), или запретить.
Обновление приложений к политике: инструмент появляется в списке разрешённых, появляются правила использования и краткая инструкция.
Обучение: короткое уведомление команде, что появилось, что можно, что нельзя.

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

Артефакт: приложение к политике «Инструменты и доступы» (шаблон)

Ниже — шаблон, который можно вставить в политику как приложение. Он задаёт структуру и снижает риск «дыр».

Белый список инструментов — Инструмент 1: название, ссылка на внутреннюю инструкцию, разрешённые контуры (А/В/С), разрешённые роли (базовый/расширенный/спец), запреты (файлы/плагины/экспорт). — Инструмент 2: аналогично. — Инструмент 3: аналогично.
Общие требования к аккаунтам — Используется только корпоративная почта. — Обязательная MFA. — Запрещено использование личных аккаунтов для рабочих задач (кроме публичных и общих вопросов, если компания это допускает, но тогда нужно прямо прописать границу). — При увольнении доступ отзывается в день прекращения работы, история и рабочие пространства очищаются по регламенту.
Роли и права — Пользователь: базовые функции, без интеграций, без изменения настроек, без приглашений внешних пользователей. — Руководитель: управление шаблонами и процессом внутри отдела, без системных прав. — Администратор: управление пользователями, группами, настройками, ограничениями, аудитом.
Файлы и загрузки — Запрещено загружать документы с персональными данными, коммерческой тайной, клиентскими договорами. — Разрешено загружать только публичные и обезличенные материалы (в контуре А/В), если инструмент утверждён для этого. — Любые исключения оформляются через специальный режим (контур С) и фиксируются.
Плагины, расширения, боты — Запрещены по умолчанию. — Разрешаются только после утверждения администратора и владельца политики. — Самостоятельная установка расширений и подключение ботов к рабочим перепискам запрещены.
Экспорт и распространение результатов — Результаты ИИ, содержащие внутренние детали, хранятся только в утверждённом корпоративном хранилище. — Запрещено пересылать такие результаты в личные мессенджеры и личные почтовые ящики. — Экспорт истории чатов допускается только при необходимости и по регламенту.
Процесс добавления нового инструмента — Заявка → оценка → решение → обновление белого списка → обучение.

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

Глава 4. Разрешённые сценарии: как встроить ИИ в процессы и не допустить «автопилота»

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

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

Что такое «сценарий» в политике ИИ и зачем он нужен

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

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

Хороший набор сценариев строится не по отделам, а по типам задач. Потому что одни и те же задачи встречаются в продажах, поддержке, маркетинге и руководстве: переписка, документы, анализ, планирование, регламенты, отчёты.

Базовые разрешённые сценарии (контур А): публичные и низкорисковые задачи

Контур А — это зона, где скорость важнее всего, а риск минимален, потому что данные публичные или нейтральные. Здесь цель политики — разрешить и стандартизировать, чтобы сотрудники не уходили в теневые инструменты.

Сценарий 1. Черновики писем и сообщений без чувствительных данных. Что можно отправлять: описание ситуации без имён, реквизитов, сумм, номеров договоров, без цитирования клиентских писем целиком. Что просим у ИИ: 2–3 варианта сообщения (нейтральный/деловой/жёсткий), структура, вопросы к собеседнику. Проверка: смысл, тон, отсутствие обещаний от имени компании, корректность фактов. Ответственный: автор сообщения. Где хранить: в корпоративной переписке; промпт не сохраняем как «источник истины».

Сценарий 2. Редактирование текста (ясность, стиль, логика) для внутренних и публичных материалов. Что можно отправлять: текст без конфиденциальной конкретики; допускается публичный текст целиком. Что просим: улучшить структуру, убрать повторы, сделать короче/понятнее, предложить заголовки. Проверка: смысл не исказился, факты сохранились, нет «новых утверждений». Ответственный: автор + редактор/руководитель, если материал публичный.

Сценарий 3. Планирование и структурирование документов. Что можно отправлять: описание цели документа и аудитории; список тем; ограничения. Что просим: оглавление, логика разделов, чек-лист, план презентации/отчёта. Проверка: полнота, соответствие задаче, отсутствие лишних разделов, применимость к реальности компании. Ответственный: владелец документа.

Сценарий 4. Мозговой штурм идей и вариантов. Что можно отправлять: общая постановка задачи без внутренних деталей. Что просим: 20–50 идей, группировка, критерии выбора, риски. Проверка: реалистичность, соответствие ограничениям компании, отбраковка фантазий. Ответственный: инициатор задачи.

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

Разрешённые сценарии с обезличиванием (контур B): внутренние рабочие процессы

Контур B — это зона, где данные уже внутренние, но их можно безопасно использовать, если правильно подготовить. Здесь важен навык обезличивания и правило «выжимка вместо исходника».

Сценарий 5. Подготовка SOP и регламентов из хаотичных заметок. Что можно отправлять: обезличенное описание процесса; роли без имён («менеджер», «координатор»); шаги без названий клиентов; вместо сумм — диапазоны или категории. Что просим: оформить в структуру SOP: цель, входы/выходы, шаги, ответственные, чек-листы, типовые ошибки. Проверка: соответствие реальному процессу, выполнимость, отсутствие «выдуманных» шагов, согласование с владельцем процесса. Ответственный: владелец процесса/руководитель отдела.

Сценарий 6. Анализ типовых обращений (поддержка/продажи) без персональных данных. Что можно отправлять: обезличенные выдержки; удалены имена, контакты, ID, ссылки на профили; уникальные детали замены на «CLIENT_X». Что просим: классификация причин обращений, типовые возражения, предложения по шаблонам ответов, список улучшений процесса. Проверка: не появились «факты» из воздуха; рекомендации применимы; шаблоны не содержат обещаний/юридических формулировок. Ответственный: руководитель поддержки/продаж.

Сценарий 7. Внутренние отчёты и резюме встреч. Что можно отправлять: конспект без персональных данных и без точных коммерческих условий; допускается общая структура и решения. Что просим: резюме, список задач, риски, вопросы, следующие шаги, владельцы задач. Проверка: корректность решений и поручений; соответствие договорённостям. Ответственный: ведущий встречи/PM.

Сценарий 8. Подготовка обучающих материалов для команды. Что можно отправлять: обезличенные кейсы, принципы, чек-листы; без клиентских деталей. Что просим: структурировать в урок, добавить вопросы для самопроверки, упражнения. Проверка: соответствие внутренним стандартам, отсутствие спорных утверждений. Ответственный: владелец обучения/руководитель.

Ключевой элемент контура B — обязательное правило: если сотрудник не уверен, что обезличил достаточно, он не отправляет материал в ИИ, а превращает его в более общий описательный запрос.

Сценарии повышенного риска (контур C): только по специальным правилам

Контур C — это зона, где в задачи часто вовлечены конфиденциальные данные: юридические документы, договоры, точные коммерческие условия, финансовая детализация, чувствительная аналитика. Большинство компаний выигрывает, если честно признаёт: здесь ИИ либо не используется, либо используется строго в ограниченном режиме.

Политика должна описать, что контур C допускается только: — для ограниченного круга ролей; — в утверждённом инструменте; — с запретом на вставку исходников целиком, если это не предусмотрено специальной процедурой; — с обязательной проверкой и согласованием результата; — с фиксацией ответственности.

Примеры сценариев контура C:

Сценарий 9. Подготовка юридических формулировок. Разрешено: просить варианты формулировок на уровне принципа, без вставки договора целиком; анализ логики пункта; выявление неоднозначностей. Запрещено: «сделай договор», «проверь договор целиком», «вставляю весь текст», если нет защищённого режима. Проверка: обязательная проверка юристом/ответственным, потому что юридическая точность — зона высокой цены ошибки. Ответственный: юрист/руководитель, утверждающий документ.

Сценарий 10. Финансовые расчёты и бюджеты. Разрешено: структура бюджета, логика статей, методика расчёта, проверка формул на уровне описания. Запрещено: отправка первички, реквизитов, зарплат, детализации по людям/контрагентам. Проверка: пересчёт, сверка с источником истины, подтверждение руководителем финансов. Ответственный: финансы/руководитель.

Сценарий 11. Аналитика по клиентским проектам с конкретикой. Разрешено: обезличенные выводы, агрегированные данные, методика анализа. Запрещено: выгрузки CRM и детальные клиентские таблицы. Проверка: сверка с данными, отсутствие раскрытия клиента. Ответственный: руководитель проекта/аналитик.

Контур C нужен, чтобы компания не уходила в крайность «запретить всё». Но он должен быть редким и строго управляемым.

Что запрещено сценарно: список действий, которые ломают безопасность

Чтобы избежать «серых зон», политика должна запрещать не только типы данных, но и типы действий. Ниже — действия, которые почти всегда приводят к проблемам.

Запрещено отправлять в ИИ исходники документов и переписок целиком, если это не публичный материал и не обезличенная версия. «Целиком» опасно тем, что там всегда есть лишнее: подписи, реквизиты, уникальные детали.

Запрещено использовать ИИ как источник фактов без проверки. Если сотрудник вставляет в письмо статистику или юридическое утверждение, потому что «так сказал ИИ», это прямой путь к ошибкам.

Запрещено публиковать текст, созданный ИИ, без человеческой вычитки и ответственности. Неважно, насколько он «красиво звучит». Публикация без проверки — это перенос ответственности на инструмент, что для компании неприемлемо.

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

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

Цепочка проверки: как не допустить «автопилота» в публикациях и клиентских коммуникациях

Главный практический механизм против автопилота — обязательная цепочка проверки для материалов, которые выходят за пределы «черновика для себя». Политика должна чётко разделять уровни результата:

Черновик. Можно делать быстро. Но черновик не отправляется наружу.

Внутренний рабочий документ. Требует проверки фактов и логики автором и, при необходимости, руководителем.

Клиентский материал/публичный материал. Требует обязательной проверки по чек-листу и утверждения ответственным лицом.

Минимальный чек-лист перед отправкой клиенту или публикацией: — Нет ли в тексте раскрытия данных: имён, контактов, реквизитов, уникальных деталей? — Все ли факты подтверждены источником истины? — Нет ли обещаний и обязательств от имени компании, которые не согласованы? — Нет ли юридически опасных формулировок (гарантии, сроки, ответственность), если это не утверждено? — Соответствует ли тон бренду и стандартам коммуникации? — Явно ли отделены гипотезы от фактов, если есть предположения? — Понимает ли ответственный, что он подписывается под текстом, а не «ИИ»?

Если компания внедрит только этот чек-лист и правило «клиентское и публичное — всегда через проверку», число инцидентов и репутационных ошибок обычно падает кратно.

Как встроить сценарии в ежедневную работу: шаблоны и «быстрые кнопки»