AI Safety and Alignment Caribbean
Caribbean AI Safety Needs Local Evidence and Shared Methods
Adrian Dunkley applies his S4 framework to AI safety and alignment for Caribbean AI Association members, educators and public-service teams.
Caribbean organisations should share ways to evaluate AI while retaining local responsibility for the decisions they approve. A test developed in one territory can be a useful starting point elsewhere, but it needs new evidence when the language, service rules or consequences change. Regional cooperation should make that work easier to inspect.
My S4 AI Safety Framework offers a common structure for the conversation: Specify, Stress-test, Safeguard and Scrutinise. For the Caribbean AI Association audience, I apply it to a proposed collaboration on public-information services, with local ownership of sources, tests and complaint handling.
AI safety and alignment are a personal responsibility. When you choose to use an AI tool, you also accept responsibility for checking what you share, what you approve and who your decision could affect.
Adrian Dunkley, author’s statement
Share the test method without assuming the same answer
A university team in Jamaica and a service team in Saint Lucia could both evaluate an assistant that explains application procedures. They can share a template for recording the question, source date, expected response and rejection condition. They should not assume that the same source documents or acceptable wording apply in both places. This is a proposed collaboration, not a claim that the association has completed it.
Language evaluation needs people who understand the way the intended community asks for help. A grammatically tidy rewrite can alter emphasis, respect or meaning. Ask contributors to explain where an answer misreads a request, rather than treating standardised spelling as a substitute for comprehension. Where contributors supply examples, agree consent, access and any compensation before collecting the material.
Regional collaboration also needs a clear boundary around sensitive records. Teams can share synthetic cases, scoring guidance and descriptions of failure mechanisms without creating a central collection of identifiable applications. If sharing actual records is necessary, assess authority, safeguards and retention for each transfer. Convenience is insufficient justification for making the largest possible dataset.
I would begin with a small comparison of methods. Each participating team should publish what it tested, what it excluded and which decision the evidence supported. Keep disagreements visible: a case that one team treats as acceptable may reveal a different service obligation or community expectation elsewhere. The useful regional product is a better question and an inspectable method, rather than an unsupported league table.
A shared evaluation session could begin with the same synthetic request and ask each participating team to describe its expected answer. Differences would be useful evidence about service rules, language and available sources. Resolve what can be standardised and preserve the parts that need local judgement. Do not average away a disagreement that changes a person’s outcome.
The evaluation record should also identify who was missing from the discussion. A technically competent group may still lack the perspective of a frontline worker, a person with a disability or a speaker of the language being assessed. Invite the expertise needed for the particular service rather than claiming that a broad invitation established representative participation.
For education partners, the contribution can include teaching people how to challenge evidence. Give learners a synthetic answer with a source that is authentic but irrelevant to the claim. Ask them to explain the mismatch and identify the responsible authority. Mark the quality of the explanation, including a justified decision that the available evidence is insufficient.
A regional repository can retain the synthetic case, assessment guidance, version and conditions for reuse. It should also record cases that were withdrawn because consent, rights or context were unclear. Reusability depends on an understandable provenance record, not simply on whether the file can be downloaded.
What AI safety and alignment mean for the person affected
For the person using a service, AI safety concerns the harm an answer or action could cause. Alignment concerns whether the service behaves in accordance with its intended purpose and agreed human constraints. A service can meet an institutional target and still fail the person who needs help. Closing a difficult enquiry quickly is not evidence that the problem was resolved.
The distinction is consistent with research by Amodei and colleagues on objectives, supervision and behaviour outside familiar conditions. The application here is my proposed method, not a report of a trial or an estimate of Caribbean failure rates.
I developed the S4 AI Safety Framework to make a service’s purpose, tests, safeguards and continuing review inspectable. Its checks are Specify, Stress-test, Safeguard and Scrutinise. The service owner should be able to use the record to explain why a function is available, restricted or withheld.
Established guidance remains relevant. NIST’s AI RMF 1.0 organises risk work through Govern, Map, Measure and Manage. S4 is an educational synthesis drawing on risk management and safety engineering. It adds a practical way to organise the permission decision; completing it does not establish certification or a general guarantee of safety.
Apply S4 to a service people can question
Specify the purpose and the person with authority
For Caribbean AI Association members, educators and public-service teams, a useful specification begins with locally correct information and an evaluation method that another team can reproduce. Describe what counts as an acceptable result and who could be harmed by a mistake. Identify the source that decides the answer when records conflict. Do not approve an open-ended instruction to improve efficiency and leave the operating team to discover its limits.
The authorised task in this example is answering questions from locally approved public-information sources. The prohibited action is transferring personal records between territories or deciding applications through a shared assistant. Write that distinction into the workflow and the permission settings. Name the person who owns the service outcome and the person who can approve a change. They may need different expertise; neither role should be left to a generic team label.
Stress-test the cases that could change your decision
Build the test around territory-specific eligibility rules, language variation, missing source dates, different meanings of the same place name and inaccessible interfaces. Include a straightforward case, a difficult but legitimate request, missing evidence and a deliberately misleading input. Separate the cases used to improve the system from the cases reserved to challenge the revised version. Record the source and expected response before looking at what the model produces.
Ask a knowledgeable reviewer to explain the consequence of each error. An apparently reusable answer can exclude someone when a local rule or language distinction is lost. Decide which failures require the affected function to remain disabled. A small test can expose a problem but cannot establish a rare-event rate, and repeated attempts on the same example are not independent evidence of reliability.
Safeguard the action before it reaches another person
The first enforceable boundary should be territory-specific source access and separate approval for any new data transfer. Check it at the point where the action becomes effective. A warning in a draft does not prevent a connected tool from carrying out the wrong instruction. Verify the limit with an attempted prohibited action in an authorised test environment, and retain the observed result.
Arrange a fallback in which each local service owner provides the established information and review route. Rehearse who notices the problem, who suspends the relevant access and who carries the unfinished work. If the fallback depends on the same unavailable supplier or the same compromised account, it needs another route. Test recovery without interrupting the live service.
Scrutinise outcomes and decide whether use should continue
After release, inspect disagreements between reviewers, language-specific errors, accessibility barriers and unresolved local complaints. Include near misses and corrected drafts as well as completed transactions, because a polished final record may conceal the work needed to repair an unsuitable recommendation. Ask the people handling exceptions which problems the dashboard fails to show. Record disagreements that could affect the decision.
Set a review when the territory, source collection or language coverage changes. Define who can authorise restart and what evidence they need. A scheduled review date does not justify waiting when a serious problem appears earlier. Keep an accessible complaint route and check whether the person raising the issue receives an explanation and a correction.
Make the consequences of delay visible
For a workflow that can commit money, estimate how much direct commitment could accumulate before effective containment. In the simple S4 stress scenario, E = a × t × c: consequential actions per minute, multiplied by minutes until containment, multiplied by the maximum direct commitment per action. The result has currency units. This is a scenario envelope, not an estimate of how frequently harm will occur.
Containment means that further consequential actions have stopped. The clock includes detection, acknowledgement, the intervention itself and any queued work that still executes. Timing only how long it takes someone to press a stop button omits the delay before they notice the problem. Test the whole route with non-sensitive examples and record the conditions under which it was measured.
The scenario assumes a constant rate and the maximum commitment on each action. It excludes recovery and secondary consequences. Those assumptions make it useful for asking whether a permission is too broad, but they do not make it a complete loss model. A disclosure of personal information or an unsafe physical instruction also needs a separate assessment, even when its direct monetary commitment is zero.
A shared, independently enforced cap may reduce the direct commitment envelope. Use the smaller of the scenario envelope and the cap only after checking that all relevant accounts, agents and concurrent requests count towards the same limit. A limit that resets during the containment window needs further modelling. An aggregate cap must prevent excess commitments rather than merely announce them after acceptance.
Keep expected loss separate. Estimating expected direct loss would require a supported harmful-event frequency or probability and a consequence model, with dependence and uncertainty addressed. Do not turn an assumed percentage into a finding about a Caribbean organisation. When the evidence is weak, compare several clearly labelled scenarios and ask which restrictions remain sensible across them.
Imagine a shared service that could approve four US$250 commitments per minute, with six minutes to containment. Its direct envelope would be US$6,000. Separate country limits would not automatically create a US$6,000 regional cap. The teams would need to verify where commitments aggregate and which person can suspend the shared route.
People need a correction route after the AI answer
The organisation should be able to show which controls operate beyond the assistant’s written instructions. A statement asking the model to protect information does not establish which files its identity can retrieve or which tools it can invoke.
OWASP’s prompt-injection guidance describes risks from instructions embedded in external content. A document supplied by a user or partner should not be able to grant itself authority over the service. Limit access in the application and require independent approval where the consequence warrants it.
People also need a usable route after the answer. Provide a reviewer who can inspect the relevant record, correct an error and explain the outcome. Protect personal information when preserving the case. The user’s responsibility to check an answer does not remove the provider’s responsibility for the service it offers, especially when the affected person never chose to interact with AI.
A regional method can still reflect the priorities of the best-resourced participant. Keep space for smaller teams to reject an unsuitable requirement and explain why. Do not interpret fewer reported incidents as stronger safety without understanding reporting access, service volume and whether people trust the complaint process.
Caribbean collaboration should help us test each other’s assumptions while leaving every community with a voice in the decisions that affect it.
Adrian Dunkley, author’s statement
Inspect the decision record for this example
Permitted task: answering questions from locally approved public-information sources.
Excluded action: transferring personal records between territories or deciding applications through a shared assistant.
Who decides: a local service owner and a community-informed reviewer.
Review trigger: a change to the territory, source collection or language coverage. The owner records whether to retain, restrict or suspend the permission.
Publish the boundary before expanding the service
By 10 November 2026, choose one bounded workflow with a local service owner and a community-informed reviewer and document its current permission settings. Ask the person doing the work to identify a decision they would refuse to delegate and explain why. Use that answer to define an exclusion, a test or an escalation condition rather than dismissing it as resistance.
Prepare 12 authorised or synthetic cases: four ordinary requests, four with incomplete or conflicting information and four that challenge the permission boundary. These are suggested trial counts, not a statistical safety threshold. For every case, agree the source of truth, the acceptable action and the condition that requires a hold. Keep a copy of the test material and the configuration used.
Measure checking and correction time, unresolved cases and whether a prohibited action became possible. Conduct one controlled stop-and-fallback rehearsal. Have a colleague who did not build the workflow examine the evidence. If the case exposes an unresolved critical failure, leave that function disabled and record the repair needed before reconsideration.
End the review with a written decision about this workflow and its stated limits. The useful output is a permission decision supported by evidence. Training attendance, an attractive demonstration and a completed form do not answer whether the system should receive additional authority.
Sources and further reading
Independent Caribbean analysis from the Caribbean AI Association. More analysis · Join the association