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

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

Роли и права

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

– Руководитель: управление шаблонами и процессом внутри отдела, без системных прав.

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

Файлы и загрузки

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

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

– Любые исключения оформляются через специальный режим (контур С) и фиксируются.

Плагины, расширения, боты

– Запрещены по умолчанию.

– Разрешаются только после утверждения администратора и владельца политики.

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

Экспорт и распространение результатов

– Результаты ИИ, содержащие внутренние детали, хранятся только в утверждённом корпоративном хранилище.

– Запрещено пересылать такие результаты в личные мессенджеры и личные почтовые ящики.

– Экспорт истории чатов допускается только при необходимости и по регламенту.

Процесс добавления нового инструмента

– Заявка → оценка → решение → обновление белого списка → обучение.

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

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

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

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

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

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

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

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

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

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

Сценарий 1. Черновики писем и сообщений без чувствительных данных.

Что можно отправлять: описание ситуации без имён, реквизитов, сумм, номеров договоров, без цитирования клиентских писем целиком.

Что просим у ИИ: 2–3 варианта сообщения (нейтральный/деловой/жёсткий), структура, вопросы к собеседнику.

Проверка: смысл, тон, отсутствие обещаний от имени компании, корректность фактов.

Ответственный: автор сообщения.

Где хранить: в корпоративной переписке; промпт не сохраняем как «источник истины».

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

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

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

Проверка: смысл не исказился, факты сохранились, нет «новых утверждений».

Ответственный: автор + редактор/руководитель, если материал публичный.

Сценарий 3. Планирование и структурирование документов.

Что можно отправлять: описание цели документа и аудитории; список тем; ограничения.

Что просим: оглавление, логика разделов, чек-лист, план презентации/отчёта.

Проверка: полнота, соответствие задаче, отсутствие лишних разделов, применимость к реальности компании.

Ответственный: владелец документа.

Сценарий 4. Мозговой штурм идей и вариантов.

Что можно отправлять: общая постановка задачи без внутренних деталей.

Что просим: 20–50 идей, группировка, критерии выбора, риски.

Проверка: реалистичность, соответствие ограничениям компании, отбраковка фантазий.

Ответственный: инициатор задачи.

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

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

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

Сценарий 5. Подготовка SOP и регламентов из хаотичных заметок.

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

Что просим: оформить в структуру SOP: цель, входы/выходы, шаги, ответственные, чек-листы, типовые ошибки.

Проверка: соответствие реальному процессу, выполнимость, отсутствие «выдуманных» шагов, согласование с владельцем процесса.

Ответственный: владелец процесса/руководитель отдела.

Сценарий 6. Анализ типовых обращений (поддержка/продажи) без персональных данных.

Что можно отправлять: обезличенные выдержки; удалены имена, контакты, ID, ссылки на профили; уникальные детали замены на «CLIENT_X».

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

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

Ответственный: руководитель поддержки/продаж.

Сценарий 7. Внутренние отчёты и резюме встреч.

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