Where preparation becomes a consequential act
When we built digital banking for millions of customers, the most scrutinized design work was never the account summary screen. It was the moment a customer or banker moved from looking at information to doing something with it: sending a payment, changing a payee, approving an exception. Each of those transitions had an explicit authority model, and examiners tested it. AI workflows deserve the same discipline, and in most pilots I review they do not yet have it.
Many AI workflows start with information and end close to an action. Claude summarizes an overdue credit file, recommends a supplier or drafts a note to a patient. The design question is where preparation becomes a consequential act, and who is authorized to approve that transition. Write the sequence in plain business language: the records reviewed, the recommendation produced, the person who checks it and the system that executes. A clear sequence makes it harder for a convenient integration to quietly acquire more authority than the business intended.
Approval is a specific decision, not a button
Having a human somewhere in the loop is not enough. The reviewer must know what they are approving, see the relevant evidence and actually hold authority for the decision. A generic “continue” button after a long generated explanation is not meaningful review. Approving a draft customer message is different from approving a wire or changing a source record, and the interface language should say so.
Plan for the state changing between recommendation and execution. A balance, a recipient or an order status may no longer match what was reviewed. In private banking and wealth management we took this seriously, because advisors act on client instructions that can go stale within hours. The workflow needs a rule for rechecking or requesting renewed approval when the change matters.
Keep business authorization separate from technical authentication. A banker can be signed in and still lack authority for a particular credit exception. An integration can hold broad technical capabilities while the approved workflow permits only a narrow operation. The implementation must preserve the narrower business boundary.
Calibrate the control to consequence and scale
Choose controls for the action involved. A loan-file summary can remain read only while the officer makes the decision in the existing system. A drafted customer message needs an authorized approver before sending. A prior authorization summary and its submission also deserve separate treatment. Make those transitions visible in the workflow and test that a convenient tool call cannot bypass the intended approval.
Use a read-only pilot wherever that is enough to prove value. It shows whether recommendations are useful and inspectable before you add execution, and it reduces the number of uncertainties tested at once. It does not imply that every workflow should eventually become autonomous. Many never should.
Test attempts to cross the line
Include requests that ask the assistant to skip review, bundle several actions or reinterpret an earlier approval. A conversational instruction should never silently expand the scope of an approval or transfer one person's authority to another.
Test failure around the action itself. If execution times out, the system must not present an uncertain outcome as a confirmed success. Retrying may duplicate a payment, so recovery must distinguish a failed request from an action whose outcome is unknown. That design depends on the target system and deserves specialist review.
Walk through a rejected proposal during acceptance testing. Rejection should leave the business state unchanged, and a revised proposal should go through review again rather than inheriting approval from earlier in the conversation.
Accountability continues after the click
Name who can investigate an action, correct a problem and communicate with affected customers or patients. Preserve evidence of what was proposed, approved and performed under your retention and access rules, without collecting extra sensitive content just to make the record look complete.
Watch how people behave in normal work. If they assume a recommendation has already been executed, fix the product language. If approval becomes reflexive, check whether you are presenting too many low-value confirmations.
Good assistance shortens the path to a decision. Good authorization keeps the organization in control of consequences. Design both deliberately, and Claude can work close to real business processes without fluency or convenience ever standing in for authority.