«Безопасно ли отправлять это в Claude?» Рано или поздно этот вопрос звучит на любом security-ревью. Честный ответ зависит от того, что такое «это», каким путём оно идёт и что вы делаете на своей стороне. Ниже разобран реальный путь данных при вызове Claude через шлюз вроде codexkey, то, что на самом деле говорит коммерческая политика данных Anthropic в 2026 году, и приёмы, которыми команды держат под контролем PII, секреты и регулируемые данные.
Куда на самом деле идут ваши данные
Когда приложение вызывает Claude через codexkey, запрос проходит четыре точки:
- Ваш клиент (сервер, edge-функция, мобильное приложение) собирает тело запроса.
- Шлюз codexkey принимает запрос по TLS, проверяет API-ключ, записывает метаданные расхода и пересылает запрос дальше. Действуют правила аккаунта и канала провайдера; API ключей личного кабинета не даёт бюджетов и лимитов запросов для ключа.
- Anthropic обрабатывает запрос на своей инференс-инфраструктуре и возвращает ответ.
- Шлюз стримит ответ обратно и фиксирует расход токенов для биллинга, а ваш клиент получает результат.
Здесь два момента. Первый: тело запроса (промпт и вложения) проходит через шлюз в открытом виде, внутри TLS-туннеля. Второй: логи пишут и шлюз, и Anthropic. Что именно попадает в эти логи, и есть суть вопроса о комплаенсе.
Коммерческая политика данных Anthropic
Для платного API-трафика опубликованные коммерческие условия Anthropic на 2026 год содержат три пункта, важных для комплаенса:
- Обучения на API-данных нет. Входы и выходы коммерческих API-вызовов не используются для обучения моделей Anthropic. Это закреплено контрактом, а не переключателем в настройках.
- Хранение 30 дней по умолчанию. Запросы и ответы могут храниться до 30 дней для мониторинга злоупотреблений и операционной отладки, затем удаляются.
- Доступен Zero Data Retention (ZDR). Подходящие enterprise-клиенты могут запросить ZDR, который убирает 30-дневное окно. Условия и настройка обсуждаются через enterprise-продажи Anthropic.
ZDR нужен, когда вы работаете с сильно регулируемыми данными: записями вроде HIPAA, финансовым PII в большом объёме, юридической тайной. Большинству продуктовых команд хватает стандартных 30 дней при условии, что вы не отправляете в промпты незачищенные секреты.
Логи шлюза: минимизируйте то, что логируете
codexkey пишет метаданные запроса и ответа для точности биллинга: модель, токены входа и выхода, латентность, код статуса, отпечаток API-ключа. Полные тела промптов хранятся не дольше, чем нужно для краткосрочной отладки, но относитесь к шлюзу как к системе, которая на короткое время видит ваши данные.
Что из этого следует на практике:
- Не кладите в тело промпта учётные данные, сырые OAuth-токены и живые session cookies. Если они нужны агенту, получайте их на сервере и используйте в tool-вызовах, не выводя в контекст модели.
- Клиентские данные редактируйте до того, как запрос покинет ваш сервис. Шлюз это транспорт, а не граница вашего DLP.
- Утечку чаще создают собственные логи приложения. Многие команды пишут полный промпт для отладки, а потом годами не вспоминают об этих логах. Сначала проверьте собственный ретеншн, потом беспокойтесь о чужом.
Редакция PII в два слоя
Паттерн, который выживает в проде, многослойный: сначала дешёвый детерминированный проход, затем проход через LLM там, где первого не хватает.
Слой 1: regex-предпроход. До того как промпт уйдёт из вашего сервиса, прогоните вход через regex по очевидным вещам:
const REDACTORS: [RegExp, string][] = [
[/\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/gi, "[EMAIL]"],
[/\b(?:\d[ -]*?){13,19}\b/g, "[CARD]"], // PAN-подобные цифры
[/\b\d{3}-\d{2}-\d{4}\b/g, "[SSN]"], // US SSN
[/\b\+?\d{1,3}[\s-]?\(?\d{2,4}\)?[\s-]?\d{3,4}[\s-]?\d{3,4}\b/g, "[PHONE]"],
];
function scrub(input: string): string {
return REDACTORS.reduce((acc, [re, tag]) => acc.replace(re, tag), input);
}
Это ловит 80% случайного PII почти бесплатно.
Слой 2: LLM-редакция через gpt-5.6-luna. Для свободных полей, куда пользователи вставляют произвольный текст (тикеты поддержки, пункты договоров, медицинские заметки), вызывайте gpt-5.6-luna как дешёвый пред-проход.
Haiku у нас тоже есть: в каталоге claude-haiku-5.5 и claude-haiku-4.5, цены на странице моделей. Они работают в канале Premium, в канале Cheap Haiku их нет.
Вызов выглядит так:
const redacted = await anthropic.messages.create({
model: "gpt-5.6-luna",
max_tokens: 2000,
system: "Замени имена, адреса, номера счетов, даты рождения и медицинские идентификаторы на [REDACTED-NAME], [REDACTED-ADDRESS] и т.д. Остальное сохрани дословно. Выведи только отредактированный текст.",
messages: [{ role: "user", content: userInput }],
});
По тарифам шлюза gpt-5.6-luna настолько дешёвая, что ставить её фильтром-редактором перед Sonnet или Opus экономически разумно для чувствительных нагрузок. Базовый URL при этом остаётся прежним:
import Anthropic from "@anthropic-ai/sdk";
const anthropic = new Anthropic({
apiKey: process.env.CODEXKEY_API_KEY,
baseURL: "https://api.codexkey.ru/v1",
});
Комбинируйте слои: сначала regex (детерминированный, удобный для аудита), затем gpt-5.6-luna, но только для свободных полей с высоким риском. Логируйте сам факт редакции, чтобы потом доказать, что именно убрали.
EU-присутствие и GDPR
Если у вас европейские пользователи, важна география транзита и обработки. codexkey держит шлюзовую инфраструктуру в EU, и это означает следующее:
- Запросы от EU-клиентов сначала попадают на EU-edge, а не уходят через Атлантику до применения каких-либо политик.
- Логи на стороне шлюза (биллинг-метаданные, счётчики rate limit) лежат в EU.
- Цепочка DPA короче: одно соглашение с codexkey на шлюзовой слой плюс условия Anthropic на инференс.
Anthropic от этого не становится обработчиком только в EU: инференс по-прежнему идёт на её инфраструктуре, в основном в США. EU-присутствие сокращает число транзитных хопов, упрощает ваш реестр операций обработки и даёт контрагента в вашей юрисдикции. Для большинства B2B SaaS с GDPR-постановкой этого достаточно. Данным, которые действительно нельзя выпускать из EU, нужна другая архитектура: on-prem-инференс, EU-only-модели других вендоров или гибрид. Ни одно коммерческое развёртывание Claude сегодня этого не решает.
Гигиена ключей: ротация и права
Больше всего в эксплуатации даёт дисциплина с ключами:
- Ключ на каждое окружение. Прод, стейджинг, CI, локальная разработка и каждый батч-джоб получают отдельные ключи. Общих не бывает.
- Ротация раз в месяц, автоматическая. Выпустите новый ключ, выкатите его, а старый выключите через 24 часа перекрытия. Если ротация причиняет боль, чинить нужно управление секретами.
- Именованные ключи и срок действия. Заводите отдельные ключи codexkey под каждую интеграцию, выбирайте Premium или Cheap и при необходимости срок действия. Для Cheap можно разрешить резервный Premium. Статистика показывает расход каждого ключа.
- Правила держите в своём сервисе. API ключей личного кабинета не даёт бюджетов, списков разрешённых моделей, IP-фильтров, ограничений IDE и RPM/TPM для ключа. Не считайте ключ ограничителем расходов или доступа к моделям.
Аудит-логи на вашей стороне
Логи шлюза нужны для биллинга и борьбы со злоупотреблениями. Аудит-трейлом они не служат. У себя записывайте:
- Кто инициировал каждый запрос (correlation ID, user ID, tenant ID).
- Какая модель и какой ключ использованы.
- Токены и стоимость (берите из заголовков ответа, которые возвращает codexkey).
- Применялась ли редакция и какие редакторы сработали.
- Хеш входа, а не сам вход, если политика ретеншена запрещает хранить тела промптов.
Так учёт получается полным, а чувствительное содержимое не хранится. Когда регулятор или аудитор спросит «уходили ли данные пользователя X в Claude такого-то числа», вы ответите по своим логам и не будете зависеть от чужого ретеншена.
Модель угроз: украденный ключ
Исходите из того, что ключ рано или поздно утечёт: в git-коммит, лог CI, ноутбук подрядчика. Важно, что атакующий успеет сделать до того, как вы заметите.
Мастер-ключ без капов позволяет за ночь нагнать четырёхзначный счёт, гоняя Opus в цикле, а то и выгрузить контекст, если ключом пользуется агент с доступом к инструментам.
Ключ codexkey не задаёт лимит расходов, список моделей или IP-фильтр. Срок действия ограничивает время жизни ключа, но украденным активным ключом можно пользоваться до истечения срока. Храните ключи в хранилище секретов, следите за расходом, отзывайте утёкшие ключи и применяйте правила доступа в своём сервисе.
Итог
Безопасность облачных LLM строится как эшелонированная защита, а не как один переключатель:
- Коммерческая политика Anthropic (без обучения, хранение 30 дней, доступен ZDR) закрывает upstream-слой.
- Шлюз codexkey с EU-присутствием закрывает транзит и применение политик.
- Ваш пайплайн редакции (regex + gpt-5.6-luna) закрывает то, что уходит из вашего сервиса.
- Отдельные именованные ключи, срок действия, мониторинг и быстрый отзыв сокращают время доступа при утечке.
- Собственные аудит-логи закрывают вопрос регулятора.
Каждый слой по отдельности дёшев. Вместе они дают конфигурацию, которая проходит security-ревью без показухи. Добавьте к этому ценовую дисциплину из гайда по тарифам Claude API, и у вас сложатся и юнит-экономика, и комплаенс-история.