Build the operating foundation before the next AI pilot.

A production AI workflow needs more than a working prompt. It needs enforced permissions, integrations that can recover from failure, tests of real tasks and an operating owner. Include these in the first release scope whenever the system will read restricted information or change business records.

Scope the first production release around those responsibilities. Reuse existing identity, integration and monitoring capabilities where they meet the requirement. Building a new shared platform is justified only when the workflow needs it and someone can maintain it.

Define the work before the architecture

Describe a complete transaction before selecting shared infrastructure: who starts it, which records it reads, what it may change and how the business knows it is finished. Map denied access, missing data and failed writes alongside the successful path. Those requirements reveal which parts need to be shared and which belong to one workflow.

Choose one real workflow and one credible second use before generalizing the architecture. A component that has no identified second user may not need the maintenance burden of becoming a shared service.

Make permissions part of every action

An assistant that can retrieve information should only retrieve what the current user is allowed to see. A workflow that can change records needs a separate decision about which actions it may take, under whose authority, and when approval is required.

In a hypothetical service operation, an assistant might summarize a customer's history and propose a replacement order. The service agent can review the proposal, while a supervisor approves exceptions to the replacement policy. The underlying business system enforces those permissions. A helpful model response does not grant authority.

Define what happens when identity cannot be verified, access is denied, or a request exceeds scope. These paths are part of the service experience.

Build integrations for recovery

A successful demonstration usually follows the expected path. Operations include delayed responses, incomplete records, repeated requests, and systems that are temporarily unavailable.

Integrations need clear ownership, stable data contracts, and a way to establish whether an action actually completed. If a request is retried, the service must avoid creating a duplicate order. If a source record changes, the workflow needs a defined response. Keep business rules in systems that can enforce them consistently, and record enough information to investigate failures without exposing unnecessary sensitive data.

Evaluate the workflow people will use

Test representative tasks and consequential exceptions before release. Include missing information, conflicting sources, unauthorized requests, and cases that should reach a person. Evaluate whether the completed work is correct and useful, how much review it requires, and what it costs to operate.

Shared evaluation tools can make these checks repeatable. The acceptance criteria still belong to each workflow. A useful draft response and an authorized financial adjustment require different evidence. Recheck relevant cases when the model, prompts, source data, or connected systems change.

Choose the first release's action boundary

A read-only release can test whether the assistant finds the right evidence and prepares a useful result. A draft-creation release also needs to show where drafts live, who reviews them and how they are distinguished from final records. An action-taking release must establish authorization, confirmation, recovery and a way to stop further changes.

Choose the least authority that can test the operating hypothesis. If the team cannot determine whether an interrupted write completed, keep final submission with the operator until recovery is reliable. Increasing the system's authority should be a deliberate release decision.

Name the owner before deployment

Agree who monitors quality, handles escalations, maintains source information, approves changes, and can pause the service. Operators need a usable fallback and a clear route for reporting failures. Engineers need those reports to improve the system.

Before approving the next pilot, review its design with the workflow owner and engineering lead. Produce one operational brief covering permissions, integration failures, evaluation criteria, release scope, and ongoing responsibility. Then identify the parts worth sharing with the next workflow. That is a concrete foundation the team can build, operate, and improve.