Why this matters (and why August 2, 2026 is circled on your roadmap)
If your typing‑test product has EU learners or customers, the EU AI Act’s phased rollout hits a major milestone on August 2, 2026. That’s when the core rules for most high‑risk AI systems begin to apply, alongside transparency duties for certain AI uses; some embedded product categories follow in 2027. In short: what and how you collect keystroke data will soon be a compliance question—not just a UX one. (digital-strategy.ec.europa.eu)
Keystroke biometrics vs. “typing telemetry”: know the line
- Keystroke biometrics means using typing patterns (dwell/flight times, cadence) to uniquely identify or verify a person. Under the GDPR, biometric data is a special category of personal data when it’s processed to uniquely identify someone. In practice, that often requires explicit consent or another Article 9 exception. (privacy-regulation.eu)
- Typing telemetry (e.g., words‑per‑minute, accuracy, per‑key error rates) isn’t automatically biometric. It becomes biometric data when you process it to confirm or establish identity (e.g., continuous authentication). The UK ICO’s guidance—aligned in substance with GDPR—makes this distinction explicit. (ico.org.uk)
- Regulators have treated “keystrokes” as a biometric/behavioral signal in broader debates on remote identification—so handle with care. (edpb.europa.eu)
Map your use cases against the AI Act: prohibited vs. high‑risk vs. lower‑risk
Here’s the quick classification lens for typing‑test platforms:
1) Prohibited practices (don’t do these):
- Biometric categorisation to infer sensitive traits (e.g., political opinions, sexual orientation, religion) from biometric data. Avoid any attempt to deduce sensitive attributes from typing. (europarl.europa.eu)
- Emotion inference at work or in education from biometric data (including typing), except for narrow medical/safety reasons. If your classroom or workplace product tries to read a learner’s “frustration” from keystrokes, that’s off‑limits. (bundesnetzagentur.de)
2) High‑risk (strict obligations from August 2, 2026):
- Remote biometric identification (RBI) systems are high‑risk; note that “biometric verification solely to confirm someone’s identity” is carved out of this RBI category. Still, other high‑risk categories can catch proctoring/identity checks when they influence access or assessment in education or employment. (ai-act-text.com)
- Education and vocational training: AI used to determine access or assess learners (e.g., automated grading/proctoring decisions that materially affect outcomes) is high‑risk. Employment/worker management tools that influence hiring, promotion, or termination are also high‑risk. (ai-act-service-desk.ec.europa.eu)
3) Possible non‑high‑risk (document it):
- Article 6(3) allows certain Annex III systems not to be classified as high‑risk if they only perform a narrow procedural task or do not materially influence outcomes. If your AI simply aggregates timing signals to populate a coach’s dashboard without driving decisions, this route may apply—document it thoroughly and watch for Commission guidance. (ai-act-service-desk.ec.europa.eu)
What you can collect (safely by default) and what to avoid
Adopt privacy‑by‑design to keep valuable coaching insights while minimizing biometric risk:
- Prefer aggregate over raw: store per‑exercise WPM, accuracy, and error distributions (e.g., top‑5 confusion pairs like S–A, O–P) rather than raw, per‑keystroke timestamps. Bucket dwell/flight times into quantiles (p10/p50/p90) instead of full time series. This reduces identifiability while preserving skill signals. (GDPR data‑minimisation principle.) (service.betterregulation.com)
- Make identity optional: if you want progress tracking, use pseudonymous IDs and separate identity from telemetry at rest. Treat any template built for verification as sensitive and encrypt it with strict retention and rotation.
- On‑device first: compute sensitive timing features locally; send only summaries server‑side. If you must retain fine‑grained logs for debugging, time‑limit them (e.g., 7–30 days) and gate access.
- No “mood meters” in class or at work: avoid emotion inference entirely in those contexts. It’s either prohibited (if biometric‑based) or a compliance headache you don’t need. (bundesnetzagentur.de)
Your August 2, 2026 readiness checklist (typing‑test edition)
Use this as a practical playbook to align GDPR and the AI Act:
1) Lawful basis and transparency
- Map data flows and purposes; if any processing is “biometric for unique identification,” you’ll likely need explicit consent (or another Article 9 condition) and clear notices. Avoid consent for employees where there’s a power imbalance. (privacy-regulation.eu)
- If you deploy emotion recognition or biometric categorisation (best: don’t), Article 50 adds transparency duties to inform exposed persons. (artificialintelligenceact.eu)
2) Risk classification and documentation
- Decide: prohibited, high‑risk, or qualifies under Article 6(3) “narrow procedural task.” Capture your reasoning in technical documentation; monitor for Commission guidance due before 2026. If you claim a 6(3) exception, mind related registration steps. (ai-act-service-desk.ec.europa.eu)
- If high‑risk (e.g., automated exam decisions), prepare the full stack: risk management, data governance, technical documentation, logging, user information, human oversight, robustness/cybersecurity—and register in the EU database before placing on the market/putting into service. (regulyn.com)
3) Data governance and logging
- Build a data schema that separates identity from telemetry; implement role‑based access and immutable audit logs. High‑risk systems must support automatic logging over their lifecycle. (ai-act-service-desk.ec.europa.eu)
4) Human oversight that actually works
- Define when a human coach or proctor intervenes (e.g., before any adverse exam outcome). Oversight must be effective, not symbolic. (actproof.ai)
5) DPIA and rights
- A DPIA is likely if you process biometrics for identification at scale or systematically monitor students/employees. Use your DPIA to justify minimisation choices and retention periods. (edpb.europa.eu)
6) Penalties and governance
- Breaching prohibited‑use bans can trigger fines up to €35M or 7% of global turnover—one more reason to avoid biometric categorisation and emotion inference in sensitive contexts. (consilium.europa.eu)
“Proving human authorship” with keystrokes: cool idea, messy reality
Some proposals suggest using keystroke dynamics to certify that a passage was typed by a human (vs. pasted AI text). Recent research shows timing‑forgery and copy‑type attacks can evade such checks—and collecting fine‑grained motor‑signal logs raises biometric and GDPR concerns. If you explore this, keep it optional, on‑device, and minimised—and never use it for decisions with consequences (grading, discipline). Pair behavioural signals with transparent challenge‑response tasks instead. (arxiv.org)
A 90‑day starter plan
- Weeks 1–2: Inventory every keystroke signal you collect; tag which ones could enable unique identification.
- Weeks 3–6: Redesign analytics to use aggregated metrics; purge legacy raw logs; draft DPIA.
- Weeks 7–10: Classify each AI feature (prohibited/high‑risk/6(3) narrow task); if high‑risk, spin up risk management, human oversight flows, and technical documentation.
- Weeks 11–12: Update privacy notices and consent UX; set retention; rehearse access‑request and deletion flows.
Bottom line
Typing‑test platforms can keep great coaching insights without creeping into biometric trouble. Stick to aggregated telemetry, avoid emotion inference and sensitive categorisation, and be crystal‑clear about any identity‑related features. Do that—and start now—and August 2, 2026 will feel like a routine release, not a scramble. (digital-strategy.ec.europa.eu)
