Responsible AI: a working checklist for small organisations
Created by Adrian Dunkley, MaestrosAI. Use this checklist to decide what a proposed workflow needs before use. It is not a timed audit, a legal opinion or proof that a system is safe.
1. Describe one task and its limits
For example: “Draft answers to fictional guest questions from our approved property sheet; a receptionist checks every answer.” State what the tool must not do: confirm bookings, invent prices, change policies, collect sensitive information or send replies.
- Name the owner and reviewer.
- List tools, integrations, data sources and recipients.
- Identify people who could be affected by an error.
- Explain why AI is needed and how the existing process works.
- Keep the pilot draft-only and separate from production systems.
2. Check the information before upload
Use synthetic or approved non-sensitive material initially. Do not put medical files, children’s records, personal financial information, credentials or confidential client documents into a general-purpose chatbot. Removing names does not by itself authorise an upload or prevent identification.
Ask who has authority to approve the data use, what purpose is permitted, which provider receives it, where it is retained, and who can access or delete it. Legal grounds and transfer requirements depend on the activity and applicable rules; a generic consent checkbox is not a substitute for review.
Document a justified retention period and deletion process. Do not adopt a universal 30-day rule or retain every prompt “for safety”: logs can themselves expose private information. Record only what is needed, restrict access and protect originals.
3. Define the test before running it
Use a small set of fictional cases to find obvious problems, then decide what further evidence is needed. A handful of examples cannot establish reliability or fairness.
Include:
- A normal request that the approved source answers.
- Missing and contradictory source information.
- Dates, currencies, units and local terminology that are easy to confuse.
- A request outside scope that must reach a person.
- Text in an uploaded document that tries to change the assistant’s instructions.
- Attempts to obtain private information or trigger an unauthorised action.
For each case record the expected behaviour, actual output, source, reviewer and result. Count omissions, false alarms, correction time and harmful errors, not only fluent answers. Check calculations independently.
4. Test language and fairness without stereotyping
Ask reviewers who know the intended language variety to design realistic fictional examples. Compare equivalent requests whose task-relevant facts stay the same while language, spelling or presentation changes. Do not infer ethnicity from a name, assume older people speak slowly, or treat a dialect as defective standard language.
Where an evaluation needs demographic data, obtain specialist privacy and research advice before collecting it. Do not silently infer protected characteristics from users. Give reviewers a way to record disagreements and limitations.
The system should communicate respectfully and provide a usable human route. A prompt change may improve one example while harming another; rerun the relevant tests rather than declaring bias solved. A more expensive model is not automatically a remedy.
5. Tell users what is actually happening
A notice should match the deployed service and the organisation’s approved privacy information. Do not promise capabilities, human availability, retention periods or compliance that have not been verified.
Draft template, to complete and review before use:
You are using an AI-assisted service for [permitted task]. Its replies may be incomplete or incorrect. For [out-of-scope matters], contact [working human channel and stated service hours]. Do not enter [information the service must not collect]. Read our approved privacy information at [link].
Translate only the approved wording and obtain competent local review. The notice does not replace legal disclosures or permission to process information. If the human channel is unavailable, say so rather than promising an immediate response.
6. Ask vendors questions that require evidence
- Which exact service and account terms apply? Does pricing cover the required controls?
- Are inputs or outputs used for training, and under what settings or exceptions?
- What is retained, where, by whom, and after account closure?
- What access controls, deletion/export options and incident support are available?
- What is the scope and date of any audit or certification offered?
- Which subprocessors and external actions are involved?
- What changes when a model or service is updated?
- How can the organisation stop use and recover its records?
“Can I opt out?” and “Where is the data stored?” need specific answers, not a checklist of yes responses. Self-hosting is an engineering and governance decision, not a shortcut around privacy or security work.
7. Set a meaningful approval gate
Before external use, verify data permission, output review, action limits, incident ownership and fallback. Unresolved hazards can require stopping or narrowing the task. Do not deploy first and assume all deficiencies can be repaired later.
Document the approved scope and who can change it. Keep payments, messages, filings, account changes and equipment control outside a drafting trial. High-impact use needs qualified review appropriate to the domain; this checklist does not authorise it.
A short internal policy worksheet
Fill in actual decisions rather than copying an assurance statement:
Allowed task and purpose:
Approved tool, version and account:
Permitted inputs and prohibited information:
Permitted outputs and prohibited actions:
Required reviewer and evidence to check:
Human contact and error-correction process:
Retention, access and deletion decisions:
Stop conditions and incident owner:
Approval date, approver and next review:
If a field is unknown, record it as unresolved. Do not publish a policy claiming that all providers meet international standards unless the organisation can substantiate that statement for the relevant services.
Sources and related guidance
NIST’s voluntary AI RMF and UNESCO’s AI ethics recommendation provide broader reference frameworks. This checklist is the Playbook’s practical adaptation, not an official audit instrument or a substitute for their full texts. Sources checked 11 November 2026.
Adrian Dunkley | MaestrosAI | maestroailabs.com | ceo@maestrosai.com. Educational guidance.