GitHub Copilot Enterprise: un ghid pentru Spaces și API-ul Usage Metrics

Ce este GitHub Copilot Enterprise?

GitHub Copilot Enterprise se află în vârful ierarhiei planurilor Copilot de la GitHub.

Comparativ cu GitHub Copilot Business sau Pro+, Enterprise se concentrează puternic pe guvernanță, context organizațional și capabilități de măsurare. Este conceput pentru companii care operează medii de inginerie mari, nu pentru dezvoltatori individuali sau echipe mici.

Două capabilități contează cel mai mult în practică:

1. Context organizațional personalizat prin Spaces
2. Telemetrie la nivel de organizație prin API-ul Usage Metrics

Aceste două funcții transformă Copilot din „autocomplete inteligent” într-o platformă internă de AI pentru inginerie.

Companiile care obțin cea mai mare valoare din GitHub Copilot Enterprise îl tratează ca pe o componentă cheie a infrastructurii interne. Configurează cu atenție contextul organizațional, măsoară constant adopția și ajustează politicile pe baza datelor de utilizare, nu a presupunerilor.

Pentru o privire de ansamblu asupra ecosistemului GitHub, îți recomand să citești ghidul nostru Introduction to GitHub Products.

Cum diferă Enterprise de Business și Pro+

GitHub Copilot Enterprise extinde abonamentul Business cu funcții suplimentare precum:

• Metrici de utilizare la nivel de organizație
• Controale de guvernanță extinse
• Moștenirea politicilor la nivel de enterprise
• Alocări mai mari pentru cereri premium (1.000 vs 300 în nivelul Business)
• Acces și management suplimentar al modelelor

Enterprise necesită GitHub Enterprise Cloud pe lângă abonamentul Copilot Enterprise propriu-zis. Acest lucru adaugă un cost suplimentar per utilizator, așa că asigură-te că organizația ta chiar are nevoie de guvernanță, telemetrie și administrație la nivel de enterprise.

Notă: Abonații Business au acces la API-ul Usage Metrics la nivel de organizație (/orgs/{org}/…). Abonații Enterprise au în plus acces la rapoarte agregate la nivel de enterprise (/enterprises/{enterprise}/…) care acoperă toate organizațiile într-o singură vizualizare.

Pentru cine este GitHub Copilot Enterprise

GitHub Copilot Enterprise vizează organizațiile care operează deja medii GitHub mature.

Clienții tipici Enterprise includ:

• Organizații mari de inginerie
• Industrii reglementate
• Grupuri de platform engineering cu mai multe echipe
• Companii cu standarde interne de dezvoltare
• Organizații care necesită guvernanță centralizată

Reține că acest lucru nu îmbunătățește în mod inerent performanța Copilot. Cred că această distincție contează pentru că multe echipe cumpără prea mult la început. Presupun că Enterprise înseamnă „Copilot mai bun”, când, în realitate, Enterprise adaugă în principal instrumente de guvernanță și măsurare.

Copilot Spaces: context personalizat pentru organizația ta

Copilot Spaces rezolvă una dintre cele mai mari slăbiciuni ale asistenților de codare AI generaliști.

Din start, Copilot înțelege destul de bine cunoștințele publice de programare. Nu înțelege automat API-urile tale interne, deciziile de arhitectură, convențiile de codare, fluxurile de deploy sau documentația de onboarding.

Spaces oferă un context organizațional curatoriat pe care Copilot îl poate folosi în conversații și asistență la codare.

În termeni practici, Spaces îl ajută pe Copilot să răspundă la întrebări precum:

• „Cum structurăm intern handler-ele pentru API?”
• „Ce bibliotecă de autentificare recomandă echipa noastră de platformă?”
• „Ce flux de deployment ar trebui să folosească acest microserviciu?”
• „Ce convenții de denumire urmează echipa noastră de backend?”

Ce acceptă Spaces

Spaces acceptă o gamă mai largă de conținut organizațional decât vechiul sistem Knowledge Bases.

Tipurile de conținut acceptate includ:

• Fișiere de cod
• Documentație Markdown
• Fișiere JSON
• Fișiere încărcate
• Imagini
• GitHub Issues
• Pull request-uri

Fiecare tip de conținut contribuie diferit.

Fișierele de cod îl ajută pe Copilot să înțeleagă tiparele de implementare. Fișierele Markdown oferă explicații de arhitectură și ghiduri de onboarding. Pull request-urile expun discuțiile din review-uri și deciziile istorice de inginerie. Această combinație îi oferă lui Copilot o mai bună înțelegere a practicilor de dezvoltare ale organizației tale.

Un punct subtil, dar important, este că Spaces nu sunt pur și simplu baze de date vectoriale atașate la GitHub. Ele includ controale de partajare și fluxuri de guvernanță organizațională concepute pentru medii enterprise.

