Choose rules, classical ML or an LLM for a client workflow

Choosing an LLM because the project is labelled AI reverses the architecture process. Begin with the decision boundary. Stable fields and explicit policies often belong in code; repeatable patterns with labelled outcomes may suit classical ML; open-ended language, synthesis and tool choice may justify an LLM. A workflow can use all three at different steps.

Build the decision artifact

Describe the input variability, available labels, required explanation, tolerance for error, latency target and change frequency. Build the simplest credible baseline first. Compare candidates on the same held-out cases, including rare and expensive failures. Separate the component that interprets language from the component that enforces money, permissions or policy.

The enterprise delivery lab makes this reasoning executable with synthetic data:

from enterprise_cases import solution_choice_case

result = solution_choice_case()
assert result["selected"] == "rules"
assert result["workflow"] == "validate invoice totals against typed fields"
assert result["model_called"] is False
assert result["scores"]["rules"] > result["scores"]["llm"]

The synthetic case selects rules for validating typed invoice totals. The result is not a universal scorecard: its weights encode this workflow’s high error cost and deterministic inputs. Change the workflow to ambiguous email triage and the evidence may favour a classifier or LLM. The decision record should state which facts would reverse the choice.

Test the failure path

A model comparison is invalid when each candidate sees different examples, when accuracy ignores abstentions and downstream review, or when the strongest model is assumed to be the cheapest total system. Count human exceptions, retries, integration work and monitoring alongside inference.

Save evidence that another reviewer can inspect:

• workflow decomposition with decision types
• shared benchmark and labelled error taxonomy
• quality, latency and total-cost comparison
• architecture record with reversal conditions

This exercise aligns with the enterprise delivery, secure integration, operations and leadership work in the FDE for Professionals course. The course link describes the pathway; this local draft and its synthetic verifier do not claim that a client deployment, security approval or production result occurred.

Practice task

Take one proposed LLM step and write a rule baseline and a classical-ML baseline. State which errors are unacceptable and run every option against the same cases.

Continue learning

This article is part of the Enterprise AI delivery and architecture sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Scope an enterprise AI pilot with stop-go criteria.
• Continue with Map an enterprise data boundary before building retrieval.

Reference: NIST AI Risk Management Framework.