Find the POs that have been "almost done" for nine days
Open your procurement system and filter for purchase orders sitting in approval limbo. You will find a familiar pile: a PO waiting on a director who is in back-to-back meetings, a vendor who replied "can you resend the PO number?" and got buried, a duplicate request someone opened because they assumed the first one was lost, and three POs that bounced back because the attached quote expired. Nobody owns this chase. It falls to whoever notices at month-end, usually someone in IT or data who got pulled in to "just run a report."
That pile is exactly why purchase-order follow-up is a good first AI pilot for a technical team. The work is repetitive, the data already lives in structured systems you administer, and the upside is measurable in days-of-cycle-time rather than vague "productivity." Adoption pressure is real — the U.S. Census AI business adoption analysis and Deloitte State of AI in the Enterprise 2026 both show mid-market teams under the gun to show something working — but the trap is reaching for a flashy use case when the win is the unglamorous one in front of you. Scope the pilot to three jobs: pull the context on a stalled PO, draft the reminder to the right human, and flag the exceptions that a person needs to look at. Nothing in that list moves money or grants an approval.
The line you do not let the model cross
Here is where these pilots go sideways. A reminder fires to a vendor before the PO clears the three-way match, and now you have nudged a payment the approver never signed off on. Or the model "helpfully" re-sends a PO that was duplicated, and the vendor ships twice. The whole value of follow-up automation evaporates the moment it weakens the control it was supposed to support.
So draw the line in writing before you build: the model drafts, a human in finance or procurement approves and sends. Segregation of duties stays intact — the person who can approve a PO is never the system nudging it forward. Set your baseline this week from real numbers you can pull: average days a PO sits with an approver, count of duplicate follow-ups in the last quarter, how many vendor replies stalled because documentation was missing. Then run a weekly review of what the AI produced — reminders approved, drafts rejected and why, any exception that needed finance eyes. If the team is approving 80% of drafts unedited and the duplicate count is dropping, you have signal. If they are rewriting every draft, the model is generating busywork, not removing it. Once those numbers are owned by a named person, the AI Opportunity Score or the AI ROI Calculator can help you size the next move.
Govern the access, not just the prompt
For a technical team, the governance work is the part you are actually qualified to nail — and the part most pilots skip. The model needs read access to PO records, approval logs, and vendor contacts. It does not need write access to anything financial, and it should never see more vendor or banking detail than a reminder requires. The CISA AI data-security best practices are the right checklist for scoping that procurement access and the communication evidence you retain. The NIST AI Risk Management Framework gives you the four columns to fill in on one page: intended use, the risk if it misfires, how you measure it, and who is accountable when a reminder goes wrong.
Log every automated draft and every status update so an auditor can reconstruct what the system touched. Route any threshold exception to a person before a single vendor commitment changes. And only widen the pilot — to vendor onboarding, to invoice matching — once you can show shorter PO cycle times with no duplicate follow-ups and no surprises in finance review. On Monday, pull that "stuck POs" filter and count the pile. That number is your before.