Renunțarea la Knowledge Bases

GitHub a închis vechea funcție Copilot Knowledge Bases la 1 noiembrie 2025.

Spaces a înlocuit Knowledge Bases cu:

• Suport mai larg pentru conținut
• Controale de partajare mai bune
• Administrare îmbunătățită
• Management mai flexibil la nivel de organizație

Vei mai găsi documentație și articole învechite care fac referire la Knowledge Bases. Ai grijă când urmezi tutoriale mai vechi, pentru că multe endpoint-uri și fluxuri s-au schimbat în perioada de tranziție 2025–2026.

Crearea și configurarea Copilot Spaces

Din perspectiva administrării, Copilot Spaces sunt destul de simple de creat. Provocarea apare când trebuie să le gestionezi pe zeci sau sute, la nivel de echipe.

Structura pe care o alegi devreme tinde să rămână. Am văzut organizații care au creat accidental „haos de documentație” în Spaces pentru că nimeni nu a stabilit din timp reguli de proprietate.

Oricine poate crea un Copilot Space, așa că hai să testăm crearea unuia într-un repo personal. Acești pași sunt similari la nivel de Enterprise, cu câteva pagini diferite.

Configurarea unui Space

Crearea unui Space urmează, în general, acest flux:

1. Navighează la pagina Copilot Spaces din zona de administrare Enterprise
2. Creează un nou Space

3. Selectează repository-urile și sursele de conținut, inclusiv MCP-uri și alte instrumente utile

4. Adăugarea surselor se poate face apăsând butonul „+ Add sources” din partea dreaptă

5. Poți alege să partajezi spațiul sau să configurezi setările de partajare în această etapă

6. Verifică faptul că Copilot poate face referire la conținut în timpul conversațiilor

O notă pentru utilizatorii enterprise: administratorul tău poate dezactiva partajarea Spațiilor personale. Așadar, dacă folosești propriul cont, acest lucru îți poate afecta abilitatea de a partaja un Copilot Space care nu folosește repository-urile enterprise-ului.

După configurare, administratorii ar trebui să testeze Space-ul cu prompturi practice.

De exemplu:

How does our authentication middleware handle token refresh logic?

Sau:

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

Dacă Copilot nu poate răspunde corect, de obicei problema este una dintre următoarele:

• Repository-uri lipsă
• Calitate slabă a documentației
• Permisiuni incorecte
• Timp insuficient de indexare

Partajare și controale de acces

Spaces acceptă două modele principale de vizibilitate:

• Spaces individuale
• Spaces la nivel de organizație

Membrii unui enterprise pot avea spațiile individuale gestionate prin setările enterprise-ului. Administratorii enterprise pot, de asemenea, gestiona centralizat politicile de preview și disponibilitatea funcțiilor. 

Spaces private funcționează bine pentru echipe experimentale sau inițiative interne sensibile. Spaces la nivel de organizație au sens pentru standarde de inginerie, documentație de onboarding sau framework-uri la nivel de companie.

O greșeală frecventă pe care o văd este supracentralizarea. Un singur Space uriaș la nivel de companie poate deveni gălăgios și dificil de folosit eficient de către Copilot.

Organizarea Spaces pe echipă sau domeniu

Nu există o structură organizațională corectă universal.

Modelele comune includ un spațiu per echipă, un spațiu per zonă de produs sau spații partajate pentru standarde. Fiecare are un scop diferit și folosește practic aceleași setări ale spațiului într-un mod diferit.

Un Space per echipă

Util când grupurile de inginerie operează relativ independent.

Exemple:

• Platform engineering
• Data engineering
• Dezvoltare mobile

Un Space per zonă de produs

Util pentru organizații structurate în jurul produselor, nu al departamentelor.

Exemple:

• Plăți
• Analitică
• Infrastructură
• Platformă pentru clienți

Space pentru standarde partajate

Multe organizații mențin un Space partajat separat pentru:

• Linii directoare de securitate
• Convenții de codare
• Fluxuri de deployment
• Standardele de arhitectură

În practică, abordările hibride funcționează de obicei cel mai bine. Fiecare echipă poate avea propriul spațiu, iar spațiile mai mari pentru standarde sunt partajate între echipe.

API-ul Copilot Usage Metrics

Spaces rezolvă problema contextului. API-ul Usage Metrics rezolvă problema măsurării. A înlocuit mai multe sisteme mai vechi de telemetrie pe care GitHub le-a retras în timpul consolidării API-urilor din 2026. 

Fără măsurători clare, organizațiile își pierd rapid vizibilitatea asupra succesului adopției Copilot. Conducerea vrea dovezi că investiția îmbunătățește fluxurile de lucru ale dezvoltatorilor, nu doar adaugă un nou abonament în buget.

