AI Playbook LAC / AI Safety and Alignment / Caribbean and Latin America
A Small-Business AI Safety Play Using the S4 Framework
Editorial review: . Original publication date retained.
Start an AI trial with one business task, one accountable owner and a clear boundary around what the software may change. Measure the work needed to check the output as well as the work the assistant prepares. The first decision is whether a limited use helps your business under conditions you can maintain.
This playbook article applies my S4 AI Safety Framework to a small-business stock-reorder assistant. Specify, Stress-test, Safeguard and Scrutinise organise the questions an owner should answer before allowing the assistant to act. The example is a proposed practice exercise, not a measured result for a business in the region.
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 reorder suggestion must preserve the owner’s constraints
Imagine a small retailer using an assistant to prepare a reorder list. The file shows current stock, pending orders and an estimated delivery date. A hypothetical assistant treats pending stock as already available and recommends too little. A different error could recommend an order that exceeds the owner’s cash limit. Both failures begin with misunderstanding the task’s evidence or constraints.
Specify what each field means before asking for a recommendation. Stock on hand, stock reserved for a customer and stock expected from a supplier should remain separate. If the business does not maintain these records reliably, the first improvement may be a simpler recording process. AI cannot create evidence of a delivery that has not been confirmed.
The owner should also identify which decision remains personal. A retailer may accept the risk of a temporary stock gap while refusing an additional cash commitment. Another business may give priority to an item that a customer depends on. Record the reason for the constraint rather than allowing the assistant to optimise an unstated objective such as maximising sales.
For Caribbean and Latin American users, retain the local currency, supplier terms and operating context. An imported example can illustrate a method without establishing suitable prices, delivery conditions or obligations for another business. Where language changes, have a competent reader check the meaning of consequential terms before using the output with a supplier or customer.
A practical trial can use a synthetic stock sheet with one overdue order, one reserved item and one incorrect unit. Ask the assistant to identify the uncertainty and prepare a draft list. The expected answer should show which inputs support the suggestion and which need confirmation. Do not reward the most complete-looking list if it fills the gaps by guessing.
Keep purchasing access disabled during the first trial. The owner can review the suggestion and place an order through the established route. If a later version proposes connected purchasing, treat that as a new permission request with its own evidence and limits. It should not arrive as an unnoticed convenience feature.
The playbook’s AI tool assessment can organise the intended use, evidence and control questions. Use it to find what is missing, and retain the source references needed to explain the judgement. An assessment score does not establish a probability of harm or prove that the business should expand the assistant’s authority. Treat it as a structured screening aid. This article supplies no independent validation of that score, security certification or assurance of regulatory compliance.
At the end of the trial, compare preparation, checking and correction time with the established method. Keep the owner’s unresolved decisions in the result. A tool can be useful for organising evidence even when the owner decides to retain all ordering authority. The outcome should follow the business’s need rather than an assumption that more autonomy is always the next step.
Use S4 to connect purpose, evidence and permission
AI safety asks what harm a system could cause and how you can prevent, detect or contain it. Alignment asks whether its behaviour serves the intended purpose within the human constraints agreed for that use. A system can follow a poorly chosen objective and still harm the people it was meant to help. A fluent answer alone establishes neither safety nor alignment.
Consider a hypothetical service assistant assessed only on how quickly it closes enquiries. It could improve that measure by ending difficult conversations early. The dashboard would show progress while some people receive less help. The corrective work starts with the objective, the evidence of a resolved problem and the route for an unresolved case. Polishing the response does not settle those choices.
This distinction connects with Amodei and colleagues’ research on concrete AI safety problems, which separates difficulties involving objectives, supervision and unfamiliar conditions. Here I apply that distinction to everyday decisions about authority. This article offers a proposed working method and illustrative cases. It does not report a trial of these organisations or a measured regional failure rate.
My S4 AI Safety Framework brings four checks into the decision about what an AI system may do: Specify, Stress-test, Safeguard and Scrutinise. I developed it as an educational synthesis drawing on risk management and safety engineering. Each check should leave evidence that someone else can inspect, challenge and use to change the deployment.
S4 sits alongside established guidance. NIST’s AI Risk Management Framework 1.0 uses Govern, Map, Measure and Manage. S4 is an author-developed educational framework; this article does not establish that it has been independently validated. Using either framework does not by itself certify a system as safe or compliant. S4’s narrower practical question is whether the evidence supports the permission being requested for a particular workflow. The answer can be a restricted trial, continued assistance, a redesign or a decision to stop.
Apply S4 to the work you are about to approve
Specify the purpose and the person with authority
For micro and small-business owners in the Caribbean and Latin America, a useful specification begins with a stock decision the owner can verify against availability, commitments and cash constraints. 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 reorder suggestion from the authorised stock and supplier records. The prohibited action is placing an order, spending beyond the cash limit or treating an unconfirmed delivery as received. 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 reserved stock, overdue orders, mixed item units, uncertain supplier dates and a proposed order beyond the cash limit. 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 wrong suggestion can create a stock gap or a cash commitment the owner did not intend to accept. 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 draft-only recommendations and owner-controlled purchasing access. 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 owner checks the authorised stock records and places any order through the existing 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 incorrect units, unsupported deliveries, draft corrections, checking time and decisions deferred for clarification. 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 stock-record definition, supplier terms or purchasing permission 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.
Put numbers on the permission boundary
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. An observed average rate does not bound bursts, retries or simultaneous agents. For indivisible purchases, model a supported maximum count of commitments during the containment window rather than treating a fractional action as a spending limit. This scenario 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.
In a hypothetical purchasing trial, five commitments per minute at US$120 each over four minutes create a US$2,400 direct envelope. Replace the currency and assumptions only with values supported by your own proposed workflow. The model does not forecast sales, margin, customer demand or a suitable stock level.
Make permissions enforceable and review workable
An instruction such as “do not share private information” expresses a rule. Access controls determine whether the software can retrieve and transmit that information. Both matter, but they perform different jobs. Put consequential permissions in application code, identity settings and approval processes that the model cannot rewrite merely by producing different text.
OWASP describes indirect prompt injection as a risk when instructions arrive through external material such as files or webpages. A supplier attachment can contain words directed at an assistant rather than information intended for the task. Treat that material as untrusted input and prevent it from granting itself authority to send, spend or change records.
Review should show the person what will happen, to whom, using which records and with what consequences. An approval label without the underlying action details makes it difficult to challenge a mistake. For higher-impact decisions, require someone who can assess the substance and has enough time to refuse. Record both the original recommendation and the authorised correction where retention is justified.
Personal responsibility therefore needs institutional support. Staff need approved tools, clear limits, access to a competent reviewer and permission to report uncertainty without being punished for slowing a queue. Leaders remain responsible for the targets, permissions and working conditions they approve. Affected people need a workable correction route, including when they did not choose to use AI themselves.
The weakest assumption may be the stock record itself. Preserve that uncertainty in the recommendation and decide who can confirm it. If the business cannot maintain the information needed for the trial, simplify the task before giving the assistant a broader role.
A useful AI play should help the owner make a better decision within the business’s limits, including the decision to keep authority with a person.
Adrian Dunkley, author’s statement
Inspect the decision record for this example
Permitted task: preparing a reorder suggestion from the authorised stock and supplier records.
Excluded action: placing an order, spending beyond the cash limit or treating an unconfirmed delivery as received.
Who decides: the business owner and a colleague or adviser who understands the stock process.
Review trigger: a change to the stock-record definition, supplier terms or purchasing permission. The owner records whether to retain, restrict or suspend the permission.
Test one workflow before granting more authority
At your next review, choose one bounded workflow with the business owner and a colleague or adviser who understands the stock process 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. Record which actions may proceed, which remain disabled and who will check the next change. Training attendance and a completed form alone do not establish whether the system should receive additional authority.