Business rules in AI workflows for sensitive decisions

Why prompt control breaks

A prompt can tell a model what tone to use and what steps to follow. It cannot enforce policy the way code can. If a workflow touches refunds, account access, pricing, or compliance, the model will still try to complete the task from the text it sees. That makes prompts too soft for sensitive decisions.

Small prompt edits can change the outcome more than teams expect. Move one sentence, add a new example, or tack on one more instruction, and the model can read an approval limit or eligibility rule differently. The edit may look harmless in review, but the result can swing from "deny" to "approve" because the model guessed what the team meant.

The problem gets worse when rules live in hidden prompt text. Teams often spread logic across system prompts, templates, fallback instructions, and tool notes. After a few rounds of changes, nobody can answer a basic question: which rule blocked this case, and where is that rule defined? That becomes a real problem when finance, support, or legal asks for an audit trail.

Money, access, and compliance need fixed checks. If a refund is over $200, the workflow should stop unless it sees a manager approval flag. If a customer does not meet plan requirements, the system should block premium access before the model writes a friendly explanation. The model can summarize a case, draft a response, or classify a request. It should not set the limit.

That is the weak spot in prompt-only control. Prompts guide behavior, but they do not lock it. In sensitive AI workflows, the hard lines need to live outside the model, where teams can test them, audit them, and change them without hoping the model interprets them the same way every time.

What rules stay outside the model

Sensitive decisions need fixed rules in product logic, not inside a prompt. The model can explain, summarize, or draft a recommendation, but it should not invent who qualifies, how much money it can approve, or when a case must stop.

Start with money. Refund caps, discount ceilings, credit limits, and spending thresholds should sit in app code or approval settings. If a customer asks for a $600 refund and the automatic approval limit is $100, the flow should stop there. The model can write a polite response, but it should never decide that $600 feels reasonable.

Authority rules also belong outside the model. Your company decides who can approve an exception. Maybe a support lead can approve up to $250, and anything above that goes to finance or an operations manager. Keep that map in your own data, with named roles and clear limits.

Eligibility checks belong there too. Use your own records to confirm whether the customer paid for the order, whether the request falls inside the refund window, whether the account has fraud flags, whether the product or service is covered, and whether the form includes every required field.

If required data is missing, stop the flow before the model gives an answer. Missing order IDs, payment records, consent boxes, or policy acknowledgments can lead to bad decisions very quickly.

Risk blocks should work like hard brakes. If the fraud score is too high, the account is under review, or the request touches a regulated case, the app should route it to a person. Do not ask the model to "be careful" with those cases. That sounds fine, but it is still loose.

A simple rule works better: the model can speak, but your product decides. That split keeps approvals consistent, makes audits easier, and cuts down on expensive mistakes.

Where to place limits and approvals

Put limits and approvals before the model step, not inside it. If a workflow involves money, access, benefits, or account changes, the model should never decide what is allowed. Your app should decide that first.

This matters because a model works with language, not policy. If it reads a persuasive message before your system checks the facts, it can produce text that sounds confident while ignoring a spending cap, a missing approval, or a failed eligibility check. The model should enter only after the hard boundaries are already set.

A safer flow starts with your own systems. Pull account status, customer tier, transaction amount, prior approvals, and any block flags from your database or internal tools. Do not rely on what a user typed in chat, even if it sounds precise.

Store thresholds in code or in a separate rules service. That includes refund caps, discount ceilings, region limits, and approval paths. When someone changes a limit, you want one clear place to update it. You do not want to hunt through prompts and hope every version matches.

Only approved actions should reach the model. If policy says an agent can offer a refund up to $50 with no manager review, your system should pass the model a narrow set of allowed next steps: explain that a refund is approved, ask for one missing document, route the case to a manager, or decline based on a recorded rule.

Log every rule check. Record what rule ran, when it ran, what data it used, and why it passed or failed. When a customer asks, "Why was this denied?", your team needs an answer from system records, not from model memory.

One simple test helps: unplug the model and see whether the policy still holds. If the answer is no, the limits sit in the wrong place.

How to build the flow

Good business rules in AI workflows start small. Pick one decision where the stakes are easy to see and the policy already exists. Expense approvals, account access changes, and discount requests work better than broad tasks like "handle customer issues."

A narrow starting point keeps the flow honest. You can test it, watch failure cases, and fix gaps before you let the model touch anything more sensitive.

Write each rule in plain language, the way you would explain it to a new team member. Skip fuzzy wording. "Approve expenses under $100 if the receipt is present and the employee is active" is usable. "Approve normal requests when they look fine" is not.

