Что нельзя отправлять в LLM: персональные данные, секреты

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

Примеры PII:

• ФИО (полностью или “Фамилия И.О.”)

• домашний адрес и место работы/учёбы

• номер телефона

• e-mail

• дата рождения

• номера документов (паспорт, ID, водительские права)

• геолокация/координаты, “я сейчас в таком-то отеле/квартире”

• фото и сканы документов, селфи с бейджем/пропуском

И да — даже если кажется безобидным (например, “просто почта для рассылки” или “адрес, чтобы посчитать доставку”), лучше заменить всё на вымышленные данные или шаблоны.

С LLM лучше вообще не экспериментировать, когда речь про деньги. Нельзя отправлять любые данные, которыми можно оплатить, вернуть, списать или “переоформить” платеж — даже если вам кажется, что это просто «для примера».

Что точно не стоит вставлять в чат:

• Данные банковских карт: номер карты (PAN), срок действия, CVV/CVC, PIN, фото карты (да, на фото всё читается).

• Онлайн-банк и доступы: логин/пароль, одноразовые коды (SMS/OTP), токены, QR для входа, резервные коды 2FA.

• Банковские реквизиты: IBAN/р/с, номер счёта, БИК/SWIFT, имя владельца + реквизиты в одной связке.

• Платёжные ссылки и инвойсы: ссылки на оплату, счета/инвойсы с ID транзакций, invoice/payment/reference number, клиентскими номерами — всё, где есть идентификаторы.

• Налоговые и идентификационные номера: ИНН, VAT ID, номера налогоплательщика, данные деклараций/выписок, суммы и остатки по счетам.

• Платёжные сервисы: данные PayPal/Stripe/Apple Pay/Google Pay, merchant keys, API-ключи, секреты вебхуков.

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

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

Что точно не отправляем:

• Пароли от почты, соцсетей, банков, админок, VPN и т.д.

• Одноразовые коды: SMS-коды, 2FA/TOTP-коды из приложений-аутентификаторов

• Recovery-коды / backup-codes (те самые “на случай, если потеряете доступ”)

• API-ключи (OpenAI/Stripe/AWS/Google и любые другие)

• Токены доступа: OAuth tokens, bearer tokens, session tokens

• Приватные ключи (SSH private key, ключи криптокошельков, seed-фразы)

• Ссылки-приглашения с доступом (invite links в Slack/Notion/GitHub/доступ к папке/доске)

• Cookies и любые куски заголовков/дампов запросов, где они видны

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

Есть простое правило: если документ или цифры неловко показать “всем в компании”, то в LLM их тоже лучше не тащить. Потому что это уже зона корпоративных секретов — и тут риски не теоретические. Утечка, нарушение NDA, потом разборки с партнёрами/клиентами, репутационные потери и, да, вполне реальные юридические последствия.

К корпоративным секретам обычно относится вот что:

• Внутренние документы: регламенты, инструкции, политики безопасности, схемы процессов, оргструктура.

• Стратегии и планы: дорожные карты, планы запусков, бюджеты, прогнозы, M&A, планы по сокращениям/найму.

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

• Клиентские базы и лиды: списки клиентов, контакты, сегментация, история покупок, LTV, причины оттока.

• Договоры и приложения: коммерческие условия, SLA, штрафы, акты, счета, реквизиты, переписка по согласованиям.

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

• KPI и внутренняя аналитика: планы продаж, воронка, показатели команд/людей, зарплатные вилки, бонусные схемы.

• Исходники и дизайн до релиза: код, ключи, токены, архитектура, макеты, прототипы, тексты, которые ещё не вышли.

• Данные из CRM/ERP: выгрузки, карточки сделок, заказы, остатки, себестоимость, логистика, финансовые отчёты.

И вот что важно: даже если вы “просто попросили модель переформулировать” договор или “подсказать по CRM-выгрузке”, вы всё равно передали наружу кусок внутренней кухни. А потом доказывай, что это никуда не утекло и не нарушило условия NDA.

Есть категория данных, с которой лучше вообще не экспериментировать — чувствительные (особо чувствительные) сведения. Это информация, которая может реально навредить человеку, если всплывёт не там: про здоровье и психику, про детей, про убеждения, про биометрию. В отличие от “просто имени”, такие штуки часто нельзя нормально «отыграть назад», если они утекли.

Примеры, что сюда обычно попадает:

• диагнозы, выписки, назначения врача (вроде “депрессия, F32.1”, “ВИЧ+”, “онкология”);

• результаты анализов и обследований (ХГЧ, МРТ, генетические тесты, инфекции);

• детали психотерапии: запросы, травматичный опыт, заметки сессий;

• любые сведения о детях: ФИО, школа/сад, адрес, особенности здоровья;

• политические/религиозные взгляды, членство в организациях, биометрия (фото лица, отпечатки, голосовые слепки).

Если без этого никак — обобщай: “мужчина 35 лет”, “анализы в норме/не в норме”, “симптомы такие-то”, и обязательно убирай идентификаторы (ФИО, даты рождения, адреса, номера карт/полисов, названия клиник и т.п.). Так полезный ответ получить можно, а рисков — сильно меньше.

Иногда прям зудит спросить у модели про кейс “как есть”. Окей, но тогда включаем режим паранойи (в хорошем смысле) и вычищаем всё, что может привязать текст к реальному человеку или компании.

Мини‑чеклист обезличивания:

• Имена → роли. “Иван Петров” превращается в “менеджер” или “клиент А”.

• Телефоны, почта, адреса — удалить целиком. Не “+48…”, не “ul. …”, вообще ничего.

• Даты и суммы — округлить/размыть. Было “12.03.2026” → стало “в марте 2026”; “12 430 PLN” → “около 12 тыс.”

• Уникальные идентификаторы — вырезать. Номера договоров, паспорта, PESEL/ИНН, ID заявки, трекинги, номера счетов, VIN, серийники — всё это в топку.

• Не вставлять документ целиком. Лучше пересказать: “в договоре есть пункт про штраф 10% при просрочке”, чем копипастить 3 страницы.

• Фейковые примеры вместо реальных. Если нужен формат — делайте выдуманные данные, но сохраняйте структуру (поля/логика/ошибка).

Пример “до/после”:

До:
“Посмотри жалобу клиента Ивана Петрова (PESEL 900312…): заказ №A-19384 от 12.03.2026, доставка: Warszawa, ul. Grochowska 12, сумма 12 430 PLN, телефон +48… Что ему ответить?”

После:
“Клиент (физлицо) жалуется на задержку доставки по заказу [номер удалён], оформленному в марте 2026. Доставка — крупный город в Польше. Сумма — около 12 тыс. Нужен черновик ответа: извинение, срок решения, компенсация по политике компании.”