Why "Black-Box LLM Decides" Fails Enterprise
Every enterprise AI demo looks the same: paste an invoice, the LLM says "approve" or "reject." Impressive for two minutes. Then your procurement team asks:
- "Which rule did this fire? Our policy says invoices over $50k go to the CFO."
- "Can we audit every decision this made last quarter?"
- "Does this comply with EU AI Act Article 22 on automated individual decisions?"
The answer to all three is "no" for black-box LLM decisions. The LLM cannot cite the rule it applied. The decision trail is not auditable — log a prompt and a completion, and you still do not know why the model produced that output. And Article 22 explicitly requires meaningful explanation of automated decisions affecting individuals or organisations.
The governed agent architecture solves all three.
The Architecture: Three Layers
A governed invoice approval agent has three distinct layers, each with a specific job:
Layer 1 — BPMN workflow (who does what, in what order): The business process: receive invoice → extract fields → evaluate against policy → route to approver → notify → log. BPMN defines the sequence. It does not make decisions.
Layer 2 — DMN policy table (what the rules are): A decision table that maps input conditions to output actions. For invoice approval:
| Amount | PO attached | Supplier risk | → Route to | Deadline |
|---|---|---|---|---|
| ≤ $10k | Yes | Low | AP Clerk | 2 days |
| ≤ $10k | No | Any | AP Manager | 1 day |
| $10k–$50k | Any | Low | Finance Manager | 2 days |
| $10k–$50k | Any | High | CFO | Same day |
| > $50k | Any | Any | CFO | Same day |
The DMN table is deterministic. Given the same inputs, it always produces the same output. It is auditable — you can see exactly which row fired for any decision. It is explainable — "this was routed to the CFO because the amount exceeded $50k."
Layer 3 — Bounded LLM (reads only, never decides): The LLM's only job is to extract structured data from the unstructured invoice text. It reads the invoice and produces: {"amount": 47200, "po_attached": false, "supplier": "Vertex Systems", "supplier_risk": "medium"}. That is it. It does not decide what to do with those values — the DMN table does.
Try It Live
Go to archiet.com/agents and open the Invoice Approval agent.
In the text box, type:
Invoice #4521 from Vertex Systems for $47,200. No purchase order attached.
Payment terms net-30. Vertex is a new supplier, first transaction.
Click Run governed agent. Watch what happens:
- The text goes to the LLM extraction endpoint. The LLM returns:
``json { "amount": 47200, "po_attached": false, "supplier": "Vertex Systems", "supplier_risk": "high" } `` (New supplier = high risk — the LLM reads context, not just numbers.)
- The DMN policy table evaluates
{amount: 47200, po_attached: false, supplier_risk: "high"}and fires Row 4: route to CFO, same-day deadline.
- The BPMN workflow routes the invoice to the CFO approval step and logs the decision.
- The audit trail shows:
- Which rule fired (Row 4) - Why it fired (amount $47,200 in $10k–$50k band, supplier risk high) - What the LLM extracted (the raw JSON) - Timestamp, agent version, policy table version
Every part of this is explainable. An auditor can reconstruct any decision from the log.
How the Policy Table Works in Code
The DMN table is a JSON model registered with Archiet's decision engine:
INVOICE_APPROVAL_MODEL = {
"name": "invoice_approval",
"hit_policy": "FIRST",
"inputs": ["amount", "po_attached", "supplier_risk"],
"outputs": ["route_to", "deadline_days", "escalation_required"],
"rules": [
{
"conditions": {"amount": {"lte": 10000}, "po_attached": True, "supplier_risk": "low"},
"output": {"route_to": "ap_clerk", "deadline_days": 2, "escalation_required": False}
},
{
"conditions": {"amount": {"lte": 10000}, "po_attached": False},
"output": {"route_to": "ap_manager", "deadline_days": 1, "escalation_required": False}
},
{
"conditions": {"amount": {"gt": 10000, "lte": 50000}, "supplier_risk": "low"},
"output": {"route_to": "finance_manager", "deadline_days": 2, "escalation_required": False}
},
{
"conditions": {"amount": {"gt": 10000, "lte": 50000}, "supplier_risk": {"in": ["medium", "high"]}},
"output": {"route_to": "cfo", "deadline_days": 0, "escalation_required": True}
},
{
"conditions": {"amount": {"gt": 50000}},
"output": {"route_to": "cfo", "deadline_days": 0, "escalation_required": True}
}
],
"default_output": {"route_to": "ap_manager", "deadline_days": 2, "escalation_required": False}
}
hit_policy: "FIRST" means the engine fires the first matching rule and stops. The winning row is logged.
EU AI Act Compliance
Under EU AI Act Article 22, automated decision-making systems affecting individuals or organisations must be explainable and subject to meaningful human oversight.
This architecture satisfies both:
- Explainability: The DMN table row that fired, with its conditions and output, is logged with every decision. Any decision can be explained in plain language: "Routed to CFO because invoice amount ($47,200) exceeded $10k with a high-risk supplier."
- Human oversight: The BPMN workflow routes every decision to a human approver. The AI never makes the final decision — it extracts data that informs a human.
Compare this to a black-box LLM: "The model said approve with 87% confidence." That is not an explanation. That will not satisfy an EU AI Act audit.
Generate This For Your Own System
When you describe a system with invoice approval, procurement, or accounts payable workflows in Archiet's Blueprint Wizard, the governed agent is generated alongside the application code:
app/services/decision_engine.py— the DMN evaluation runtimeapp/services/governed_agents/invoice_approval_agent.py— the policy model + BPMN flowapp/blueprints/agents_bp.py— the API endpoints (/extract,/policy,/decide)- Frontend components for the agent interface
Your policy thresholds are extracted from your PRD. If your PRD says "invoices over $100k require board approval," Archiet extracts $100k and inserts it as the threshold in the generated DMN table.
The governed agent demo at archiet.com/agents also covers loan adjudication, FNOL claims triage, prior authorisation, refund and retention decisions, and KYC/AML screening — each with the same BPMN + DMN + bounded-LLM architecture.