Panoul a ajuns la disponibilitate generală în februarie 2026 și este accesibil din contul tău enterprise → AI Controls → Copilot → Metrics → Copilot usage metrics, în fila Insights.

Exemplu de Copilot Usage Metrics Dashboard de pe github.blog

Ce măsoară API-ul

API-ul Usage Metrics expune mai multe categorii de telemetrie operațională.

Metricile comune includ:

• Utilizatori activi
• Linii de cod sugerate vs linii de cod acceptate
• Tipare de utilizare a IDE-ului
• Utilizarea modelelor
• Interacțiuni cu agenții
• Defalcări pe limbaje

Acest lucru oferă organizațiilor o imagine mult mai nuanțată decât simplele numărări de locuri.

O echipă cu 100 de locuri alocate, dar doar 15 utilizatori activi, are un profil de adopție foarte diferit față de una cu utilizare zilnică constantă și rate mari de acceptare.

Tranziția API din 2026

GitHub a retras mai multe API-uri anterioare de telemetrie (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) în perioada de tranziție 2025–2026, acestea fiind închise complet până în aprilie 2026.

Acestea au inclus:

• API-ul Metrics legacy
• API-urile Feature Engagement
• API-urile Direct Data Access

Noile endpoint-uri Usage Metrics, disponibile din februarie 2026, au consolidat acele sisteme de raportare într-un model mai unificat, care include și versionarea acestor API-uri în cazul modificărilor majore.

Acest lucru contează deoarece multe articole de blog și exemple GitHub mai vechi încă fac referire la endpoint-uri învechite. Ori de câte ori lucrezi cu API-ul Usage Metrics, verifică întotdeauna documentația față de cele mai recente referințe API GitHub înainte de a construi automatizări în jurul lui.

Interogarea API-ului Usage Metrics

Acum că înțelegem scopul API-ului de metrici de utilizare, hai să vorbim despre cum îl folosim efectiv în practică.

Autentificare și permisiuni

Endpoint-urile GitHub Copilot Usage Metrics îți cer, în general, să configurezi câteva permisiuni pentru Personal Access Token (PAT). Acest lucru se poate face fie prin PAT clasic, fie prin PAT cu granularitate fină.

• Pentru PAT-urile clasice, va trebui ca administratorul enterprise să îți ofere următoarele permisiuni: manage_billing:copilot și read:org. 

• Pentru token-urile cu acces granular, trebuie să te asiguri că folosești tokenul de acces al utilizatorului aplicației GitHub sau tokenul de acces al instalării cu permisiunea Enterprise Copilot metrics enterprise permissions (read) setată.

De obicei, folosirea token-urilor cu granularitate fină este preferată deoarece reduc expunerea inutilă a permisiunilor.

Endpoint-uri la nivel de organizație

Cele două rapoarte cel mai des folosite la nivel de organizație sunt:

• organization-1-day

• organization-28-day

Raport de o zi la nivel de organizație

Raportul de o zi este util pentru monitorizare operațională și analiză a tendințelor pe termen scurt. Datele istorice sunt disponibile începând cu 10 octombrie 2025 și pot fi accesate până la un an de la data curentă.

Comanda curl de mai jos va apela API-ul pentru raportul de o zi și va returna un răspuns JSON cu linkuri de descărcare pentru rapoartele de utilizare. Trebuie să incluzi YOUR_TOKEN pentru autentificarea bearer și să alegi o DAY pentru ziua specifică a raportului în format 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"

URL-urile din download_links sunt semnate și limitate în timp, ceea ce înseamnă că expiră la scurt timp după obținere. Fluxul tău trebuie să preia URL-ul de descărcare și să tragă imediat fișierul în aceeași rulare; nu poți stoca aceste URL-uri pentru utilizare ulterioară.

Răspunsul pe care îl primești ar putea conține doar download_links și report_day, dar acesta este schema potențială completă:

{
  "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"
  ]
}

Raport de 28 de zile la nivel de organizație

Raportul pe 28 de zile ajută la identificarea tiparelor de adopție mai largi și a schimbărilor de utilizare pe termen mai lung. Comenzile sunt foarte similare, cu o mică schimbare pentru a folosi API-ul de 28 de zile.

Exemplu de cerere:

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

Vei primi un răspuns similar, cu excepția faptului că va exista un response_start_day și response_end_day.

Structura raportului la nivel de organizație

Rapoartele JSON atât pentru raportul de o zi, cât și pentru cel de 28 de zile la nivel organizațional ar putea arăta astfel:

[
  {
    "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"
  }
]

După cum vezi, acest lucru îți oferă o privire de ansamblu asupra utilizatorilor dintr-o anumită organizație, echipei lor și etichetelor echipei. 

Endpoint-uri la nivel de utilizator

