Glossary · Automation software engineering and architecture
AI usage telemetry
Also known as: AI usage metrics, AI tool usage metrics, AI adoption telemetry, AI assistant telemetry
German: Telemetriedaten zur KI-Nutzung
In software engineering, AI usage telemetry is measurement data about how AI tools are used in a development or authoring organization: which tools and models are called, in which repositories or projects, at what volume, and how often proposed output is accepted, edited or discarded. Organizations collect it for license management, adoption reporting, cost control and oversight of AI-assisted work. Whether such data may be collected and evaluated per individual person is not a technical question but a legal one, decided by data protection law, labor law and — in Germany — by co-determination of the works council.
- Software engineering
- Technical documentation
In one sentence
AI usage telemetry measures how AI tools are used across teams, and where labor and data protection law limit per-person tracking.
Example
Before the coding assistant was rolled out beyond the pilot, the platform team agreed with the works council to report acceptance rate and chat volume only aggregated per team, while per-seat activity was used solely to reclaim unused licenses.
How it applies
- What vendors actually expose: Assistant vendors ship usage metrics as an API or dashboard. GitHub's documentation describes Copilot usage metrics as visibility into adoption and use across an organization — engagement, activity, code generation and pull request lifecycle trends — available at enterprise, organization and user level, with license and seat assignment handled by a separate user management API. Scope and field names differ per resource, so a number only means something together with the endpoint it came from.
- Engineering: Treat telemetry as a data product, not a side effect. Define the unit of analysis (seat, repository, team, model), the aggregation window and the retention period before the first dashboard exists, and version that definition like any other interface contract.
- Metric design: Acceptance rate measures what a person clicked, not whether the code was correct, safe or maintainable. Pair usage counts with outcome signals you already have — code review findings, static code analysis results, defect rates, rework — and expect Goodhart effects once a usage figure appears in a target agreement.
- Compliance (EU/EEA): Personal-level telemetry about employees is personal data processing under the GDPR and needs a lawful basis, a defined purpose, data minimization and transparency toward the people measured. The GDPR allows more specific rules for the employment context through national law or collective agreements, so the answer varies by jurisdiction.
- Co-determination (Germany): Introducing and using technical devices that are suited to monitor behavior or performance of employees triggers works council co-determination under Section 87(1) no. 6 BetrVG; German labor court practice reads "suited to monitor" broadly, which in practice pulls most per-person tool telemetry into a works agreement. Naming a works agreement in a rollout plan is not the same as having one in force.
- AI Act relevance: For high-risk AI systems, deployers who are employers must inform workers' representatives and the affected workers before putting the system into service at the workplace, and deployers must keep logs generated by the system for a defined minimum period. A usage dashboard is not itself an AI system; but if AI is used to monitor or evaluate the performance and behavior of workers, the employment uses listed in Annex III come into scope and a case-by-case assessment is required. Using an assistant that is documented as AI Act conformant says nothing about whether your telemetry setup is lawful.
- Documentation teams: The same questions arise in authoring: assistant calls inside a CCMS or editor, accepted suggestions per topic type, and review effort afterwards. Record in the tool documentation which events are captured, who can see them at which granularity, and how long they are kept.
- Evidence value: Research on AI-assisted development (DORA's 2025 report, based on a survey of technology professionals) found AI adoption close to universal among respondents and throughput gains accompanied by delivery instability where foundational practices were weak. Usage telemetry can show adoption; it cannot on its own show value or quality.
AI usage telemetry vs. AI Act logging
AI usage telemetry is a management instrument: it answers who used which tool, how much, and with what acceptance. Logging obligations under the AI Act are a compliance instrument for high-risk AI systems: automatically recorded events over the system's lifetime, kept by the deployer for a minimum retention period so that operation is traceable after the fact. The two data sets overlap technically and differ in purpose, addressee and retention rule — keeping seat-level dashboards does not satisfy a logging obligation, and keeping compliance logs does not justify performance dashboards.
External references
- GitHub Docs: GitHub Copilot usage metrics
- GitHub Changelog: agentic CLI customizations in the usage metrics API
- European Commission AI Act Service Desk: Article 26 — Obligations of deployers of high-risk AI systems
- DORA 2025: State of AI-assisted Software Development (PDF)
- Luther: Software vs. co-determination (Section 87(1) no. 6 BetrVG)
Keep in mind
Product names, endpoint scopes, metric definitions and default retention settings of AI assistants change frequently; verify the current vendor documentation and your contract before building governance on a specific field, and re-check the legal status in your jurisdiction, which may have moved since this entry was written (regulatory facts stated as of 2026-09-29).