ИИ внедрили. Что забыли?

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

Маркетолог начинает редактировать через ChatGPT тексты. Менеджер загружает расшифровку встречи и просит подготовить follow-up. HR сравнивает резюме кандидатов. Руководитель прикрепляет отчёт и ищет отклонения. Разработчик отправляет кусок кода, чтобы быстрее найти ошибку.

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

И только потом возникает вопрос: а что именно всё это время сотрудники отправляли в ИИ?

Полные записи разговоров с клиентами? Резюме с телефонами и почтой? Договоры? Финансовые таблицы? Коммерческие предложения? Внутренние исследования? Исходный код? Доступы к другим системам?

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

Самые опасные ошибки обычно выглядят как нормальная работа

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

В этой истории интересен не масштаб Samsung, а сам механизм.

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

Для сотрудника изменился способ выполнения задачи. Для компании изменилось место, куда начала попадать информация.

Четыре вещи, которые нужно спроектировать вместе с ИИ

Удобно смотреть на любое внедрение через четыре уровня:

1. Задача. Что именно мы поручаем ИИ?
2. Данные. Какая информация нужна ему для этой задачи?
3. Инфраструктура. Где эта информация будет обрабатываться?
4. Ответственность. Кто проверяет результат и отвечает за дальнейшее действие?

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

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

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

Для составления короткого follow-up нейросети большая часть этого вообще не нужна.

Хорошая автоматизация начинается с вопроса «без каких данных она всё ещё сможет решить задачу».

С персональными данными всё шире, чем кажется

Обычно под персональными данными представляют паспорт, СНИЛС или банковскую карту.

Но понятие значительно шире: это информация, которая относится прямо или косвенно к определённому или определяемому человеку.

В обычной работе такими данными могут оказаться:

• ФИО, телефон, email, адрес и дата рождения;
• информация из резюме;
• фотография, видео или запись голоса;
• сведения о зарплате конкретного сотрудника;
• история заказов или переписки;
• данные о здоровье;
• банковская и финансовая информация;
• комбинация признаков, по которой человека можно определить.

Поэтому удалить имя недостаточно.

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

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

Пять вопросов к любому процессу с персональными данными

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

Не обязательно становиться специалистом по 152-ФЗ, чтобы заметно улучшить процесс. Для начала достаточно заставить команду отвечать на пять вопросов:

• зачем нам эти данные;
• какие конкретно сведения действительно нужны;
• кто получает к ним доступ;
• где они обрабатываются и хранятся;
• когда они перестают быть нужны.

Эти вопросы быстро вскрывают странные решения.

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

Но если модель должна только определить проблему и подготовить ответ, зачем ей адрес клиента? Возможно, достаточно номера заказа, фотографии и текста обращения, а всё остальное внутренняя система уже знает сама.

Чем меньше чувствительных данных входит в ИИ-процесс, тем меньше потом приходится защищать.

Не всё чувствительное является персональными данными

Вторая распространённая ошибка — защищать только данные людей.

Представим файл, в котором нет ни одной фамилии и ни одного телефона. Зато внутри:

• исходный код;
• архитектура продукта;
• себестоимость;
• финансовый прогноз;
• стратегия выхода на рынок;
• результаты закрытого исследования;
• тендерные условия;
• условия сделки;
• внутренние инструкции;
• неопубликованные показатели.

Для компании потеря такого документа может оказаться не менее болезненной.

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

Поэтому перед отправкой файла полезно задавать два вопроса:

Можно ли по этим данным определить человека?

Будет ли проблема, если эта информация окажется за пределами компании?

Первый вопрос ловит персональные данные. Второй — всё остальное, что имеет ценность именно потому, что пока известно не всем.

Причём коммерческая тайна — это не просто файл с названием SECRET. Для полноценного режима коммерческой тайны организация должна сама оформить и поддерживать соответствующие внутренние меры и документы.

Не загружайте документ целиком только потому, что это возможно

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

Допустим, маркетолог хочет улучшить коммерческое предложение.

Исходник:

Иван Петров, ООО «Альфа», проект «Вектор», стоимость 4 700 000 рублей, запуск 18 сентября.

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

Клиент №7, Компания А, проект [ПРОЕКТ], стоимость [СУММА], запуск [ДАТА].

Смысл документа сохранился. Ненужные для задачи данные исчезли.

Рабочая последовательность может выглядеть так:

1. Создать копию исходника и не менять оригинал.
2. Удалить ФИО, телефоны, email, адреса, реквизиты и номера документов, если они не нужны.
3. Заменить компании, проекты, суммы и внутренние обозначения условными метками.
4. Проверить косвенные признаки, по которым всё ещё можно восстановить человека или клиента.
5. Удалить технические детали, не участвующие в задаче.
6. Только после этого передавать очищенную версию модели.

Главный принцип здесь не в механическом удалении фамилий.

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

Если вы обучаете собственную модель — это уже другой сценарий

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

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

Нужно отдельно проверить:

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

Здесь полезно запомнить простую вещь:

данные, которые компания накопила, и данные, которыми она вправе обучать ИИ, — не обязательно один и тот же набор.

Облако, корпоративный сервис или локальная модель?

После разговора о рисках легко уйти в крайность: всё чувствительное обрабатывать только локально.

Иногда это действительно правильное решение, но универсального ответа нет.

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

Поэтому разумнее разделять несколько режимов работы.

При этом локальная модель тоже может быть настроена плохо.

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

Вопрос не в том, где моднее запускать модель.

Вопрос в том, какой уровень контроля требуется конкретным данным.

Корпоративный тариф

Здесь возникает ещё одна опасная иллюзия.

У корпоративных продуктов и API могут быть существенно более строгие правила работы с данными, чем у обычных пользовательских аккаунтов. Например, бизнес-продукты OpenAI по умолчанию не используют данные клиентов для обучения моделей. (верим)

Это действительно важно, но две фразы нельзя путать:

«данные не используются для обучения»

и

«данные не передаются внешнему поставщику».

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

Поэтому перед профессиональным использованием нового ИИ-сервиса стоит проверять не только качество модели.

Нужно понять:

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

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

Платная подписка — это набор возможностей. Не сертификат безопасности ваших данных.

Российское законодательство

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

С ИИ так не работает.

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

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

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

В России ключевым для работы с персональными данными остаётся 152-ФЗ. Он регулирует основания и цели обработки, обязанности оператора, безопасность, локализацию и трансграничную передачу персональных данных.

Для компании здесь важны несколько практических вещей.

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

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

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

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

Новый закон об ИИ уже принят, но пока ещё не действует

Здесь есть важное изменение буквально этого лета.

26 июля 2026 года был опубликован Федеральный закон №243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации».

Это произойдёт 1 сентября 2026 года.

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

Поэтому даже после 1 сентября никуда не исчезнут 152-ФЗ, договорные ограничения, коммерческая тайна, интеллектуальная собственность и отраслевые нормы.

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

проверять нужно конкретный ИИ-процесс, а не просто наличие слова «ИИ» в законодательстве.

Штрафы

Ответственность за нарушения в области персональных данных в последние годы заметно выросла.

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

Но я бы не строил внедрение только вокруг страха штрафа.

До штрафа можно спросить, себя (если вы владелец) или владельца (если вы внедренец):

Через какие ИИ-сервисы вы обрабатываете ваши звонки?

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

Это уже не только юридическая проблема, у вас на лицо :) отсутствие контроля.

Есть ещё вторая сторона риска: что ИИ возвращает обратно

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

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

Особенно опасно это там, где человек использует ИИ именно потому, что плохо знает предмет.

Поэтому вместе с классификацией данных нужна классификация решений.

Например:

• варианты заголовков — низкая цена ошибки;
• черновик маркетингового текста — умеренная;
• финансовый расчёт — выше;
• договор — ещё выше;
• медицинская или юридически значимая рекомендация — совсем другой уровень контроля.

Чем дороже ошибка, тем меньше автономности нужно давать модели.

Здесь человеческая проверка — это нормальная конструкция процесса.

Как это выглядит на обычных рабочих задачах

Теория становится намного понятнее, когда смотришь на конкретные процессы.

Внутренний финансовый отчёт

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

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

Коммерческое предложение

Если задача — отредактировать текст, реальное название клиента, сумма сделки, номер договора и внутренние условия чаще всего не нужны.

Замените их условными обозначениями и работайте с содержанием.

Тендерная переписка

Здесь одновременно могут находиться технические детали, цены, условия и информация о заказчике.

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

Резюме

Для сравнения опыта кандидатов обычно не нужны ФИО, телефон, email и домашний адрес.

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

Исходный код

Нет смысла передавать целый закрытый репозиторий ради одной ошибки.

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

База клиентов

Не начинайте с загрузки таблицы.

Сначала задайте вопрос: какую закономерность мы ищем? Часто реальные ФИО, телефоны и email вообще не участвуют в ответе.

Что ещё нужно проверить самостоятельно под свой проект

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

Их стоит исследовать отдельно:

