Learning data is employee data. We treat it that way.
A retention engine necessarily knows things: what each employee practised, got wrong, and still knows. That data makes the platform work — and makes privacy design non-optional. Here’s what’s held, why, who sees it, and the line we don’t cross.
The line between measurement and surveillance
Any system that measures people can become a surveillance system, and learning platforms are unusually exposed: daily engagement, response times, error patterns, confidence signals. It would be technically simple to render all of that as a productivity dashboard — and doing so would be both a privacy failure and a pedagogical one, because practice honesty depends on learners not feeling watched for judgement.
So the design draws lines. Data is collected for learning and compliance evidence, and access is scoped to those purposes: learners see their own detail, managers see their team’s capability and risk states, program owners see aggregates, and platform admins see configuration. No emotion inference, no keystroke analysis, no ambient monitoring — and no product roadmap toward them.
What we deliberately don’t collect
No keystroke logging, no webcam monitoring in the learning product, no emotion or attention inference, no correlation with productivity systems. Absence here is a design decision, not an oversight.
Learner-facing transparency
Employees can see their own data and what it’s used for — transparency that also improves the pedagogy, because visible progress motivates and hidden measurement corrodes trust.
Controls for works councils and DPOs
Individual-level visibility can be restricted where agreements require, with aggregate reporting preserved — the configuration European deployments usually need.
Minimal data, provably handled
What is collected, why, for how long — per data class, with the retention clock and deletion path shown.
| Data class | Contents | Policy | Window |
|---|---|---|---|
| Identity | Name, work email | retained | Contract term |
| Learning | Answers, levels | retained | Configurable |
| Derived | Memory forecasts | retained | Regenerable |
| Deleted | On request | SLA | 30 days |
Interface shown as an illustration with representative numbers, not a screenshot — the layout is the product’s.
Review the data model with us.
Fields, purposes, retention and access — walked through for your DPO rather than summarised on a page.
The evidence this page stands on
Questions buyers ask
Can managers see individual practice detail?
They see capability and risk states for their team — what needs attention and why. Granular response-level detail stays with the learner by default, and the boundary is configurable where policy demands more restriction.
Is learning data used for performance management?
Not by design, and we advise against it: the moment practice feels like assessment for pay, honest practice stops and the measurement degrades. Where organisations do connect them, that’s their policy decision — and we’ll say plainly that it costs data quality.
How long is learner data retained?
Per your configured policy and record class — evidence for compliance requirements often needs long retention; ordinary practice detail usually doesn’t. Both are policy settings, not defaults we impose.
Can employees request their data?
Yes — export and access requests are supported, which is also what subject-rights compliance requires of you as controller.
Do you use customer data to train AI models?
No. Customer content generates that customer’s question banks; it isn’t used to train foundation models.
See it on your own content.
Bring one course. We’ll show you the retention curve your current training leaves behind — and what scheduled review does to it.
- 30 minutes, on your calendar — pick a slot here
- Run on your own content wherever possible, not a canned deck
- You see the dashboards, the learner surface and the evidence exports
- No commitment — and pilot data stays yours either way