Kitobni o'qish: «Не доверяй нейросети слишком много - личные данные, ошибки ИИ и цифровая осторожность»

К читателю

Нейросеть редко получает слишком много данных потому, что пользователь решил нарушить правило. Чаще причина буднична: так быстрее. Целый договор вставить проще, чем вырезать один пункт; полный лог — быстрее, чем сделать минимальный пример; всю переписку — проще, чем пересказать ситуацию. Удобство постепенно стирает границу между тем, что мы готовы сообщить внешнему сервису, и тем, что должно остаться внутри устройства, семьи или организации.

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

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

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

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

Как пользоваться книгой

Если вас прежде всего волнует приватность — начните с частей I–III. Если вы используете ИИ для исследований, права, бизнеса или публикаций — особенно важны части IV–VII. Если подключаете почту, календарь, файлы, код или базы — не пропускайте часть VIII. Если инцидент уже случился, переходите сразу к части IX.

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

ЧАСТЬ I. ДО КНОПКИ «ОТПРАВИТЬ»

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

Глава 1. Почему чат кажется личным пространством

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

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

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

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

Словом «приватный» часто называют несколько разных вещей. Первая — разговор не публикуется в открытом интернете. Вторая — данные не используются для обучения. Третья — они хранятся ограниченное время. Четвёртая — доступ к ним ограничен внутри организации. Пятая — пользователь может удалить историю. Это пять разных свойств.

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

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

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

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

Ключевой вывод. Интерфейс чата уменьшает ощущение риска, но не превращает внешний сервис в личный блокнот.

Глава 2. Что происходит после кнопки «Отправить»

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

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

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

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

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

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

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

Режим обработки определяется продуктом, тарифом, настройками и договором, а не одним названием бренда.

Глава 3. «Только на минуту»: как удобство расширяет границы доверия

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

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

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

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

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

Минимизация снижает и риск, и шум. Модель реже цепляется за несущественные детали, а человек лучше понимает, какие данные реально используются. Это важное противоядие привычке «загрузить всё — пусть сама разберётся».

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

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

Глава 4. Красная, жёлтая и зелёная зоны данных

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

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

Красная зона — секреты доступа, seed-фразы, пароли, одноразовые коды, полный комплект банковских реквизитов, паспортные данные, клиентские базы, медицинские документы с идентификаторами, закрытые финансовые отчёты, коммерческие тайны и сведения, на передачу которых у вас нет права.

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

Ключевой вывод. Один файл может одновременно содержать зелёные, жёлтые и красные сведения.

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

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

Полезен тест «можно ли заменить?». Имя заменяется на КЛИЕНТ_1, реальная сумма — на диапазон, внутреннее название проекта — на ПРОЕКТ_A. Если после замены задача решается так же, исходное значение было лишним. Второй тест — «можно ли сократить?»: отправьте один пункт вместо всего договора, один стек ошибки вместо полного лога, несколько синтетических строк вместо выгрузки CRM.

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

Если задача решается после замены или удаления поля, реальное поле модели не нужно.

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

Глава 6. Десять секунд до отправки

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

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

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

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

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

Перед переходом дальше

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

ЧАСТЬ II. ЛИЧНЫЕ ДАННЫЕ В ОБЫЧНОЙ ЖИЗНИ

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

Глава 7. Что считается персональными данными

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

Российский закон № 152-ФЗ строится вокруг возможности определить физическое лицо по информации прямо или косвенно. Для бытовой практики важно не юридическое определение само по себе, а смена привычки: перед загрузкой смотреть на документ глазами постороннего. Можно ли понять, о ком речь? Можно ли найти этого человека по оставшимся деталям?

Фраза «я удалил фамилию» ещё не означает обезличивание. В небольшом городе сочетание «директор школы № 7, женщина, 58 лет, уволена в мае» может однозначно указывать на человека. В маленькой компании должность и проект иногда идентифицируют лучше фамилии.

Идентификация часто происходит не по одному уникальному полю, а по мозаике. Дата рождения не всегда уникальна. Город не уникален. Должность не уникальна. Но их сочетание может быть единственным.

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

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

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

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

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

Глава 8. Контакты, адреса и геолокация

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

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

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

Контактные данные почти никогда не нужны модели для работы со смыслом текста.

Глава 9. Документы, банковские реквизиты и идентификаторы

Скан паспорта содержит не только ФИО. Там есть серия, номер, дата рождения, место рождения, орган выдачи, фотография и подпись. Даже если нейросеть нужна для распознавания одной строки, загрузка всего разворота создаёт несоразмерный риск.

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

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

Особая категория — платёжные секреты: CVV, PIN, одноразовые коды, seed-фразы, приватные ключи. Их нельзя передавать ИИ ни «для проверки», ни «для восстановления», ни «на минуту».

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

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

Глава 10. Медицинские данные: полезный анализ без раскрытия личности

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

Вторая проблема — высокая цена ошибки. После обезличивания остаётся вопрос: что модель делает с содержанием? Объяснить термин простыми словами — одна задача. Назначить лечение, отменить препарат или решить, что можно не обращаться к врачу, — другая.

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

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

Ключевой вывод. Обезличивание защищает приватность, но не превращает модель во врача.

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

Глава 11. Фото, видео и голос как данные

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

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

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

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

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

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

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

Передача изображения — это передача всего видимого контекста, а не только объекта, о котором вы спрашиваете. Знакомый голос больше не является достаточным способом подтверждения личности.

Глава 12. Дети и семейный цифровой след

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

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

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

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

Глава 13. Чужая переписка, семейные конфликты и интимные подробности

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

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

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

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

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

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

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

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

