GitHub Copilot Enterprise: guía de Spaces y la Usage Metrics API

¿Qué es GitHub Copilot Enterprise?

GitHub Copilot Enterprise se sitúa en la parte alta de la jerarquía de planes de Copilot de GitHub.

En comparación con GitHub Copilot Business o Pro+, Enterprise pone el foco en el gobierno, el contexto organizativo y las capacidades de medición. Está pensado para empresas con grandes entornos de ingeniería, no para desarrolladores individuales o equipos pequeños.

En la práctica, dos capacidades son las más importantes:

1. Contexto organizativo personalizado mediante Spaces
2. Telemetría a nivel de organización con la Usage Metrics API

Estas dos funciones hacen que Copilot pase de ser un simple «autocompletado inteligente» a algo más cercano a una plataforma interna de ingeniería con IA.

Las empresas que más partido sacan a GitHub Copilot Enterprise lo tratan como un componente clave de su infraestructura interna. Configuran el contexto organizativo con cuidado, miden la adopción de forma continua y ajustan las políticas basándose en datos de uso, no en suposiciones.

Para una visión más amplia del ecosistema de GitHub, te recomiendo leer nuestra guía Introduction to GitHub Products.

En qué se diferencia Enterprise de Business y Pro+

GitHub Copilot Enterprise amplía la suscripción Business con funciones como:

• Métricas de uso a nivel de organización
• Controles de gobierno ampliados
• Herencia de políticas en toda la empresa
• Asignaciones más amplias de solicitudes premium (1.000 frente a 300 en el nivel Business)
• Acceso y gestión adicionales de modelos

Enterprise requiere GitHub Enterprise Cloud además de la suscripción a Copilot Enterprise. Esto añade un coste adicional por usuario, así que asegúrate de que tu organización realmente necesita gobierno, telemetría y administración a nivel empresarial.

Nota: Los suscriptores de Business acceden a la Usage Metrics API a nivel de organización (/orgs/{org}/…). Los de Enterprise, además, acceden a informes agregados a nivel de empresa (/enterprises/{enterprise}/…) que abarcan todas las organizaciones en una sola vista.

Para quién es GitHub Copilot Enterprise

GitHub Copilot Enterprise se dirige a organizaciones que ya operan entornos de GitHub maduros.

Clientes típicos de Enterprise:

• Grandes organizaciones de ingeniería
• Industrias reguladas
• Grupos de platform engineering multi-equipo
• Empresas con estándares internos de desarrollo
• Organizaciones que requieren gobierno centralizado

Ojo: esto no mejora por sí mismo el rendimiento de Copilot. Creo que esta distinción importa porque muchos equipos inicialmente compran de más. Suponen que Enterprise equivale a «mejor Copilot», cuando en realidad Enterprise añade sobre todo herramientas de gobierno y medición.

Copilot Spaces: contexto a medida para tu organización

Copilot Spaces resuelve una de las mayores debilidades de los asistentes de codificación con IA generalistas.

De serie, Copilot entiende razonablemente bien el conocimiento público de programación. Lo que no entiende automáticamente son tus APIs internas, decisiones de arquitectura, convenciones de código, flujos de despliegue o documentación de onboarding.

Spaces proporciona un contexto organizativo curado que Copilot puede consultar durante las conversaciones y la asistencia al escribir código.

En la práctica, Spaces ayuda a Copilot a responder preguntas como:

• «¿Cómo estructuramos internamente los handlers de API?»
• «¿Qué librería de autenticación recomienda nuestro equipo de plataforma?»
• «¿Qué flujo de despliegue debe usar este microservicio?»
• «¿Qué convenciones de nombres sigue nuestro equipo de backend?»

Qué admite Spaces

Spaces admite una gama más amplia de contenido organizativo que el sistema anterior de Knowledge Bases.

Tipos de contenido admitidos:

• Archivos de código
• Documentación en Markdown
• Archivos JSON
• Archivos subidos
• Imágenes
• GitHub Issues
• Pull requests

Cada tipo de contenido aporta algo distinto.

Los archivos de código ayudan a Copilot a entender patrones de implementación. Los archivos Markdown aportan explicaciones de arquitectura y guías de onboarding. Los pull requests exponen debates de revisión y decisiones de ingeniería históricas. Esta combinación da a Copilot una mejor comprensión de las prácticas de desarrollo de tu organización.

