Onboard an AI Workflow to Your Business Rules

A new assistant sounds friendly and knows the company description. Then a customer asks for an exception, two policy documents disagree, and nobody knows whether the assistant should act or ask for help. The problem is not simply an insufficiently detailed personality prompt. The workflow has not been onboarded to a coherent business process.

Good onboarding turns business expectations into facts, rules, examples, permissions, and ownership. It makes the system easier to evaluate and makes future policy changes less dependent on someone editing a long block of instructions.

Turn cultural language into observable behavior

Be helpful is an intention, not a test. In a booking workflow, helpful might mean asking only for missing required information, explaining an unavailable appointment honestly, and preserving the customer's preferred contact method. Never surprise a customer might mean requiring confirmation before changing an accepted date.

Write those behaviors so a reviewer can tell whether they occurred. Keep a distinction between how the assistant communicates and what the business permits it to do.

Also resolve unclear policies before automating them. If experienced staff disagree about whether a cancellation fee applies, a model should not become the accidental policy owner. Record the disagreement and send it to the responsible manager.

Separate three kinds of configuration

Communication guidance covers tone, terminology, concise explanations, and when to offer human help. Factual policy covers supported services, required information, exclusions, and effective dates. Action permissions define which authenticated actor can change which business record under which conditions.

These layers should be related but not interchangeable. A new phrase in the communication guidance must not silently grant refund authority. A policy update must have an effective version and an owner.

OWASP's Excessive Agency guidance describes the risks of giving systems too much functionality, permission, or autonomy. Enforce important action boundaries in the connected application, rather than asking the model to decide whether its own request is authorized.

Build an appointment-change test pack

Consider an illustrative service company onboarding a scheduling assistant. The approved policy says which appointments customers may request to change, what identity checks apply, and which situations require a coordinator. The scheduling database remains authoritative for confirmed slots.

The team assembles a small set of representative cases. A customer asks to move an eligible visit to a genuinely available slot. Another asks to move someone else's booking. A third refers to an appointment without enough identifying information. A fourth has an urgent service problem that is outside routine scheduling.

For each case, the test specifies the expected next state and unacceptable behavior. Missing identity should produce a clarification or approved support path, not a guessed customer match. A stale slot should produce a fresh availability check, not a fabricated reservation.

AI interprets the customer's request and drafts the explanation. Conventional checks establish identity, policy eligibility, slot availability, and the permitted update. The responsible coordinator owns exceptions; the final schedule record establishes whether the change succeeded.

The tests also include two conflicting policy documents. The assistant must surface the unresolved conflict or use an explicitly authoritative approved version. It must not blend the documents into a more convenient policy.

Include a boundary case where the policy changes after a customer booked but before they request an amendment. The policy owner must define which version applies and whether the original commitment has special treatment. Preserve that decision in the test case. Otherwise the system may use today's document to explain a promise that was made under different conditions.

Onboard the operating team as well

Staff need to know what the workflow does, what it cannot do, and how to correct it. Give them a concise process map, access to the relevant case evidence, and a place to record recurring problems.

When a policy changes, identify the facts, tests, explanations, and permissions affected. Keep the previous version available for investigation and rollback where appropriate. A change that looks like copy editing may alter customer commitments if it changes an exclusion or response promise.

The NIST AI RMF Playbook can help structure contextual evaluation. It does not supply the company's policy or decide which customer exceptions are acceptable.

Release by evidence, not by personality

A useful onboarding review asks whether the workflow behaves correctly when the request is ordinary, unclear, or outside scope.

• Can every consequential rule be traced to an approved owner and version?
• Are required facts distinct from optional conversational detail?
• Do missing or conflicting facts remain unresolved rather than invented?
• Are unauthorized changes rejected by the application?
• Can staff inspect and correct a failed case?
• Are policy updates accompanied by appropriate regression tests?

Run an initial limited release with real exceptions reviewed. Compare the actual next state with the expected one, and inspect what staff needed to repair. Do not count a graceful explanation as success when the underlying booking is wrong.

A well-onboarded workflow should feel consistent with the business because its behavior is consistent with the business. That comes from maintained rules and tested operating arrangements, not from making software sound more like a long-serving employee.