Ваши разработчики уже сливают данные клиентов в ИИ. Они просто не считают это утечкой
Привет, меня зовут Евгений Вихров, я legal ops и юрист в Рунетлексе. Сегодня я расскажу почти невыдуманную историю Сергея, руководителя небольшой IT-компании, который столкнулся с отсутствием правового регулирования ИИ внутри своей фирмы.
Эту историю я разберу по шагам: что произошло, почему это стало проблемой и что можно было сделать иначе. В конце статьи вы найдёте чек-лист с вопросами, которые стоит проработать в первую очередь.
У Сергея небольшая IT-компания: 25 человек, несколько подрядчиков, клиенты из ритейла и логистики. Команда делает внутренние сервисы и интеграции с CRM.
Однажды постоянный клиент попросил срочно доработать программный модуль, чтобы добавить несколько статусов и поменять логику маршрутизации. Сроки откровенно горели — новую услугу нужно было запускать уже в понедельник, иначе запуск переносился почти на месяц.
Разработчик Иван взялся за задачу и через два дня написал в рабочий чат, что всё готово. Сергей удивился, ведь обычно такие доработки занимали не меньше недели.
— А как это ты так быстро сделал?
— Часть кода собрал через Claude Code. Потом чуть поправил руками, обычное дело. Я в принципе с начала этого года сам код уже почти не пишу.
Сергей не стал спорить. Он знал, что все в компании так или иначе пользовались ИИ: кто-то писал письма, кто-то делал выжимки из договоров, кто-то просил помочь с формулами в Excel. Компания не вводила никаких запретов на этот счёт, но и никакого внутреннего правового регулирования этого вопроса тоже не было.
Что пошло не так. Если компания не дала сотрудникам понятный способ использовать ИИ, они найдут свой. И этот способ почти всегда окажется личным аккаунтом в удобном сервисе, без какого-либо контроля со стороны работодателя.
Наша рекомендация. Определить, какие сервисы разрешены, и подключить сотрудникам корпоративные аккаунты. Тогда компания будет знать, где хранятся рабочие данные, и сможет этим управлять.
Через месяц от клиента пришла претензия, в которой он сообщал, что модуль неправильно обработал часть заявок, несколько десятков обращений ушли не тем менеджерам. Сергей сел разбираться и обнаружил кое-что поважнее самой ошибки.
Выяснилось, что перед тем как писать код, Иван загрузил в ИИ фрагменты технического задания, переписку с менеджером клиента и реальные заявки из CRM, чтобы модель лучше поняла контекст задачи. В итоге чувствительные данные ушли во внешний сервис без какого-либо обезличивания.
Сергей открыл договор с клиентом. В разделе о конфиденциальности было указано, что компания не должна раскрывать третьим лицам коммерческую информацию, полученную при исполнении договора. ИИ-сервис третьей стороной был, а клиент согласия на загрузку материалов не давал.
Что пошло не так. Для сотрудника загрузить текст договора или пример заявки в ИИ означает примерно то же самое, что и вставить текст в онлайн-переводчик, но для компании это может быть передачей персональных данных или нарушением NDA. По факту это означает утечку чувствительных данных, что и произошло в кейсе Ивана.
Наша рекомендация. Зафиксировать в ЛНА, какие данные нельзя передавать в ИИ в исходном виде, и показать, как их анонимизировать. Рекомендуем дополнительно провести обучение по этому вопросу и предупредить о негативных последствиях такой утечки.
Сергей попросил Ивана показать, как именно он работал с ИИ. Иван открыл свой личный аккаунт, в котором смотрел рецепты, планировал отпуск и делал рисунки котиков по просьбе ребёнка. Там же лежали рабочие запросы по клиентскому проекту: фрагменты кода и ТЗ, внутренние данные, полученные от клиентов.
— «Почему не через корпоративный аккаунт?» — спросил Сергей.
— «А что, он у нас есть? Мне его не подключили, когда я выходил. Я и не знал про него!» — с недоумением ответил Иван.
У компании был корпоративный доступ к ИИ-сервисам. Но онбординг новых сотрудников был устроен так, что про это никто не рассказывал. Иван просто использовал свой личный аккаунт, который зарегистрировал задолго до трудоустройства в компанию к Сергею. В результате рабочие данные оказались в неконтролируемой среде: непонятно, где они хранятся и можно ли их удалить.
Когда тимлид попросил Ивана показать все его запросы к ИИ по этому проекту, оказалось, что цепочка скиллов — ценный актив: в ней были архитектурные решения, отвергнутые варианты, объяснения выбора. Именно в ней хранилось понимание того, как Иван пришёл к этому коду. И всё это лежало в его личном аккаунте, к которому у компании не было доступа.
Что пошло не так. Промпты и скиллы, это интеллектуальный актив компании, в содержании которых могут быть ценные рабочие решения. Если они находятся в личном аккаунте сотрудника, компания может даже не узнать об их существовании и понести финансовые потери.
Наша рекомендация. С самого начала договориться, что рабочие скиллы, проекты и пр. хранятся в корпоративном аккаунте, а не в личном. Этот процесс важно вписать в онбординг, чтобы не получилось так, что сотрудник об этом узнает в день увольнения.
Через две недели после инцидента Иван сообщил, что уходит, так как ему поступил оффер, который он не стал отклонять. Сергей не связывал это с историей про модуль, но осадок оставался.
В последний день тимлид спросил:
— «А проект по тому клиенту ты перенёс?»
— «Они в моём аккаунте. Могу экспортнуть часть переписки»
— «А доступ дать?»
— «Так это же мой личный аккаунт. Там и мои личные запросы тоже. Полный доступ не могу дать».
Что пошло не так. Компания привыкла давать сотруднику ноутбук, заводить почту и добавлять в трекер задач. Но ИИ добавил новый слой: рабочие материалы могут находиться в личном аккаунте внешнего сервиса, о котором работодатель вообще не знает.
Наша рекомендация. Прописать в ЛНА обязанность передавать ИИ-материалы при увольнении и хранить их только в корпоративной среде.
После увольнения Ивана Сергей собрал руководителей и предложил урегулировать вопрос использования ИИ. На встрече выяснилось, что почти все сотрудники уже используют ИИ: маркетолог загружала отзывы клиентов, HR вставлял куски резюме, менеджер по продажам делал выжимки из созвонов. Никто не считал это каким-то особым риском, тем более что ИИ существенно ускорял работу, чего требовало руководство.
Запрещать это уже не имело смысла.
Сергей попросил юриста и тимлида для начала написать короткие правила: какие сервисы разрешены, что нельзя загружать, кто проверяет результат, где хранятся рабочие материалы, что считается инцидентом.
Спустя некоторое время из таких коротких правил появилась полноценная политика использования ИИ в компании. У сотрудников появилась понятная рамка его использования, а у руководства контроль над новыми рисками, которые раньше просто не замечали.
Что должна закрывать политика использования ИИ
- Какие ИИ-сервисы разрешены и через какие аккаунты работать
- Что нельзя загружать без предварительного обезличивания
- Кому принадлежат промпты, скиллы и рабочие настройки ИИ
- Кто и как проверяет результаты ИИ перед использованием
- Что считается инцидентом и что делать, когда он случился
- Что сотрудник обязан передать компании при увольнении
Если вам нужна помощь с внедрением ИИ — мы поможем разобраться, как упорядочить его использование в вашей компании — от политики до конкретных инструментов.
Приходите на консультацию: форма обратной связи или Телеграм.