Un punto sutil pero importante: Spaces no es simplemente una base de datos vectorial conectada a GitHub. Incluye controles de compartición y flujos de trabajo de gobierno organizativo diseñados para entornos empresariales.

El ocaso de Knowledge Bases

GitHub retiró la antigua función Copilot Knowledge Bases el 1 de noviembre de 2025.

Spaces sustituyó a Knowledge Bases con:

• Soporte de contenido más amplio
• Mejores controles de compartición
• Administración mejorada
• Gestión más flexible a nivel de organización

Aún encontrarás documentación y entradas de blog obsoletas que hacen referencia a Knowledge Bases. Ten cuidado al seguir tutoriales antiguos, porque muchos endpoints y flujos cambiaron durante el periodo de transición de 2025 a 2026.

Creación y configuración de Copilot Spaces

Desde el punto de vista de administración, crear Copilot Spaces es bastante sencillo. El reto llega al gestionar decenas o cientos entre equipos.

La estructura que elijas al principio tiende a perdurar. He visto organizaciones crear sin querer una «dispersión de documentación» dentro de Spaces porque nadie definió reglas de propiedad desde el principio.

Cualquiera puede crear un Copilot Space, así que probemos a crear uno en nuestro repo personal. Estos pasos son similares a nivel Enterprise, con algunas pantallas distintas.

Cómo configurar un Space

Crear un Space suele seguir este flujo:

1. Ve a la página de Copilot Spaces en el área de administración de tu Enterprise
2. Crea un nuevo Space

3. Selecciona repositorios y fuentes de contenido, incluidos MCPs y otras herramientas útiles

4. Puedes añadir fuentes haciendo clic en el botón «+ Add sources» en el lado derecho

5. Puedes optar por compartir el Space o configurar los ajustes de compartición en esta fase

6. Verifica que Copilot puede consultar el contenido durante los chats

Nota para usuarios de Enterprise: tu administrador puede desactivar el intercambio de Spaces personales. Si usas tu propia cuenta, esto puede afectar a tu capacidad de compartir un Copilot Space que no use los repositorios de la empresa.

Tras la configuración, los administradores deberían probar el Space con prompts prácticos.

Por ejemplo:

How does our authentication middleware handle token refresh logic?

O bien:

Show me an example of how our backend services structure database migrations.

Si Copilot no puede responder con precisión, normalmente el problema es alguno de estos:

• Repositorios que faltan
• Documentación de baja calidad
• Permisos incorrectos
• Tiempo de indexación insuficiente

Controles de compartición y acceso

Spaces admite dos modelos principales de visibilidad:

• Spaces individuales
• Spaces a nivel de organización

Los miembros de una enterprise pueden tener sus espacios individuales gestionados por la configuración global de la empresa. Los administradores de Enterprise también pueden gestionar de forma centralizada las políticas de previsualización y disponibilidad de funciones. 

Los Spaces privados funcionan bien para equipos experimentales o iniciativas internas sensibles. Los Spaces de organización tienen sentido para estándares de ingeniería, documentación de onboarding o frameworks comunes.

Un error frecuente es la sobrecentralización. Un único Space gigante a nivel de empresa puede volverse ruidoso y difícil de aprovechar por Copilot.

Organizar Spaces por equipo o dominio

No existe una estructura organizativa universalmente correcta.

Patrones habituales incluyen un Space por equipo, un Space por área de producto o Spaces compartidos de estándares. Cada uno tiene un alcance distinto y, en esencia, usa el mismo espacio de configuración de forma diferente.

Un Space por equipo

Útil cuando los grupos de ingeniería operan de forma relativamente independiente.

Ejemplos:

• Platform engineering
• Data engineering
• Desarrollo móvil

Un Space por área de producto

Útil para organizaciones estructuradas por productos más que por departamentos.

Ejemplos:

• Pagos
• Analytics
• Infraestructura
• Plataforma de clientes

Space compartido de estándares

Muchas organizaciones mantienen un Space compartido aparte para:

• Directrices de seguridad
• Convenciones de código
• Flujos de despliegue
• Estándares de arquitectura

En la práctica, los enfoques híbridos suelen funcionar mejor. Cada equipo puede tener su propio Space y compartir Spaces más amplios de estándares entre equipos.

La Copilot Usage Metrics API