• Автоматические решения по людям. HR-скоринг, кредитные решения, страхование и другие процессы, где вывод алгоритма влияет на права человека.
• Медицина. Работа с медицинской информацией, рекомендациями и специальными категориями персональных данных.
• Банки, страхование, транспорт и государственный сектор. Здесь могут действовать дополнительные отраслевые требования.
• GDPR. Если деятельность попадает под европейское регулирование, нужен отдельный анализ обработки и передачи данных.
• Авторские права. Нужно смотреть юрисдикцию, человеческий творческий вклад и условия конкретного генератора.
• Реклама и дипфейки. Использование ИИ-контента может затрагивать требования к рекламе, достоверности и введению потребителя в заблуждение.
• Маркировка ИИ-контента. Правила в этой области продолжают развиваться, поэтому конкретный режим стоит проверять на момент публикации.
• Договоры с клиентами. Отдельно посмотреть NDA, условия обработки информации и разрешено ли подключать внешних поставщиков.
• Обучение собственных моделей. Если используются клиентские данные или большие внутренние массивы, этот процесс стоит проектировать отдельно.

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

Минимальный ИИ-регламент можно собрать на одной странице

Большой корпоративный документ на старте часто никто не читает.

Гораздо полезнее короткий регламент, который отвечает на понятные вопросы.

В нём должны быть семь вещей:

1. Разрешённые сервисы. Какие инструменты можно использовать и через какие аккаунты.
2. Типы данных. Что можно отправлять свободно, что только после очистки, а что нельзя передавать внешним сервисам.
3. Правило минимизации. Модель получает только необходимый для задачи контекст.
4. Работа с аккаунтами. Кому принадлежат ассистенты, базы знаний, API-ключи и автоматизации.
5. Человеческий контроль. Какие результаты нельзя использовать без проверки.
6. Порядок подключения новых сервисов. Кто проверяет их условия и безопасность.
7. Действия при ошибке. Кому сообщать, если уже отправили лишнее.

Последний пункт особенно важен.

Запретить любую ошибку невозможно. Можно сделать так, чтобы сотрудник не пытался её скрыть.

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

Удалить чат и сделать вид, что ничего не произошло, — не процесс реагирования.

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

Сначала проведите простой аудит.

Попросите команду перечислить всё, что она реально использует: ChatGPT, Claude, DeepSeek, Perplexity, генераторы изображений, сервисы расшифровки, ИИ для кода, Telegram-ботов, браузерные расширения, внутренних ассистентов и автоматизации.

Потом для каждого инструмента ответьте:

• кому принадлежит аккаунт;
• какие данные туда поступают;
• есть ли персональные или клиентские данные;
• подключены ли почта, CRM, Drive, Notion, репозитории или другие системы;
• где хранится история;
• кто имеет доступ;
• кто проверяет результат;
• что произойдёт при увольнении сотрудника.

Особенно полезен последний вопрос.

ИИ-процесс легко оказывается привязан к личному аккаунту сотрудника. Там остаётся база знаний, история запросов, промпты, ключи и автоматизации.

Человек уходит — и вместе с ним исчезает часть инфраструктуры компании.

Раньше бизнес терял таким образом таблицы и пароли. Теперь можно потерять целого ассистента.

Самая простая проверка

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

Какие ИИ-сервисы вы используете при работе с нашей информацией? Какие наши данные туда передаются? Где они обрабатываются? Кто имеет к ним доступ? Кто отвечает за результат?

Сможете собрать ответ за час?

Если да, у вас уже есть хотя бы базовый контроль.

Если для этого придётся писать в общий чат «кто вообще чем пользуется?» — то пу пу пуууу.

ИИ вы уже внедрили. Управление им — ещё нет.

Именно поэтому внедрение заканчивается не в момент покупки подписки и не после обучения сотрудников промптам.

Нужно понять задачу, данные, инфраструктуру, права доступа, цену ошибки и ответственность.

А уже потом решать, где нужен облачный сервис, где корпоративный API, где локальная модель, а где ИИ вообще не должен видеть исходный документ.

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

Но плохо спроектированные процессы они ускоряют ровно так же.

AnthonyAugust 13

После аудита: как довести внедрение ИИ до работающего решения

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

AnthonyJuly 24

Как приоритизировать задачи для автоматизации с помощью ИИ

«Давайте внедрим ИИ» — частый запрос от бизнеса.

AnthonyJuly 22

Аудит бизнес-процессов перед внедрением ИИ

Если бизнес-процесс держится на Excel, пяти чатах и одном человеке, который помнит всё, у компании уже есть автоматизация 😅