# AI System Card: AML alert triage agent (completed synthetic example)

**Version:** 1.0
**Last updated:** 2026-10-12
**Blank template:** [AI system card template](/downloads/eu-ai-act-ai-system-card-template.md)

> **Synthetic example.** Northwind Bank, its people, systems, versions, and dates are fictional. The agent design follows the AML alert-triage agent template in KLA's demo tenant. This is not legal advice, and it does not describe any real deployment.

## 1) Identification

- **System name:** AML alert triage agent
- **Product / service:** Transaction-monitoring alert review, financial crime operations
- **System owner:** Head of financial crime operations
- **Responsible team:** Financial crime technology
- **Primary stakeholders:** MLRO, compliance, model risk, data protection officer
- **Release / version:** 2.4
- **Environment(s):** prod (EU region)
- **Geography:** EU

## 2) Role and purpose

- **We are a:** Deployer. The bank builds the agent on a general-purpose model supplied by a third-party provider.
- **What the system does:** Reads each transaction-monitoring alert, gathers KYC, sanctions, PEP, and transaction signals through governed tools, and drafts a review packet with a recommended disposition, a confidence score, a rationale, and evidence references.
- **Intended purpose:** Help level-1 analysts triage alerts faster and with complete evidence.
- **Decisions the system may propose:** A disposition of `low`, `medium`, `high`, `blocked`, or `needs_review`, and the next action for the reviewer.
- **Decisions the system never makes:** It never files a SAR, never contacts the customer, never closes a case, and never approves or releases a case.
- **Users:** Internal (financial crime analysts and reviewers)
- **Who can trigger the system:** The alert queue, for each new alert

## 3) Component models

| Component | Model or engine | Version pinned | Model card or source | Evaluated scope | Known limits |
| --- | --- | --- | --- | --- | --- |
| Primary model | General-purpose LLM from a third-party provider | Provider version ID pinned per release | Provider model card | English and French alert text; triage tasks in the bank's test set | Can state conclusions with more confidence than the evidence supports; output must cite evidence |
| Prompt-injection detector | Open-source classifier | v0.0.1 | Project model card | English, single-turn input up to 128 tokens | Longer or multi-turn input is outside its evaluated scope |
| Sensitive-data recognizer | Rule and NLP-based recognizer with an allowlist | Package versions pinned | Package documentation | English AML and payment text | Other languages untested |

## 4) Tool permissions

| Tool | Access | Policy outcome | Approver (if any) | Notes |
| --- | --- | --- | --- | --- |
| `alerts.read` | read | allow | none | One alert and its case context |
| `customer_kyc.read` | read | allow | none | Profile, KYC status, risk rating, UBO summary |
| `sanctions_pep.screen` | read | allow | none | Sanctions, PEP, and adverse-media matches |
| `transactions.summarize` | read | allow | none | Aggregates only, no raw statement export |
| `counterparty_graph.lookup` | read | allow | none | Related parties and shared owners |
| `evidence.retrieve` | read | allow | none | Evidence items by class |
| `case_packet.draft` | draft | allow | none | Draft packet; the reviewer sees it before any decision |
| `case_note.draft` | draft | allow | none | Investigation notes |
| `decision_request.create` | write | require_approval | AML level-1 reviewers | Sends the case to Decision Desk; a reviewer confirms the route matches the evidence |

- **Actions with no tool:** SAR filing, customer messaging, case closure, payment release. The agent cannot perform them.
- **Who can change tool permissions:** The system owner proposes; a second person approves the policy change before it is published.

## 5) Data flows

| Flow | Source | Data categories | Destination | Retention | Personal data? |
| --- | --- | --- | --- | --- | --- |
| Alert input | Transaction-monitoring system | Alert ID, customer ID, alert type, summary, transactions, KYC snapshot, screening matches | Agent | Per case retention | yes |
| Tool reads | Core banking, KYC, screening | Fields returned by each tool above | Agent | Not stored beyond the execution record | yes |
| Model calls | Agent | Prompt with alert context | Model provider (EU region endpoint) | Provider retention per contract | yes |
| Recommendation | Agent | Disposition, confidence, recommended action, rationale, evidence references | Decision Desk and execution record | Per case retention | yes |
| Human decision | Reviewer | Decision, reason, time, reviewer identity | Execution record and evidence export | Per case retention | yes |

