--- service: "Publicasta" schema_version: "1.0" article_id: 762 title: "Проверяемое федеративное обучение Google меняет вопросы к приватности для покупателей ИИ" language: "ru" default_language: "en" canonical_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ru" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=ru" api_url: "https://publicasta.com/api/public/v1/channels/ai_practice/articles/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ru" channel_url: "https://publicasta.com/api/public/v1/channels/ai_practice" channel_articles: "https://publicasta.com/api/public/v1/channels/ai_practice/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-10-04T10:24:45+00:00" updated_at: "2026-10-04T10:24:45+00:00" translations: - language: "ar" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ar" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=ar" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=ar" - language: "de" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=de" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=de" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=de" - language: "en" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=en" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=en" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=en" - language: "es" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=es" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=es" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=es" - language: "fr" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=fr" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=fr" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=pl" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=pl" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=ru" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=ru" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist?lang=zh" markdown_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.md?lang=zh" json_url: "https://publicasta.com/ai_practice/google_verifiable_federated_learning_enterprise_privacy_checklist.json?lang=zh" --- # Проверяемое федеративное обучение Google меняет вопросы к приватности для покупателей ИИ > Новая система Google на базе доверенных сред выполнения делает заявления о приватности при федеративном обучении более проверяемыми. Для команд, работающих с чувствительными данными, важно отличать технические ограничения от обещаний и понимать, что система всё ещё может раскрыть. Последние разработки Google в области федеративного обучения легко принять за очередную работу об инфраструктуре. Но практический смысл в другом. Важна не только возможность обучать модель на данных, которые остаются на телефонах или в разных организациях. Меняется сам серверный процесс обучения: теперь его проектируют так, чтобы внешние стороны могли проверить, какие рабочие нагрузки разрешены, удостовериться в личности программного обеспечения и убедиться, что наружу выходят только обезличенные результаты. ![Редакционная визуализация: телефоны и узлы организаций передают зашифрованные данные в аттестованный защищённый вычислительный модуль для конфиденциального федеративного обучения.](https://publicasta.com/storage/projects/8/pages/762/2026/10/d3e4cd7a-818f-4aa7-8478-47402f347374.webp) 2 октября Google Research объявила о новой системе федеративного обучения на базе доверенных сред выполнения (Trusted Execution Environments, TEE), публичных журналов прозрачности, зашифрованных загрузок и дифференциальной приватности. По словам Google, система уже используется для моделей предсказания следующего слова на английском и японском языках в Gboard. Компания сообщает о более быстром обучении и лучшем компромиссе между приватностью и полезностью по сравнению с прежней конфигурацией. Сопроводительная статья описывает архитектуру и её промышленное развертывание. Это не означает, что федеративное обучение внезапно стало универсальным ответом для приватного ИИ. Зато разговор о покупке таких систем смещается от привычного обещания — сырые данные остаются на месте — к более трудному вопросу: может ли организация доказать, что обучающему сервису было разрешено делать с данными после их поступления? Для компаний, которые рассматривают ИИ для чувствительных текстов, медицинской информации, финансовых записей, промышленной телеметрии или данных, которыми обмениваются учреждения, это различие полезно. Система может не создавать центральное хранилище сырых данных и всё равно раскрывать информацию через обновления, журналы, модели участия, поведение модели или слабые операционные средства контроля. Приватность — свойство всего рабочего процесса, а не следствие модного названия архитектуры. ## Что именно объявила Google Федеративное обучение распределяет части процесса обучения модели между несколькими клиентами. В знакомой архитектуре с устройствами телефоны или другие конечные точки вычисляют локальные обновления на локальных данных, отправляют защищённые обновления координатору и получают обновлённую модель. Поставщику сервиса не нужно собирать исходные примеры в одну обычную обучающую базу. Google представила этот подход в 2017 году и, согласно [объявлению исследовательской команды](https://research.google/blog/toward-provably-private-learning-from-federated-data/), использовала его для таких функций, как предсказание следующего слова в Gboard, Smart Compose, подсказки ответов и Smart Text Selection. Новая конструкция меняет место выполнения части ресурсоёмкой работы. Клиентские устройства загружают зашифрованные обучающие примеры, а серверные TEE выполняют программу обучения. TEE — это аппаратно изолированная среда, предназначенная для конфиденциальности и целостности кода и данных во время вычислений. Она также может поддерживать удалённую аттестацию: проверяющая сторона удостоверяется, что запущена конкретная одобренная рабочая нагрузка, прежде чем передать ей ключи или данные. Google соединяет это свойство с политикой доступа. Политика определяет, какие серверные рабочие нагрузки могут обрабатывать загрузку. Устройство проверяет и авторизует политику до отправки зашифрованных данных, а сервис управления ключами выдаёт ключи расшифровки только рабочей нагрузке, соответствующей политике. Google сообщает, что политики публикуются в Rekor — публичном журнале прозрачности, — поэтому аудиторы могут видеть, в каких серверных рабочих нагрузках устройства могли участвовать. В системе также используются сервис управления ключами, размещённый в TEE, корневая TEE обработки, рабочие TEE для параллельных задач и зашифрованное состояние восстановления после сбоев. Логика обучения выражается на Federated Language — языке оркестрации с открытым исходным кодом, производном от TensorFlow Federated. Операторам рабочих нагрузок должны быть доступны только метрики и веса моделей с дифференциальной приватностью, а не отдельные обучающие примеры. Это более конкретная поверхность контроля, чем заявление о приватности в рекламной брошюре. Вопрос теперь не только в том, говорит ли поставщик, что не будет просматривать данные. Нужно выяснить, могут ли данные быть расшифрованы только аттестованной рабочей нагрузкой, записывается ли разрешённая рабочая нагрузка, можно ли воспроизвести сборку и ограничивает ли механизм выпуска то, что покидает защищённую среду. ## Почему фразы данные никуда не уходят было недостаточно Федеративное обучение часто объясняют формулой модель приходит к данным. Для общего описания идеи это удобно, но такая формула скрывает несколько классов отказа. Обновление обучения может содержать сведения о примерах, на которых оно было создано. Сервис агрегации может просматривать обновления до их объединения. Вредоносный или скомпрометированный координатор способен изменить код обучения. Журналы могут показать, кто участвовал, когда именно и как часто определённая группа вносила вклад. Модель, выпущенная без достаточной гарантии приватности, может позволить злоумышленнику сделать выводы о своём обучающем наборе. Даже промежуточная структура, которая выглядит приватной, может раскрывать информацию при многократных запросах или в сочетании с внешними знаниями. Поэтому приватное федеративное обучение обычно объединяет несколько методов, а не полагается на один. Безопасная агрегация может не дать координатору увидеть отдельные обновления клиентов, но сама по себе не гарантирует, что итоговая модель не раскроет сведения. Дифференциальная приватность задаёт формальную границу влияния данных отдельного человека или группы на выпущенный результат, однако цена для полезности зависит от рабочей нагрузки, объёма данных, схемы выборки и бюджета приватности. TEE защищает код и данные внутри анклава, но не устраняет уязвимости оборудования, побочные каналы, ошибки реализации, сбои управления ключами или чрезмерно широкую рабочую нагрузку. Значимость объявления Google в том, что оно пытается связать эти уровни. TEE контролирует выполнение и выдачу ключей. Политика и журнал прозрачности создают аудиторский след. Дифференциальная приватность ограничивает выпущенные веса модели. Воспроизводимые сборки позволяют сопоставлять исходный код с развёрнутыми бинарными файлами. Архитектура стремится уменьшить объём доверия к оператору и одновременно сделать оставшиеся предположения видимыми. Оговорка важна. Google сама описывает гарантии TEE как зависящие от ограничений нынешнего поколения технологий. Компания также говорит, что логика, связанная с приватностью, должна оставаться жёстко заданной в Python-программе обучения, если архитектуры проприетарных моделей или детали предварительной обработки динамически подгружаются. Для аудиторов это создаёт границу, которую нужно понимать: не каждый параметр или компонент промышленной рабочей нагрузки обязательно обладает той же проверяемостью, что и сам механизм приватности. ## Полезный переход от доверия к серверу к проверке рабочей нагрузки При закупке размещённого ИИ обычно спрашивают, где поставщик хранит данные, как долго держит запросы, использует ли содержимое клиентов для обучения и какие администраторы могут получить доступ к среде. Эти вопросы остаются необходимыми. Но когда сервис вычисляет что-то над зашифрованными или распределёнными данными, их недостаточно. Более строгая проверка спрашивает, что сервис технически не может сделать. Например: - Какие именно программы имеют право расшифровывать и обрабатывать данные? - Может ли клиент или независимый аудитор проверить личность рабочей нагрузки до выдачи ключа? - Неизменна ли политика авторизации на протяжении обучения или привилегированный оператор может изменить её позже? - Попадают ли изменения политики в публичный журнал прозрачности или журнал, доступный клиенту? - Собираются ли бинарные файлы воспроизводимым образом из исходного кода, который могут проверить эксперты? - Какая информация выпускается на каждом этапе: отдельные обновления, агрегированные обновления, метрики, контрольные точки, эмбеддинги или только финальная модель? - Как ведётся учёт дифференциальной приватности и учитывает ли он повторяющиеся выпуски во времени? - Что происходит при отказе рабочего процесса, восстановлении снимка или откате модели? Это операционные вопросы, а не теоретическое украшение. Систему, которая отвечает на них точно, легче контролировать: её утверждения можно сопоставить с артефактами — подписанными бинарными файлами, записями аттестации, журналами выдачи ключей, регистрами приватности, репозиториями исходного кода и процедурами реагирования на инциденты. Если ответом остаётся лишь общее заверение в конфиденциальности, клиент по-прежнему зависит от внутреннего процесса поставщика. Google использует Rekor как журнал прозрачности и сообщает, что KMS и бинарные файлы обработки данных можно воспроизводимо собрать из открытого кода в репозитории Confidential Federated Compute. Это не то же самое, что независимый аудит каждого развёртывания. Но у проверяющих появляется нечто полезнее абзаца в политике: путь к изучению разрешённых рабочих нагрузок и сравнению реализации с заявленной архитектурой. Различие похоже на разницу между зашифрованной базой данных и проверяемой политикой доступа к данным. Шифрование защищает содержимое в определённых состояниях. Политика объясняет, кто и с какой целью может получить доступ. Проверка даёт другой стороне способ выяснить, соблюдает ли система эту политику. Зрелая инженерия приватности нуждается во всех трёх элементах. ## Практическая выгода переноса вычислений обратно на сервер Самая неочевидная часть объявления Google состоит в том, что более сильные гарантии приватности могут появиться вместе с большим объёмом серверных вычислений. Ранние федеративные системы сильно зависели от доступности устройств, локальных вычислительных ресурсов, состояния сети и конкуренции с другими задачами. Если нужная группа устройств была недоступна, раунды обучения занимали больше времени или давали более слабый результат. Google сообщает, что некоторые прежние федеративные модели Gboard обучались от одного до двух месяцев. Новая архитектура сначала собирает зашифрованные загрузки, а затем выбирает расписание участия на сервере внутри защищённой рабочей нагрузки. Благодаря этому система может оптимизировать выбор устройств и параметры дифференциальной приватности после наблюдения за доступностью, а не позволять ритму обучения полностью зависеть от того, какие телефоны случайно находятся онлайн. По данным Google, нынешним узким местом стала доступность ресурсов TEE, а не вычисления на устройствах. Это существенный инженерный компромисс. Если оставить вычисления на конечных точках, центральный сервис увидит меньше, но одновременно ограничатся размер модели, выбор алгоритма, расход энергии и планирование. Перенос вычислений в защищённую серверную среду может сделать обучение предсказуемее и потенциально поддержать более крупные модели. Польза для приватности зависит от защиты этой среды: аттестации, выдачи ключей, применения политик, контроля выходных данных и модели угроз для оборудования. Для предприятия это означает, что слово федеративный нельзя считать синонимом слов на устройстве. Промышленная система может включать распределённый этап сбора данных, зашифрованную передачу, серверный этап конфиденциальных вычислений и этап выпуска с дифференциальной приватностью. У каждого этапа свои режимы отказа и своя структура затрат. ## Что даёт дифференциальная приватность и чего она не делает Дифференциальная приватность — математическая система для количественной оценки потери приватности. В [SP 800-226](https://csrc.nist.gov/pubs/sp/800/226/final) NIST описывает её как способ рассуждать о том, как наличие или отсутствие данных некоторой сущности влияет на результат, одновременно предупреждая, что реальные реализации связаны с многочисленными рисками и проектными решениями. На практике система обучения с дифференциальной приватностью ограничивает степень влияния данных одного участника на выпущенный результат. Распространённые механизмы ограничивают вклад отдельных обновлений и добавляют калиброванный шум. Меньший бюджет приватности обычно означает более сильную формальную гарантию, но слишком большой шум может снизить точность. Компромисс определяется числом участников, частотой повторного использования данных, единицей приватности — записью, пользователем, устройством или организацией — и числом выпускаемых результатов. Последний пункт легко упустить. У модели может быть гарантия приватности для одного запуска обучения, а последовательность контрольных точек, аналитических панелей, экспериментов или вариантов модели потребует дополнительного бюджета. Организации нужен регистр и политика выпуска, а не только разовое значение эпсилон в исследовательской статье. Также нужно прямо указать, чья приватность защищается. Приватность на уровне пользователя — не то же самое, что приватность на уровне события: защита одного нажатия клавиши не ограничивает влияние всего, что человек передавал в течение месяцев. Дифференциальная приватность также не решает вопросы управления данными до обучения. Она не определяет, было ли законным основание для сбора, сообщили ли людям о способе использования, справедливы ли метки и безопасна ли полученная модель для развёртывания. Она не мешает разрешённой рабочей нагрузке учиться не тому, чему следует. Это ограничение утечки информации из результатов, а не замена ограничению цели, контролю доступа, правилам хранения или понятной процедуре удаления. Поэтому правильный вопрос покупателя звучит не так: используется ли здесь дифференциальная приватность? Нужно спросить: какова единица приватности, каков бюджет, какие выпуски его расходуют, кто проверяет расчёты и какую потерю полезности измерили на нашей задаче? ## Где TEE помогает и где доверие сохраняется TEE может уменьшить необходимость доверять облачным операторам открытые данные во время обработки. Это важно для рабочих нагрузок, в которых поставщик должен вычислять результат, но клиент не хочет, чтобы обычные администраторы хоста, соседние арендаторы или оператор сервиса просматривали данные. Удалённая аттестация может связать решение о выдаче ключа с измеренной идентичностью программного обеспечения. Но TEE не является волшебным контейнером приватности. Покупателю стоит задать как минимум пять дополнительных вопросов. Во-первых, какое оборудование и микропрограмма входят в область контроля? TEE зависит от возможностей процессора, прошивки, криптографических ключей и обновлений безопасности поставщика. Модель угроз может исключать некоторых привилегированных участников или предполагать, что определённые побочные каналы нельзя эксплуатировать. Во-вторых, какой код измеряется и проходит аттестацию? Ответ должен включать операционную среду, логику управления ключами, программу обучения, релевантные библиотеки и динамически загружаемые компоненты. Если измеряется только небольшой загрузчик, а важная логика приватности подгружается позже, утверждение об аттестации может быть уже, чем кажется. В-третьих, как выдаются секреты? Управление ключами должно быть связано с одобренной рабочей нагрузкой и явной политикой. Человек-администратор, способный обойти это решение, входит в модель угроз, даже если обычный путь защищён криптографическими ограничениями. В-четвёртых, что можно вывести из метаданных? Время, принадлежность к когорте, размер запроса, характер отказов и расписание выпусков могут нести информацию, даже если полезная нагрузка зашифрована. Проверка приватности должна охватывать трафик и операционные метаданные, видимые каждому участнику. В-пятых, что происходит во время реагирования на инцидент? Скомпрометированный хост, отозванное измерение, уязвимый анклав или нарушенный конвейер сборки требуют практического плана: остановить выдачу ключей, сменить ключи, сделать рабочие нагрузки недействительными, сохранить доказательства и определить, можно ли доверять ранее выпущенным результатам. Система, приватная только пока ничего не ломается, не готова к чувствительной промышленной эксплуатации. Более ранние рекомендации NIST по приватному федеративному обучению показывают тот же принцип с другой стороны. В обсуждении приватного пересечения множеств и фильтров Блума NIST отмечает, что методы, предназначенные для согласования данных, всё равно могут раскрывать сведения о совпадениях, а более сильная защита часто требует производительности. Вывод не в том, чтобы отвергнуть эти методы, а в том, чтобы включить утечку в модель угроз и явно решить, приемлема ли она. ## Трения при запуске будут значительными Компания не может внедрить такую архитектуру, просто включив переключатель приватности в обычном API ИИ. Сложная работа начинается ещё до обучения модели. Команде нужно определить владельца данных, единицу приватности, разрешённую цель, ограничения хранения и результаты, которым разрешено покидать защищённую среду. Нужно решить, будут ли клиенты загружать примеры, градиенты, признаки или другое представление. Потребуются путь аттестации, сервис управления ключами, формат политик, журнал прозрачности, конвейер воспроизводимых сборок и механизм учёта приватности. Нужно проверить восстановление и отзыв доступа. Также следует документировать связь между конфиденциальными вычислениями и юридическими или договорными обязательствами. Инженерная поверхность шире скрипта обучения модели. Промышленное развёртывание требует клиентских библиотек, механизмов регистрации и обновления, криптографической идентичности, планирования рабочих нагрузок, наблюдаемости, которая не собирает лишние чувствительные метаданные, средств контроля цепочки поставки ПО и способа сравнить измеренное развёртывание с проверенным исходным кодом. Организации, которые уже обслуживают мобильную инфраструктуру, парк устройств, кластеры конфиденциальных вычислений или конвейеры регулируемых данных, находятся в лучшем положении, чем команда, начинающая с одного ноутбука. Затраты появятся в нескольких местах. Для TEE нужно совместимое оборудование, а оно может уменьшить доступную ёмкость или осложнить доступ к ускорителям. Аттестация и управление ключами добавляют операционные зависимости. Публичное журналирование и воспроизводимые сборки требуют дисциплины выпуска. Дифференциальная приватность может потребовать большего числа участников, дополнительных раундов или большего объёма данных для достижения приемлемой точности. Аудит и проверка на проникновение становятся постоянными расходами, а не задачей перед запуском. Архитектура всё же может оказаться дешевле централизации, если централизация создаёт неприемлемые юридические, защитные или договорные риски. Но автоматически дешевле обычного обучения она не становится. Сравнивать нужно полную стоимость успешной и соответствующей требованиям модели: инфраструктуру, разработку, аудиты, потерю производительности, готовность к инцидентам и ценность доступа к данным, которые нельзя объединить в обычной форме. ## Кому стоит попробовать этот подход Подход наиболее перспективен, когда данные распределены не случайно, а по существенной причине, и задача обучения выигрывает от объединения сигналов разных участников. Примеры — персонализация на устройствах, обнаружение мошенничества между организациями, клинические исследования, в которых учреждения не могут обмениваться сырыми записями, а также промышленные или полевые данные, остающиеся под локальным контролем. Это сильный кандидат, если главное возражение против централизованного обучения связано не с предпочтением поставщика, а с конкретным риском: договорным запретом, чувствительной группой, регуляторным ограничением или реальной угрозой со стороны инсайдеров и скомпрометированной инфраструктуры. В таких условиях проверяемая авторизация рабочей нагрузки может заметно изменить оценку риска. Подход также стоит рассматривать, когда покупателю нужен убедительный ответ для аудиторов или партнёров. Журнал прозрачности, воспроизводимая сборка, запись аттестации и регистр приватности создают доказательства, которые можно проверить позже. Они не обязательно закрывают каждый вопрос, но улучшают разговор между инженерией, безопасностью, юристами и владельцами данных. Небольшой пилот следует начинать с задачи, где единица приватности и метрика успеха определены ясно. Предсказание следующего слова удобно тем, что система может измерять точность, скорость обучения, участие и учёт приватности в повторяющихся раундах. Предприятию следует выбрать столь же ограниченный процесс: узкую задачу классификации, небольшой набор участвующих организаций и определённый график выпуска. Пилот должен сравнить защищённую архитектуру с обычной базовой конфигурацией и показать полезность, задержку, стоимость, утечки и операционную нагрузку. ## Кому пока стоит отказаться Команде, у которой нет проблемы распределённых данных, вероятно, не следует начинать с этой архитектуры. Если все необходимые данные уже разрешено централизованно использовать, хорошо защищённое частное облако или изолированная среда обучения может быть проще для защиты и объяснения. Федеративное обучение добавляет координацию и криптографическую механику; само по себе оно не является улучшением приватности. Это также плохой выбор, если данных слишком мало или они распределены слишком неравномерно для полезного обучения. Дифференциальная приватность требует участия и аккуратного учёта. Система с несколькими участниками может дать формальную гарантию, но при этом произвести слишком зашумленную, предвзятую или нестабильную модель. Организациям, которые не могут поддерживать цепочку поставки ПО, систему управления ключами или процесс реагирования на инциденты, не стоит воспринимать архитектуру на базе TEE как короткий путь. Конфиденциальные вычисления переносят ответственность, но не снимают её. Если команда не умеет проверять изменения рабочих нагрузок, отзывать ключи, отслеживать бюджет приватности или расследовать утечки из метаданных, архитектура может создать более сложный отказ, которым труднее управлять. Наконец, нужно проявлять осторожность, если желаемый результат — решение с серьёзными последствиями для конкретных людей. Защита приватности не отвечает на вопросы дискриминации, возможности оспаривания, качества данных или необходимости человеческой проверки. Приватная модель всё равно может принять несправедливое решение. ## Контрольный список покупателя для проверяемого приватного обучения До подключения любого сервиса федеративного обучения попросите поставщика письменно ответить на следующие вопросы и, где возможно, приложить подтверждающие материалы: 1. **Что именно является приватным?** Относится ли гарантия к исходным входам, отдельным обновлениям, вкладам на уровне пользователя, финальной модели или ко всему перечисленному? 2. **Какова модель угроз?** Включает ли она оператора сервиса, администраторов облака, скомпрометированные клиенты, вредоносных участников, сговорившиеся стороны и атаки на оборудование? Какие атаки прямо исключены? 3. **Что обеспечивается криптографией или оборудованием?** Отделите договорные обещания от средств, которые реально не дают оператору прочитать данные или заменить рабочую нагрузку. 4. **Как работает аттестация?** Попросите указать измеряемые компоненты, процедуру проверки, условия выдачи ключа и процесс отзыва. 5. **Можно ли проверить логику приватности?** Выясните, доступны ли для изучения исходный код, зависимости, процесс сборки, файлы политик и измерения развёрнутой системы. 6. **Как рассчитывается бюджет приватности?** Подтвердите единицу приватности, метод учёта, композицию при нескольких выпусках, предположения о выборке и обработку повторных попыток и восстановления. 7. **Что покидает защищённую среду?** Учитывайте метрики, контрольные точки, эмбеддинги, ошибки, журналы, данные о времени, статистику когорт и материалы поддержки. 8. **Что раскрывает участие?** Определите, может ли координатор или другой участник понять, что внесли вклад конкретное устройство, сотрудник, организация или группа пациентов. 9. **Что будет, если модель ошибается?** Проверки приватности и полезности должны включать качество по подгруппам, дрейф, устойчивость к отравлению и план отката. 10. **Сколько это стоит в целевом масштабе?** Оцените мощности TEE, хранение, управление ключами, журналирование, аудиты, обновления клиентов, повторы и цену точности при более сильной приватности. Если поставщик не может ответить на эти вопросы, сервис всё ещё может пригодиться для экспериментов с низким риском. Но его не следует считать доказанным средством защиты чувствительных производственных данных. ## Более широкий вывод для закупки ИИ Объявление Google не означает, что доверенное оборудование решило проблему приватного машинного обучения. Оно показывает, что граница приватности становится более операционной. Ценность системы в соединении нескольких механизмов: зашифрованного приёма, ограниченной выдачи ключей, аттестованного выполнения, проверяемых политик, воспроизводимого программного обеспечения, дифференциальной приватности и контролируемого выпуска. Уберите любой из них — и утверждение станет уже. Меняется и то, что компании должны измерять. Проект приватного ИИ должен сообщать не только точность модели и стоимость инфраструктуры. Нужно показывать, кто и что мог видеть, какие рабочие нагрузки были разрешены, сколько информации выпущено, как изменился бюджет приватности, как система вела себя при отказе и какие доказательства может проверить независимый эксперт. Это более требовательный стандарт, чем фраза мы не обучаемся на ваших данных, но и более полезный. Обещание распределённого обучения становится убедительным, когда владелец данных может изучить разрешённые вычисления, оператор не способен незаметно подменить рабочую нагрузку, а финальный результат сопровождается документированной ценой приватности. Для покупателей ИИ непосредственный совет прост: рассматривайте федеративное обучение как решение по архитектуре и закупке, а не как свойство модели. Сначала определите информацию, которую необходимо защищать, стороны, которым нельзя доверять, и доказательства, которые понадобятся аудитору. Затем проверьте, действительно ли предлагаемая архитектура устанавливает эти границы. Новое развёртывание Google для Gboard показывает, что такой подход можно довести до промышленного масштаба. Более трудный вопрос для остальных — оправдывает ли выигрыш в приватности всю эту механику и готова ли организация честно ею управлять. ## Источники - [Google Research: Toward provably private learning from federated data](https://research.google/blog/toward-provably-private-learning-from-federated-data/) — описание системы и её промышленного развёртывания. - [arXiv: Toward provably private learning from federated data](https://arxiv.org/abs/2609.31494) — сопроводительная исследовательская статья об архитектуре. - [NIST SP 800-226: Guidelines for Evaluating Differential Privacy Guarantees](https://csrc.nist.gov/pubs/sp/800/226/final) — контекст для оценки гарантий дифференциальной приватности. - [NIST: Protecting Model Updates in Privacy-Preserving Federated Learning: Part Two](https://www.nist.gov/blogs/cybersecurity-insights/protecting-model-updates-privacy-preserving-federated-learning-part-two) — контекст о рисках и компромиссах защиты обновлений модели.