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

¿Qué es GitHub Copilot Enterprise?

GitHub Copilot Enterprise se sitúa en lo más alto 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 compañías con grandes entornos de ingeniería, no para desarrolladores individuales o equipos pequeños.

En la práctica, hay dos capacidades clave:

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

Estas dos funciones convierten a Copilot de un simple «autocompletado inteligente» en 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 una pieza clave de su infraestructura interna. Configuran cuidadosamente el contexto organizativo, miden la adopción de forma continua y ajustan las políticas basándose en los 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 adicionales como:

• Métricas de uso a nivel de organización
• Controles de gobierno ampliados
• Herencia de políticas a nivel empresarial
• Asignaciones mayores de peticiones premium (1.000 frente a 300 en el plan Business)
• Acceso y gestión de modelos adicionales

Enterprise requiere GitHub Enterprise Cloud además de la propia 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 suscriptores de Enterprise además acceden a informes agregados a nivel enterprise (/enterprises/{enterprise}/…) que cubren todas las organizaciones en una sola vista.

A quién va dirigido GitHub Copilot Enterprise

GitHub Copilot Enterprise está pensado para organizaciones que ya operan entornos maduros en GitHub.

Clientes típicos de Enterprise:

• Grandes organizaciones de ingeniería
• Industrias reguladas
• Equipos de plataforma con múltiples equipos
• Empresas con estándares internos de desarrollo
• Organizaciones que requieren gobierno centralizado

Ten en cuenta que esto no mejora por sí mismo el rendimiento de Copilot. Esta distinción importa porque muchos equipos tienden a sobredimensionar la compra al principio. Suponen que Enterprise equivale a «un Copilot mejor», cuando en realidad Enterprise añade sobre todo herramientas de gobierno y medición.

Copilot Spaces: contexto personalizado para tu organización

Copilot Spaces resuelve una de las mayores debilidades de los asistentes de código de IA generalistas.

De serie, Copilot entiende razonablemente bien el conocimiento público de programación. No comprende automáticamente tus APIs internas, decisiones de arquitectura, convenciones de código, flujos de despliegue o la 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 contestar 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 debería usar este microservicio?»
• «¿Qué convenciones de nombres sigue nuestro equipo de backend?»

Qué admite Spaces

Spaces admite un abanico más amplio de contenido organizativo que el antiguo sistema de Knowledge Bases.

Tipos de contenido compatibles:

• 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 explican arquitectura y onboarding. Los pull requests exponen debates de revisión y decisiones de ingeniería históricas. Esa 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 vectores conectada a GitHub. Incluye controles de compartición y flujos de gobierno organizativo diseñados para entornos enterprise.

El fin de Knowledge Bases

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

Spaces sustituyó a Knowledge Bases con:

• Compatibilidad con más tipos de contenido
• 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 posts desactualizados que mencionan Knowledge Bases. Ten cuidado al seguir tutoriales antiguos, porque muchos endpoints y flujos cambiaron durante la 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 está en gestionarlos por decenas o cientos entre equipos.

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

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

Configurar un Space

Crear un Space suele seguir este flujo:

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

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 definir la configuración de compartición en este paso

6. Verifica que Copilot pueda consultar el contenido durante las interacciones de chat

Nota para usuarios enterprise: tu administrador puede desactivar el uso compartido de Spaces personales. Si usas tu propia cuenta, 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:

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

Compartición y controles de acceso

Spaces admite dos modelos principales de visibilidad:

• Spaces individuales
• Spaces de toda la organización

Las personas de una enterprise pueden tener sus spaces individuales gestionados por la configuración general de la empresa. Los administradores de enterprise también pueden gestionar de forma centralizada las políticas de preview 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 corporativos.

Un error común es la sobrecentralización. Un único Space gigante para toda la empresa puede volverse ruidoso y difícil de usar de forma eficaz 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 básicamente usa la configuración del space de forma diferente.

Un Space por equipo

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

Ejemplos:

• Plataforma
• Data engineering
• Desarrollo mobile

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 de estándares compartidos

