Privacy-preserving AI — это подходы, позволяющие обучать и запускать модели, не раскрывая входные данные и/или веса, а также криптографически доказывать корректность вычислений.
На практике три основных «столпа»:
- FHE (полное гомоморфное шифрование): вычисления прямо над шифртекстами.
- SMPC (безопасные многосторонние вычисления): данные разделяются между сторонами и обрабатываются без их раскрытия.
- zkML (доказуемый ML): выпуск кратких доказательств корректности инференса/обучения (SNARK/STARK).
Связанные страницы: Model serving, Model evaluation, Prompt injection, Prompt leakage, Model poisoning, Evals, Контекстное окно, KV cache, Prefill cache, Retriever, Vector index.
Для чего это нужно (модель угроз) - Privacy-preserving AI (FHE / SMPC / zkML)
- Конфиденциальность данных пользователя: медицинские записи, KYC, телеметрия устройств.
- Конфиденциальность модели: закрытые веса/архитектуры как коммерческая тайна.
- Доказуемая корректность: регуляторика и аудит — «ответ действительно получен из модели *M* на входах *X*».
- Композиция с блокчейном: on-chain верификация результатов ML или их аттестация оффчейн-доказательствами.
Ключевые компромиссы: латентность, стоимость, точность (квантование/аппроксимации), а также требования к доверенным сторонам.
Коротко о каждом подходе
FHE (Full Homomorphic Encryption)
Вычисления над зашифрованными данными: пользователь шифрует x, провайдер применяет f(·) в криптодомене и возвращает Enc(f(x)). Расшифровка только у владельца ключа.
*Сильные стороны*: «одна сторона» достаточна; нет раскрытия входов и промежуточных значений. *Слабые стороны*: высокая латентность и стоимость (особенно для нелинейностей), ограничения на точные типы операций; обычно требует квантования/полиночных аппроксимаций активаций.
SMPC (Secure Multi-Party Computation)
Данные делятся на секрет-шары между несколькими участниками; никакая одиночная сторона не видит исходных данных, но совместно они вычисляют функцию.
*Сильные стороны*: лучшее соотношение скорость/точность для многих задач; поддержка «острых» нелинейностей через протоколы. *Слабые стороны*: нужен кворум доверенных исполнителей и устойчивая сеть; угроза сговора и отказов.
zkML (Zero-Knowledge ML)
Провайдер выполняет инференс/обновление весов и вырабатывает криптодоказательство, что «вычисление корректно выполнено по задекларированной модели на заявленном входе».
*Сильные стороны*: верифицируемость (в том числе on-chain), отделимость вычислений и проверки, прозрачный аудит. *Слабые стороны*: «тяжёлый» этап подготовки (аритметизация/компиляторы), накладные расходы на генерацию доказательства, сложность для больших трансформеров (но быстрое развитие специализированных схем).
Что выбрать: сравнительная таблица
| Критерий | FHE | SMPC | zkML |
| — | — | — | — |
| Конфиденциальность входов | Очень высокая (данные всегда шифрованы) | Высокая (секрет-шары) | По сценарию (не гарантирует приватность входов, если вход открыт для доказательства) |
| Конфиденциальность весов | Возможна (инференс над шифр. весами/входами) | Возможна при шардировании весов | По сценарию (модель может быть коммитнута хэшем; веса не обязаны раскрываться) |
| Доказуемость корректности | Не по умолчанию | Не по умолчанию | Да (SNARK/STARK) |
| Латентность | Высокая | Средняя/высокая (зависит от протокола/сети) | Высокая на генерации доказательства; проверка быстрая |
| Точность | Часто аппроксимации | Близко к нативной | Близко к нативной |
| Доверительные допущения | Ключ у клиента | Несговорчивость подмножества сторон | Криптодопущения схемы, корректность компиляции |
| Подходит для LLM-чата | Пилоты/нишевые узкие задачи | Пилоты; лучше на коротких запросах | Верифицируемые ответы/оценки; пока ограниченный масштаб |
| Интеграция с блокчейном | Косвенно (как оффчейн сервис) | Косвенно | Нативно (проверка доказательств on-chain) |
Типичные сценарии использования
- Конфиденциальный инференс по персональным данным: FHE/SMPC с короткими глубинами сетей, или узкими задачами классификации/скоринга.
- Проверяемая аналитика и анти-фрод: zkML — выпуск доказательств корректности для отчётов/требований регулятора.
- On-chain верификация сигналов из ML: zk-доказательства, проверяемые смарт-контрактами (без раскрытия всего датасета).
- Сторонние модели как «чёрный ящик»: SMPC/FHE для защиты весов от утечек у интегратора.
Интеграция с LLM и RAG
LLM-чат и RAG имеют специфические ограничения: длинное контекстное окно, большая математика внимания, интенсивный KV cache. Это осложняет прямое применение FHE/SMPC «в лоб». Прагматичные паттерны:
- Гибрид по частям пайплайна:
- Приватизируйте до- и пост-обработку (классификаторы слотов, детекторы PII) через SMPC/FHE, а саму генерацию держите нативной.
- Используйте zkML для верификации отдельных шагов (например, корректность вычисления скорингов/фильтров).
- Приватный ретрив: чувствительная часть запроса «анонимизируется» локально; на сервер уходит искомая проекция/эмбеддинг с шумом/клиппингом, а верификация корректности выдачи делается zk-доказательством на стороне ретривера (доказуемые top-k правила). См. Retriever, Vector index.
- Кэш-стратегии: системные префиксы можно разделять (см. Prefill cache), но приватные части — изолировать; никаких «сырьевых» промптов в логи (см. Prompt leakage).
Архитектурные паттерны
1) Конфиденциальный инференс (FHE-путь)
- Клиент генерирует ключи, шифрует входы.
- Сервер выполняет инференс в зашифрованном виде; нелинейности аппроксимируются полиномами.
- Клиент расшифровывает результат.
Практические заметки: проектируйте модель изначально под FHE-допустимые операции (свёртки, матрицы, полиномиальные активации), проводите квантование и клиппинг весов.
2) Конфиденциальный инференс (SMPC-путь)
- Источники делят данные на шары и отправляют разным серверам.
- Серверы исполняют протокол (GMW/Beaver triples/OT-варианты), возвращая зашифрованные выходы.
- Уполномоченная сторона собирает результат.
Практические заметки: следите за сетевой латентностью, балансируйте партии, ограничивайте глубину сети; для тяжёлых нелинейностей используйте заранее скомпилированные протоколы.
3) Верифицируемый инференс (zkML)
- Провайдер исполняет модель нативно или в «подготовленном» аритметическом формате.
- Параллельно строится доказательство, что «y = f(x; w)» при коммитах на x и w.
- Любая сторона быстро проверяет доказательство (в том числе on-chain), не видя x/w.
Практические заметки: добавляйте в схему коммиты на вход/веса/код; фиксируйте версию модели и формат нормализаций/квантования, чтобы исключить «подмену пути».
Ограничения и инженерные trade-offs
- Латентность: FHE — самый «тяжёлый», затем zk-доказательства; SMPC чувствителен к сети и числу раундов. Планируйте SLO по p95/p99 (см. Model serving).
- Точность: FHE часто требует замен активаций (ReLU → полином), что ведёт к деградации; компенсируйте дообучением под FHE.
- Стоимость: считайте $ за ответ и GPU/CPU-часы на доказательство. Для zkML выгодно держать «тёплый пул» генераторов.
- Безопасность пайплайна: крипто-ядро не отменяет уязвимостей верхнего уровня — инъекции, утечки, supply-chain риски model poisoning.
- Наблюдаемость: логируйте метаданные, а не сырой контент; для evals используйте синтетические/деперсонализованные кейсы (см. Evals).
Как спроектировать PPAI-проект (пошагово)
1) Сформулируйте требования: что защищаем (входы, веса, оба), нужна ли доказуемость для третьих лиц. 2) Выберите столп: FHE (макс. приватность при «одной стороне»), SMPC (компромисс скорость/качество при мульти-узлах), zkML (верификация/он-чейн). 3) Спроектируйте модель под ограничения (активации/квантование/разрядность фиксируйте в спецификации). 4) SLO/стоимость: задайте p95, tokens/s (если LLM-модули), бюджет $/ответ; ранний прототип на части пайплайна. 5) Граница доверия: кто держит ключи/коммиты; политика ротации ключей, geo-распределение серверов SMPC. 6) Контуры безопасности: защита от инъекций/утечек, изоляция KV и prefill по уровням доверия, маскирование логов. 7) Evals: соберите golden-набор приватных сценариев; добавьте метрики faithfulness и ASR/PLR; для zkML — проверки валидности доказательств. 8) План развёртывания: выберите рантайм/пулы генерации доказательств, параметризуйте партии, внедрите admission control (очереди/квоты).
Паттерны «прикладных» решений
- KYC/AML-проверки: локальная нормализация и выделение признаков → SMPC-скоринг между банками/провайдерами; отчёт подписывается zk-доказательством корректности правил.
- Медицинские коллаборации: федеративный сбор эмбеддингов и SMPC-агрегация градиентов; публикация агрегата с доказуемыми статистиками (zk-сводки).
- On-chain оракулы ML: провайдер публикует хеш модели и zk-доказательства корректности выдачи; контракт принимает/отвергает результат.
- Защита многомодальных данных: локальная векторизация изображений/аудио → шары в SMPC; глобальная аналитика без раскрытия исходников.
Как это сочетается с «классикой» безопасности ИИ
- PPAI ≠ серебряная пуля: даже с FHE/SMPC/zkML нужен слой политик и проверок. См. Prompt injection, Prompt leakage, Model poisoning.
- Guardrails на выводе: проверка форматов/JSON, фильтры PII/токсичности, «честный отказ».
- Supply-chain: подписи артефактов модели/доказательств, хеш-коммиты, репродуцируемые сборки.
Частые ошибки (анти-паттерны)
- «Сделаем приватный LLM целиком на FHE» — реалистичнее гибрид: FHE/SMPC на узких задачах + нативная генерация с защитой контента.
- «zk-доказательство = приватность» — zkML про верифицируемость, приватность входа/весов требует доп. коммит/скрытие.
- «Нет SLO — только крипта» — без p95/стоимости проект не взлетит.
- «Логи с сырыми промптами» — прямой риск утечек; логируйте только габариты/коды возврата/хеши артефактов.
- «Смешали версии квантования» — несовместимость трасс/доказательств; фиксируйте формат/калибровку.
Мини-глоссарий
- FHE — шифрование, позволяющее вычислять над зашифрованными данными.
- SMPC — вычисления над секрет-шарами между несколькими сторонами.
- zkML — доказуемый ML с нулевым разглашением (SNARK/STARK-класс).
- Коммит (commitment) — криптографическая фиксация значения без раскрытия.
- Аритметизация — перевод вычислений в форму, удобную для доказательств.
- Квантование — понижение разрядности весов/активаций для ускорения/совместимости.
Вопросы и ответы (FAQ)
Можно ли обучать большие модели «приватно»?
Да, но с оговорками: федеративное обучение + SMPC-агрегация статистик, локальные эмбеддинги; для FHE — специализированные слои/архитектуры. Полный тренинг LLM «вслепую» сегодня не практичен.
Подходит ли это для прод-чата с LLM?
Чаще — гибридно: приватные препроцессоры и верифицируемые части; основная генерация — нативно с жёсткими политиками и изоляцией кэшей.
Зачем zkML, если можно «доверять провайдеру»?
Доказуемость снижает требования доверия и открывает on-chain-интеграции и аудит без раскрытия данных.
Что быстрее: SMPC или FHE?
В большинстве практических задач SMPC быстрее и точнее, но требует нескольких исполнителей и устойчивой сети.
Можно ли совместить приватность и персонализацию?
Да: локальное дообучение или адаптеры, а наружу — только агрегаты/доказательства корректности. Не храните персональные градиенты «как есть».