Buying AI services: a procurement guide

AI services are unusually hard to buy. The field moves quickly, the vocabulary is unsettled, and the gap between a strong vendor and a weak one doesn't show up in the proposal. It shows up six months later, in a system nobody uses.

This guide is the checklist we'd want a buyer to hold us to. It applies whether you're a procurement officer scoring submissions or an owner comparing three quotes.

Questions that separate vendors

Skip "what AI do you use." Models change quarterly and the answer tells you nothing. Ask these instead, and listen for specifics:

• Who, by name, will do the work? Agencies that sell a principal and deliver a rotating bench are the most common source of quality drift. If subcontractors are involved, names and scopes should be disclosed up front.
• What happens when you leave? The honest answer names who owns the code, where it runs, and what documentation transfers. "You own everything" should appear in the contract, not the conversation.
• Show me a system still in use a year after handoff. Anyone can demo a build. Surviving twelve months of real staff and real edge cases is the actual product.
• What won't you automate? A vendor with no answer has never thought about failure modes. Good ones name the workflows they'd leave manual and why.

Deliverables to require in writing

The contract should name artifacts, not outcomes like "improved efficiency" that nobody can verify. The minimum set:

• Source code and configuration, owned by you, in a repository you control.
• Documentation written for the next person: how it runs, what to check when it misbehaves, and how to switch it off safely.
• Training for named staff, delivered before final payment, not promised after.
• A defined support window with response times, and a price for what comes after it.
• Data handling terms: what the vendor accesses, where it's processed, and what happens to it at exit. For public-sector buyers this section does the heavy lifting in any privacy review.

Red flags that predict stalls

Three patterns precede most failed AI projects we've been called in to rescue:

• A fixed-bid black box. If the team isn't involved while the vendor works, the system arrives as a surprise, and surprises don't get adopted.
• Platform lock dressed as convenience. If the work product only runs inside the vendor's proprietary platform, your exit cost is the rebuild. That's not a deliverable, it's a subscription with extra steps.
• No named internal owner on your side. Projects without an internal lead don't fail loudly. They just stop, around week six, when the novelty wears off.

Scoring smaller vendors fairly

Procurement frameworks often default to headcount as a proxy for capacity, which screens out exactly the principal-led firms that deliver this work best. More useful proxies: named accountability (who answers when something breaks), handoff quality on past work, and whether the vendor's own operation visibly runs on the systems they sell.

Transparency cuts both ways, so here is ours: Yellow Bird is a principal-led consultancy. The person you talk to is the person who does the work, named subcontractors are disclosed per scope, and everything we build is owned by the client at handoff. How we run engagements is documented in our services, and the contact page takes procurement inquiries with RFP references directly.