At Level 3 Builder, a successful prototype is not permission to use live data. When an AI component touches information about participants, patients, employees, customers, or applicants, you must make the proposed processing visible to the people who own ethics, privacy, security, contracts, and the affected service. This mini-book helps you prepare that review without pretending to replace it.
2. The analysis works, but the approval is older than the tool
You have built an analysis that groups free-text recovery comments into themes. It performs well on synthetic records. The real research dataset replaces names with participant codes, so your team calls it pseudonymised. The proposed model is reached through a US-hosted API, but the study's ethics approval predates that service and describes analysis inside the institution's controlled environment.
A colleague suggests sending ten coded rows as a small test. You stop before uploading them. Codes can be reconnected to people, comments may contain health details and indirect identifiers, and neither the provider's subprocessors nor retention terms appear in the existing review record. Enterprise, pseudonymised, and already approved do not answer whether this specific transfer and output use are permitted.
Your next deliverable is therefore not a live run. It is a decision-ready description of the data, purpose, service, account, locations, agreements, retention, affected people, safeguards, and output use. Until the accountable ethics, privacy, security, procurement, and domain reviewers record their decisions, the live-data state remains STOP.
3. After this you can
- Classify and map proposed inputs and outputs from source to deletion without treating a data label as permission.
- Compare a new AI use with the recorded purpose, consent or notice, ethics approval, data-protection assessment, contracts, and security decision that already exist.
- Prepare the facts reviewers need: necessity, data fields, processor location, agreement, retention, access, re-identification capability, output use, and safeguards.
- Route a proposal to ethics, privacy or data protection, information governance, security, procurement, clinical safety, or another accountable owner instead of deciding alone.
- Recognise when health data, minors, vulnerable groups, free text, international processing, or an output affecting treatment or opportunity demands a different or additional approval path.
4. Prerequisites
T15-L02- Reproducibility with AI in the loop, so the proposed model, prompt, version, settings, input boundary, and retained output can be described.T12-L03- Rules for things that run without you, so permissions, volume limits, human approval, stop conditions, and accountability are explicit if the component runs unattended.- The current protocol, ethics decision, consent materials or participant information, privacy notice, data-management plan, information-classification rule, retention schedule, and relevant contracts for one project.
- The organisation's current routes for research ethics, privacy or data protection, information governance, security, procurement, records, incident response, and, where relevant, clinical safety.
- A service owner or principal investigator and a named reviewer who can decide whether the proposal may proceed.
Use only the synthetic cases on this page to practise. Do not paste real participant or patient records, study free text, employee comments, customer cases, identifiers, linkage keys, unpublished results, credentials, contracts, or review documents into an AI service for this exercise. Do not put identifying details into the review draft merely to make it complete. Describe fields and risks generically and keep the real review record only in its approved location.
This book is workflow guidance, not legal, clinical, or ethics advice. Terms such as personal data, health data, anonymisation, controller, processor, consent, amendment, and impact assessment can have specific meanings under the rules that apply to your project. Use the language and decision process required by your institution, organisation, review body, contract, profession, and jurisdiction.
5. The idea in one page
Start with what would actually enter the component, not the vendor's security page or the model's usefulness. A label describes risk; it does not grant permission.
| Material | Review meaning | Safe default before review |
|---|---|---|
| Synthetic | Invented records test format and flow, not permission for live processing. | Build here first; do not lightly alter real records. |
| Public | Availability does not remove licence, sensitivity, or impact questions. | Record source, terms, purpose, and affected people. |
| Anonymous | Identifiability is not reasonably likely in the relevant context. This is a contextual conclusion. | Document and independently challenge the method. |
| Pseudonymised | Codes replace identifiers, but a key or other information can reconnect people. | Separate the key, minimise fields, restrict access, and seek approval. |
| Identifying or sensitive | Direct identifiers, health, biometrics, finances, or safeguarding increase duties and harms. | Keep it out until necessity and route are approved. |
| Free text or media | Identifiers can hide in quotations, metadata, filenames, images, or speech. | Inspect and minimise locally before any transfer. |
| Outputs and logs | Summaries, embeddings, predictions, caches, and traces can preserve or infer protected facts. | Classify and protect them like inputs. |
Removing a code column may leave a rare diagnosis, date, job, site, or quotation that singles someone out. Do not ask a destination model to anonymise material it was not permitted to receive. Minimise rows, fields, precision, text, outputs, recipients, and retention.
A model call is not simply dataset -> answer. Draw content and recoverable representations through deletion:
approved source -> minimisation/pseudonymisation -> application or connector
-> API gateway -> model provider -> named subprocessors/regions
-> output, safety logs, caches, backups and monitoring
-> approved reviewer -> accepted result or rejection -> deletion/archive
separate linkage key ------------------------X never sent to the model route
At each stage, record system, location, fields, purpose, access, retention, deletion, and evidence owner. Distinguish headquarters, processing region, support, subprocessors, and backups. Write unknown - owner to confirm when evidence is absent.
Compare that flow with the actual protocol, consent or notice, ethics decision, privacy assessment, security decision, contract, and retention plan. Summarise the delta:
Previously approved: [data, purpose, systems, recipients, locations, outputs].
Proposed change: [new AI component and every changed fact].
Unchanged: [facts that genuinely remain fixed].
Decision requested from: [named review route and accountable role].
Live-data status: STOP until that decision is recorded.
The authorised body decides whether the delta needs an amendment, impact, contract, security, or information review. Consent alone does not replace those decisions.
Escalate health or clinical use; minors or vulnerable groups; biometrics, genetics, linkage, or covert inference; uncertain external processing; unattended scale; and output affecting treatment, employment, finance, safety, publication, or opportunity. Human review requires a qualified person with source evidence, rejection criteria, time, and stop authority.
Give reviewers the owner and decision; purpose; affected people and fields; minimisation; complete flow and processor evidence; retention and reuse; model and prompt record; prohibited uses and controls; alternatives and unresolved questions; and an APPROVE, REVISE, or STOP field. Only the authorised reviewer completes that field.
6. The worked example: one review pattern, two settings
The two cases below are entirely synthetic practice and cannot satisfy the exit check. Course Model API, its regions, agreements, and retention settings are fictional; they do not describe a real provider. Both teams have a useful prototype and an older approval. Both submit the same fields and keep live data out while decisions are pending.
Lab framing: coded recovery comments
Project LANTERN-LAB studies how fictional adult participants describe recovery after a routine procedure. Its existing protocol permits coded survey analysis in the university research environment. The proposed component would assign themes to one optional free-text response. The source table has 120 rows. Names and contact details are held in a separate recruitment system, but the research team can reconnect the study code. Comments can mention symptoms, a clinic, dates, relatives, work, and rare events. The material is therefore treated as pseudonymised participant health data with risky free text, not anonymous text.
The prototype used twelve invented comments and made no care or eligibility decision. The proposed service is Course Model API through an institution-managed account. Its fictional primary processing region is the United States; subprocessor and support-access evidence is not yet attached. The old ethics decision names local statistical analysis and does not describe this provider. The principal investigator therefore asks the ethics office whether an amendment or other determination is required, while privacy, information governance, security, and procurement review the route. The team does not send one "test" participant row while waiting.
The design is narrowed before review. A local approved preprocessing step removes study code, exact dates, clinic names, names, contact details, relatives' details, and unnecessary quotations. It converts each approved comment into controlled phrase categories where the research question allows. The linkage key never enters the analysis workspace or model call. Output contains a row number generated for the run, proposed theme, supporting source span, uncertainty flag, and HUMAN_REVIEW; it cannot write to a clinical record, contact a participant, determine treatment, or change study inclusion. A trained researcher compares every theme with the minimised source, rejects unsupported inferences, and reports only approved aggregate findings.
Even with those controls, the status remains STOP. The reviewer may require a different processor, local model, revised information, further minimisation, deletion evidence, a new risk assessment, or no AI use. The team has reduced the proposal; it has not approved it.
Company framing: coded employee-support comments
Project LANTERN-COMPANY seeks aggregate themes in a fictional voluntary employee-support survey. The existing notice covers collection and internal reporting, but the proposed AI processor and individual-level inference were not specified. The export replaces names with staff codes, while HR retains the mapping. Comments can reveal mental health, disability, caring responsibilities, location, team, grievances, and manager identity. Managers could often recognise a writer from combinations. The dataset is treated as pseudonymised personal data containing sensitive free text.
The prototype again uses twelve invented comments. The same fictional US API and managed account are proposed, and the same processor evidence is missing. Jonas routes the design to the company's privacy or data-protection owner, information security, procurement or vendor management, HR data owner, employee-relations or worker-representation route where applicable, and the AI review group. These are not decorative sign-offs: each route answers a different question about expectations, necessity, contracts, access, impact, security, and worker safeguards.
The narrowed design excludes staff code, names, contact details, exact dates, team names, precise locations, manager names, case references, and raw quotations. It reports only broad themes above a minimum aggregation threshold chosen by the accountable reviewers. No row-level score is exposed to a manager. Output cannot influence performance, promotion, discipline, absence management, access to support, redundancy, or recruitment. An authorised analyst checks themes against the approved minimised source, searches for small-group disclosure, and suppresses unsafe aggregates. Employees retain the organisation's existing contact, correction, objection, complaint, and incident routes as applicable; the review determines whether further notice or participation safeguards are needed.
Again, these safeguards do not produce permission. The current state is STOP until the named reviewers record decisions and every condition is reflected in the system.
The shared submission section
Each team completes one section in its own approved review system. This filled example shows the level of specificity expected while keeping the cases synthetic:
| Review field | LANTERN-LAB entry | LANTERN-COMPANY entry |
|---|---|---|
| Owner and decision requested | Principal investigator requests a determination on the AI component and any required ethics amendment, plus privacy, information-governance, security, and procurement decisions. | Service owner requests privacy/data-protection, security, procurement, HR data-owner, employee-impact, and AI-governance decisions. |
| Purpose and necessity | Propose themes for aggregate research reporting from one optional response. Compare against local manual coding and a non-AI local method; convenience alone is not sufficient. | Propose broad themes for aggregate service improvement. Compare against manual coding and sampling; no individual management purpose. |
| People and data | 120 fictional adult-participant rows; pseudonymised health-related free text; research team can re-identify through a separately held key. | Fictional employee survey; pseudonymised sensitive free text; HR can reconnect staff codes and colleagues may recognise combinations. |
| Input minimisation | Remove code and direct identifiers locally; remove or generalise dates, clinics, relatives, jobs, rare events, and quotations; send only approved fields. Key excluded. | Remove code and direct identifiers locally; remove team, manager, location, dates, case references, and quotations; use controlled categories where possible. Key excluded. |
| Flow and location | Approved source to local preprocessing to managed connector to fictional US API and declared subprocessors, then output to restricted research workspace. No clinical-system connection. | Approved survey store to local preprocessing to managed connector to fictional US API and declared subprocessors, then output to restricted analytics workspace. No HR action-system connection. |
| Processor and agreement | Course Model API; institution-managed account. Processing agreement, transfer review, subprocessor list, support access, and deletion evidence: pending, owned by procurement/privacy. | Same fictional provider and pending evidence, owned by vendor management/privacy. Consumer accounts prohibited. |
| Retention and reuse | Requested: provider logging disabled where contractually available; zero content retention or shortest approved period; no provider training or improvement use; local source/output retained only under the approved study schedule. Evidence pending. | Same provider request; local aggregate output retained under approved survey schedule; row-level working copy deleted or archived as review directs. Evidence pending. |
| Model record and change | Record prompt, requested/returned model version, settings, input/output hashes, date, validation, and limitations under T15-L02. Provider, model, region, retention, prompt purpose, or fields changing triggers re-review. | Same reproducibility record and change triggers; scale, recipient, aggregation threshold, or proposed decision use also triggers re-review. |
| Output and human check | Theme proposal with source span and uncertainty; trained researcher checks every row. No diagnosis, care, contact, eligibility, or clinical-record update. | Broad theme proposal; authorised analyst checks every source link and small group. No manager receives row scores; no employment or support-access decision. |
| Failure and incident | Stop calls, preserve minimum approved evidence, notify principal investigator and local privacy/security/ethics routes, assess affected records, and do not silently rerun. | Stop connector, prevent distribution, preserve minimum approved evidence, notify service owner and local privacy/security/HR routes, and follow the incident process. |
| Unresolved questions | Does the ethics body require amendment? Is this purpose within participant information and approvals? Which subprocessors and locations apply? What retention is contractually guaranteed? Is preprocessing sufficient? | Is the use consistent with notice and worker expectations? Which impact review applies? Which subprocessors and locations apply? What retention is guaranteed? Is aggregate disclosure sufficiently controlled? |
| Current status | STOP - no live transfer until all required decisions and conditions are recorded. | STOP - no live transfer until all required decisions and conditions are recorded. |
The strength of the section is not that it promises perfect anonymisation or perfect model accuracy. It tells reviewers what is known, what is missing, how people could be affected, and exactly where the system is prevented from acting.
7. What goes wrong
Pseudonymised is treated as unrestricted
Symptom: the team replaces names with codes and sends the table through any convenient account.
Fix: classify it accurately as linkable, protect the key separately, test indirect identification, minimise fields, and require approval for the exact service and purpose. Do not put the key in prompts, logs, filenames, or output.
Free text bypasses the column review
Symptom: the structured fields look clean, but comments contain names, dates, diagnoses, workplaces, relatives, or distinctive events.
Fix: treat the complete free-text field as sensitive until locally inspected and minimised. Prefer controlled categories or synthetic text. If meaning cannot be retained without disclosure risk, keep it out of the model route.
A consumer tool has no reviewed agreement
Symptom: a builder relies on a paid subscription, privacy toggle, or vendor marketing page but cannot show the organisation-managed account, governing terms, processor role, locations, subprocessors, retention, deletion, or reuse conditions.
Fix: stop. Give vendor management, privacy, security, and procurement the exact service and architecture. Use synthetic fixtures while they assess an appropriate arrangement or reject the route.
The old approval is stretched around the new tool
Symptom: the project title and research question are unchanged, so the team assumes external AI processing is covered.
Fix: compare the old approved flow with the proposed one and submit the delta. Let the authorised body determine amendment, new review, updated information, or another outcome before live processing.
Review happens after a "small test"
Symptom: ten live rows are sent to obtain performance evidence for the review.
Fix: use synthetic data or an explicitly approved evaluation route. Review must cover the transfer that the test itself would perform. Small volume can reduce impact; it does not create permission.
Human review is only a label
Symptom: one analyst approves hundreds of opaque scores, cannot open the source, and has no authority to stop delivery.
Fix: define the evidence, workload, competence, rejection criteria, escalation route, and stop control. Remove the model from consequential decisions if meaningful review cannot be provided.
Output risk is ignored
Symptom: the input flow is secured, but inferred health themes or staff-risk scores are shared more widely than the source data.
Fix: classify output and logs, restrict recipients, prohibit unapproved individual decisions, test subgroup and disclosure harms, and retain only what the approved purpose needs.
The builder decides alone
Symptom: the submission ends with "low risk; proceed," signed only by the person who built the prototype.
Fix: separate preparation from decision. Name the service owner and every applicable independent review route. Keep status at STOP until authorised decisions, conditions, and owners are recorded.
8. Do it yourself: draft the review section in 90 minutes
Choose one real project only as a subject for documentation. Do not copy its live data into the exercise, do not query a model, and do not contact a provider. Use field names, counts, system names, approved policy references, and generic descriptions in the organisation's protected review location. If even those details cannot be used there, complete a Section 6 synthetic case as practice but do not claim the exit check.
Minutes 0-10: name the project, accountable owner, bounded purpose, affected people, intended output, and decisions the output must never make. Write live-data status: STOP pending review at the top. List the ethics, privacy or data-protection, information-governance, security, procurement, domain, worker, clinical-safety, or other routes that may apply; ask their owners rather than excluding a route yourself.
Minutes 10-22: inventory inputs field by field. Mark synthetic, public, anonymous, pseudonymised, identifying, sensitive, free text, and linkage capability. Include attachments, metadata, prompts, retrieval content, output, embeddings, logs, caches, and error traces. State where the key exists and confirm that it is excluded from the proposed model route.
Minutes 22-34: draw the complete flow from source through preprocessing, connector, API, provider and subprocessors to output, review, retention, archive, and deletion. Add location or region, access role, encryption boundary, and owner at every stage. Mark facts not supported by evidence as unknown.
Minutes 34-44: compare the flow with the existing protocol, approval, consent or participant information, notice, data-management plan, privacy assessment, security decision, and contract. Write previously approved, proposed change, and unchanged. Form the exact questions that authorised reviewers must answer; do not answer them on their behalf.
Minutes 44-56: document the provider arrangement: exact service and account, provider role as locally defined, named subprocessors, processing and support regions, governing agreement, transfer assessment where applicable, content retention, backups, deletion, model-training or improvement use, support access, and incident notification. Attach or cite current evidence in the protected system. If evidence is absent, assign an owner and retain STOP.
Minutes 56-68: minimise the proposal. Remove fields, rows, precision, text, retrieval access, output detail, recipients, and retention that the purpose does not need. Describe a synthetic-first evaluation and at least one non-AI or local alternative. Explain why any remaining personal or sensitive field is necessary rather than convenient.
Minutes 68-79: define participant, patient, employee, customer, or applicant safeguards as applicable. Name who verifies outputs, the source they see, rejection criteria, prohibited inferences and decisions, aggregation or small-group controls, withdrawal/correction/complaint routes, incident handling, and the kill switch. If output could influence treatment, study eligibility, employment, education, finance, insurance, benefits, access, or safety, route that use separately and prohibit it in the current design.
Minutes 79-86: define reproducibility and change control. Record the prompt and model fields from T15-L02; name changes that trigger re-review, including provider, account, model, region, subprocessor, retention, purpose, population, fields, scale, recipients, automation, and output use. Do not promise identical model output.
Minutes 86-90: combine the work into one review-submission section. Read it as an independent reviewer: can you locate every unknown, owner, evidence source, safeguard, prohibited use, and requested decision? Remove identifiers from the section. Send it only through the approved review route, and do not change STOP yourself.
9. Exit check
Deliver exactly one artifact: one review-submission section covering the AI component of one real project. It must contain the owner and requested decisions; purpose and necessity; affected people; data categories and linkage capability; field-level minimisation; complete data flow; provider, account, locations and subprocessors; governing agreement and evidence status; retention, deletion and provider-reuse terms; model and prompt record; output use; participant, patient, employee, customer or applicant safeguards as applicable; human review; incident and stop route; alternatives; unresolved questions with owners; re-review triggers; and current decision state. A completed synthetic case is practice only and does not satisfy this artifact.
It passes the learning check when an independent reviewer can distinguish fact from assumption, compare the old and proposed flows, see why pseudonymised or free-text data remains protected, identify who can re-identify, trace input and output to deletion, understand how people could be affected, and make an informed APPROVE, REVISE, or STOP decision through the applicable process. The learner does not fill the approval field. A complete section with unresolved questions may pass this documentation exercise while the project correctly remains stopped.
It fails if live data was used to prepare it, if a provider claim lacks evidence but is stated as fact, if "anonymous," "consented," "enterprise," or "human reviewed" substitutes for analysis, if consequential output use is hidden, or if the builder treats submission as approval.
10. Rule to remember
The approval covered the study, not the tool you added later.
11. Further reading & tools
- Taught:
T15-L02- Reproducibility with AI in the loop - records model, prompt, settings, input, output, rerun, and limitations for the component described in review. - Taught:
T12-L02- Privacy and labelling in everyday work - distinguishes anonymisation from pseudonymisation and checks free text, hidden surfaces, linkage, rights, and impact before upload. - Taught:
T12-L03- Rules for things that run without you - defines permitted actions, approvals, limits, accountability, and a kill switch for unattended processing. - Taught: Privacy & safe AI use - applies approved-tool, minimisation, source-boundary, verification, and human-escalation checks.
- Catalogued: NIST Privacy Framework (opens in a new tab) - voluntary privacy-risk guidance; it does not approve a dataset, model, transfer, or purpose.
- Catalogued: NIST AI Risk Management Framework (opens in a new tab) and Generative AI Profile (opens in a new tab) - lifecycle risk-management references for mapping, measuring, managing, and governing AI risks.
- Catalogued: WHO guidance on ethics and governance of artificial intelligence for health (opens in a new tab) - international health-focused principles and governance considerations; local clinical, ethics, professional, and legal routes still decide a project.
- Catalogued: UK Information Commissioner's Office guidance on anonymisation and pseudonymisation (opens in a new tab) - one regulator's contextual guidance on identifiability and pseudonymisation; use the authority and definitions applicable to your project.
- Catalogued: US HHS Office for Human Research Protections decision charts (opens in a new tab) - US-oriented navigation aids for human-subjects questions, not a substitute for an institutional review determination.
- Catalogued: UK Health Research Authority guidance on amendments and changes (opens in a new tab) - one jurisdiction's review route for study changes; consult the review body responsible for the actual project.
- Catalogued: Tools index - compare product capabilities only after data, purpose, account, agreement, location, retention, review, and output boundaries are defined.