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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разрешено использовать ИИ для черновиков и подготовки материалов, если не передаются чувствительные данные:

– черновики писем и сообщений, где нет персональных данных, реквизитов, конкретных условий договоров;

– структурирование текста: план, оглавление, логика разделов, улучшение ясности;

– редактирование: стиль, тональность, сокращение воды, устранение повторов;

– генерация вариантов формулировок для внутренних документов без конкретных данных;

– подготовка SOP и регламентов на основе обезличенных описаний процессов;

– анализ идей и гипотез при условии последующей проверки исходными данными;

– переводы и локализация текстов, если содержание не относится к конфиденциальным материалам.

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

Запрещено передавать в ИИ и использовать ИИ для действий, связанных с критическими данными и обходом контроля:

– пароли, ключи, токены, конфигурации доступа, коды подтверждения;

– персональные данные клиентов и сотрудников: ФИО, телефоны, e-mail, адреса, паспортные данные, идентификаторы, аккаунты;

– клиентские базы, выгрузки CRM, списки контактов, скриншоты с персональными данными;

– коммерческую тайну и внутренние финансовые детали в разрезе людей/клиентов/зарплат/платежей без утверждённого безопасного режима;

– договоры и юридические документы целиком без обезличивания и без согласованного инструмента;

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

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

Минимальная проверка перед использованием результата ИИ в работе:

– Факты: каждое утверждение, которое влияет на решение, подтверждается исходными данными компании или надёжным источником внутри контуров компании.

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

– Логика: проверка причинно-следственных связей, отсутствие подмены понятий, корректность выводов.

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

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

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

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

83

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

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

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

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

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

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

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

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

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

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

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

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

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