Additional course links
This lesson is for teams designing the evidence and handoff process around an established safeguarding policy. It does not teach a model to determine whether someone is safe. Bring your organization’s approved procedure, responsible roles and an authorized fictional test case. You will produce a restricted record template and a tested handoff.
Put the response procedure before the software
Staff need to know how to raise a concern directly, including when the usual person is unavailable or the system is down. If there is immediate danger, follow the applicable emergency and safeguarding procedures without waiting for AI analysis or a routine review queue.
Reporting duties and routes differ by jurisdiction, population and organization. The responsible safeguarding lead should define them. A keyword list or a prompt cannot establish the appropriate legal threshold or replace trained judgment.
For a child-safeguarding example, NSPCC guidance emphasizes reporting concerns through the appropriate safeguarding route and distinguishing facts from opinions in records. Apply the guidance relevant to your setting rather than treating this example as a universal procedure.
Record the concern and the source accurately
Use the person’s actual words when known, and label paraphrases as paraphrases. Record relevant observations, the date and time, who recorded the information and how it was received. Separate the event time from the time the note was entered.
Do not invent a quotation to complete a field. A concern based on an observation or pattern can still require action even when no exact sentence was spoken. Likewise, an exact quote does not establish that the entire situation is understood.
| Record component | Purpose |
|---|---|
| Relevant person and source | Keep the concern associated with the correct record and contributor. |
| Event and recording dates | Distinguish when something occurred from when it was documented. |
| Reported account or observation | Preserve what is known without embellishment. |
| Action already taken | Show the actual response, not merely a recommendation. |
| Recipient and acknowledgment | Confirm the handoff reached the appropriate person. |
| Decision and follow-up | Record authorized judgment, reasons and outstanding actions. |
Separate an alert from a completed handoff
A flag, queued message, delivered message and acknowledged concern are different states. Define who is responsible for checking that the handoff succeeds and what happens if it does not.
A prompt setting a field to “human review required” does not guarantee that anyone receives or acts on it. Test the actual notification, access, acknowledgment and fallback process. Do not mark the matter resolved because a notification was sent.
Keep the responsible person’s urgency assessment and decisions distinct from any automated suggestion. An AI system may miss indirect language, context or negation. Absence of an alert is not evidence of safety.
Test a fictional handoff failure
In a fictional training exercise, a staff member records a concern and uses the designated reporting route. The system shows “sent,” but the intended reviewer cannot open the restricted record. This is an access and acknowledgment failure, not evidence that the concern was reviewed.
The staff member follows the approved fallback procedure. The authorized reviewer obtains the relevant information, acknowledges receipt and records the next action. The system team then repairs and retests the failed access path without exposing the case to unrelated users.
The test should confirm what happened at each step. Do not use a real person’s sensitive record merely to demonstrate that the interface works.
Limit access while enabling appropriate sharing
Restrict sensitive notes to people with an appropriate role and purpose. A general course-progress dashboard or public report should not reveal the concern or its source passages.
Do not assume that consent is always the only basis for necessary safeguarding sharing, or that confidentiality means information can never be shared. Follow applicable law and the organization’s procedure with the responsible practitioner. Government information-sharing guidance for safeguarding children provides a jurisdiction-specific reference; it is not a substitute for determining the rules in your setting.
Record the reason for a sharing decision, what was shared, with whom and when. Apply the appropriate retention requirements and preserve relevant amendments rather than silently overwriting the history.
Keep any AI assistance narrowly bounded
If the organization permits AI in this workflow, define its role with the safeguarding lead. It might help locate a relevant passage or organize a record for an authorized reviewer. Do not rely on it as the sole detector, assign it authority to close a concern or describe a scan as a safety guarantee.
Test missed concerns as well as false alarms using authorized examples. Include unclear wording, corrections, different languages and records with no relevant concern. A single successful demonstration does not establish reliable detection.
Do not infer that mentioning a child, a diagnosis or a named person automatically establishes a particular risk level. The appropriate response depends on context and the responsible procedure.
What to verify in a Sopact setup
Verify the actual configuration before using it for sensitive operational work: permissions, source retrieval, audit history, notifications, acknowledgment and fallback arrangements. Confirm where the official safeguarding record is maintained and how this workflow relates to it.
Keep a direct human reporting route. Connected evidence can help an authorized person review context, but a general data platform or AI prompt should not be presented as a dedicated safeguarding system unless the required capabilities and controls have been established.
Practice: test the process with the responsible lead
- Define the approved reporting route and fallback.
- Prepare a fictional record with a paraphrase clearly labeled.
- Test correct identity, restricted access and acknowledgment.
- Simulate an unavailable reviewer or failed notification.
- Record what needs repair and retest before operational use.
Frequently asked questions
Should staff wait for an AI alert?
No. Raise concerns through the applicable procedure. AI should not be a prerequisite for reporting or responding.
Must every concern have an exact quotation?
No. Record exact words when known, but distinguish observations and paraphrases accurately. Do not delay a concern or invent wording to satisfy a field.
Does “sent for review” mean the issue is resolved?
No. Confirm receipt and the responsible person’s next action under the agreed process.
Can a clear scan establish that someone is safe?
No. A system can miss relevant evidence. Safety and safeguarding decisions cannot be inferred from the absence of a flag.