Choose enterprise AI tools around a defined piece of work: the information it needs, the result someone will accept, the actions it may take and the people who will support it. Start with the simplest arrangement that meets those needs, then test the complete handoff before expanding its reach.
For an IT, operations or adoption lead, that means evaluating more than the quality of a generated answer. A tool also introduces permissions, review work, dependencies and maintenance. Those commitments should be visible while you still have a choice.
This guide helps you make that operating decision. For choosing the wider program and its priorities, use the AI adoption strategy guide.
Name the work that must get finished
“Help the facilities team with AI” leaves almost every important decision open. “Prepare a maintenance work order from an incoming request, with the correct site and equipment confirmed by a coordinator” gives you something to examine.
Suppose a facilities team receives requests about faulty warehouse doors. A coordinator reads each message, identifies the site and door, checks the maintenance record and prepares a work order for a technician. Missing details cause a follow-up call. Urgent or safety-related reports already have a separate escalation procedure.
An AI tool might extract details from the message and draft the work order. It should leave an unknown door number unresolved. The coordinator checks the draft against the original request and equipment record before creating the order. The existing escalation procedure continues to handle urgent reports; this trial is not asking AI to diagnose equipment or decide whether it is safe.
Write down four things before comparing products:
- Inputs. Which messages, records and instructions are actually needed?
- Accepted output. What must the work order contain before the technician can use it?
- Human check. Who can verify those details, using which source?
- Exceptions. What happens when information is missing, contradictory or outside scope?
If the team cannot describe the current work, observe a recent task before proposing an AI use case. A more elaborate tool will not settle an unclear handoff.
When the next step depends on an experienced colleague's unwritten judgment, capture the cues, exceptions and reasoning behind a real decision. Test whether someone else can apply that guidance before relying on AI to reuse it.
Choose the simplest useful arrangement
The amount of freedom a system needs should follow the task. A coordinator asking for a draft, a predefined sequence moving approved information and an agent choosing its next action create different support obligations.
Anthropic's engineering guide distinguishes workflows with predefined paths from agents that direct their own process and tool use. It recommends starting with simpler solutions and adding complexity when needed. This is vendor engineering guidance, not evidence that one architecture wins every task.
| Arrangement | When it may fit | What the team must support |
|---|---|---|
An assistant used by a person | A coordinator requests and checks a draft, then completes the handoff | Approved inputs, source checking and a clear place to save accepted work |
A predefined workflow with an AI step | Requests follow a stable route, with extraction or drafting inside it | Connections, validation, exception handling and checks before consequential actions |
An agent choosing steps or tools | The route varies enough to justify model-directed decisions | Bounded permissions, stopping conditions, action records and stronger evaluation |
An existing system may already support the necessary arrangement. Compare that option with a new purchase or custom build using the same sample work. Include setup, checking and support effort alongside license or usage cost. A familiar interface is useful only if the required controls and output quality are there. The buy, build or combine guide compares the components and operating responsibilities behind those options.
AI workflow automation also includes plenty of ordinary software work.
18%
of steps were AI steps in the selected durable workflows
Zapier's Q2 2026 report examined durable AI workflows in the top 375 of 1,500 eligible Team and Enterprise customer accounts, ranked by durable-workflow count. Durable meant active in both monthly windows from April 15 to June 14. This selected customer cohort does not represent all enterprises or establish an ideal AI share.
The practical implication is modest: decide which steps benefit from interpreting language and which can use established rules. In the maintenance example, drafting a description may suit AI. Checking that a required site field exists and saving an approved order need not involve another model decision.
Set data and action boundaries
For employee-facing rules, the AI acceptable-use policy guide explains how to define permitted accounts, inputs, review and help.
Approval to use a tool needs a scope. A trial that drafts from sanitized requests is different from a connection that reads all maintenance records and can assign technicians.
Before connecting it, agree:
- Data access. Identify the necessary records and fields, who permits their use, and whether the tool can preserve the source system's access restrictions.
- Data handling. Verify the selected service's applicable terms and settings for retention, training use, deletion and third-party access. Record unresolved questions with the responsible owner.
- Action authority. Separate reading, drafting, saving and sending. Name the person who approves actions that affect other people or systems.
- Failure handling. Define what stops the workflow, who receives the exception and how the ordinary process resumes.
A prompt telling a model to respect permissions is not a substitute for access controls. Ask the technical owner to demonstrate the actual restriction with an appropriate test account and approved test data. A successful draft from an administrator's account says little about what another employee should be able to retrieve.
NIST's voluntary Generative AI Profile provides a useful reference for this planning. Its inventory guidance includes oversight roles, data considerations and underlying models; it also addresses periodic review and third-party fallbacks. Use those questions to clarify responsibilities, without treating a completed checklist as proof that a tool is safe.
Agree what people need to know about AI use
Disclosure belongs in the workflow design. Decide what colleagues or recipients need to know to interpret an output and who is responsible for explaining its limitations. Check applicable organizational policy, contracts and legal requirements with their owners rather than assuming every AI-assisted task has the same disclosure rule.
For the maintenance trial, a technician needs a checked work order, access to the original request where permitted, and a way to query an unclear detail. If an AI-generated summary is being passed along without verification, presenting it as a confirmed account would hide information relevant to that decision. Fix the handoff and its labeling before expanding use.
Test the complete handoff
A useful trial ends when the next person can use the work. Count the coordinator's correction time and the technician's follow-up questions, as well as the time spent producing the draft.
When people try the tool but do not return, observe the task to distinguish usability barriers from training needs. Watch where the person gets stuck before deciding which kind of support or repair will help.
Use approved examples covering ordinary requests and important exceptions. Include an ambiguous site, a missing equipment identifier, conflicting descriptions and a request outside the trial's scope. Agree the acceptance criteria before inspecting the outputs, and keep examples for later retesting.
Test one complete request
Follow the work beyond the generated draft.
Prepare approved inputs
Keep the original request and relevant equipment record available.
Produce the draft
Extract supported details and leave missing information unresolved.
Check before creating the order
The coordinator confirms site, equipment and required details.
Review the handoff
The technician identifies omissions or clarification work.
Keep, change or stop
Use accepted work, correction effort and exceptions to decide whether this arrangement is worth supporting.
Treat a faster first impression as a hypothesis. In its February 2026 developer-productivity update, METR explained why selection effects and difficulties measuring work time made its later speedup estimates unreliable. That research concerns software development, not maintenance coordination. It is a reminder to examine what a measurement includes before importing a claimed gain into your own decision.
Record accepted outputs, corrections, total human effort and the important failures. Keep the definition of an accepted work order consistent across the old and trial processes. If review simply moves from the coordinator to the technician, record that transfer. The AI value guide explains how to distinguish task improvements from wider business outcomes.
For a closer look at changing the route itself, see how to redesign a workflow and retire duplicate work.
Before adding software, test whether your existing tools can run the adoption program through guidance updates, question resolution and realistic staff effort.
When buying outside help, compare AI enablement services and platforms on deliverables, internal duties and a handover your own team can demonstrate.
Give support a named owner
After training, employees need a way to get unresolved questions to the right person. Set up ongoing AI support with a visible help route, accepted handoffs and a checked answer returned to the employee.
A promising prototype can reveal a need while leaving the maintenance commitment unresolved.
In a public r/sysadmin discussion, a Reddit user described a COO who had used AI to create a dashboard in a single HTML file and then asked IT to review and maintain it. The poster described themselves as a generalist sysadmin who also writes software.
My main concern is code maintainability and who will be responsible for it.
In their follow-up, the poster proposed retaining the mockup's useful requirements while agreeing implementation, review and maintenance time. Employer and company size were not stated; the account is a self-report.
The discussion also contained a different experience. Another Reddit user reported that collaborating on a similar request led to an internal tool their team found useful. Neither account establishes how well a particular system worked. Together they expose the decision worth making: what would it take to turn a useful idea into something the team can responsibly support?
Make these responsibilities explicit:
- Business owner. Accepts the result and decides whether the workflow remains worthwhile.
- Technical owner. Maintains connections, configuration and changes.
- Routine reviewers. Check outputs and raise exceptions during the work.
One person may hold several responsibilities, but their available time still matters. Support and practice need room in the working week.
Agree when the arrangement must be reviewed again. A changed model, new data source, broader permission, recurring error or rising support burden can invalidate an earlier test. Keep the previous working configuration where feasible, document how to stop new automated actions, and rehearse returning to the ordinary process.
Keep a small operating record
Before expanding the maintenance trial, the coordinator and technical owner should be able to complete this record together. Use named people and actual decisions in your version.
| Field | Maintenance-request example |
|---|---|
Work and accepted output | Draft a work order with confirmed site, equipment and required details |
Inputs and boundaries | Approved request text and relevant equipment record; unresolved identifiers stay blank |
Tool arrangement | An assistant drafts; the coordinator checks and creates the order |
Exceptions and fallback | Missing information goes back for clarification; urgent reports follow the existing procedure |
Owners and capacity | Name the business, technical and review owners; agree support time |
Trial evidence | Keep representative inputs, accepted outputs, corrections and total human effort |
Change and exit | Record retest triggers, who can stop use and how work continues without the tool |
Test whether the alternative can handle the actual work. Use the AI continuity exercise to decide which tasks can wait, use a manual route or stop, and what must pass before normal service resumes.
An unanswered field identifies work still to do. Resolve it with the person who has authority to decide, then compare the options again. The tool that earns a place is the one the team can use, check and maintain within those conditions.
Questions about AI tools and workflows
Do we need an AI agent for every workflow?
No. A person using an assistant or a predefined workflow may meet the need. Consider an agent when the task genuinely requires choosing different steps or tools, and when its added freedom can be bounded and evaluated. Start by comparing the arrangements against the same accepted output.
Should we use an existing tool or build something new?
Test whether an existing approved tool can produce the required result with acceptable data access, checking and support. Compare a new purchase or custom build on those same conditions, including ongoing ownership and cost. A capability missing from the existing system may justify another option; a better demo alone does not settle the choice. Use the operating record to expose the commitments.
How do we know an AI workflow trial has worked?
A trial works when it meets agreed output and risk criteria with an acceptable total burden on the people and systems involved. Inspect accepted work, correction effort, exceptions and the downstream handoff. Keep the old process as a comparison where practical, and decide what evidence would justify continuation before reviewing results. Follow the complete-handoff test, then assess broader outcomes separately.
When should we disclose AI use in a workflow?
Decide disclosure according to the recipient's needs and applicable policy, contracts and legal requirements. Identify when AI involvement or unresolved uncertainty changes how someone should interpret an output. Assign an owner to confirm those requirements and make the explanation part of the handoff. The disclosure section gives a maintenance-request example without assuming a universal rule.
Who should maintain an AI workflow after launch?
Assign a technical owner for connections, configuration and changes, a business owner for acceptable results, and reviewers for routine outputs. Agree their capacity, escalation route and fallback before launch. These roles may overlap, but none should be left implicit. Use the support responsibilities to decide who can pause use and when retesting is needed.
