AI Jamaica / AI Safety and Alignment / Jamaica
AI Safety in Jamaica: Check the Claim Before It Becomes a Decision
A Jamaican organisation should test the decision its AI service influences, including the source, the permissions and the correction route. A fluent summary can still omit the detail that determines how a customer is treated. Start with the person affected and the evidence the reviewer needs.
I apply my S4 AI Safety Framework to a hypothetical motor-insurance service workflow. The example is educational and does not describe a deployment at a named insurer. Specify, Stress-test, Safeguard and Scrutinise help separate useful document assistance from authority over a claim.
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
A claims summary must preserve what the reviewer needs to decide
Imagine a customer in Jamaica submitting documents after a collision. An assistant extracts the dates, identifies missing information and prepares a summary for staff. If it treats an uncertain date as established, the reviewer may begin from the wrong account. The harm can arise through influence even when the software has no payment permission.
The team should preserve the difference between the customer’s statement, a document entry and a conclusion reached by the reviewer. Link each consequential item to the original record and flag a conflict rather than silently selecting the most convenient version. A customer should have a way to correct a factual error without having to argue with the assistant’s confident wording.
Test questions as Jamaican customers actually ask them, including local place names, incomplete descriptions and changes in register. Do not treat dialect as evidence that a claim is suspicious or less credible. Ask reviewers familiar with the service context to assess meaning and consequence. Keep the original wording available where necessary and permitted so a standardised summary does not erase an important detail.
For a motor-insurance example, deciding which questions require professional judgement belongs to the authorised process owner. The assistant can help prepare the file without establishing coverage or liability. The evidence needed to summarise a record differs from the evidence needed to decide the customer’s outcome. Keep that distinction visible in the interface and the operating procedure.
Ask the claims reviewer to inspect a case in which the customer’s statement and an uploaded form give different dates. The assistant should show both sources and the unresolved conflict. It should not decide that the cleaner-looking document is more credible. The authorised reviewer needs to determine which clarification is required and how to obtain it fairly.
The same care applies to missing information. A document absent from the assistant’s search results may still exist elsewhere in the authorised file. Distinguish not found by the system from not supplied by the customer. That wording can affect the next contact and the way staff understand responsibility for a delay.
Check whether the customer-facing explanation preserves the basis of the decision. A person disputing a factual error should be directed to a reviewer who can inspect the source and correct the record. The assistant should not repeatedly restate the original conclusion as if consistency were evidence.
For a supervised trial, compare the preparation and checking time with the established process on cases of similar difficulty. Preserve unresolved cases in the comparison. Excluding every case that needed a correction would make the service appear easier to operate while hiding precisely the work that determines its usefulness and risk.
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 Jamaican frontline teams, managers and customers, a useful specification begins with a Jamaican customer receiving a review based on accurate, contestable 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 extracting source-linked information and flagging missing or conflicting documents. The prohibited action is rejecting a claim, deciding liability or changing customer entitlement. 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 conflicting collision dates, uncertain place names, dialect variation, missing evidence and an instruction embedded in an attachment. 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. A factual error can delay a claim or influence how staff interpret the customer’s account. 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 source-linked summaries with separate professional review and no settlement authority. 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 claims reviewer examines the original file and uses the established customer contact process. 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 misstated facts, missing sources, reviewer corrections, unresolved customer disputes and delay caused by the assistant. 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 policy source, document extractor or decision 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.
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.
As a separate hypothetical payment scenario, four commitments per minute at J$25,000 each over a six-minute containment interval produce a J$600,000 envelope. A claims-summary assistant should not receive payment authority merely because this calculation is available. The permissions must follow the task and evidence, with non-financial consequences assessed separately.
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 summary can make a complicated case look simpler than it is. The unresolved challenge is ensuring reviewers still see uncertainty when queues are busy. Sample difficult and disputed files during monitoring, and ask whether staff had the information and time needed to challenge the summary before it influenced a decision.
A Jamaican customer should be able to correct a fact before that fact becomes a decision about them.
Adrian Dunkley, author’s statement
Inspect the decision record for this example
Permitted task: extracting source-linked information and flagging missing or conflicting documents.
Excluded action: rejecting a claim, deciding liability or changing customer entitlement.
Who decides: the claims process owner and an experienced customer-facing reviewer.
Review trigger: a change to the policy source, document extractor or decision authority. 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 the claims process owner and an experienced customer-facing 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.