AI for SEND is not a smaller version of AI for everyone else.

AI can genuinely help a SEND teacher, mostly by taking on the documentation that surrounds the work rather than the work itself. It can draft a support plan from a teacher's notes, adapt a text to a reading age, produce the same instruction in three formats, and turn a term of observations into something a SENCO can actually file. What it cannot do, and what guidance explicitly forbids, is decide whether a child has a need, or write a statutory Education, Health and Care Plan.

Why does SEND get designed last?

Because building for the average user is cheaper, and accessibility is treated as a compliance pass at the end rather than a constraint at the start. The result is predictable. The child with an EHCP, the pupil who uses AAC or Makaton, the learner who does not type the way a keyboard expects, all get the version that was adapted after the decisions were already made.

Twenty years in classrooms is enough to watch that happen several dozen times. The adaptation is never as good as the original, because the original's architecture assumed something that is not true of the child in front of you. You cannot retrofit a starting assumption.

What can AI safely do in SEND work, and what can it not?

The safe ground is drafting, adapting and organising, with a qualified adult reviewing everything before it reaches a child or a parent. The unsafe ground is anything that looks like a diagnosis, a decision about provision, or a judgement of need.

• Safe: drafting an individual support plan from a teacher's own notes, for the teacher to correct.
• Safe: adapting an existing worksheet to a different reading age, or into symbol-supported form, without changing what is being taught.
• Safe: producing a staff guide to a particular need, from published sources, for the SENCO to check.
• Not safe: deciding whether a child has a need. Guidance forbids it, and the tool has not met the child.
• Not safe: writing a statutory EHCP. That is a legal document with a named accountable author.
• Not safe: flagging risk or distress without a route to a human. A signal nobody receives is not a safeguard.

Where does the data problem sit in SEND?

Squarely in the middle of it. Drafting a support plan means handling the most sensitive information a school holds: a named child, the difficulties they have, the help they receive, what goes wrong on a bad day. That is exactly the material you least want travelling to a server you do not own, under terms that can change while you sleep.

The direction of policy makes this heavier rather than lighter. Proposals to record more day-to-day provision in individual support plans mean more plans, drafted by more classroom teachers and SENCOs, for more children. If each of those plans is a small private decision about whether a child's data is safe to paste into a text box, the system leaks by design and asks exhausted people to plug the gaps.

What does building SEND-first actually change?

It changes the defaults. Symbol support, reading-age control, alternative input and screen-reader behaviour become properties of the system rather than settings someone has to know to find. It changes the evaluation too: a tool tested only on typical learners has no evidence at all about the pupils it will be used with most.

It also changes who is in the room. Aevum Learn is built SEND-first, aware of AAC and Makaton from the first line, and it is being shaped with the people who do this work rather than at them. If you are a SENCO, a speech and language therapist, or a teacher who lives in this every day, we would rather have you arguing with us now than reviewing us later.

Aevum Learn and the Marking and Feedback module have trained models. Everything remains in development, and no claim here is a claim about outcomes for children. Nothing we build removes the need for a qualified human in the loop, and in safeguarding it does not even reduce it.