Ir al contenido

How your school’s information is protected

This page is written to be read by a principal, not an engineer. It explains the three things people most often wonder about before trusting a platform with data about minors.

One school sees nothing of another school

The platform hosts several schools at once. The reasonable question is what stops one from seeing another’s data.

The answer is that the separation does not live in the code behind the screens, but in the database itself. Every query carries, before it runs, the condition that it may only return rows from the schools the person asking belongs to. It is not a filter a programmer might forget to add to a new screen: it is a rule of the database engine, applied always.

The difference matters. In an application where the filter lives in the code, one slip on one screen exposes someone else’s data. Here, that same slip returns an empty list.

Whoever administers the platform IS an exception, and it is worth saying plainly: they can enter any school. That is what makes it possible to fix a fault without waiting for someone at the school to be available.

What they cannot do is go in quietly. Every visit of theirs to a school is noted in that school’s audit trail, with its date, and so is every action they take inside: a message of theirs in a course channel is signed with their name, like anyone else’s. Whoever administers the school can consult that trail whenever they want.

Two things stay outside that access, and they are what make it verifiable. The audit trail cannot be altered or deleted by anyone, not even by whoever administers the platform, so the record of what was done cannot be removed by whoever did it. And the content of a message can only be rewritten by whoever wrote it: neither the school's administration nor the platform's can put words in a teacher's mouth.

Minors and guardian consent

The platform handles data about students who are mostly minors: name, course, grades, submissions, observations and communications with the school.

When the student is under 18, their account stays shut until a guardian gives the authorisation for their data to be processed. That authorisation is recorded with its date and the exact version of the document accepted, so that later it can be shown what was authorised and when.

The guardian can withdraw it at any time from their account. The withdrawal is recorded too, and the previous one is not deleted: the history of authorisations is what backs up having handled that data during that time.

Law 1581 of 2012 and Decree 1377 of 2013 also recognise the right to see what data is held about a person, to obtain a copy and to ask for its deletion. All three are requested from the account itself, without writing to anyone.

What the artificial intelligence assistant does and does not see

The assistant answers questions in plain language about what is already on the platform. The reasonable worry is what information reaches it.

When someone asks it something, the assistant queries the database with that person’s session, not with a more powerful credential of its own. It is the same session their screens use, so the same rules decide what the query returns. If a guardian asks about a student who is not their dependant, the query returns nothing, and the assistant says so.

It is read-only: it does not create assignments, does not grade, does not send messages and changes nothing. And every answer cites the record it came from, with a link, so it can be checked rather than believed.

It always warns that the one answering is an artificial intelligence and that it can be wrong, with an explicit recommendation to confirm any important grade, date or detail on the corresponding screen. There is a record of which tool was consulted and when, so it can be audited; the content of the answers is not stored.

The school decides whether to turn it on. It can switch it off entirely, exclude particular roles and limit how many queries each person can make per day.

The rest, in brief

Passwords are not stored: what is kept is a cryptographic fingerprint that cannot be reversed. Nobody — including the administrator — can read them or set them.

Five failed attempts in a row from the same connection block access for fifteen minutes. The account is not disabled, so that this mechanism cannot be used to lock anyone out.

The session closes on its own after an hour of inactivity, with a warning beforehand. This is the case of the laptop left open in the staff room.

Uploaded files are checked on the server: the actual content is inspected, not just the extension in the name.

Sensitive actions — changing a published grade, withdrawing a message, exporting data — are recorded with their author and their date.