AI governance: establish responsibility before deployment
Created by Adrian Dunkley, MaestrosAI. Governance means deciding who may use a system, for which work, with which information, and who can stop it. A policy becomes useful when those decisions are reflected in permissions, review steps and records.
This guide is a planning aid for Caribbean and Latin American organisations, not a country-by-country legal opinion. A model provider’s availability, a paid subscription or a human approval button does not establish lawful or safe use.
Start with the actual workflow
Write down the task before choosing a framework. For a guesthouse, drafting an answer from an approved amenities list differs from confirming a reservation or charging a guest. For a lender, indexing synthetic documents differs from assessing a real applicant. Record these distinctions explicitly.
| Record | Questions to resolve |
|---|---|
| Purpose | What task is proposed? Could a simpler non-AI process do it? |
| People | Who uses the output, who is affected, and who can challenge an error? |
| Information | What enters the system, where does it go, and what must stay out? |
| Actions | Can it only draft, or can it send, modify records, spend or operate equipment? |
| Ownership | Who checks outputs, approves changes, handles incidents and can stop use? |
| Evidence | What tests, source documents and reviews support the intended scope? |
Use fictional or approved non-sensitive material for the first trial. Removing names alone does not make a record safe or authorised to upload.
Separate law, guidance and internal choices
A statute, a bill, a regulator’s guidance, a voluntary framework and your own policy are different kinds of documents. Do not label a proposal as enacted law or infer an organisation’s obligations from a regional table.
For each relevant requirement, keep:
- The exact issuer, document title, official URL and version.
- Publication and effective dates, including any transition provisions.
- The jurisdiction, sector, activity and people to which it may apply.
- The section supporting the requirement and any unresolved interpretation.
- The qualified person who confirmed applicability and the next review date.
An AI summary may help locate passages, but the responsible person must check the original. Do not let a model invent legal bases, reporting deadlines, transfer mechanisms or exemptions.
A small source register, not a regional legal map
These official starting points illustrate how to find primary material. They are not a complete list of applicable authorities or rules.
- Jamaica’s Office of the Information Commissioner: data-protection standards. Consult the underlying law and current guidance for the actual processing activity.
- Brazil’s ANPD: incident communication. Check the current requirements rather than applying another country’s deadline.
- Chile’s official text of Law 21.719. Check the version and transitional provisions. A future-effective provision is not automatically an obligation already in force.
- NIST AI Risk Management Framework. This voluntary framework organises work around Govern, Map, Measure and Manage; it is not a compliance certificate.
- UNESCO Recommendation on the Ethics of Artificial Intelligence. This provides an ethical reference centred on human rights; citing it does not prove compliance with national law.
Do not assume that a lack of a dedicated AI statute means no law applies. Data protection, consumer protection, employment, professional, sector and contractual requirements may need separate review. Nor does a rule in one Caribbean jurisdiction establish the rule in another.
Assign decisions to people who can make them
Name an owner for the workflow and a reviewer with the time, knowledge and authority to reject an output. A person who merely clicks approve without checking evidence is not an effective control.
Keep consequential decisions about treatment, credit, employment, public benefits and legal rights out of a general chatbot pilot. A proposed specialist system needs its own legal, domain, security and affected-person review. Human involvement does not excuse a poorly justified system.
Before external use, resolve access to a human, correction of errors, complaints, accessibility, language support and a manual fallback. Do not present residency, tax or licence advice as a low-risk FAQ simply because it appears in a chat window.
Review vendors and data flows
Ask for terms covering the exact product and account: processing purposes, model training, retention, deletion, subprocessors, access, security controls and incident support. Establish what evidence is available and what remains a contractual promise.
A server location alone does not settle applicable law or cross-border transfer duties. Local hosting still requires access control, patching, backups, logging and privacy review. Enterprise branding or a certification must be examined for its scope and date; neither proves that your proposed workflow is appropriate.
Make a launch decision, not a checklist score
Document the scope allowed, evidence reviewed, unresolved risks, approver and conditions for stopping. Missing permission to use data, uncontrolled actions, unverified high-impact outputs or an inability to respond to harm can block launch. Do not treat every unanswered question as something to fix after deployment.
A limited internal trial may be reasonable when its data, access and consequences are controlled. Expanding to real users or live actions is a new decision. Reassess after a model, vendor, data source, purpose or permission changes.
Related work
Primary references checked on 11 November 2026 for the limited functions described. No prediction of pending legislation or comprehensive legal comparison is made.
Adrian Dunkley | MaestrosAI | maestroailabs.com | ceo@maestrosai.com. Educational guidance, not legal advice.