AML alert triage shows the real shape of enterprise AI automation

An AML analyst logs in with a queue full of alerts that mostly will not become cases.

That does not make the work cheap. Each alert still needs transaction history, customer context, policy checks, prior SARs, and a disposition note someone can defend later. The bank may close 90% or more as false positives, but it still has to prove why each one was closed.

The repeatable work is evidence assembly, not judgment.

On May 28, 2026, the AWS Machine Learning Blog published a walkthrough for automating AML alert triage with Amazon Quick Flows and Snowflake Cortex AI. The workflow validates an alert ID, calls a Snowflake Cortex Agent through a Snowflake-managed MCP server, gathers evidence from structured and unstructured sources, and returns a structured investigation brief.

The agent is not asked to be the compliance officer. It prepares the case file the compliance officer reviews.

The artifact matters more than the agent

The walkthrough starts with an alert ID and an optional time window. Amazon Quick Flows validates the input, confirms the alert exists, and hands the request to Snowflake through MCP.

From there, the Cortex Agent pulls from both sides of the record. Cortex Analyst handles structured transaction and customer data. Cortex Search searches policy manuals, prior investigator notes, compliance documents, and other text sources. The agent coordinates the work and returns a brief with fixed sections: alert summary, transaction pattern, customer profile, prior SARs, policy references, risk score, disposition recommendation, and draft narrative.

A fixed brief changes the review.

A human analyst can scan it, challenge a risk score, check a policy citation, edit the narrative, or send the case back because a data source was missing. The output is not a chat answer floating outside the process. It is a reviewable artifact.

The guardrails in the AWS example are practical, not decorative. The MCP connection uses OAuth. The workflow respects Amazon Quick's 300-second MCP timeout. The system instruction tells the agent not to fabricate transaction data and to say when information is missing.

Those details are the difference between a demo and a workflow a compliance team could start to inspect.

Look for the queue, not the category

The AML example travels because it is a queue problem before it is a banking problem.

A support manager opening a refund escalation has to inspect the order, shipment events, account notes, policy exceptions, and prior tickets before approving anything. A vendor onboarding reviewer has to check tax forms, insurance certificates, sanctions results, security questionnaires, and the approval history before releasing the vendor record.

The useful automation target is not "support" or "vendor onboarding." It is the repeated packet: trigger, evidence, policy comparison, recommendation, human decision.

For process automation, scope the queue instead of the department. Pick one queue where the trigger is clear, the evidence sources are known, and the reviewer already has authority to accept, reject, or send the packet back.

Keep evidence assembly separate from authority

The cleanest part of the AWS and Snowflake example is the boundary around the agent.

The agent can retrieve facts, summarize prior history, find relevant policy language, flag missing data, produce a risk assessment, and draft the narrative. It cannot close the case. It cannot escalate the customer. It cannot file the SAR. It cannot turn a recommendation into an official disposition without human review.

The separation is easiest to defend before the pilot starts working.

When the brief looks good, the temptation is to remove the review step. Regulated automation gets dangerous at that handoff. A suggestion quietly becomes an action. A draft narrative becomes the record. A missing-data note gets ignored because the happy path worked during the demo.

Better early projects keep the handoff visible. The workflow prepares the review. A human owns the decision.

We made the same argument in our piece on building an AI approval queue before giving an agent side effects. Drafting, routing, checking, and assembling work are safer early wins than handing an agent the keys to the business process.

For regulated teams, approval gates, audit trails, role boundaries, missing-data behavior, and escalation paths need to be part of the workflow before the pilot looks impressive.

Policy text is part of the evidence

AML triage does not live entirely in tables.

Transaction amounts, merchant names, account history, and customer risk ratings are structured. Policy manuals, SAR guidance, investigator notes, and prior case narratives are not.

A useful brief needs both. Structured data can show what happened. Search over policy text can show which rule, threshold, exception, or prior note may matter.

Cortex Search matters because it retrieves the language a reviewer would otherwise go find manually. The agent still has to cite it clearly enough for the analyst to check.

This is also where sensitive data handling becomes architecture, not paperwork. AML workflows touch customer records, transaction details, compliance notes, and potentially privileged investigative material. Teams need rules for which fields the agent can retrieve, what gets redacted, what gets logged, who can run the flow, and how the final output enters the official case record.

A fast brief that leaks the wrong fields or leaves no receipt is not an improvement.

How to test a workflow like this

The planning work should start with the receipt, not the model.

What should the reviewer see when the run finishes? Which sections are required? Which sources should be cited? What does the workflow say when transaction data, policy text, or prior notes are missing? What fields can never be included in the generated narrative?

Once that artifact is defined, the rest of the rollout has something to test against.

Run the workflow on known historical alerts. Compare the generated brief with the analyst's actual disposition notes. Track where the agent found the right evidence, where it missed context, and where the reviewer had to rewrite the narrative. Log the input, sources queried, output generated, missing-data notes, reviewer edits, final decision, and any exception path.

The useful metric is not whether the agent sounds confident. It is whether the reviewer gets a better packet faster and can still tell exactly what happened.

Two controls matter more than the vendor stack. The output has to be structured enough to review, and the agent has to stop before the decision.

Controlled workflows leave receipts

The AML alert triage example is useful because it is not glamorous.

It depends on orchestration, retrieval, structured output, authentication, timeouts, missing-data rules, and human review. Some teams will build that with Amazon Quick Flows and Snowflake Cortex Agents. Others will use a different MCP server or orchestration layer.

Before choosing the stack, write down the receipt the reviewer should get: the trigger, evidence sources, policy excerpts, missing-data notes, draft recommendation, reviewer edits, and final decision.

If the workflow cannot produce that receipt, it is not ready for regulated work. If it can, the model has a bounded job: make the work before judgment faster, cleaner, and easier to audit.

For finance operations, compliance, and other evidence-heavy processes, that connects to our earlier look at finance agents and boring, useful AI automation. The useful projects are usually controlled workflows, not magic boxes.