Muchas organizaciones mantienen un Space compartido aparte para:

• Guías de seguridad
• Convenciones de código
• Flujos de despliegue
• Estándares de arquitectura

En la práctica, suelen funcionar mejor los enfoques híbridos. Cada equipo puede tener su propio space, con grandes spaces de estándares compartidos 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ó a varios sistemas de telemetría antiguos que GitHub retiró durante la consolidación de APIs de 2026. 

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

El panel alcanzó disponibilidad general en febrero de 2026 y es accesible desde tu cuenta 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 visión 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 diferente al 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 la transición 2025–2026, quedando totalmente obsoletas en abril de 2026.

Incluían:

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

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

Esto importa porque muchos posts y ejemplos de GitHub antiguos siguen haciendo referencia a endpoints en desuso. Siempre verifica la documentación más reciente de GitHub antes de automatizar con la Usage Metrics API.

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 mediante el PAT clásico o un PAT de acceso granular.

• Para PAT clásicos, tu admin de enterprise deberá concederte estos permisos: manage_billing:copilot y read:org. 

• Para tokens de acceso granular, asegúrate de usar el token de acceso de usuario de la app de GitHub o el token de instalación con el permiso Enterprise Copilot metrics enterprise permissions (read).

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

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 es útil para el monitoreo operativo y el 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 a la API del informe de un día y devuelve una respuesta JSON con enlaces de descarga de los informes de uso. Asegúrate de incluir YOUR_TOKEN para la autenticación Bearer y de elegir un DAY para el día concreto 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 de duración limitada, por lo que expiran poco después de recuperarlas. Tu flujo debe obtener la URL de descarga y tirar del archivo inmediatamente en la misma ejecución; no puedes guardar estas URLs para más tarde.

La respuesta podría contener solo download_links y report_day, pero este es el esquema potencial completo:

{
  "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 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.

Solicitud de ejemplo:

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, excepto que incluirá response_start_day y response_end_day.

Estructura del informe a nivel de organización

Los informes JSON, tanto el de un día como el de 28 días a nivel de organización, podrían 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, te ofrece una vista de alto nivel de los usuarios de una organización concreta, 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. Es decir, puedes entender cómo usa Copilot cada persona a un nivel muy alto.

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 a nivel de departamento

Estas solicitudes son muy similares a los informes de uno 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 el endpoint user-teams-1-day, que mapea cada usuario con su pertenencia a equipos. No contiene métricas de uso en sí; 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 dentro de estos informes es mucho mayor, dado que apuntan a los datos de uso de una persona concreta:

[{
  "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 calidad del desarrollador.

Para ver todas las métricas potenciales que puedes encontrar, visita the documentación de datos de métricas de uso de GitHub 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 setup y los flujos de trabajo más comunes.

Montar un flujo de reporting para 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 de reporting ligeros 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:

• Un 55% más rápido en completar tareas
• Un 88% de tasas de retención de código

Esas cifras apuntan a mejoras significativas de productividad. Tus resultados variarán según el equipo y el flujo de trabajo, y precisamente 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.

Del dato en bruto a un dashboard de equipo

Un flujo de reporting ligero suele tener este aspecto:

1. Llamada a la API programada
2. Almacenamiento de respuestas en una base de datos u hoja de cálculo
3. Transformación de datos a tablas de reporting
4. Visualización de métricas en tu plataforma de BI

La tecnología concreta importa menos que la consistencia.

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

Arquitectura de ejemplo:

GitHub API

  ↓

Script de Python programado

  ↓

PostgreSQL / CSV / Hoja de cálculo

  ↓

Power BI / Tableau / Looker

Conclusiones

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

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

• Cuidan con esmero el contexto interno
• Monitorizan la adopción de forma continua
• Se toman en serio el gobierno de Copilot
• Midan resultados en lugar de asumir ganancias de productividad

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

Si quieres llevar más lejos tus habilidades con Copilot y la IA, te recomiendo nuestro curso Software Development with GitHub Copilot o el itinerario completo AI for Software Engineering.