8 Questions to Ask Before Signing an AI Vendor:
A Procurement Checklist for Staying in Control
Comparing prices when you're hiring a vendor for AI adoption or a system build is the easy part. The hard part is judging whether the result, once it's done, actually belongs to you or to them. An international consultancy, Tenten, published a delivery methodology we think every owner buying a system should read once. Its most valuable idea isn't a technology choice; it's a single test: a system only counts as production-ready if it can be handed over. This piece translates that into procurement language for Taiwan SMBs, with 8 questions to ask before you sign.
Context: written for the Taiwan market; vendor and pricing examples are illustrative, not country-specific.
The core idea: cheap isn't scary. Un-hand-over-able is.
The single most quotable line in that methodology:
A cheap system that can't be handed over turns the monthly fee you saved into your next migration bill.
In plain terms, "hand-over-able" means: when the engagement ends, you get back the documentation, configuration, and code, and whoever takes over can actually understand and run it. In the opposite case, where only the original vendor can operate the system, what you pay every month isn't a service fee: it's ransom. This test has nothing to do with which technology stack is used, and nothing to do with whether AI is involved; it applies to any outsourced system.
Clarify responsibility first: an SLA won't run your operations for you
Plenty of vendors sell "big-cloud-grade availability guarantees" as a selling point. Take Hetzner, a European cloud provider, as an example of a published SLA: 99.9% monthly availability, which works out to about 43 minutes of allowed downtime a month, with overages compensated in service credits. Sounds reassuring? Notice what it doesn't cover: an SLA won't make your application highly available, and it doesn't protect against bad deployments, expired certificates, or database corruption. OS updates, permissions management, database maintenance, and restore drills all sit on your side of the line, or your vendor's, if you've delegated it.
Same logic for ISO 27001: it certifies the vendor's own management system, and it can't substitute for how your specific system is actually configured. None of these terms are unimportant, they're just a floor, not a ceiling. Ask at signing: who owns everything above that floor?
What a proper delivery actually looks like
That methodology breaks delivery into five phases, each with a checkable acceptance point. You don't need to understand the jargon in the table, just confirm your vendor can name the equivalent for their own project:
| Phase | What the vendor should deliver | What you should check |
|---|---|---|
| Fit assessment | Requirements, budget, and dependency inventory | Did they clearly list what's "not a good fit"? |
| Architecture design | System and data-flow diagrams | Where are the single points of failure? Is cost traceable? |
| Automation build | Automated scripts that can rebuild the environment | Can the environment actually be rebuilt? Are changes version-tracked? |
| Migration & cutover | Backup, testing, cutover, and rollback plan | Was there a rehearsal before go-live? Are rollback conditions written down? |
| Operational hand-over | Monitoring, alerting, operating manuals, permission transfer | Can your own people take over, or is the managed scope clearly written down? |
Two details worth flagging in that last phase specifically. First, "the data has been migrated" doesn't mean you're ready to cut over. The real bar is the new system passing health checks, login, writes, scheduled jobs, email sending, and backup-and-restore tests, restore especially: a backup that's never been rehearsed is functionally not a backup. Second, an alert with no owner and no runbook just turns errors into more notifications.
8 questions to ask before you sign
The original list was written for cloud migration; we've rewritten it for AI-adoption procurement. Question 2 folds in advice from another article on the same site, "measure first, then talk tools"; the rest follow the logic of the original list:
- Which processes should stay exactly as they are, and which are actually worth handing to the new system? (A vendor willing to say "this part isn't worth doing" is more credible.)
- Has the expected benefit actually been measured? Log a week of the current process before adoption, how much time it takes daily, how often it fails, so there's a real before/after to compare.
- Who holds the system's accounts, keys, and admin permissions?
- Where are backups stored, and how often is a restore drill actually performed?
- How long can an outage last before it's intolerable? How many hours of data loss is acceptable? (Make the vendor answer in plain language.)
- If go-live fails, under what conditions do you roll back to the old process, and who makes that call?
- After launch, who's responsible for updates, alerts, and incident response, and is it billed separately?
- When the engagement ends, can we get back the complete documentation and code?
If you only remember one, remember question 8. It sets your leverage in every renewal negotiation from here on.
One more thing: don't let "one-click approve" burn you
A common temptation once AI is in the picture is automating the review step all the way: one button, everything goes through. The time saved is real, and so is the risk. The principle is simple: reserve the shortcut for low-risk, reversible, routine actions; anything touching money, external sending, or deleting/modifying data keeps a human approval step and a record. Tools can reduce friction; they can't replace governance.
The methodology framework in this article is drawn from a public Tenten article (tenten.co, written in Chinese), service-marketing content with the vendor's own point of view, though the SLA and responsibility-boundary facts it cites are each backed by independently verifiable vendor documentation. The 8-question AI-adoption version is our own rewrite; question 2, "log a week before you evaluate," comes from another article on the same site. And yes, we're a vendor too. We're glad to be judged by this same checklist.
Our vendor has ISO 27001. Does that mean we're covered?
Certification covers the vendor's own management system; it can't substitute for the actual OS- and application-level configuration of your system. The same goes for cloud availability guarantees (an SLA): they only cover infrastructure, not high availability for your application, and they don't protect against bad deployments, expired certificates, or database corruption. Certifications and SLAs are a floor, not the finish line of acceptance testing.
Can we go with a much cheaper vendor?
Yes, but compare total cost of ownership, not just the monthly fee: ongoing operations staffing, monitoring, backups, incident response, and the migration cost if you ever switch vendors all need to be counted. A cheap system that can't be handed over turns today's savings into tomorrow's migration bill.
We have no technical staff. How do we accept a vendor's delivery?
Check three things that don't require reading code: one, is there written operating documentation and hand-over material, and was it produced well before the last day; two, has a restore drill actually been performed for you, not just promised verbally; three, does the contract state you get back the complete documentation and code when the engagement ends. If you're still unsure, bring in a third party for an independent acceptance review.
Feel free to ask us these same 8 questions
Tell us about the project you're evaluating, and we'll translate scope, acceptance criteria, and hand-over standards into plain language before you decide whether to move forward, and with whom.
Talk to us about your project