A general document-upload form can receive more than its designer expected. A family may attach a school report to explain a request, or an administrator may upload a file containing several children's details when only a case reference was needed. Once that file reaches an AI service, changing the summary afterwards cannot undo the processing that already occurred.
The first deliverable should therefore be a review brief, before a live intake workflow. This article provides a proposed way to assemble that brief for a South African organisation. It identifies decisions for the information owner and a qualified privacy reviewer; it does not determine whether a particular processing activity is permitted or whether an authorisation is required.
Use the guidance index as a starting point
The Information Regulator's guidance index includes material on processing children's personal information and an authorisation application form. It is an appropriate starting point for locating specialist-review material. The index itself does not establish your organisation's authority, and the date beside the form should not be presented as the publication date of the guidance. Source: Information Regulator guidance index
Ask the qualified reviewer to identify the applicable current material and document how it relates to the exact activity. A broad statement that the organisation serves families is not a processing decision. The reviewer needs the purpose, information categories, roles, recipients and proposed uses, including whether an outside provider processes the documents.
Keep the questions concrete. Will the workflow only route a request, extract particular fields or create a decision recommendation? Who supplies the document, and how will the organisation verify their authority through its approved process? What evidence is required? Do not ask an AI model to infer permission from a polite message or an apparent family relationship.
Reduce the intake before considering extraction
Identify the smallest information set that supports the service. If a request can be routed using an internal case reference and request category, a full report may be unnecessary. The information owner and reviewer should decide which documents and fields are genuinely needed, rather than letting a generic upload box define the scope.
Design a clear route for unexpected material. The proposed workflow holds an unrequested sensitive attachment in the organisation's approved intake process and alerts an authorised owner without copying its contents into a broad notification. Whether to retain, return or delete it requires the established handling decision; the assistant does not invent a retention rule.
Do not infer a child's age or relationship from names, photographs or narrative clues. If a classification is necessary, establish an approved source and verification method. Uncertainty should be recorded as uncertainty, with a route to the authorised team, rather than becoming a confident label that affects access or service decisions.
Map provider processing and local copies
An intake map should include the upload store, document conversion, AI request, extracted result, reviewer workspace and notifications. Each stage can create a separate copy or reveal information to a different audience. Removing a detail from the final answer does not remove it from the preceding stages.
OpenAI's data-controls guide distinguishes abuse-monitoring logs from application state, with different conditions across endpoints and features. Review the actual proposed configuration and applicable controls; a generic statement about model training is not a complete retention assessment. Source: OpenAI data controls
Present the reviewer with the intended endpoint, input types, storage features and deletion process. Also include local error logs, backups and staff downloads. Where a fact is unknown, name its owner and keep it unresolved. Do not convert a provider capability into a promise that the organisation's whole workflow retains nothing.
Privacy-review brief for sensitive intake
Copy this complete proposed brief into the planning record. The questions are decision prompts, not legal answers; the named reviewer must provide the actual determinations and references.
Activity: AI-assisted routing of a family-service document request. Proposed initial output is a request category and restricted case reference, without a substantive decision about a child. Real document processing remains on hold pending the decisions below.
| Review area | Question and information to supply | Required decision record | Hold rule |
|---|---|---|---|
| Purpose and boundaries | What service needs the information, and which proposed uses are excluded? Supply the current manual process | Approved purpose, excluded uses and accountable owner | Broad or undocumented purpose |
| Authority and applicable requirements | Who supplies the document, who is entitled to act, and what current requirements apply? Supply the verification process | Qualified review with applicable references, evidence requirements and unresolved conditions | Authority or requirements unresolved |
| Necessary intake | Which document types and fields are required? Supply a minimal field list and reasons | Approved minimum input and alternative route for unnecessary attachments | Intake exceeds the approved scope |
| People and systems receiving data | Which staff roles, processors and subprocessors receive source material or extracts? Supply the complete processing map | Approved destinations, access boundaries and outstanding due-diligence items | Unknown recipient or unreviewed destination |
| Storage and disposal | Where do source, outputs, logs and backups exist, and how are handling decisions executed? | Owner-approved handling schedule and verified operational responsibilities | Unsupported deletion or retention assumptions |
| Operational actions | What may the assistant suggest or trigger, and which decisions require authorised staff? | Allowed outputs, prohibited actions and escalation owner | Proposal extends into unapproved decisions |
| Unexpected content | How are additional children's details, mixed-family files or uncertain authority handled? | Restricted hold path, notification content and response owner | Automatic forwarding or broad disclosure |
| Testing and release | Which fictitious cases are acceptable, and what evidence is needed before any real pilot? | Test scope, acceptance criteria and explicit release decision | Test success mistaken for processing permission |
Attach three supporting records: a field inventory showing required, optional and excluded items; a system map listing each input, output, access role and storage location; and a decision log with reviewer, date, version, rationale and open questions. Do not paste real children's information into the brief merely to make it concrete.
Use four fictitious fixtures for routing: a request with one approved case reference; a request missing that reference; two files with conflicting references; and an unrequested report containing additional imaginary children's details. Expected dispositions are respectively a proposed category for authorised review, a request for approved clarification, a hold for conflict resolution, and the restricted unexpected-content route. No fixture should be submitted through a real customer channel or imply an actual child exists.
The brief is ready for qualified review when its inputs, boundaries, owners and unresolved questions are complete. A real pilot requires the documented release decision and its conditions to be met; finishing this document does not itself authorise processing.
Keep extraction separate from authority
A schema can require a request category, evidence reference and uncertainty status. OpenAI's Structured Outputs documentation supports structured response formats and refusal handling. It does not verify the submitter's authority, establish a legal basis or determine that the document may be processed. Source: OpenAI structured outputs
If extraction is eventually approved, the application should enforce the allowed fields and routing decisions. A model-generated permission status must not unlock access. A refusal or unreadable document should remain an exception for the designated owner rather than being treated as an empty, harmless record.
Compare normal and unresolved intake cases
In a hypothetical normal case, the approved process confirms the submitter's authority through the established verification route and supplies a permitted case reference. Within the approved processing scope, the assistant proposes a request category for staff review. It does not make a judgement about eligibility or the child's circumstances.
In a missing-information case, the reference is absent and authority has not been confirmed. The assistant should not search unrelated records or infer identity from the attached narrative. It follows the approved clarification route. In a duplicate case, two copies with different references are held until an authorised person resolves the conflict; filename similarity does not establish that they concern the same person.
These cases make the operational choices reviewable while preserving the larger question of whether processing is permitted. They are deliberately narrower than a general sensitive-form launch checklist: the output is a specialist-review brief for this particular intake activity.
FAQ about children's information in AI intake
Does a parent's upload establish permission to use an AI provider?
Do not treat the upload as a complete determination. Ask the qualified reviewer to assess the actual authority, purpose, proposed recipients and applicable requirements, then implement the approved verification process.
Can a synthetic pilot answer the legal questions?
No. Fictitious cases can test routing and access behaviour without using real children's records. They cannot establish the authority or requirements for the intended live activity.
What should staff do with an unexpected sensitive attachment?
Use the organisation's approved restricted handling route and contact the designated owner. Avoid forwarding the contents widely or deciding on deletion through an AI suggestion. The review brief should define the route before intake begins.
If your business needs help defining this process, explore Document processing, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.