2 октября 2026 года Google Research представила федеративное обучение с проверяемой серверной обработкой: устройства передают зашифрованные примеры, а вычисления выполняются в доверенных средах исполнения — TEE. Для бизнеса главное следствие новости: место вычислений нужно оценивать вместе с доказательствами того, какой код получает доступ к данным. Источник: Google Research.
Материал подготовлен редакцией AIrassvet для руководителей ИТ, владельцев ИИ-проектов и команд данных. Первая версия — 3 октября 2026 года. Разбираем архитектуру и вопросы приёмки; установка системы и юридическая оценка обработки персональных данных требуют отдельной работы. Собственных испытаний TEE, сборки бинарных файлов или экспериментов Gboard редакция не проводила.
Содержание:
- Что изменилось в федеративном обучении
- Три разных доказательства приватности
- Что показал эксперимент Gboard
- Где заканчиваются гарантии
- Какие материалы запросить у поставщика
- Как применить выводы к корпоративному проекту
- Ответы на частые вопросы
- Как AIrassvet помогает подготовить данные для ИИ
- Вывод
Что изменилось в федеративном обучении
Федеративное обучение — совместное обучение модели по данным множества участников при координации сервиса. В новой системе Google клиент заранее согласует политику разрешённых вычислений. Ключами управляет KMS — сервис управления ключами в TEE; он выдаёт их только подходящим вычислительным компонентам. Политики публикуются в журнале прозрачности, а обучение распределяется между корневым узлом и рабочими TEE. Google сообщает о применении системы для английской и японской моделей предсказания следующего слова Gboard. Описание Google.
Поэтому обещание «данные всегда остаются на устройстве» для этой архитектуры было бы неточным. При обсуждении корпоративного проекта полезнее нарисовать маршрут конкретного поля: где оно появляется, кто разрешает обработку, где происходит расшифровка и какой результат выходит наружу. Такая схема показывает, какой вопрос задавать инженеру и какой документ нужен для ответа.
Новость опубликована 2 октября, но препринт появился 25 сентября; рассматриваемая версия v3 датирована 29 сентября 2026 года. Публикация на arXiv сама по себе не подтверждает рецензирование в научном журнале. Карточка версии.
Три разных доказательства приватности
TEE защищает исполнение, аттестация подтверждает исполняемый компонент, а дифференциальная приватность ограничивает утечку через опубликованный результат. Эти уровни полезно проверять отдельно. Дифференциальная приватность, или DP, — математический подход к количественной оценке потери приватности при включении данных участника в набор; NIST отдельно описывает ошибки, возникающие при практической реализации. NIST SP 800-226.
В репозитории Confidential Federated Compute описана связь шифрования, политики доступа и удалённой аттестации — проверки того, какой бинарный файл выполняется. Документация также связывает записи проверки с воспроизводимой сборкой. Сам репозиторий сопровождается оговоркой: это не официально поддерживаемый продукт Google. Наличие исходников не подтверждает готовность сервиса для конкретного заказчика. README проекта.
Rekor хранит подписанные метаданные в защищённом от незаметного изменения журнале и позволяет другим участникам запрашивать их. Документация Sigstore. Редакционный вывод: запись в журнале помогает проверить опубликованный артефакт, но не заменяет оценку его содержания. Для приёмки нужны и ссылка на запись, и объяснение, почему зафиксированный код удовлетворяет требованию компании.
Что показал эксперимент Gboard
В разделе 5.3 препринта описан A/B-тест английской модели: каждая экспериментальная группа включала 3,5 млн устройств. Лучший вариант TEE использовал бюджет zCDP 0,215 против 0,641 у производственной модели после приведения к тому же механизму MF-DP-FTRL. Авторы характеризуют различие как примерно трёхкратное. Показатели Words Per Minute и Words Modified Ratio остались нейтральными; обучение заняло три недели против двух месяцев у предыдущей производственной модели. Препринт v3, раздел 5.3.
Это результат авторов для определённой модели клавиатуры. Он не означает «в три раза меньше вероятность утечки» и не обещает такое же ускорение корпоративного обучения. zCDP — параметр математической гарантии, а не процент безопасности. В разделе 6.1 авторы указывают модели до 10 млн параметров; масштабирование к существенно большим моделям обсуждается как дальнейшая работа. Препринт v3.
Для руководителя проекта практический вывод такой: прежде чем переносить цифру в бюджет, запросите аналогичный эксперимент на своей задаче. Зафиксируйте одинаковый набор приёмочных примеров, метрику качества, стоимость вычислений и полный срок подготовки. Ускорение одной стадии не показывает длительность всего проекта, если сбор и согласование данных занимают больше времени.
Где заканчиваются гарантии
В технической статье срок доступности расшифровки TTL описан как обеспечиваемый KMS на основе best effort; это не равнозначно доказательству физического удаления всех копий. Ответственность за анонимизацию выпускаемого результата лежит на авторе программы. Препринт, разделы 3.1 и 4.1. В блоге Google отдельно отмечены ограничения современных TEE, побочные каналы и условие: значимая для приватности логика должна оставаться в проверяемой программе при динамической загрузке информации. Google Research.
В корпоративной приёмке из этого следуют разные вопросы. Если поставщик описывает только срок хранения, запросите поведение ключей и возможность повторной обработки. Если он показывает только аттестацию, запросите допустимые выходы программы. Если подтверждена конкретная версия, выясните, что происходит при обновлении и кто согласует новую политику.
Также стоит различать техническую защиту и допустимость передачи данных. Эта статья не даёт заключения о соответствии российскому законодательству: регионы обработки, договорные условия и основание использования каждого набора данных нужно проверить отдельно. Цена, доступность корпоративного предложения и условия применения новой системы Google в России по изученным источникам не установлены.
Какие материалы запросить у поставщика
Таблица ниже — редакционный список вопросов для оценки предложения. Он не является выполненным аудитом системы Google или сертификатом безопасности.
| Обещание поставщика | Материал для проверки | Решение при нехватке доказательства |
|---|---|---|
| Доступ получает согласованный код | Версия программы, политика доступа, хеш бинарного файла и запись аттестации | Не считать проверенной связь согласованной версии с исполнением |
| Результат сохраняет приватность | Определение защищаемой единицы, механизм DP, параметры и учёт выпуска результатов | Попросить инженера объяснить гарантию в терминах конкретного набора данных |
| Доступ ограничен по времени | Срок действия ключей, поведение при сбоях и описание остаточных копий | Развести прекращение расшифровки и удаление в критериях приёмки |
| Обучение станет быстрее | Сопоставимый эксперимент на согласованной задаче и полном цикле | Не переносить результат Gboard в финансовый план |
| Система готова к эксплуатации | Поддерживаемые компоненты, обновления, ограничения и ответственность сторон | Начать с проверки применимости, затем обсуждать внедрение |
Полезный формат ответа — «требование → артефакт → версия → проверяющий → решение». Заполняйте его для каждого существенного обещания. Если доказательство отсутствует, помечайте это явно и назначайте ответственного за получение; общая презентация не должна закрывать несколько разных вопросов одной отметкой.
Проверку можно начать с самой простой цепочки. Выберите один разрешённый выход программы, выясните, какое поле участвует в его формировании, затем проследите правила обработки до выпуска результата. После этого добавляйте остальные выходы и обновления. Такой порядок помогает сделать объём проверки обозримым, но не гарантирует её полноту.
Как применить выводы к корпоративному проекту
Предположим, компания хочет улучшать классификатор обращений по данным филиалов. Это гипотетический сценарий, а не клиентский кейс. Сначала команда должна решить, действительно ли нужно обучение на распределённых данных: возможно, задачу можно проверить на уже согласованной обезличенной выборке. Архитектуру выбирают после описания цели и ограничений, а не по известности технологии.
Предлагаемый порядок подготовки:
- Определить решение, которое модель помогает принять, и допустимый выход: например, категорию обращения для маршрутизации.
- Перечислить поля, которые необходимы для этой задачи, и отдельно согласовать исключаемые сведения.
- Зафиксировать текущий способ обработки, набор приёмочных примеров и ответственность за ошибку классификации.
- Сопоставить варианты размещения вычислений с ограничениями данных и доступными доказательствами защиты.
- Согласовать условие остановки: какое отсутствующее доказательство или ухудшение качества не позволит перейти к эксплуатации.
Здесь нет универсального порога точности или срока пилота: их нельзя вывести из новости Google. Для подготовки набора примеров пригодится материал о подготовке данных перед внедрением ИИ, а вопросы отсутствия хранения запросов разобраны отдельно в статье о Zero Data Retention.
Метод этого разбора — сопоставление датированной новости, препринта v3, документации кода и материалов NIST и Sigstore. Числа взяты из раздела 5.3 работы авторов; таблица и сценарий являются предложениями редакции. Если обнаружится ошибка, сообщить о ней можно через контакты на сайте AIrassvet с указанием раздела и первоисточника.
Ответы на частые вопросы
Остаются ли данные на телефоне при новом федеративном обучении?
В описанной системе Google зашифрованные обучающие примеры загружаются на сервер. При оценке предложения нужно проверить разрешённые способы их обработки и выхода результатов. Обещание отсутствия передачи данных нельзя выводить из слова «федеративное».
Доказывает ли TEE безопасность всей ИИ-системы?
Для решения о внедрении одной отметки TEE недостаточно. Команде нужны подтверждения политики доступа, исполняемой версии, обработки выходов и ограничений оборудования. Состав этих доказательств следует согласовать до приёмки.
Можно ли использовать цифры Gboard для расчёта окупаемости?
Без сопоставимого эксперимента на своей задаче переносить их в расчёт не следует. Результат модели клавиатуры полезен как повод запросить проверку, но не задаёт стоимость, качество или сроки корпоративного проекта.
Подтверждает ли открытый код готовность продукта для бизнеса?
Исходники помогают изучить компоненты. Для решения о внедрении отдельно нужны поддержка, условия использования, совместимость и доказательства работы конкретной конфигурации. Их наличие нельзя предполагать по одной ссылке на GitHub.
Как AIrassvet помогает подготовить данные для ИИ
Новость ставит прикладной вопрос: какие данные действительно нужны выбранному процессу и по каким признакам принимать результат. В рамках описанных на сайте направлений AIrassvet — аудита процессов, подготовки данных и внедрения LLM — можно обсудить три задачи:
- описать один процесс, его текущий способ выполнения и критерий полезного результата;
- подготовить необходимый набор данных с учётом ограничений доступа;
- определить требования к размещению LLM и интеграции с существующими системами.
Первый шаг — выбрать процесс и перечислить источники данных, ограничения и критерий приёмки. Поддержка новой TEE-системы Google, проведение её аттестационного аудита и повторение результатов Gboard здесь не заявляются. Обсудить задачу.
Вывод
Федеративное обучение Google показывает, почему расположение сервера — лишь один из вопросов приватности. Для корпоративного решения нужны проверяемые связи между данными, разрешённым кодом и выпускаемым результатом. Начните с таблицы требований и доказательств для одного процесса; численные эффекты подтверждайте на собственной задаче, а открытые вопросы сохраняйте в решении о внедрении.
