In one paragraph
One school's data is separated from every other school's inside the database itself, not by application code. Passwords are hashed with Argon2id and sessions rotate. The parent and student apps contain no advertising or analytics SDKs. AI never receives more than a first name and academic facts. Everything is backed up nightly and can be exported in full at any moment — and if you would rather none of it left your building, the Institution plan puts the whole system on a server inside your school.
Separation between schools
AiLycée is one system serving many schools. Every table that belongs to a school carries its school's identifier, and PostgreSQL row-level security filters every single query against the current tenant — including queries written by mistake. The application connects with a database role that cannot bypass this. A bug in a screen therefore cannot show one school another school's students.
Accounts and sessions
Passwords are hashed with Argon2id. Sign-in by one-time code sends a short-lived, single-use code over WhatsApp or SMS. Access tokens are short-lived; refresh tokens rotate on every use and a reused token invalidates the family, which turns a stolen token into a detected incident rather than a silent one. Roles — director, accountant, teacher, parent, student, driver, nurse — decide what each screen and each API route will return.
What we send to an AI model, and what we never send
Only two features call a model today: report-card comments and the weekly parent digest. Both receive the child's first name and academic facts — marks, averages, trends, attendance counts, the teacher's own descriptors. Nothing else is in the prompt: no family name, no phone number, no address, no national ID, no photo, no message content, no financial data. The prompt builder enforces this and tests cover it.
Every generation is recorded with its model, prompt version, token count, status and, once approved, the name of the person who approved it. A comment is only ever a draft until a teacher clicks approve. A digest is checked number by number against the source data before it is sent, and an unverifiable figure stops the message rather than shipping it.
Documents and files
Student documents, receipts and report cards are stored in object storage under keys prefixed by the school, and are served through short-lived signed links rather than public URLs. Receipts are immutable once issued: a correction is a credit note, so the audit trail is never rewritten. Every receipt and report card carries a QR code pointing at ailycee.com/verify, which confirms the document is genuine while revealing only the document type, the school, the issue date, its validity and the holder's first name.
Backups and recovery
Cloud tenants are backed up nightly, encrypted, with 30-day retention. On-prem installs write a nightly encrypted dump to the school's own NAS, with an optional offsite copy to storage the school controls. Restores are rehearsed rather than assumed, and a school on the Institution plan can ask to observe a restore drill.
The applications on the phones
The teacher, parent and student apps hold a local database so they work through a power or network cut. That local copy holds only the data the signed-in user is entitled to see, is removed on sign-out, and syncs back with an audit trail rather than a silent overwrite. There are no advertising SDKs and no third-party analytics SDKs in these apps — a rule, not a setting.
This website
The marketing site you are reading is a set of static files. Fonts are self-hosted, there is no analytics script, no tag manager, no advertising pixel and no third-party embed. Opening it sends a request to nobody but us. The directory search and the demo form call our own API and nothing else.
Operations
The same container images run in our cloud and inside a school, so what is tested is what is deployed. Secrets live in the orchestrator's secret store, never in an image. Public forms are rate-limited and carry a honeypot. A security review runs before every release, and dependency updates are applied on a schedule rather than when something breaks.
If something goes wrong
We will tell you. If a security incident affects your school's data we will contact the school directly, describe what happened and what data was involved, say what we have done, and keep updating you until it is closed — we will not wait for a quarterly report. To report a vulnerability, write to security@ailycee.com; we will acknowledge within two working days and we will not pursue anyone who reports a genuine issue in good faith.
Ask us anything specific
If your IT lead or your board has a question this page does not answer, write to security@ailycee.com. We would rather answer a hard question before you sign than after.
security@ailycee.com