Human review and attestation for AI-created training

Human review and attestation for AI-created training exist to answer one question: when a member of staff acts on a training module and something goes wrong, who approved the instruction they followed. That question arrives in a governors' meeting, an accreditation interview or a serious incident review, and it does not accept software as an answer.

The question is not new. Schools have always run training written by somebody, and the somebody was identifiable. What AI changes is the volume and the speed. A model produces a full safeguarding module from a policy in a few minutes, and a school that is pleased with the time saved can publish it in the same afternoon. The drafting became fast and the approval did not, so the approval is the step that quietly gets skipped.

The Department for Education states in its guidance on generative AI in education that these tools cannot replace the judgement and deep subject knowledge of a human expert, and that staff must apply professional judgement when using them. In safeguarding that principle needs a mechanism behind it, because a good intention does not leave a record.

A reviewer who knows what to look for finds the same categories of error repeatedly, and none of them look like errors on the page. The first is confident smoothing. A policy says a concern must be reported to the DSL on the same day, and the draft renders it as promptly, which is fluent and materially different. Somebody reading that module will report tomorrow.

The second is the invented middle step. Where a policy leaves a gap, a model fills it with a procedure that exists in the training material it learned from, which usually means a procedure from England or the United States. The school ends up teaching a route it never approved, and the first person to notice is the evaluator who asks a member of staff to describe it.

The third is tonal. Safeguarding training has to be direct about adult conduct, about disclosures, and about what a member of staff must do even when a colleague is involved. Drafts tend to soften those passages, because softening is what fluent writing does. A reviewer has to put the hard edges back, particularly in anything covering low-level concerns about adults.

The fourth is scenario realism. A generated scenario about a child disclosing in a classroom will be competent and generic. It will not mention that in this school the classroom doors have glass panels, that the nearest deputy DSL teaches on the floor above, or that Friday afternoon is when the DSL leaves early. Those details are what make a scenario a rehearsal, and they come from the reviewer rather than the model.

A review that depends on somebody remembering to do it will hold for a term. The way to make it hold longer is to build it into the publishing path: the module cannot reach staff until a named person with the authority to approve it has recorded a decision. That person should be the Designated Safeguarding Lead, with the Head of School informed, because the DSL is the one who will be asked to defend the content.

The reviewer needs three things in front of them at the same time: the source policy, the draft module, and the specific claim that the draft makes about the school's procedure. Reviewing a module in isolation produces a proofread rather than a review. Most of the errors above are only visible when the policy sentence and the training sentence sit side by side.

Reviewers also need permission to reject. If the practical expectation is that the DSL approves whatever appears, because rejecting it means rebuilding the module by hand, the gate is decorative. A workable process lets the reviewer send a module back with a note about the specific paragraph, and produces a corrected draft quickly enough that rejecting is cheaper than tolerating.

Attestation is the reviewer's declaration, made once, in plain language, and stored with the version it applies to. It should be short enough that the person signing it reads it, and specific enough that it means something when read back two years later by somebody who was not there.

The record around the declaration matters as much as the words. A school that keeps the following set can reconstruct any published module, explain who stood behind it, and show which staff completed which version.

• The source policy documents and their version dates.
• The generated module version, with a content hash so the approved text is identifiable later.
• The name and role of the reviewer, and the date and time of approval.
• The declaration text the reviewer accepted, stored as it was worded at the time.
• The language of the version approved, and the name of whoever checked that language.
• The list of staff assigned to that version and their completion status.

Long declarations get accepted without being read, which defeats the purpose. Four statements cover the ground: that the reviewer has checked this version against the named policies, that the examples and questions suit the staff group it is assigned to, that the urgent reporting instructions are correct and unambiguous, and that the reviewer accepts responsibility for releasing it to staff.

The fourth statement is the one that does the work. The first three describe checks and could be delegated. Accepting responsibility for release is what makes the reviewer read the first three properly, and it is the sentence a Head will look for if the module is ever questioned.

Wording it in the first person also helps. A declaration that reads as the reviewer speaking, rather than as a system confirming a step, is treated differently by the person clicking it. Schools that phrase this as a checkbox labelled approved usually find, a year later, that nobody can remember what was checked.

A school that publishes safeguarding training in Russian, Kazakh, Arabic or Spanish has multiplied the review task, and the multiplication is not obvious. Approving the English version and assuming the translations follow is the most common mistake I see, and it is understandable, because the translated text reads fluently.

Machine translation is reliable about ordinary prose and unreliable about institutional terms. A role title becomes a generic phrase. A named legal duty becomes a description of a duty. A referral body becomes the equivalent body in a different country. Each of these reads perfectly well and points staff at the wrong system.

The check is narrow and quick. Someone who speaks the language and knows the school reads the reporting route, the names and roles, the legal references and the recording instructions, and confirms they match. That check should be recorded against the language version rather than the module as a whole, so that a school can say who approved the Kazakh text specifically.

Evaluation teams and inspectors do not usually ask how a module was written. They ask what staff were trained on, who approved it, and when. A school that answers with a named person, a date and a version number closes the topic in about a minute. A school that answers with a completion spreadsheet spends the rest of the interview explaining.

This is also why the attestation is worth more than the training file it sits in. It is evidence of a functioning governance step rather than of an event, and it holds up when the DSL changes, which happens often in international schools. The successor inherits a record instead of a set of assumptions, which is the same argument behind training records that stand up to inspection and behind what a safeguarding training certificate should prove.

None of this makes AI-drafted training better than training a school wrote by hand. It makes the two comparable, which is the point. A school should be able to show the same chain of accountability whichever way the words were produced, and that chain is what AI can and cannot do in faculty training rests on.

SafeguardIS builds training from the school's own safeguarding and child protection policies, and holds every module at the review gate before staff see it. The Designated Safeguarding Lead reviews and approves each one, publishing requires a named reviewer's declaration, and the approved content is hashed and logged, so the version behind any completion stays identifiable. Certificates are countersigned by the Head of School and the DSL and carry a code anyone can check on a public verification page.

The platform ships training in English, Russian and Kazakh today, and each language version carries its own approval rather than inheriting the English one. If your staff work in a language the platform does not ship yet, I build that language in for your school as part of the pilot. Alongside the training there is a policy audit that checks a school's documents against ITFCP-aligned expectations and produces an action plan, and I run live workshops in English and Russian as well as whole-school safeguarding audits.

I have worked in international education since 2008, as an IB and MYP teacher, an IB DP economics teacher, an IB and CIS evaluator and workshop leader, and most recently as CIS accreditation coordinator. I am not a Designated Safeguarding Lead, which is precisely why I put a named human at the publishing gate rather than around it. To see the review and attestation flow on your own policy, book a 20-minute walkthrough.