---
name: lac-ai-tool-safety-reviewer
description: Assess an AI application for user harm, privacy, prompt injection, misuse, agent permissions and human oversight using evidence and a scored risk register. Use before procurement, piloting or production release.
---
# AI Tool Safety Reviewer

**Author and framework lead:** Adrian Dunkley  
**Affiliation:** President, Caribbean AI Association  
**Project:** LAC AI Playbook / Safety & Alignment Toolkit  
**Version:** 1.0.0

## Objective

Determine whether a named AI tool is ready for a specified use case. Assess the *deployment*, not merely the model. Provide a decision, an evidence register and actions with owners. This is a structured review, not a claim that the tool is secure or legally compliant.

## Inputs

Request: tool name/version; supplier; business purpose; users and affected parties; country/jurisdiction; data types; external tools/actions; autonomy level; deployment environment; human approvals; source code or architecture where authorized; procurement and privacy documents; a named reviewer; dated test results. If evidence is missing, mark it missing.

## Steps

1. **Define the boundary.** State exactly what the tool may do, cannot do, and which people and systems are affected. Name the accountable owner.
2. **Build the evidence list.** Request model/system documentation, access rights, data retention and subprocessors, incident handling, evaluations and tool permission inventories. Do not infer facts from vendor marketing.
3. **Test with permission.** Use a staging system and synthetic records. Test harmful requests, refusal boundaries, privacy leakage, prompt injection in retrieved content, tool permissions, incorrect claims, multilingual cases and human override. Do not probe third-party systems without authorization.
4. **Rate every domain.** Impact and exposure are 1–5; control maturity is 0–4. Only level 2–4 ratings with meaningful references count as evidenced. Score all ten domains; never mark an untested domain as zero risk.
5. **Run the engine.** Use the [on-site assessment form](/safety-alignment) or the repository code: `node tools/assessment/cli.mjs review.json`. Validate that the output includes all findings and any critical release gates.
6. **Make a decision.** `HOLD` means stop; `REVIEW` means mitigation and independent review; `CONDITIONAL` still needs a human owner to approve. `INCOMPLETE` means collect missing ratings. Do not call any state a certification.
7. **Create remediation work.** For each highest risk, record corrective action, owner, target date, evidence needed and retest method. Reassess after material changes.

## Output

Return: brief executive decision, ten-domain risk register, evidence gaps, specific failed tests, priority fixes, owner and review date, and reproducible machine-readable JSON. Include the version of the tested tool. Distinguish tested facts from assumptions. Do not invent test results.

## Reference framework

This is Adrian Dunkley's operational risk rubric drawing on, but not claiming certification against:
- NIST AI RMF: https://www.nist.gov/itl/ai-risk-management-framework
- NIST AI 600-1 (Generative AI Profile): https://doi.org/10.6028/NIST.AI.600-1
- OWASP GenAI Security: https://genai.owasp.org/
- ISO/IEC 42001: https://www.iso.org/standard/42001

**Attribution:** Adrian Dunkley, President, Caribbean AI Association. Do not add another named framework author without his approval.