Глава 14. Можно ли спрашивать ИИ о другом человеке

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

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

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

Ключевой вывод. Не используйте ИИ как скрытого диагноста или оценщика другого человека.

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

Перед переходом дальше

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

ЧАСТЬ III. РАБОЧИЕ ДАННЫЕ И КОММЕРЧЕСКАЯ ТАЙНА

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

Глава 15. Почему рабочий файл вам не принадлежит

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

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

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

Ключевой вывод. Рабочий доступ к данным — это право использовать их в рамках обязанностей, а не право выбирать любой внешний сервис.

Глава 16. Договоры и служебные документы

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

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

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

Учебный пример. Сотруднику нужно понять один пункт о сроках уведомления. Вместо целого контракта с ценами, банковскими данными и подписями он делает копию, оставляет нужный пункт и два соседних абзаца, а названия сторон заменяет на ПОСТАВЩИК и ЗАКАЗЧИК.

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

Глава 17. CRM и клиентские базы

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

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

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

Учебный пример. Маркетолог хочет сегментировать клиентскую базу. Вместо 20 000 реальных строк он отправляет структуру таблицы и 30 синтетических примеров. Модель помогает сформулировать правила сегментации без доступа к клиентским контактам.

Для проектирования аналитики реальная клиентская база обычно не нужна.

Глава 18. Финансовые отчёты и управленческие цифры

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

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

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

Непубличные цифры — тоже чувствительные данные, даже если в таблице нет ни одного имени.

Глава 19. Совещания, аудиозаписи и протоколы

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

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

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

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

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

Глава 20. Исходный код, логи и секреты доступа

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

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

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

Некоторые данные нельзя сделать безопасными заменой фамилии. Пароль, одноразовый код, приватный ключ, seed-фраза, токен API, cookie активной сессии — это полномочие. Тот, кто его получает, потенциально получает доступ.

Нельзя спрашивать модель «рабочий ли этот ключ» или «почему эта seed-фраза не подходит». Если нужен разбор формата, используйте вымышленный ключ той же структуры. Если секрет случайно попал в чат, правильное действие — отозвать и перевыпустить, а не только удалить сообщение.

Организациям стоит использовать secret scanning и хранилища секретов. Но даже без специальных систем правило простое: секрет не является данными для нейросети.

Учебный пример. Инженер просит объяснить исключение из production-лога. В строках вокруг ошибки есть email клиента и bearer token. Минимальный стек с замаскированными значениями даёт тот же технический контекст, но не раскрывает секреты.

Ключевой вывод. Секрет доступа не обезличивают — его исключают из входа; случайно раскрытый секрет ротируют.

Практика. Создайте безопасный шаблон кода/лога с placeholders YOUR_API_KEY, USER_ID, INTERNAL_HOST.

Глава 21. Коммерческая тайна — это режим, а не наклейка

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

Но сотруднику опасно делать обратный вывод: «если на файле нет грифа, можно отправлять куда угодно». Внутренние данные могут быть защищены договором, NDA, персональными правилами, требованиями клиента или политикой безопасности.

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

Оценка «это не секрет» не равна разрешению передавать данные внешнему сервису.

Глава 22. Shadow AI: почему один запрет работодателя не работает

Shadow AI — использование ИИ-инструментов без официального согласования. Чаще всего оно рождается не из бунта, а из разрыва между задачей и доступными средствами: сотруднику нужно перевести, суммировать, написать формулу или разобрать PDF, а корпоративный процесс слишком медленный.

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

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

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

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

Технические меры — DLP, блокировка загрузок, корпоративный браузер, SSO, разделение аккаунтов — дополняют, а не заменяют правила. Если запрет легко обходится личным телефоном, а безопасной альтернативы нет, контроль остаётся символическим.

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

Ключевой вывод. Запрет без рабочего безопасного пути почти неизбежно создаёт Shadow AI.

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

Перед переходом дальше

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

ЧАСТЬ IV. КОГДА УВЕРЕННОСТЬ ИИ ПУТАЮТ С ИСТИНОЙ

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

Глава 23. Почему уверенный тон обманывает

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

У ответа нет внутреннего индикатора «я сейчас придумал». Модель может назвать дату, номер дела, автора статьи и цитату с одинаковым стилем — независимо от того, существуют они или нет. Современные системы всё чаще подключаются к поиску и базам знаний, но это уменьшает часть ошибок, а не отменяет проверку.

Лучшее противоядие — отделять форму от содержания. Задавайте себе вопрос: что в этом абзаце можно проверить независимо? Дата, число, имя, цитата, закон, функция сервиса, цена, медицинская рекомендация — это проверяемые элементы. Красивые связки между ними — уже интерпретация.

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

Особенно опасны формальные реквизиты: номер судебного дела, DOI статьи, ГОСТ, пункт закона. Они выглядят настолько технически, что пользователь реже сомневается. В делах Mata v. Avianca и Zhang v. Chen именно несуществующие судебные ссылки прошли в официальные документы.

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

Учебный пример. Модель уверенно сообщает точную дату и номер документа. Формат выглядит настолько профессионально, что пользователь копирует его в отчёт. На проверке выясняется, что документ существует, но дата и вывод относятся к другой редакции. Уверенность текста не является метаданными источника.

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

Глава 24. Ссылка, документ и цитата — три разных проверки

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

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

В профессиональной работе полезно требовать от модели не просто список ссылок, а связку «утверждение — источник — место в источнике». Но даже тогда человек должен открыть документ. Модель может ошибиться в указании страницы или абзаца.

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

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

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

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

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

Практика. Для одной ссылки найдите точную фразу или таблицу, подтверждающую тезис. Если не нашли — ссылка не прошла проверку.