Then match every rule to a real data source. If a rule depends on employee status, decide where that status comes from. If it depends on receipt amount, name the field that holds it. If you cannot point to a field, table, or system record, the rule is still too vague to automate.

A simple build order works well:

• Choose one decision with a clear cost if it goes wrong.
• Turn the policy into short, testable rules.
• Map each rule to a source of truth.
• Add stop points for missing data, conflicts, or higher-risk cases.
• Let the model write or summarize only after the system clears the checks.

Stop points matter more than many teams expect. If the amount is above the limit, stop. If the employee record is missing, stop. If two systems disagree, stop. A person can review those cases with context instead of cleaning up a bad automated decision later.

Bring the model in late. After your workflow checks limits, approvals, and eligibility, the model can draft the message, explain the result in plain English, or collect one missing detail. That keeps the model useful without letting it invent policy.

A practical example makes the split clear. A company auto-reviews small software purchase requests. The workflow checks budget, manager approval, vendor status, and prior spend. If every check passes, the model drafts the approval note. If one check fails, the system routes it to finance. The rule decides. The model just helps communicate it.

A simple example: refund requests

A customer asks for a refund 45 days after buying a product. This is exactly where policy needs to stay outside the model. If the refund window, amount limit, or fraud rules live only in the prompt, the model can guess, bend the rule, or miss a detail.

A safer flow starts with hard checks in the app or backend. The system reads the order date, refund amount, payment status, and any fraud or abuse flags tied to the account. Those checks happen before the model writes a single word.

A simple flow might work like this:

• If the order falls outside the refund window, the system marks it for review or denial based on policy.
• If the refund amount is above a set limit, the system sends it to a manager.
• If fraud signals appear, the system blocks automatic approval.
• If the request passes every rule, the system allows the next step.

The model still has a job, just not the policy job. It can read the customer message, pull the right facts from the case, and write a clear reply. It can also draft a short summary for the support team with the order date, amount, stated reason, and the rule that sent the case forward.

That split matters. The backend decides whether the request is eligible. The model explains the outcome in plain language. If the order is 45 days old and the policy allows only 30 days, the reply can say that clearly and politely. If the amount is high, the reply can say a manager is reviewing it. If fraud checks stop the flow, the case can move to a person without the model trying to soften or override the rule.

This is what business rules in AI workflows should look like in practice. The model helps with communication, but code and policy decide who gets approved, who gets reviewed, and who does not.

What the model should still do

A model is useful in a sensitive workflow when it handles language and structure, not the decision itself. It should work from approved facts that your system already checked, then turn those facts into messages people can understand.

If a refund request is over the allowed amount, the model should not argue with that limit or invent an exception. It should say, in plain words, that the request needs review because the amount is above the approved threshold.

Good uses for the model are narrow and practical:

• Write customer messages from system data such as status, amount, reason code, and review state.
• Ask for missing details in a fixed format, like order number, date, and proof of purchase.
• Summarize the case for a human reviewer with the facts, timeline, and missing items.
• Sort free-text explanations into known reason types, such as duplicate charge, damaged item, or subscription confusion.
• Suggest next actions, while leaving the final call to rules or a person.

Fixed formats matter more than many teams expect. If details are missing, the model should ask the same way every time. That keeps replies easy to process and makes the next step predictable for both the customer and the reviewer.

A short case summary can save real time. Instead of making a reviewer read ten back-and-forth messages, the model can produce a compact note with the customer request, transaction amount, rule result, missing evidence, and any risk flags raised by the system.

Reason sorting is another good fit because people write messy text. One customer says "I got charged twice," another says "same payment hit my card again." The model can map both to the same approved reason type, which keeps reports cleaner and queues easier to manage.

The model can also suggest actions such as "request a receipt" or "send to manual review." It should stop there. That line matters: the model can prepare the work, but it should not decide who gets approved.

When a person should step in

People should review cases where the rule engine stops the flow, the facts conflict, or the request falls outside normal patterns. Edge cases need an owner. Send them to a named person or role, such as the finance lead on duty, not to a vague queue that everyone ignores.

That handoff should stay tight. The reviewer does not need a full chat transcript or every model draft. Long logs waste time and can push staff to trust the model's tone instead of the actual rule.

A good review screen shows the request and amount, the customer or account facts used in the decision, the exact rule that stopped the flow, what data is missing or conflicting, and a short model summary if it helps.

Showing the exact stop matters. "Over refund limit of $500" is clear. "Risk flag detected" is not. If staff cannot see which rule fired, they start guessing, and guesses turn into uneven decisions.

Make overrides easy to review later

If a reviewer decides to override a stop, require a reason every time. One short sentence is enough, and a reason code helps even more. "Customer was charged twice, payment processor confirmed duplicate" gives the next reviewer something real to check.

