Generative AI in Rules-Based Workflows: Keep the Business Rule Explicit

Introduction

The difficult part of adding generative AI to a rules-driven workflow often sits before the decision table: turning an email, document or conversation into facts the rule can actually evaluate.

The rule itself may be straightforward. A return is permitted within 30 days. A discount above a defined threshold requires approval. A supplier in a restricted category needs additional due diligence. A service request with a particular combination of attributes follows a prescribed route.

Customers, however, describe circumstances in prose. Supporting documents use inconsistent terminology. Employees omit fields because they do not know which facts the process requires. One request can contain information relevant to several rules without using any of the vocabulary expected by the workflow.

Generative AI can help translate that material into usable inputs by identifying candidate facts, extracting supporting evidence, summarising context or preparing information for a deterministic decision.

The business rule does not have to move with it.

The Object Management Group’s current formal Decision Model and Notation 1.5 specification provides a way to represent business decisions and rules explicitly and can operate alongside process models such as BPMN. Current workflow platforms are also beginning to combine LLM-driven interpretation with governed decision logic rather than asking the model to absorb both.

That boundary gives generative AI in rules-based workflows a useful role: deal with ambiguity around the decision without making the decision logic itself harder to inspect.

At a glance

• Business rules operate on explicit inputs, while real requests often arrive as free text, documents or conversations.
• Generative AI can convert unstructured material into candidate facts before deterministic decision logic runs.
• Structured model output makes integration easier but does not prove that extracted business facts are correct.
• Material thresholds, eligibility conditions and mandatory approvals remain easier to inspect when they stay in executable rule logic.
• Model or prompt changes can alter downstream rule outcomes even when no business rule has changed.

The rule is only as deterministic as the facts it receives

A decision table can evaluate `purchase_date`, `product_type`, `sales_channel` and `receipt_status` consistently every time.

The difficult case is the customer who writes:

“I ordered this for my father around the end of last month. It is still sealed. I cannot find the receipt, but the charge is on my account.”

A conventional workflow can force the customer through a structured form, send the case to an employee for interpretation or derive missing fields from connected systems.

A model can instead read the message, inspect permitted supporting information and return candidate values such as the likely order, purchase date, product category and whether proof of purchase exists elsewhere in the account history.

Those values can then enter the existing decision logic.

Asking the model to determine whether the return should be approved would move a different responsibility into the model. If policy already states that unopened goods in a given category are returnable within 30 days when purchase can be verified, that logic has a precise expression outside the prompt.

The model’s useful contribution is resolving the messy evidence that reaches it.

Structured output gives the workflow a cleaner interface

Modern model APIs make this pattern easier because useful GenAI output no longer has to arrive as prose.

Microsoft’s current structured-output documentation supports JSON Schema definitions for model responses and describes use cases including extraction and multi-step workflows.

A return workflow can therefore request fields such as:

• purchase date;
• product category;
• order identifier;
• whether proof of purchase was located;
• stated reason for return;
• supporting evidence references.

The schema can constrain how those values arrive.

It cannot establish that the model identified the correct order.

Suppose the customer has two similar purchases and the model associates the message with the wrong one. The downstream decision table may work exactly as designed: it receives a date inside the 30-day window and returns an approval.

The rule engine has evaluated the information it was given. The problem entered upstream through the interpretation of the case.

For consequential fields, model-derived values can therefore require validation against authoritative data before the workflow treats them like ordinary business facts. An extracted account number can be matched against the customer record. An invoice total can be compared with the source document. A product category can be resolved against the product master.

The structure of the response makes automation easier. The evidential status of the values still depends on how they were obtained and checked.

Policy thresholds are easier to govern when they remain executable

Business rules have operational properties that become important when somebody needs to change or defend them.

A reviewer can inspect a decision table and see that purchases above £25,000 require a second approval. The threshold can be versioned. Regression testing can establish which cases change when it moves from £20,000. An audit can identify which rule version applied to a transaction.

DMN is designed to make that decision logic explicit.

Camunda’s current business rule task documentation illustrates the separation directly. A process can invoke governed decision logic such as DMN, and Camunda’s agentic-orchestration guidance also allows an AI agent to delegate a decision to deterministic rule logic rather than relying on LLM reasoning for that step.

A prompt could contain:

“Require additional approval for purchases above £25,000.”

For a low-consequence assistant, that may be sufficient.

In an operational workflow, however, the threshold now sits inside natural-language instructions alongside other model context. Prompt changes can affect its interpretation, and policy review becomes tied to the model configuration rather than to a discrete decision artefact.

Where the organisation already has a precise rule, moving it into a prompt adds little. Keeping the threshold in executable logic preserves independent inspection, testing and change control while leaving the model free to interpret the information surrounding the decision.

The decision can stay fixed while the explanation changes

A deterministic result is not always a useful piece of communication.

