Using AI in a school without giving it a child’s name

The instruction nobody can follow

Most schools have landed on roughly the same policy for AI: use it, but do not put anything about a child into it. It is a reasonable instruction and it is close to impossible to follow, because the whole point of the record a member of staff is writing is that it is about a child.

So one of two things happens. Either staff avoid the tools and keep the administrative load, or they use them and make a judgement call under time pressure about what is safe to paste in. Neither is a good position for the setting, and neither is fair on the member of staff being asked to make that call at half past four.

Move the decision out of the staff room and into the architecture

The anonymisation bridge sits between SHINE and the AI service, and it makes that judgement automatically, on every request. Before any text is sent, SHINE assembles the people and places the record could reasonably mention: the child, other children, staff, parents and carers, the setting, the local authority, dates of birth, addresses, identifiers. Each of those values is replaced with a neutral code.

A second pass then looks for the things that turn up in free text and are in no database: a phone number, an email address, a postcode, a date written into the middle of a sentence.

What the member of staff writes:

After lunch, Amira became distressed when the timetable changed. Ms Lewis offered a visual choice board.

What the AI service receives:

After lunch, [CHILD_1] became distressed when the timetable changed. [STAFF_1] offered a visual choice board.

The AI can still do the part it is good at. It can structure the account, prompt for context that is missing, and suggest which outcomes the observation might evidence. It does all of that without ever being told who [CHILD_1] is.

The list that maps the codes back to real names is the sensitive part, so it is treated as the sensitive part. It is held in memory for that one request, used to restore the draft inside SHINE, and then destroyed. It is never written to a database, never cached, never logged, and never sent anywhere.

What it does not do, which matters just as much

It would be easy to oversell this, and an oversold version would not survive its first conversation with a data protection officer. So, plainly:

• It does not make the setting’s processing anonymous. The codes can be mapped back inside the application, so the records are still personal data and still need a lawful basis.
• It does not remove the need for a DPIA, a data processing agreement, or a proper look at the AI provider’s retention and model training terms.
• It does not guarantee that a child cannot be recognised. A rare event described in detail can single a child out with no name attached, which is why minimisation and professional review still apply.
• It does not make any decision about a child. It moves text across a boundary. Every record is still written, checked and saved by a person.

What it does do is remove a category of risk that should never have been an individual member of staff’s problem, and remove it the same way on every single request.

Why we built it this way

Education settings are right to be cautious about AI. That caution usually gets written down as a policy, and a policy is only as good as the hundred small decisions people make under pressure. Building the protection into the workflow means it does not depend on anyone remembering it on a difficult afternoon.

It also gives an information governance lead something better than a supplier’s promise. There is a specific control they can test: capture the outbound request in a test environment, and look at what is actually in it.