Spaces resuelve el problema del contexto. La Usage Metrics API resuelve el problema de la medición. Sustituyó varios sistemas de telemetría antiguos que GitHub retiró durante la consolidación de APIs de 2026. 

Sin medidas claras, las organizaciones pierden visibilidad rápidamente sobre si la adopción de Copilot está funcionando. Dirección quiere evidencias de que la inversión mejora los flujos de trabajo de los desarrolladores y no añade solo otra partida de suscripción.

El panel alcanzó disponibilidad general en febrero de 2026 y es accesible desde tu cuenta de enterprise → AI Controls → Copilot → Metrics → Copilot usage metrics en la pestaña Insights.

Ejemplo de Copilot Usage Metrics Dashboard en github.blog

Qué mide la API

La Usage Metrics API expone varias categorías de telemetría operativa.

Métricas habituales:

• Usuarios activos
• Líneas de código sugeridas vs aceptadas
• Patrones de uso del IDE
• Uso de modelos
• Interacciones con agentes
• Desglose por lenguajes

Esto ofrece una imagen mucho más matizada que un simple recuento de licencias.

Un equipo con 100 licencias asignadas pero solo 15 usuarios activos tiene un perfil de adopción muy distinto de otro con uso diario constante y altas tasas de aceptación.

La transición de APIs en 2026

GitHub retiró varias APIs de telemetría anteriores (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) durante el periodo 2025–2026, con su retirada completa en abril de 2026.

Incluían:

• La Metrics API heredada
• Feature Engagement APIs
• Direct Data Access APIs

Los nuevos endpoints de Usage Metrics, disponibles desde febrero de 2026, consolidaron esos sistemas de reporting en un modelo más unificado, con versionado de las APIs en caso de cambios incompatibles.

Esto importa porque muchos posts antiguos y ejemplos de GitHub siguen haciendo referencia a endpoints obsoletos. Siempre que trabajes con la Usage Metrics API, verifica la documentación frente a las referencias más recientes de GitHub antes de construir automatizaciones.

Consultar la Usage Metrics API

Ahora que entendemos el propósito de la Usage Metrics API, veamos cómo usarla en la práctica.

Autenticación y permisos

Los endpoints de GitHub Copilot Usage Metrics suelen requerir configurar algunos permisos para tu Personal Access Token (PAT). Puedes hacerlo con el PAT clásico o con un PAT de acceso granular.

• Para los PAT clásicos, necesitarás que tu admin de enterprise te otorgue los permisos: manage_billing:copilot y read:org. 

• Para los tokens de acceso granular, asegúrate de usar el user access token o el installation access token de la app de GitHub con el permiso Enterprise Copilot metrics enterprise permissions (read).

Normalmente se prefieren los tokens de acceso granular porque reducen la exposición de permisos innecesarios.

Endpoints a nivel de organización

Los dos informes más comunes a nivel de organización son:

• organization-1-day

• organization-28-day

Informe de un día a nivel de organización

El informe de un día funciona bien para monitorización operativa y análisis de tendencias a corto plazo. Hay datos históricos desde el 10 de octubre de 2025 y pueden consultarse hasta un año desde la fecha actual.

El siguiente comando curl llama al endpoint del informe de un día y devuelve una respuesta JSON con enlaces de descarga de los informes de uso. Debes incluir YOUR_TOKEN para la autenticación Bearer y elegir un DAY para el día concreto del informe en formato YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

Las URLs en download_links están firmadas y son temporales, por lo que caducan poco después de generarse. Tu flujo debe obtener la URL de descarga e inmediatamente descargar el archivo en la misma ejecución; no puedes guardar estas URLs para más tarde.

La respuesta que recibas puede contener solo download_links y report_day, pero este es el esquema completo posible:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

Informe de 28 días a nivel de organización

El informe de 28 días ayuda a identificar patrones de adopción más amplios y cambios de uso a más largo plazo. Los comandos son muy similares, con un pequeño cambio para usar la API de 28 días.

Ejemplo de solicitud:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Recibirás una respuesta similar, salvo que incluirá response_start_day y response_end_day.

Estructura del informe a nivel de organización

Los informes JSON tanto del día único como de los 28 días a nivel organizativo pueden tener este aspecto:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

Como ves, ofrece una vista de alto nivel de los usuarios dentro de una organización, su equipo y sus etiquetas de equipo. 