- **Data the system must not receive:** Data from closed SAR files, health data.

## 6) Risk tier orientation (estimate)

- **Potential prohibited elements (Article 5)?:** no
- **Potential Annex III high-risk use case?:** no. AML alert triage is outside Annex III points 5(b) and 5(c).
- **Transparency duty likely (Article 50)?:** no. The system does not interact with customers.
- **Classification rationale:** Internal decision support for analysts; a human decides every routed case.
- **Approved by:** Chief compliance officer, before release 2.0

## 7) Approval owner and human oversight

- **Approval owner for the system:** Head of financial crime operations, who accepts the residual risk for each release
- **Reviewer group for runtime approvals:** AML level-1 reviewers
- **When a human must review:** Every case the agent sends to Decision Desk, every `high`, `blocked`, or `needs_review` disposition, and a sample of `low` dispositions
- **How to intervene:** Reject or return the routing in Decision Desk; the system owner can pause the agent
- **What gets recorded for each human decision:** Reviewer, decision, reason, time, and the policy version that required the review
- **Training:** Reviewer playbook on automation bias and evidence checks

## 8) Failure conditions

| Condition | Detection | System behaviour | Human follow-up |
| --- | --- | --- | --- |
| Model or tool unavailable | Tool error or timeout | Run stops; the alert stays in the manual queue | Analyst works the alert by hand |
| Policy decision fails | Policy service error | The action is denied | System owner investigates |
| Confidence below 0.6 | Output field | Disposition set to `needs_review` | Reviewer decides |
| Alert text longer than the detector's evaluated scope | Input length check | Coverage gap recorded; case routed to review | Reviewer decides |
| Stale KYC record | `last_refresh` older than policy limit | Case routed to review | KYC refresh requested |

## 9) Controls

### Govern

- **Policy gates:** `decision_request.create` requires approval; all other tools are read or draft only
- **Escalation rules:** `high` and `blocked` dispositions go to the senior reviewer group
- **Change control:** Model, prompt, tool, and policy changes ship as a new release with two-person approval

### Assure

- **Evaluation approach:** Monthly sample review of `low` dispositions; release test set of 400 labelled historical alerts
- **Key quality metrics:** Reviewer agreement rate, override rate, share of `needs_review`
- **Monitoring signals:** Rising override rate or confidence drift opens a finding

### Prove

- **Audit trail sources:** Execution records with tool calls, policy decisions, and reviewer decisions
- **Retention policy:** Per the bank's AML record-keeping schedule
- **Evidence export cadence:** Quarterly, and on request

## 10) Incident response and reporting

- **What counts as an incident:** A routed case approved on evidence the packet misstated; any action outside the tool permissions above
- **Escalation contacts:** System owner, MLRO
- **Containment & rollback path:** Pause the agent; roll back to the previous release
- **Post-incident evidence to preserve:** Execution records and reviewer decisions for the affected cases

## 11) Version changes

| Release | Effective from (UTC) | What changed | Why | Re-approval | Evidence |
| --- | --- | --- | --- | --- | --- |
| 2.3 | 2026-06-02 09:00 | Added `counterparty_graph.lookup` (read) | Analysts needed shared-owner links in the packet | System owner and second approver, 2026-05-29 | Release test results; policy diff |
| 2.4 | 2026-07-08 01:30 | Routing policy 1.3.0 → 1.4.0: `needs_review` threshold raised from 0.5 to 0.6 | Sample review found low-confidence `medium` dispositions that reviewers overturned | System owner and second approver, 2026-07-06 | Sample review notes; policy diff; first-week override rate |

The change log records the exact cutover time. Decisions made before 2026-07-08 01:30 UTC are reviewed against policy 1.3.0, and later ones against 1.4.0.

---

*Completed synthetic example provided by KLA Digital. Not legal advice.*