AI Risk Domains
AI Risk Domains For Regulated AI Systems
Classify AI risks, identify evidence gaps, and map each risk to controls, owners, escalation paths, and reviewable records.
AI Risk Register View
Evidence Gap ScanThe risk question
AI Risk Is An Evidence Problem
The central AI risk question is not only whether a model performs well. In regulated environments, the question is whether the organization can reconstruct how the system was governed, reviewed, escalated, and controlled.
Risk taxonomy
AI Risk Domain Matrix
This matrix separates AI risk domains from the evidence needed to govern them. The goal is not generic risk awareness. The goal is control mapping and reviewable documentation.
| Risk Domain | What Can Go Wrong | Control Implication | Evidence Needed |
|---|---|---|---|
|
Vendor Vendor AI Risk |
Vendor claims cannot be verified, model limitations are unclear, or change notices are incomplete. | Require documentation, testing evidence, contractual controls, monitoring, and periodic review. | Vendor questionnaire, SOC report, model documentation, testing summary, issue log, change record. |
|
Oversight Human Oversight Risk |
Human review exists on paper but reviewers lack authority, context, escalation paths, or decision records. | Define reviewer authority, escalation triggers, override conditions, and decision documentation standards. | Reviewer notes, decision rationale, escalation log, override record, approval trail. |
|
Financial Crimes AML / Financial Crimes AI |
Alerts lack explainability, escalation logic is inconsistent, or reviewer disposition cannot be reconstructed. | Require reviewable rationale, case handling standards, escalation rules, and quality review. | Alert disposition, case notes, escalation rationale, quality review, exception record. |
|
LLM LLM / RAG Risk |
Outputs fabricate, leak data, retrieve unsupported content, bypass access boundaries, or create unreviewed advice. | Apply access controls, retrieval testing, prompt/output monitoring, human review, and logging. | Prompt logs, retrieval tests, access review, output review notes, incident record. |
|
Model Risk Model Risk Support |
Limitations, monitoring, assumptions, performance changes, or validation dependencies are not documented. | Prepare validation-readiness artifacts, monitoring records, limitation registers, and issue tracking. | Limitation register, monitoring summary, issue log, test evidence, approval record. |
|
Data Data and Input Risk |
Data lineage, quality, permission, sensitivity, access, or drift is not controlled or documented. | Map data governance controls to AI use, access boundaries, lineage, retention, and quality checks. | Data lineage record, access review, quality checks, sensitivity review, retention evidence. |
Evidence gap severity
Risk Signals
InfoSecured.ai treats weak evidence as a risk signal. A control that cannot be evidenced is not ready for audit, governance review, or serious challenge.
- Policy exists and is mapped to the AI use case.
- Control owner is assigned.
- Review records are retained.
- Escalation path is documented.
- Control exists but review records are incomplete.
- Vendor documentation is partial.
- Human review criteria are unclear.
- Exceptions are tracked inconsistently.
- No accountable owner is assigned.
- No retained evidence proves the control operated.
- Human review cannot be reconstructed.
- Vendor claims cannot be verified.
Control mapping logic
From Risk To Evidence
Practical artifact
AI Risk Register Starter Kit
A template set for documenting AI risk in a way that supports governance review, vendor diligence, control mapping, human oversight, and audit readiness.
- AI Use Case Inventory
- Risk Domain Taxonomy
- Risk-to-Control Map
- Control Owner Register
- Human Oversight Checklist
- Vendor AI Risk Questionnaire
- Evidence Register Fields
- Escalation and Exception Log
- Model Change Review Notes
- Audit-Readiness Gap List
Prototype proof-of-work
GridLock GRC Connection
GridLock GRC is the prototype layer that turns this risk taxonomy into structured evidence: use case, risk domain, failure mode, control, owner, evidence artifact, exception, and review status.
The purpose is to make AI risk reviewable. Broad AI risk language becomes a traceable register that can be inspected, challenged, improved, and mapped to governance workflows.
Build An AI Risk Register That Produces Evidence
Map AI risks into controls, owners, evidence records, vendor documentation, human oversight notes, and audit-ready review status.