Endpoints a nivel de usuario

Los informes a nivel de usuario aportan una visibilidad más granular de la adopción. Te permiten entender, a alto nivel, cómo usan Copilot las personas.

Endpoints comunes:

• users-1-day

• users-28-day

• user-teams-1-day

Estos informes ayudan a los administradores a identificar:

• Usuarios muy activos
• Equipos con baja adopción
• Oportunidades de formación
• Tendencias de uso por departamento

Estas solicitudes son muy similares a los informes de 1 y 28 días a nivel de organización; simplemente apuntan a una API distinta.

Informe de un día a nivel de usuario

Ejemplo de llamada a la API users-1-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

Informe de 28 días a nivel de usuario

Ejemplo de llamada a la API users-28-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Informe de un día user-teams

También existe un endpoint user-teams-1-day, que vincula cada usuario con sus pertenencias a equipos. No contiene métricas de uso; su objetivo es servir como clave de unión cuando quieras agregar los datos por usuario a nivel de equipo.

Estructura del informe a nivel de usuario

El nivel de detalle de estos informes es mucho mayor, ya que apuntan a los datos de uso de un usuario concreto:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Estas métricas son más valiosas como señales de adopción a nivel de equipo. Las tasas de aceptación y los recuentos de uso son señales operativas, no mediciones de la calidad del desarrollador.

Para ver el conjunto completo de métricas potenciales, consulta the GitHub usage metrics data documentation para conocer las métricas más actualizadas.

Los informes a nivel de usuario incluyen datos de interacción por CLI. Si tus equipos usan Copilot desde la línea de comandos, nuestro GitHub Copilot CLI Tutorial cubre la configuración y los flujos de trabajo habituales.

Crear un flujo de reporting de Copilot

Llamar a la API manualmente es útil para experimentar y entender el esquema. Para que sea accionable, es mejor crear un flujo automatizado.

Los equipos que más valor obtienen de Copilot Enterprise suelen construir pipelines ligeros de reporting que combinan telemetría de uso con métricas internas de ingeniería.

Métricas clave para demostrar el ROI

No todas las métricas de Copilot importan por igual. Las más útiles suelen ser:

• Crecimiento de usuarios activos
• Tendencias en la tasa de aceptación
• Código sugerido frente a retenido
• Mejoras en el tiempo de ciclo de PR
• Frecuencia de uso del IDE

GitHub ha publicado benchmarks como:

• Hasta un 55% de reducción en el tiempo de finalización de tareas
• 88% de tasas de retención de código

Estas cifras muestran mejoras significativas de productividad. Tus resultados variarán según el equipo y el flujo de trabajo, justo por eso existe la Usage Metrics API. Un equipo de infraestructura backend puede interactuar con Copilot de forma distinta a un equipo de prototipado frontend.

De datos en bruto a un panel de equipo

Un flujo de reporting ligero suele tener este aspecto:

1. Llamada programada a la API
2. Almacenar respuestas en una base de datos u hoja de cálculo
3. Transformar datos en tablas de informes
4. Visualizar métricas en tu plataforma de BI

La tecnología concreta importa menos que la constancia.

Incluso un flujo sencillo con scripts de Python programados y exportaciones a CSV puede ofrecer una visibilidad operativa útil.

Arquitectura de ejemplo:

GitHub API

  ↓

Script de Python programado

  ↓

PostgreSQL / CSV / Hoja de cálculo

 ↓

Power BI / Tableau / Looker

Reflexiones finales

GitHub Copilot Enterprise va de preparar tu infraestructura para un código listo para la IA. Spaces aporta el contexto organizativo que hace que Copilot sea más útil en entornos de ingeniería reales. La Usage Metrics API aporta la telemetría necesaria para entender si la adopción está funcionando.

Las organizaciones que obtienen mejores resultados con Copilot Enterprise comparten un patrón:

• Curan el contexto interno con cuidado
• Monitorizan la adopción continuamente
• Se toman en serio el gobierno de Copilot
• Midiendo resultados en lugar de dar por hecho las ganancias de productividad

Esa mentalidad importa mucho más que simplemente asignar licencias.

Si quieres profundizar en tus habilidades con Copilot y la IA, te recomiendo el curso Software Development with GitHub Copilot o el itinerario completo AI for Software Engineering.