Adrian Dunkley / AI Safety and Alignment / Caribbean
AI Safety in the Caribbean Starts With What You Approve
If you use AI to prepare advice, approve a document or influence a decision, start by deciding what remains your responsibility. Check the evidence behind the output, the authority you are giving the software and the people who could bear the cost of an error. That is the practical starting point for AI safety and alignment in the Caribbean.
I developed the S4 AI Safety Framework to make those choices explicit. Its four checks are Specify, Stress-test, Safeguard and Scrutinise. My argument is that accepting a useful answer and authorising an action require different evidence. You can benefit from assistance while keeping the consequential decision with a person who can explain it.
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
Your signature still needs an explanation
Imagine a Caribbean executive receiving a board paper drafted with AI. In this illustrative example, the financial table is accurate, but a paragraph describes a proposed project as approved. Signing the paper could change what directors believe they have authorised. Checking the arithmetic alone would miss the error because the problem sits in the status of the decision.
The executive should identify the minute, approval or instruction that supports each consequential statement. Where that record is absent, the document should state what remains proposed. A useful assistant can organise the evidence and expose the gap. It should not fill the gap with an assertion that sounds reasonable. The person submitting the paper must understand the distinction well enough to defend it.
Personal responsibility also means recognising the limit of your competence. If an AI tool gives you a specialist answer that you cannot assess, confidence in the prose is a poor reason to sign it. Seek a reviewer who understands the decision, reduce the task to something you can verify or retain the established process. The appropriate response depends on the consequence of being wrong.
For Caribbean leaders, I would make the responsibility visible in the work itself. Record who checked the source, who challenged the recommendation and who authorised the next action. Do not turn that record into a ritual in which the same person fills every role. Where a small team needs external expertise, include its cost in the decision to adopt the tool.
I would separate three questions in the board-paper review: what is supported by the record, what I recommend and what I have authority to authorise. The assistant may help with each preparation task, but the distinction has to survive into the final paper. A recommendation should not become a statement of fact because the draft needs a shorter sentence.
My responsibility also extends to the assumptions I pass on. If I accept a cost estimate without checking its currency, period and included work, another person may build a decision on it. Preserve the assumptions that could change the recommendation and name who can verify them. The paper can remain concise while making those dependencies visible.
There is a practical test for whether the review has worked. Ask a colleague to take one consequential sentence and find the supporting record without help from the author. Then ask what action the sentence permits. A disagreement can reveal a missing source, ambiguous wording or a disputed decision right. Each requires a different repair.
That test should include the version that actually reaches the decision-maker. A corrected draft is insufficient if an earlier attachment remains in circulation or a summary page repeats the old assertion. Record the version approved, replace the circulating copy where possible and tell the relevant recipient what changed when the correction affects their understanding.
Responsibility starts with the objective
I use safety to ask how a system could harm someone, including when it follows the instruction I gave it. I use alignment to ask whether its behaviour serves the intended purpose within the constraints agreed for that use. Choosing the objective is part of my responsibility; a fluent answer cannot decide whose interests deserve protection.
An illustrative customer-service assistant rewarded only for closing enquiries could improve its metric by ending difficult conversations early. I would want evidence that the person received help, not merely that the conversation ended. Amodei and colleagues’ safety research distinguishes problems involving objectives, supervision and unfamiliar conditions. I apply that distinction here to decisions about delegated authority.
I developed the S4 AI Safety Framework as an educational synthesis drawing on risk management and safety engineering. Its four checks leave a record of purpose, challenge, controls and review. They support a bounded decision rather than a permanent declaration that a system is safe.
NIST’s AI RMF 1.0 uses Govern, Map, Measure and Manage. I am not claiming to replace those functions. S4 focuses on whether the evidence supports the particular permission I am being asked to give.
How I would use S4 to decide what to delegate
Specify the purpose and the person with authority
For Caribbean professionals and leaders, a useful specification begins with a decision the responsible person can explain using the underlying records. 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 preparing a source-linked recommendation for a named decision owner. The prohibited action is claiming an approval or issuing an instruction that the owner has not authorised. 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 a proposed decision described as final, an outdated board minute, conflicting figures and a persuasive but unsupported recommendation. 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 incorrect statement about authority can change another person’s actions even when no money moves immediately. 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 a draft-only workspace with separately controlled signing and sending permissions. 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 the decision owner uses the original records and an agreed human 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 unsupported assertions, review time, corrections after circulation and whether colleagues can challenge the recommendation. 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 decision purpose, source record or sign-off authority 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.
Estimate what could happen before you intervene
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.
Suppose, purely for illustration, an assistant can authorise six commitments a minute at US$200 each, and effective containment takes five minutes. The direct commitment envelope is 6 × 5 × US$200 = US$6,000. If the assistant has drafting permission only, that particular commitment route is absent, although disclosure and misleading advice still need controls.
Your judgement needs support from the organisation
A prompt can express a boundary; I also need to know what the connected software can actually do. If the application identity can retrieve confidential records and send them elsewhere, a sentence asking it to be careful leaves an important part of the control unresolved.
OWASP describes indirect prompt injection through external material such as files and webpages. An incoming attachment is evidence for the task, not a source of authority to change the assistant’s job. I would test whether the application preserves that boundary when the document contains an instruction directed at the model.
My review also needs the action details: the recipient, source record, proposed change and consequence. I cannot assess a vague request to approve something without seeing what approval permits. The organisation must provide the time, competence and access needed for that review. Responsibility remains shared across the person using the tool and the leaders who approve its targets and permissions.
My approach is weakest where the organisation has not agreed whose interests should govern the objective. A technically careful system cannot resolve that disagreement for us. A board, public agency or employer must make the decision openly enough that affected people can challenge it. The record should preserve the disagreement and identify what would change the decision.
Before I accept an AI recommendation, I need to know what supports it and what my approval will allow someone else to do.
Adrian Dunkley, author’s statement
Inspect the decision record for this example
Permitted task: preparing a source-linked recommendation for a named decision owner.
Excluded action: claiming an approval or issuing an instruction that the owner has not authorised.
Who decides: the person whose signature gives the document effect.
Review trigger: a change to the decision purpose, source record or sign-off authority. The owner records whether to retain, restrict or suspend the permission.
Choose one decision to examine this week
By 10 November 2026, choose one bounded workflow with the person whose signature gives the document effect 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.