Without that note, overrides turn into a silent habit. Then nobody can tell whether the rule is too strict, the reviewer made a good call, or the team is slowly bypassing policy.

Emergency actions need tighter limits. Give people a narrow escape hatch for rare cases, but put an end date on it. A manager might approve a one-time exception during a system outage for the next 12 hours. That is very different from a permanent "approve anyway" button.

People should handle judgment and unusual facts. The system should still keep the boundaries, record the reason, and return to the normal path as soon as the exception ends.

Common mistakes that cause trouble

Teams often hide hard limits inside a long prompt and assume the model will follow every line. That works until someone edits the prompt, adds more context, or the model tries to be helpful. If a refund cap is $200, keep that number in code or a policy table, not in text the model can treat as advice.

Another mistake is letting the model invent exception logic. A prompt that says "use judgment for unusual cases" sounds practical, but it opens the door to made-up policy. In sensitive work, exceptions need fixed rules or a person who can approve them. The model can explain the case. It should not decide that one customer deserves a special pass.

Stale data causes quieter damage. The model may read an old order total, an outdated account status, or a missing fraud note and still produce a polished answer. That makes the error harder to catch. Pull current data right before the decision step, and stop the flow if required fields are missing or too old.

Teams also get into trouble when they skip logs for retries, overrides, and manual approvals. If an agent changes the outcome, the system should record who changed it, when, and why. If a request runs twice, the logs should show both attempts. Without that record, you cannot explain a bad result or spot a pattern that needs fixing.

A more basic issue is mixing policy text with live decision code. The policy document says one thing, the app checks another, and the prompt contains a third version in plain English. That drift creates inconsistent results fast. Keep one source of truth for limits, approvals, and eligibility checks, then let the model read the outcome instead of rebuilding the rule.

A plain split usually works best. The system checks facts and enforces the rule. The model turns that result into clear language for staff or customers.

Quick checks before launch

A workflow is not ready if your team cannot explain every decision in plain words. In refunds, access changes, or eligibility cases, the model can read, sort, and summarize. The actual gate should come from code, policy settings, or a person.

Start with traceability. If the system blocks a request, someone on staff should be able to point to the exact rule that fired and the data that triggered it. "The amount was over the refund cap" is clear. "The model decided it felt risky" is not.

Use this as a hard pre-launch check:

• Store limits, approval thresholds, and eligibility rules outside the prompt.
• Put failed checks in front of the model's final step.
• Give reviewers a simple override path with a short reason.
• Keep logs that show the inputs, the rule IDs that fired, the model output, any human action, and the final result.
• Test one policy change and one blocked case before launch.

This is where a workflow either holds up or falls apart. If the refund cap changes from $200 to $150, your team should update one value, rerun a test, and move on. If they need to rewrite the prompt, the model is carrying policy it should never own.

One more check matters. When a reviewer overrides a decision, that action should stay visible in the logs, not disappear into a note field nobody reads. If the workflow cannot show who changed the outcome and why, it will be hard to defend later.

Next steps for a safer rollout

Pick one workflow that already creates risk or eats staff time. Good candidates are refund approvals, account changes, vendor onboarding, or any case where a wrong answer can cost money or break policy. That narrow start makes it easier to see where your rules fail.

Move the hard rules into code first. Set approval limits, eligibility checks, required fields, and who can override a decision outside the model. This is what keeps the system boring in a good way.

Keep the model on work that helps people move faster without making the final call. Drafting a response, sorting incoming cases, extracting details from a form, and writing a short summary are usually safe places to start. If the model cannot approve, reject, or bend policy on its own, you remove a lot of risk.

A simple rollout often looks like this:

• Choose one process with clear pain and clear rules.
• Put limits, approvals, and eligibility checks in code.
• Let the model draft, classify, or summarize only.
• Test edge cases with the staff who handle exceptions.
• Expand only after the logs show stable results.

Test with real staff before you roll it out wider. They know the messy cases: missing documents, unusual customer history, duplicate requests, and requests that look valid but should stop for review. Those edge cases matter more than a clean demo.

Watch for two signals during testing. First, does the model ever sound confident when the coded rules say no? Second, do people start trusting polished language more than the actual checks? That gap causes trouble fast.

If you want an outside review, Oleg Sotnikov offers Fractional CTO advisory through oleg.is and works on AI-first software development, automation, and workflow design. A review like that can help when you need approval points and failure paths to stay simple, testable, and hard to misuse.

A safer rollout is usually a smaller one. Start with one controlled process, prove the guardrails work, and widen the scope only after the logs hold up.