Completed example: AML alert triage agent (synthetic, excerpt)
Scroll to see all columns
Download the completed example · Synthetic: Northwind Bank and every value below are fictional.
2) Role and purpose
- 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, confidence, rationale, and evidence references.
- 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.
3) Component models
| Component | Version pinned | Evaluated scope | Known limits |
|---|---|---|---|
| Primary model (third-party LLM) | Provider version ID per release | English and French alert text | Can overstate confidence; output must cite evidence |
| Prompt-injection detector (open source) | v0.0.1 | English, single-turn input up to 128 tokens | Longer input is outside its evaluated scope |
4) Tool permissions
| Tool | Access | Policy outcome | Approver |
|---|---|---|---|
customer_kyc.read | read | allow | none |
sanctions_pep.screen | read | allow | none |
case_packet.draft | draft | allow | none |
decision_request.create | write | require_approval | AML level-1 reviewers |
No tool exists for SAR filing, customer messaging, case closure, or payment release.
5) Data flows
| Flow | Source | Destination | Personal data? |
|---|---|---|---|
| Alert input | Transaction-monitoring system | Agent | yes |
| Model calls | Agent | Model provider (EU region endpoint) | yes |
| Recommendation | Agent | Decision Desk and execution record | yes |
| Human decision | Reviewer | Execution record and evidence export | yes |
7) Approval owner
- Approval owner: Head of financial crime operations, who accepts the residual risk for each release
- Runtime reviewers: AML level-1 reviewers decide every case the agent sends to Decision Desk
8) Failure conditions
| Condition | System behaviour |
|---|---|
| Model or tool unavailable | Run stops; the alert stays in the manual queue |
| Policy decision fails | The action is denied |
| Confidence below 0.6 | Disposition set to needs_review |
| Alert text longer than the detector's evaluated scope | Coverage gap recorded; case routed to review |
11) Version changes
| Release | Effective from (UTC) | What changed | Re-approval |
|---|---|---|---|
| 2.3 | 2026-06-02 09:00 | Added counterparty_graph.lookup (read) | System owner and second approver |
| 2.4 | 2026-07-08 01:30 | Routing policy 1.3.0 → 1.4.0: needs_review threshold 0.5 → 0.6 | System owner and second approver |
View the worked example
Worked change record: release 2.3 → 2.4
| Field | Entry |
|---|---|
| What changed | Routing policy 1.3.0 → 1.4.0. The needs_review confidence threshold rose from 0.5 to 0.6. |
| Why | The monthly sample review found medium dispositions with confidence between 0.5 and 0.6 that reviewers overturned. |
| Card sections updated | 8) Failure conditions, 9) Controls, 11) Version changes |
| Tested before release | Release test set re-run on 1.4.0; more cases routed to review, none newly auto-dispositioned |
| Re-approval | Proposed by the system owner; approved by a second person before publication |
| Effective from | 2026-07-08 01:30 UTC |
| How reviewers use it | Decisions before the cutover are read against 1.3.0; later ones against 1.4.0 |
| Evidence | Sample review notes, policy diff, release test results, first-week override rate |
Synthetic example.
Before you begin
For compliance, risk, product, and ML ops teams shipping agentic Processes into regulated environments.
A system card describes one deployed AI system: what it is for, which models it uses, which tools it may call and with what access, where its data goes, who approves its actions, how it fails, and how it has changed. For an agent, the tool permissions and the approval owner matter as much as the model.
A model card describes one model. A system card describes the system you run around it. Annex IV technical documentation is the formal file a provider of a high-risk system keeps under Article 11 of the EU AI Act, and a current system card supplies much of its content. The EU AI Act does not use the term system card.
When we assessed an open-source prompt-injection detector as a component for our own runtime, its model card stated that it was configured for 128-token inputs. That one line belongs in the system card that uses it: longer inputs are outside the evaluated scope, and the system should record a coverage gap for them. The completed example shows where that goes.
In a synthetic evidence sample we built for an analyst briefing, the routing policy changed in the middle of the sample week, and 16 of the 50 recorded decisions ran on the earlier version. A reviewer could only read each decision correctly with the exact cutover time in hand, which is why the version-change table asks for the time a change took effect.
When to use this resource
- You are putting an AI agent into a regulated workflow and reviewers ask what it can do and who approves it.
- You are assembling Annex IV technical documentation or deployer records under Article 26 and need one current description of the system.
- A release changes a model, a prompt, a tool permission, or a policy, and the change needs a record a reviewer can follow.
Information to gather
- The release you are documenting, with its version and the date and time it took effect.
- The model card or vendor documentation for each component model, including what each was evaluated on.
- The list of tools the agent may call, the access each grants, and the policy outcome for each.
- Where inputs come from, where outputs and records go, and which flows carry personal data.
- The named approval owner and the reviewer groups for runtime approvals.
- Known failure conditions and what the system does when each occurs.
Review checklist
Use these checks in the review with your system owner. Confirm the applicable requirements and attach evidence for the decisions your team makes.
- The purpose names the decisions the system may propose and the actions it never takes.
- Each component model has a pinned version, a source, and the scope it was evaluated on.
- Every tool has an access level and a policy outcome, and actions without a tool are listed.
- Data flows show sources, destinations, retention, and which flows carry personal data.
- One named approval owner accepts the residual risk for each release.
- Failure conditions state how each is detected and what the system does.
- The change log records what changed, why, who re-approved it, and the exact time it took effect.
Operating controls and evidence
- Govern
Agent Registry records the agent, its owner, versions, and release state; Tool Catalog holds the tools and permissions the card lists.
Policy Builder rules set allow, warn, require_approval, or block for each tool call, and a policy change is published only after a second person approves it.
- Assure
Assurance Center tracks drift, quality, and findings for the agent, so the failure conditions in the card have a place to be checked.
- Prove
Each governed action produces a Lineage Record with the policy version, the decision, and the reviewer.
Evidence Room exports those records as a Sealed Evidence Bundle that a reviewer can verify offline.
Questions about this resource
What is the difference between a model card, a system card, and Annex IV technical documentation?
A model card covers one model: intended use, evaluation, and limits. A system card covers the deployed system: models, prompts, tools, data flows, oversight, failure conditions, and changes. Annex IV technical documentation is the provider’s formal file for a high-risk AI system under Article 11; a current system card supplies much of it.
Does the EU AI Act require a system card?
No. The Act does not use the term. Providers of high-risk systems keep technical documentation under Article 11 and Annex IV and supply instructions for use under Article 13; deployers have duties under Article 26. A system card is a practical way to keep the facts those documents need in one current place.
Why list tool permissions in a system card?
An agent acts through its tools. The list of tools, the access each grants, and the policy outcome for each tool call define what the agent can do. List the actions with no tool too, so a reviewer can see what the agent cannot do.
When should the card be updated?
With every release that changes a model, a prompt, a tool, a permission, a data flow, or an approval owner. Record the change, the reason, who re-approved it, and the exact time it took effect.
Is the completed example a real deployment?
No. Northwind Bank and every value in the example are fictional. The agent design follows the AML alert-triage agent template in our demo tenant.
Download file language: English