A rules engine may correctly return:

`RETURN_DENIED_30D_WINDOW`

A customer still needs an explanation.

Generative AI can take the decision result, applicable policy text and relevant case facts and produce something more useful: the purchase was made 37 days ago, the standard return period is 30 days, the product does not qualify for an extended-return category, and these alternatives remain available.

The language can adapt without requiring the model to recalculate the eligibility rule.

In procurement, a workflow can determine that an additional approval is required and use GenAI to explain which condition triggered it. A claims process can select a prescribed route and generate a concise case summary for the reviewer. An HR workflow can determine which policy applies and produce clearer instructions for the next step.

Generated explanations still require review where wording itself creates legal, regulatory or customer risk. Separating explanation from decision logic also makes defects easier to diagnose.

If the decision is correct and the explanation is wrong, the generation layer can be investigated without reopening the rule.

Ambiguous inputs need a valid workflow state

Not every message or document can be converted safely into a single set of values.

A customer request may match two orders. An invoice may contain conflicting totals. A contract clause may genuinely support more than one interpretation. A photograph may be too poor to establish the requested fact.

A workflow that requires every field to be populated can turn this ambiguity into invented certainty.

The model chooses one value, the decision engine treats it as ordinary data, and deterministic logic produces a confident result from an uncertain premise.

A better interface can preserve the unresolved condition itself.

The model may return that no reliable value was found, that several candidate records remain, that the evidence conflicts or that human review is required. Not every field requires a numerical confidence score; the operational question is whether uncertainty changes the next action.

In the return example, two plausible order matches might send the case to a service representative rather than directly to an approval or rejection rule.

The deterministic logic remains available once the necessary facts are sufficiently established.

A model update can alter the rulebook’s outcomes

Keeping decision logic outside the model does not make the workflow immune to GenAI change.

Assume the return-policy decision table is untouched for six months.

During that period, the intake model is upgraded. A prompt is shortened. A document-processing component changes. The new model handles some product descriptions better but begins assigning a particular phrase to a different return-reason category.

Without any change to the business rule, the inputs reaching it can now be distributed differently. Approval rates, review volumes and process paths may shift even though nobody edited a threshold or decision table.

Monitoring therefore has to reach across the boundary between probabilistic interpretation and deterministic execution.

Useful evidence includes which model-derived fields are corrected most often, how frequently cases arrive without a reliable value, whether human review changes after a model release, and whether particular downstream rule outcomes shift after a prompt or model update.

NIST’s Generative AI Profile places testing, evaluation and ongoing monitoring across the AI lifecycle, including recurring testing and monitoring after deployment.

That is particularly relevant when model output feeds conventional business logic. A small change in interpretation quality can propagate through a workflow because the rule engine will consistently act on whatever values it receives.

FAQs: generative AI in rules-based workflows

Where does generative AI fit in a rules-based workflow?

A useful role is at points where deterministic workflow logic encounters unstructured or ambiguous information.

Generative AI can interpret messages, documents or conversations and turn relevant material into structured candidate inputs. Existing business rules can then evaluate those inputs once they have been validated sufficiently for the use case.

Should business rules be put into an LLM prompt?

Some behavioural instructions naturally belong in prompts, but precise operational policies do not automatically benefit from moving there.

Thresholds, eligibility conditions, mandatory approvals and similar rules are often easier to inspect, version and test when they remain in executable decision logic such as DMN or another governed decision service.

Can structured outputs make generative AI deterministic?

Structured outputs can make the format of a model response predictable by requiring it to conform to a schema.

They do not guarantee that the values inside those fields are factually correct or appropriate for the case.

Can generative AI explain a decision made by a rules engine?

Yes.

The workflow can provide the decision result, applicable policy information and relevant case facts to a model and use GenAI to produce a clearer explanation for a customer, employee or reviewer.

The generated explanation should not silently change the underlying decision.

What should enterprises monitor when GenAI feeds a deterministic workflow?

Useful measures include correction rates for model-derived fields, unresolved-input rates, human-review frequency and changes in downstream rule outcomes after model or prompt releases.

The monitoring should connect the GenAI step to the business result rather than assessing extraction and workflow performance in isolation.

Keep the business rule visible

Rules-driven automation has never required every piece of information entering the process to begin in structured form.

People have often performed the translation. They read the email, interpreted the document, selected the correct code and entered the fields the workflow needed.

Generative AI can take on more of that interpretation.

The operating advantage goes beyond processing more unstructured information. Model-derived facts can be checked before they enter decision logic, while cases that remain ambiguous can stay unresolved until the workflow has enough evidence to continue. Prompt and model changes can be monitored through their effect on downstream outcomes, and the language used to explain a decision can evolve independently of the rule that produced it.

When the business already knows how a decision should work, generative AI is most useful around that logic—not as a substitute for making the logic explicit.