GitHub Copilot научился связывать телеметрию с пользователем без сбора промптов

GitHub Copilot получил настройку, которая разделяет два вопроса, долго смешанных в корпоративной телеметрии: кто пользуется ассистентом и что именно он ему пишет. Параметр telemetry.capture.identity в managed settings позволяет администраторам Enterprise приписывать активность Copilot конкретному пользователю, не собирая промпты, ответы и содержимое инструментов. Параметр добавляет три варианта конфигурации. В опубликованном фрагменте анонса их перечень обрезан, поэтому точные названия и значения лучше сверять с оригинальной записью в GitHub Changelog от 12 октября 2026 года.

Что именно изменилось

До сих пор у компаний, внедряющих ИИ-ассистентов для разработчиков, был неудобный выбор. Либо собирать телеметрию в обезличенном виде и не понимать, кто из сотрудников реально использует инструмент. Либо включать подробный сбор, где вместе с атрибуцией в логи попадают тексты запросов, фрагменты кода и результаты вызовов инструментов. Во втором случае в хранилище телеметрии может оказаться всё, что разработчик показал модели: внутренние API, имена клиентов, куски непубличной логики.

Новая настройка выносит идентичность в отдельную ось. Администратор может оставить привязку события к пользователю и при этом не получать содержимое взаимодействия. Конфигурация задаётся централизованно через managed settings, то есть разработчик не переключает её локально.

Зачем это нужно компаниям

Атрибуция без контента закрывает несколько типовых задач корпоративного внедрения:

• учёт лицензий: видно, какие из купленных мест реально используются, а какие простаивают;
• расчёт эффективности: активность можно сопоставлять с командами и проектами, не читая сами переписки;
• разбор инцидентов: при аномальном поведении клиента ясно, на чьём устройстве оно возникло;
• соответствие внутренним политикам: службе безопасности не нужно хранить код и промпты, чтобы отвечать на вопрос «кто и когда».

Отдельный аргумент касается регуляторики. Для европейских компаний персональные данные в телеметрии и содержимое рабочих переписок обычно подпадают под разные режимы согласования с работниками и профсоюзами. Когда сбор идентификатора отделён от сбора текстов, обосновывать его проще: цель понятна, объём данных ограничен.

Что остаётся неясным

Анонс в доступном виде не раскрывает ряд деталей. Неизвестно, какие именно три варианта предлагает telemetry.capture.identity и в каком виде хранится идентификатор: как логин, внутренний ID или хеш. Из текста также не следует, на какие клиенты Copilot настройка распространяется и как она взаимодействует с уже существующими параметрами сбора содержимого. Эти пункты определяют, насколько настройка пригодна для строгих политик, и их нужно проверить до включения.

Как действовать администраторам

Практический порядок такой:

1. Прочитать полную запись в GitHub Changelog и документацию по managed settings, зафиксировать все три значения параметра. 2. Определить цель атрибуции: учёт лицензий, безопасность или аналитика продуктивности. От цели зависит выбор режима. 3. Согласовать использование с юристами и представителями сотрудников. Идентификатор пользователя остаётся персональными данными, даже когда промптов в логах нет. 4. Проверить на пилотной группе, что содержимое действительно не попадает в телеметрию, например изучив реальные события в приёмнике логов. 5. Задать срок хранения и круг доступа к данным: атрибуция сама по себе позволяет строить профили активности.

Итог для рынка прагматичный. Корпоративные ИИ-ассистенты всё чаще выбирают по контролю над данными, а не только по качеству модели. Возможность отвечать на вопрос «кто использует» без ответа на вопрос «что он писал» убирает один из частых аргументов службы безопасности против широкого внедрения.