How to use it. Make one record per use case, not one for a whole vendor. Record the intended purpose, affected people, operating countries, model and data flow. Name the person who can accept residual risk and the person who can stop the system. Apply the controls below before a pilot with real people or data, then revisit the record after a material change. If a fact is unknown, record it as an open risk with an owner and deadline. A blank field is not evidence of a passed control.
1. Governance and scope
Inventory the actual system
The register should cover internally developed models, vendor products, external APIs, fine-tuned systems, embedded AI features and agents with tool access. Each record needs the business purpose, product and model versions where known, developer and deployer, contract holder, API and usage-fee owner, hosting account, integrations, data categories, countries, number of users and people affected, monthly decision volume and the planned retirement route. A vendor’s brand name does not identify the underlying model or subprocessors. Keep a diagram of the path from data source to model, output, human reviewer and downstream action.
Assign a business owner, a technical owner, a privacy or legal contact and an independent risk reviewer. An informal owner who cannot change access, budget or deployment is not enough for a consequential use. The business owner signs a written use boundary: what the system may do, what it may not do, and who may override it. Procurement, IT, security, compliance and affected service teams should have a recorded point of review. Internal audit can test whether this process works, while management retains responsibility for the decision.
Measure exposure and value separately
Estimate exposure from the severity and reversibility of a wrong output, the people and decisions affected, the degree of automation, sensitive data, two-way integrations, external access and country coverage. The organisation should set tolerances for errors, harmful outcomes, complaints, cost overruns and outages. Report both risk and benefit against a baseline: accuracy or service outcomes, staff time, avoided loss, implementation and API costs, customer effects and realised return on investment. A favourable ROI does not offset an unaddressed rights or safety risk. If volumes, benefits or costs are unknown, do not substitute a precise-looking score for evidence.
2. Classification and applicable law
Use two tracks
First, classify operational risk as lower, elevated, high or unacceptable under the Council’s own appetite. High exposure includes automated decisions about access to credit, insurance, health care, employment, education, public services or essential resources; physical safety; sensitive records; or actions that are difficult to reverse. An unsafe or unlawful intended practice should not enter a pilot. Second, perform a separate legal classification in every relevant location. The Council’s tier is a management tool, not a finding under the EU AI Act or any national statute.
For the EU, record whether the system is placed on the market, put into service, used, or has outputs used in the Union, and identify the organisation’s role. Check the current consolidated AI Act, including prohibited practices, Annex III use cases, provider and deployer duties, transparency and general-purpose AI provisions where relevant. Consumer creditworthiness and life or health insurance risk assessment or pricing for natural persons are specifically named in Annex III. Other uses may qualify under other entries or product legislation; a word such as “banking” or “insurance” alone does not settle classification. Legal counsel should verify scope, exceptions, effective dates and any amendments in force at the time of deployment. The GDPR and national privacy law require separate analysis.
For Caribbean use, maintain a jurisdiction register rather than assuming one regional privacy rule. For example, Jamaica’s Data Protection Act has been implemented with an Office of the Information Commissioner, while Barbados has its Data Protection Act, 2019. Those examples do not decide the rules in Trinidad and Tobago, Guyana, the Eastern Caribbean or overseas territories. Record the precise statute, commencement status, regulator, lawful basis, notice, data-subject rights, transfer conditions and any sector or public procurement rule for each location. Do not claim regional or ISO certification merely because a checklist is complete.
Escalation gates
Stop real-data deployment when the operating location, personal-data flows, accountable owner or vendor subprocessors cannot be identified. Require an independent, documented review before a consequential automated action, especially when override and appeal routes are absent. The same applies when a high-impact system has no representative testing, no extreme-case testing or no workable shutdown path. A legal or privacy assessment should be completed where required by law or where potential harm makes one prudent. Record a reasoned decision even when the answer is that a formal statutory assessment is not required.
3. Data, architecture and vendor controls
Trace the information and permissions
Map inputs, prompts, retrieved material, outputs, logs, backups, support access and deletion. Mark personal, financial, health, children’s, confidential and public data separately. Establish where each copy is stored and processed; who may access it; whether it is used to train or improve a vendor model; and how long it remains. A system running in the organisation’s account can still send data to an external model. A “read only” integration can expose sensitive data, while a two-way integration or agent may change records or trigger payments, messages or decisions. Grant the least permissions needed, limit the scope of API credentials, log actions and test revocation.
Before using personal data, the privacy lead should check purpose, legal basis, minimisation, notice, retention, security and relevant impact assessment. Cross-border transfers need a country-by-country assessment and a contract and technical safeguards appropriate to the applicable law. Tokenisation, filtering and redaction may reduce exposure but must be tested; a promise that a prompt contains “no PII” needs evidence. Do not put live records into an unapproved consumer account for a demonstration.
Make the supplier legible
Ask the supplier to identify the base model or model family, version, hosting and support regions, subprocessors, external APIs, training and inference data uses, known limits, change cadence, evaluation evidence and incident route. When the supplier cannot disclose a proprietary component, request equivalent assurance: independent test access, meaningful performance and security evidence, contractual notification of material change, and the right to suspend use. Unknowns remain risk; confidential vendor information is not a reason to mark a control as passed.
The contract should allocate responsibility for privacy, security, model changes, access, record retention, intellectual property and output claims; define data deletion and return; set service and incident notices; identify who pays variable API fees and how usage caps work; and provide an exit path. Test vendor failure, provider outage, model swap, cost spike and acquisition or insolvency scenarios. For a critical use, keep a manual or alternate process and verify that the organisation can export data and explanations. Procurement should reassess the vendor after material changes, not just at renewal.
| Supplier evidence | Question to resolve | Action when unknown |
|---|---|---|
| Model and provider | Which version produces the output, and who may change it? | Hold consequential use or impose independent validation and change notification. |
| Data locations and training use | Where do prompts, records, logs and backups go? | Keep real personal data out until the flow and contract are verified. |
| Integrations and accounts | Can the system read, write or trigger actions; whose keys pay? | Restrict access to a sandbox and set cost limits. |
| Assurance and exit | What was tested locally and how can service continue after failure? | Commission tests and rehearse rollback before launch. |
4. Testing and assurance
Test the local use, not the vendor’s generic demo
Write acceptance criteria before examining the final test set. Compare the AI with the existing process, a simple baseline and a no-AI option. Use representative local data where lawful and feasible. Check dialects, names, locations, income patterns, farm conditions and other features relevant to the actual population; never assume that a foreign benchmark transfers unchanged. Keep training, tuning and final evaluation separate. For small datasets, report uncertainty and avoid claiming subgroup performance from a handful of cases.
Measure error types and their consequences, not one average accuracy number. A false fraud alert and a missed fraud case cause different harms. Record calibration, coverage, abstention, latency, security and cost when relevant. Check performance across groups where lawful, ethically justified and statistically supportable; protect small cells from re-identification. A qualified reviewer should inspect samples of errors, and the test record should say which users and conditions were not covered.
Stress the edge of the system
Extreme-case testing should include rare but plausible values, contradictory or missing records, distribution shifts, disaster or network outages, language variation, adversarial inputs and a chain of dependent failures. For generative models, test unsupported claims, prompt injection, data leakage, unsafe tool calls, fabricated citations and retrieval contamination. For agents, test revoked permissions, repeated actions, retries and runaway costs. A “human in the loop” is only a control if that person has time, evidence, authority and a working way to stop the action. Validate independently on fresh cases before consequential deployment and after a material model, prompt, data or workflow change.
Approval should state the tested boundaries and residual risk. An untested system may still be used in a contained experiment with synthetic data and no consequential output, under an explicit protocol. Do not call that experiment a production validation. Evidence strength should be visible in the report: no evidence, demonstration, limited pilot, representative validation or independent repeated validation.
5. Operation, oversight and incident response
Monitor what can change
Set an owner and cadence for performance, drift, complaints, security alerts, access, cost and vendor changes. Measure the same error and benefit metrics used for approval. Review samples of decisions and overrides, including whether staff routinely accept AI output without independent judgement. Define thresholds that trigger investigation, rollback or suspension. When the model is updated by a vendor, verify whether the earlier evaluation still applies before the new version reaches a consequential workflow.
People affected by a consequential outcome need a usable route to correct data, seek an explanation and challenge the decision where law or policy requires it. The process should say who can reverse an outcome, what records are kept and how long correction takes. Keep communication accessible across relevant languages and service channels. Affected communities should have a way to report harms even when they cannot identify the underlying model.
Prepare for failure
Classify incidents by harm and reach: wrong decisions, privacy exposure, security compromise, hallucinated advice, biased outcomes, service outage and uncontrolled spend. Preserve logs without collecting more personal data than necessary. Assign incident command, vendor contact, regulator or customer notification review, containment, remediation and a post-incident test. Rehearse a stop switch, credential revocation, manual service, vendor failover and restoration from clean data. In a hurricane or regional network outage, the plan must work when a foreign vendor’s normal support path is unavailable.
Reassess after complaints, drift, a material vendor change, a new country, a new population, a new integration or a change from advice to automated action. Retire unused models, credentials and data; document deletion and contractual exit. Report aggregate risk, incidents, realised benefit and open unknowns to the appropriate risk committee. The board should see exceptions and decisions, not only a count of AI projects.
6. Adoption, records and sector application
A phased operating sequence
- Discover. Identify every AI use and supplier, including staff accounts and features embedded in existing software. Assign owners and stop unapproved personal-data sharing.
- Map. Document purpose, population, countries, data, model lineage, permissions, decisions and alternatives. Perform legal and privacy scoping.
- Measure. Estimate exposure and benefits, set acceptance thresholds, test local and extreme cases, and record unresolved unknowns.
- Decide. Independent reviewers record conditions, owner, residual risk and pilot or deployment boundaries. No score alone authorises launch.
- Manage. Monitor, audit, challenge, respond to incidents and reapprove after material change. Retire systems deliberately.
Small organisations can combine roles but should preserve a second review for consequential use. A shared regional test facility or sector association can lower the cost of validation, but each deployer still owns its use, data and decision. Procurement templates and evidence registers can be reused across agencies; local legal conclusions and performance claims cannot be copied between different use cases.
| Sector | Local failure to test | Decision record |
|---|---|---|
| Insurance | Coverage, claims, pricing, fraud false positives and catastrophe-driven shifts. | Human review, policyholder remedy, model and vendor evidence. |
| Banking and investment | Credit exclusion, account freezes, suitability, market loss and AML alerts. | Validation, appeal, exposure limits and recorded accountable officer. |
| Agriculture | Crop or livestock advice under sparse observations, drought and storm conditions. | Field validation, uncertainty, local extension review and fallback. |
| Health, education and public service | Safety, eligibility, vulnerable groups, language and service denial. | Qualified professional authority, privacy review and contest route. |
Evidence pack and review cadence
Keep the register, data-flow diagram, law and role analysis, vendor due diligence, signed contract, model and system card, test plan and results, impact and privacy assessments, security review, cost and benefit baseline, incident and rollback plan, approval, change history and monitoring reports together. Link each claim to its evidence and version. An “unknown” has an owner and due date; it does not disappear because a supplier provided a brochure. Review higher-exposure systems at least after each material change and on a risk-based schedule set by the organisation. Avoid prescribing one annual interval for every system.
Consistency check before sign-off: the country list matches data locations and affected people; the model type matches the vendor and testing evidence; the integration permissions match the human-oversight claim; the claimed benefits have a baseline and total cost; the residual risk statement matches the unresolved unknowns. Record departures from these guidelines with a reason and approving authority.
Sources, mapping and reuse
This guidance is an original synthesis. The Council’s proposed controls map NIST’s Govern, Map, Measure and Manage functions to a Caribbean deployment record; use UNESCO’s impact and human-rights lens; use ISO/IEC 42001 as a management-system reference without reproducing its copyrighted clauses; and use the EU AI Act and local statutes as legal questions requiring jurisdiction-specific interpretation. The Council’s consultation standard remains a separate draft. The source links below identify the versions reviewed on 26 October 2026.
- NIST AI Risk Management Framework 1.0 and AI RMF Playbook, Manage.
- NIST AI 600-1 Generative AI Profile.
- Regulation (EU) 2024/1689, consolidated 27 July 2026, especially scope, classification, Annex III and relevant provider/deployer duties; Regulation (EU) 2016/679 (GDPR).
- UNESCO Recommendation on the Ethics of Artificial Intelligence (2021) and Caribbean Artificial Intelligence Policy Roadmap.
- ISO/IEC 42001:2023 public overview. The full ISO standard is copyrighted and is not reproduced here.
- Jamaica Office of the Information Commissioner overview and Barbados Data Protection Act, 2019.
- CAIRMC Caribbean AI Risk Management Standard, February 2026 consultation draft.
Rights and attribution. © 2026 Caribbean AI Risk Management Council, a council of the Caribbean AI Association. You may link to this page and quote short extracts with attribution. Requests to reproduce substantial portions should go to the Council. Names of NIST, ISO, UNESCO, EU institutions and local authorities identify source material; they do not imply endorsement. No ISO normative text or third-party images are reproduced.