GitHub Copilot GDPR: Map Controller, Processor, and Model Routes

A GitHub Copilot GDPR review should begin with processing activities, not a single vendor label. GitHub's current privacy statement says an organization providing a GitHub account is controller for most personal data used in the services, while GitHub is processor under the organization's instructions. It also says GitHub is controller for specific processing activities defined in the agreement, so the activity determines the role.

Copilot adds another layer because model requests can travel through infrastructure and AI service providers. The review therefore needs a route record that connects each capability the organization enables to its purpose and data categories; its users and model destination; and its processors, retention terms, transfer analysis, and evidence owner.

TL;DR

• Assign GDPR roles per processing activity. GitHub may be processor for most organization-account use and is controller for specified activities.
• Map each Copilot capability and enabled model to the data it can receive and the route it uses. Record the provider terms and the organization that approved it.
• Treat GitHub's subprocessor list as a supplier inventory input, not proof that every listed provider handled every request.
• Request-level evidence can verify routed destinations and policy decisions. Privacy and legal owners remain responsible for notices, contracts, lawful basis, rights handling, and DPIAs.

GitHub Copilot GDPR roles follow the activity

The GitHub General Privacy Statement applies where GitHub, Inc. or GitHub B.V. processes personal data as controller for services displaying that statement. Its organization-account notice says the school or employer is controller for most personal data used in the services. In that context, GitHub is processor and follows the controller's instructions under a data protection agreement.

The same notice says GitHub is controller solely for specific processing activities defined in the contractual agreement. That is why procurement should not approve a one-line statement that "GitHub is our processor" and file it for all Copilot use. The record should name the activity and cite the contractual clause supporting the role.

Under the GDPR's official text, controllers determine purposes and means, while processors handle personal data on a controller's behalf. Article 28 governs processor engagement and contract terms. Article 30 requires records for controllers and processors, with different fields for each role. Those duties are why activity-level mapping is operationally useful, not merely precise terminology.

Model routes and subprocessors need separate records

GitHub's subprocessor page names providers used for cloud and data hosting, AI inference and AI services, security and support, plus other functions. The current list includes AI-service entries for Anthropic, OpenAI, xAI, and Google Cloud Platform, as well as Microsoft Azure, Amazon Web Services, and others. It also gives processing locations for each listed relationship.

That list does not establish which provider processed a particular Copilot request. GitHub's model-hosting documentation explains that the host for each model family is GitHub infrastructure or an external model provider. It also documents provider-specific data commitments and exceptions. The enabled model set is therefore part of the route and terms that the organization must review.

Draw the route on a whiteboard with four arrows: developer tool to GitHub, GitHub to model host, response back to GitHub, and response to the developer. Beside each arrow, write the legal entity and endpoint; the region and data categories; and the retention statement and evidence source. Blank spaces are review items instead of being hidden inside a vendor name.

My strong opinion is that a generic subprocessor attachment is not a Copilot data-flow map. It proves that suppliers were disclosed. It does not prove which route an approved feature used on the date under review.

Build the processing record around enabled Copilot capabilities

Start with enabled Copilot capabilities rather than seats. Inline suggestions and chat, code review and coding agents, plus command-line use and model selection can use different context and support different purposes. The GitHub Copilot security guide maps the request path and native controls. The GDPR record adds legal role and purpose; data categories and recipient; and transfer, retention, and rights-handling fields.

For each feature, record the business purpose and user population; repository scope and context sources; personal-data categories and special-category possibility; GitHub entity and organization role; GitHub role and model host; subprocessors relied upon and processing location; transfer mechanism and retention setting; and security controls and the deletion or rights workflow. Attach the current agreement and source-page retrieval date.

The privacy statement's effective date and the subprocessor list can change. A model can also be available after the original review. Set change triggers for a new Copilot feature and model; a new host and region; a new context source and retention term; or a new integration. Require a fresh review before the changed route handles in-scope repositories.

Do not copy prompts and outputs into a compliance archive by default. The GDPR principles of purpose limitation and data minimization still apply to the evidence system. A classification and protected reference, or a hash and narrowly retained excerpt, may support reconstruction without creating a second store of developer and customer data.

Test contracts against observed routes

The processor file shows what should happen. Technical evidence shows what did happen on routes the organization can observe. Reconcile approved Copilot endpoints and models against network or gateway records, then investigate destinations that lack an approved processing entry.

For a sample request, retrieve the authenticated identity or workload and approved purpose; the repository or protected context reference and data classification; the destination and model route; and the policy version and outcome. Compare that record with the processing register. The GitHub Copilot audit logs guide explains why administrative events and request-level evidence answer different questions.

A mismatch does not automatically prove a GDPR breach. It proves the approved record and observed route differ and need investigation. Privacy decides whether the difference changes role allocation and notice; lawful basis and transfer assessment; processor instructions and DPIA; or incident handling. Engineering decides how to correct the route. The DPO's wider reporting view is covered in AI risk reporting for data protection officers.

DeepInspect

DeepInspect can govern deliberately routed, authenticated HTTP AI traffic and preserve identity and destination; data classification and policy version; plus decision evidence for those requests. It can help reconcile an approved route with observed traffic. It does not change GitHub's controller or processor role or inspect Copilot traffic that bypasses the route. It does not deliver privacy notices, choose a lawful basis, execute rights requests, or approve a DPIA.

Book a demo today.