Rapoartele la nivel de utilizator oferă o vizibilitate mai granulară a adopției. Asta înseamnă că poți înțelege cum folosesc indivizii Copilot la un nivel foarte înalt.

Endpoint-urile comune includ:

• users-1-day

• users-28-day

• user-teams-1-day

Aceste rapoarte îi ajută pe administratori să identifice:

• Utilizatori foarte activi
• Echipe cu adopție scăzută
• Oportunități de training
• Tendințe de utilizare la nivel de departament

Aceste cereri sunt foarte similare cu rapoartele de o zi și de 28 de zile la nivel de organizație; pur și simplu indică spre un alt API.

Raport de o zi la nivel de utilizator

Exemplu de apel 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"

Raport de 28 de zile la nivel de utilizator

Exemplu de apel 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

Raport de o zi la nivel user-teams

Există și un endpoint user-teams-1-day, care mapează fiecare utilizator la apartenențele sale la echipe. Nu conține metrici de utilizare în sine; scopul său este să servească drept cheie de îmbinare atunci când vrei să agregi datele per utilizator pe echipe.

Structura raportului la nivel de utilizator

Nivelul de detaliu din aceste rapoarte este mult mai mare, dat fiind că indică spre datele de utilizare ale unui utilizator anume:

[{
  "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
}]

Aceste metrici sunt cele mai valoroase ca semnale de adopție la nivel de echipă. Ratele de acceptare și numărările de utilizare sunt semnale operaționale, nu măsurători ale calității dezvoltatorilor.

Pentru lista completă a metricilor potențiale pe care le-ai putea vedea, vizitează documentația pentru datele de usage metrics de pe GitHub pentru cele mai actualizate metrici măsurate.

Rapoartele la nivel de utilizator includ date despre interacțiunile prin CLI. Dacă echipele tale folosesc Copilot din linia de comandă, tutorialul nostru GitHub Copilot CLI Tutorial acoperă setarea și fluxurile de lucru comune.

Construirea unui flux de raportare pentru Copilot

Apelarea manuală a API-ului este utilă pentru experimentare și înțelegerea schemei. Ca să fie acționabil, e mai bine să creezi un flux automatizat.

Echipele care obțin cea mai mare valoare din Copilot Enterprise construiesc, de obicei, pipeline-uri de raportare ușoare care combină telemetria de utilizare cu metrici interne de inginerie.

Metrici cheie pentru a demonstra ROI

Nu toate metricile Copilot contează la fel de mult. Cele mai utile tind să includă:

• Creșterea numărului de utilizatori activi
• Tendințe ale ratelor de acceptare
• Cod sugerat versus cod păstrat
• Îmbunătățiri ale timpului de ciclu al PR-urilor
• Frecvența de utilizare a IDE-ului

GitHub a publicat repere precum:

• 55% finalizare mai rapidă a sarcinilor
• 88% rate de păstrare a codului

Aceste cifre arată îmbunătățiri semnificative ale productivității. Rezultatele tale vor varia în funcție de echipă și fluxul de lucru, motiv pentru care există API-ul Usage Metrics. O echipă de infrastructură backend poate interacționa cu Copilot diferit față de o echipă de prototipare frontend.

De la date brute la un dashboard de echipă

Un flux de raportare ușor arată adesea astfel:

1. Apel API programat
2. Stocarea răspunsurilor într-o bază de date sau foaie de calcul
3. Transformarea datelor în tabele de raportare
4. Vizualizarea metricilor într-o platformă BI existentă

Stack-ul în sine contează mai puțin decât consistența.

Chiar și un flux simplu bazat pe scripturi Python programate și exporturi CSV poate oferi vizibilitate operațională utilă.

Arhitectură exemplu:

GitHub API

  ↓

Script Python programat

  ↓

PostgreSQL / CSV / Foaie de calcul

 ↓

Power BI / Tableau / Looker

Gânduri finale

GitHub Copilot Enterprise înseamnă, de fapt, construirea infrastructurii pentru cod pregătit pentru AI. Spaces oferă contextul organizațional care îl face pe Copilot mai util în medii reale de inginerie. API-ul Usage Metrics oferă telemetria necesară pentru a înțelege dacă adopția are succes.

Organizațiile care obțin cele mai bune rezultate cu Copilot Enterprise tind să urmeze un tipar comun:

• Curatoriază cu atenție contextul intern
• Monitorizează adopția continuu
• Tratează serios guvernanța Copilot
• Măsoară rezultatele în loc să presupună câștiguri de productivitate

Acea mentalitate contează mult mai mult decât simpla alocare de locuri.

Dacă vrei să îți aprofundezi abilitățile în Copilot și AI, îți recomandăm cursul nostru Software Development with GitHub Copilot sau întregul parcurs de competențe AI for Software Engineering.