LLM Enrichment in an Order Exception Flow
A Boomi process handles order exceptions: when an order fails validation, it routes to a human queue. The team wants to add an LLM step that reads the exception reason and suggests a resolution category (e.g., address fix, credit hold, inventory shortage) to speed triage. The LLM is hosted externally and has a p95 latency of 3 seconds and a cost of $0.002 per call. Volume is 8,000 exceptions/day, peaking at 30 per minute. The process must not block the human queue if the LLM is unavailable, and suggestions must be auditable. The security team requires that no customer PII be sent to the external LLM. What architecture would you propose, and what are the key risks?
1. Design the integration pattern for the LLM enrichment, addressing availability, PII, and auditability.
Read the worked answer
Decouple the LLM call from the human queue using an asynchronous pattern: the main process writes the exception to the queue immediately, then publishes an enrichment request to a separate process or queue. The enrichment process redacts or tokenizes PII before calling the LLM, sends only the exception reason and non-PII context, and writes the suggested category plus model version, prompt version, timestamp, and confidence back to the exception record. If the LLM call fails or times out (set a 5-second timeout with one retry), mark the suggestion as unavailable and let the human proceed. Store the raw LLM response and the redaction mapping in an audit log with restricted access. Do not let the enrichment process hold the queue message; use a separate message with its own retry and dead-letter handling.
2. What risks does this design introduce, and how would you mitigate the top two?
Read the worked answer
Top risks: (1) PII leakage despite redaction, because free-text exception reasons may contain names or addresses that regex misses. Mitigate with a layered approach: a deterministic redaction step, a classifier or allowlist that rejects messages containing likely PII, and a contractual/technical guarantee that the LLM provider does not retain data. Test with a red-team set of 500 historical exceptions and measure leakage. (2) Automation bias, where humans accept wrong suggestions. Mitigate by showing the suggestion as a proposal with a confidence score, requiring explicit acceptance, and monitoring override rates by category. A secondary risk is cost drift: at 8,000 calls/day and $0.002, cost is $16/day, but retries and prompt growth can multiply it; set a daily budget alert and cap retries.