К содержимому

Предприниматели · ULTRA

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

· 13 мин чтения · Редакция ultrathink

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

Зачем компании политика использования ИИ

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

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

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

Памятка или полноценная политика: как выбрать

Объём документа зависит не от размера компании, а от того, с какими данными и в каких процессах работает ИИ. Простое правило выбора:

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

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

Термины, о которых стоит договориться заранее

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

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

Как подготовить политику: пошаговый процесс

  1. 01Опросить отделы: какие задачи уже решаются с ИИ, какими сервисами, с какими данными. Спрашивайте без осуждения, иначе получите неполную картину.
  2. 02Составить карту данных: что есть в компании — клиенты, сотрудники, финансы, договоры — и где это хранится: 1С, CRM, Excel, мессенджеры.
  3. 03Разделить данные на уровни: можно передавать, только обезличенно, нельзя.
  4. 04Выбрать разрешённые сервисы и проверить их условия: где хранятся данные, можно ли оформить аккаунт на компанию, как отозвать доступ.
  5. 05Написать черновик по структуре ниже — коротко, с примерами из ваших задач.
  6. 06Показать черновик двум-трём сотрудникам, которые активнее всех пользуются ИИ: они найдут места, где правила не совпадают с реальной работой.
  7. 07Отдать раздел о данных юристу.
  8. 08Утвердить документ у директора и назначить ответственного.
  9. 09Провести знакомство по отделам и выдать памятку.
  10. 10Назначить дату первого пересмотра.

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

Структура документа, которую можно взять за основу

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

1. Цель и сфера действия

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

2. Термины

Короткий словарь из предыдущего раздела. Пяти-семи определений достаточно; если термин в документе не используется, его не нужно определять.

3. Разрешённые сервисы и аккаунты

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

4. Классификация данных

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

5. Допустимые и недопустимые задачи

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

6. Проверка результата

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

7. Раскрытие использования ИИ

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

8. Ответственность

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

9. Инциденты

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

10. Обучение, пересмотр и контакты

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

Классификация данных: три уровня и спорные случаи

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

Уровень 1 — можно передавать

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

Уровень 2 — только обезличенно

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

Уровень 3 — нельзя

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

Как решать спорные случаи

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

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

Проверка результата по уровням риска

Требование «проверять всё одинаково» не работает: оно либо тормозит работу, либо его перестают соблюдать. Удобнее связать глубину проверки с последствиями ошибки.

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

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

Условный пример: политика в небольшой компании

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

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

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

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

Типичные ошибки и как их заметить

Политику пишут без тех, кто работает с ИИ

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

Запреты без альтернатив

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

Общие слова вместо примеров

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

Нет ответственного с именем

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

Наказание за сообщение об инциденте

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

Документ не пересматривают

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

Как внедрить и поддерживать политику

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

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

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

Чек-лист политики

  1. 01Проведён опрос отделов о текущем использовании ИИ.
  2. 02Составлена карта данных: что есть в компании и где хранится.
  3. 03Определены сфера действия и разрешённые сервисы.
  4. 04Данные разделены на три уровня с примерами из вашей работы.
  5. 05Есть инструкция по обезличиванию.
  6. 06Для каждого запрета есть разрешённая альтернатива.
  7. 07Задачи описаны по группам: можно, после проверки, по согласованию, нельзя.
  8. 08Проверка описана по уровням риска.
  9. 09Есть правило раскрытия для автоматических ответов клиентам.
  10. 10Назначен ответственный с именем и способом связи.
  11. 11Описан порядок действий при инциденте, честное сообщение не наказывается.
  12. 12Раздел о персональных данных согласован с юристом.
  13. 13Сотрудники прошли знакомство с правилами, есть памятка.
  14. 14Назначена дата пересмотра.

Вывод

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

Частые вопросы

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

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

Черновик удобно готовить ответственному за ИИ вместе с руководителями отделов. Раздел о данных проверяет юрист, утверждает директор.

Удобно назначить плановый пересмотр, например раз в полгода, и внеплановый — при подключении нового сервиса или после инцидента.

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

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

Читайте также

Все статьи
Заявка

Начнём с разговора.

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

Или напишите напрямую

Отвечаем в рабочее время в течение 30 минут.

Что интересует

Без предоплаты и без обязательств. Отказаться можно на любом шаге.

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