Privacy by Design — in code, not in PowerPoint
Ann Cavoukian's 7 principles are the backbone of GDPR Art. 25. Here's how each principle is enforced as a concrete code mechanism.
Proactive not reactive — preventative not remedial
We introduced the AI PII chokepoint (aiSafeFetch) before the first breach — not after. Every LLM function gets automatic PII scrubbing; no function can opt out.
Privacy as the default setting
New tables have access control enabled by default. AI personalisation is off for pupils below the school's digital-consent age (15 by default, configurable 13–18) until the parent actively consents via /parent/children/:id/consents. Even our own staff (incl. the platform administrator) see only pseudonymised data by default — identifying a pupil requires an audited break-glass the system with a written reason and parental consent below the same age threshold.
Privacy embedded into design
PII scrubbing, aliasing ('Pupil A') and store:false aren't a plugin — they live in _shared/ai-fetch.ts which the entire platform imports. You cannot call an LLM without going through it.
Full functionality — positive-sum, not zero-sum
We don't sacrifice pedagogical value to protect data. The AI tutor is allowed to help — but on pseudonymised text with audit, so both pupil and DPO win.
End-to-end security — full lifecycle protection
TLS 1.3 in transit, AES-256 at rest, security_invoker views, signed links for private buckets, daily pg_cron rotation of logs, and deletion 90 days after contract end.
Visibility and transparency — keep it open
ai_prompt_audit, sensitive_access_log and admin_audit_log are accessible to the school admin for their own school. The DPO can pull a quarterly report without involving us.
Respect for user privacy — keep it user-centric
The pupil is not the product. No behavioural ads, no third-party trackers on pupil pages, no resale. Export and deletion within 30 days per GDPR Art. 12(3).