What your AI vendor needs from you

Six things have to come from the buyer, and none appears in a vendor's proposal, because none is the vendor's to deliver. A named person who can decide, in hours rather than weeks. Subject-matter expert time, quantified before signature rather than requested in week three. Access — credentials, a non-production environment, and data shaped like the real thing. Examples of the work done correctly, which only your organisation holds. Someone who tests before acceptance rather than at it. And a prioritised list that somebody keeps prioritising as the build changes what is possible. When a competent firm delivers late without anybody visibly failing, it is almost always one of these.

This is not a vendor's complaint dressed up as advice, and the strongest evidence comes from the place with the least incentive to flatter contractors. The US Government Accountability Office went looking for federal IT investments that had actually succeeded, asked the officials responsible what made the difference, and published the nine factors three or more of them named. Six of the nine describe the buyer's own organisation rather than the contractor's capability: program officials were "actively engaged with stakeholders" (all seven investments), "program staff had the necessary knowledge and skills" (six), senior department and agency executives "supported the programs" (six), "end users and stakeholders were involved in the development of requirements" (five), "end users participated in testing of system functionality prior to formal end user acceptance testing" (five), and "program staff prioritized requirements" (four) (US Government Accountability Office, Information Technology: Critical Factors Underlying Successful Major Acquisitions, GAO-12-7, October 2011).

The sample is its own finding. GAO asked ten departments each to name one mission-critical major IT investment that was preferably operational and had best achieved its cost, schedule, scope and performance goals. Three could not produce one that qualified — two named systems GAO did not accept as mission critical, and the third "was unable to locate key documentation and evidence needed for our review". The seven that could name one accounted for 73 percent of planned federal IT spending that fiscal year. Success in this work is rare enough that the conditions around it are worth copying, and most of them sit on the customer's side of the table.

A named person who can decide is the first obligation and the one that silently sets the pace. An AI build generates a different class of question, and the questions are not technical: should the system refuse this category of request outright, is this output wrong or merely unexpected, may it write to the record or only propose the write, what happens to a customer's data when they cancel. Each is a judgement about your business with a deadline attached, and a team that cannot get an answer does not stop — it guesses, ships the guess, and finds out in acceptance. Give that person a response commitment in writing, the same way you would expect one from the vendor. The duties that begin on the day the system goes live are a separate list, in who owns an AI system after it ships.

Subject-matter expert time is the second, and the obligation buyers underestimate by the widest margin, because it does not look like work — it looks like meetings. GAO found officials from three of the seven investments citing subject-matter experts' knowledge in their own areas as a factor in success, with one department relying on its experts' occupational health experience by "treating them as part of the development team and including them in decision making". Two went further and drew the program manager from the end-user organisation rather than from the IT function, on the grounds that somebody who knows how the work is actually done makes better calls about what the system must do. The number to negotiate is hours per week, named person, for the duration. Our two-week AI readiness assessment asks for two to three hours of stakeholder time across the fortnight, and that is the small version; a build that touches a real workflow needs far more, and it is cheaper to say so at signature than in week five.

Access is the third, and the most common cause of a week that produces nothing. The specifics are dull and belong in the plan with dates against them: named credentials in a system the vendor can actually reach, a non-production environment, a dataset with production's shape rather than production's seed data, a contact in whichever team owns the identity provider, and a security review booked rather than assumed. That last is where AI purchases stall in a way conventional ones do not, because the questionnaire in front of the reviewer was written for software that behaves the same way twice — what AI changes in procurement and security review covers the four documents that have to change. Book it at kickoff. A team waiting on access costs exactly what a team building costs, and produces nothing.

Examples of the work done correctly are the fourth, and the one thing here that cannot be bought, borrowed or generated. A vendor will ask in week one for real cases with the outcome a competent person actually produced, and the request sounds administrative until somebody tries to fill it. The cases have to be real, drawn from the workflow being automated, varied enough to include the awkward ones, and agreed — which usually means two people arguing about a dozen of them. That is days of your experts' time, not the vendor's, and it is the raw material for the acceptance threshold, the release gate, and the regression check that tells you the system got worse. The evaluation suite is what it turns into. A build that starts without it has no definition of done, and no amount of vendor competence supplies one.

Someone who tests before acceptance is the fifth, and GAO's version of the factor is unusually concrete. Five of the seven investments had end users test and validate components before formal acceptance testing: one department connected developers and end users through a virtual site for repeated online testing during development, and another built a mock port-of-entry facility and brought a core end-user group to it several times a year. GAO's reasoning is the part to borrow — end-user testing before acceptance demonstrates "earlier rather than later in the program life cycle" that the functionality will fulfil its intended use, and "if problems are found during this testing, programs are typically positioned to make changes that are less costly and disruptive than ones made later".

The AI version has an extra edge. Conventional acceptance asks whether a feature does what the specification said; an AI system is accepted against a distribution, so somebody has to read real outputs on real inputs and say which are wrong. That cannot go to whoever is free, because the judgement being exercised is domain judgement — and it cannot wait for the last week, because the value of it is finding the disagreement while the prompt, the retrieval strategy and the guardrails are still cheap to change.

A maintained priority list is the sixth, and the maintenance is the difficult half. Four of the seven investments credited the prioritisation of requirements, and one example is worth copying exactly: end-user representatives met the program office and the developer twice a week, for between half a day and a full day, to identify and prioritise requirements, because the development iterations ran four to five weeks and each ended with useable functionality going in front of the users. That is a published number for what participation costs, and it is larger than most buyers picture. An AI build changes the list faster than a conventional one, because the first evaluation run routinely reveals that the thing you ranked second is what the system is good at and the thing you ranked first is not. What to ask for in a weekly update is the cadence that keeps the list honest.

There is a role underneath all six, and it is a real occupation with a published price rather than an abstraction. The US Bureau of Labor Statistics describes computer systems analysts as people who "study an organization's current computer systems and design ways to improve efficiency" and "consult with managers to determine the role of information technology (IT) systems in an organization", reporting 544,400 such jobs in 2025, a median annual wage of $105,850 in May 2025, employment "projected to grow 8 percent from 2025 to 2035, much faster than the average for all occupations", and about 32,900 openings a year over the decade (US Bureau of Labor Statistics, Computer Systems Analysts, Occupational Outlook Handbook). If nobody on your side holds that job, somebody at the vendor holds it by default — so the firm being paid to build the system also decides what it should do, and then marks its own homework.

Stability is the quiet seventh, and GAO names it on both sides at once: four of the seven investments reported that government and contractor staff "were consistent and stable", one department attributing part of its success to the longevity of staff whose time on the program turned them into subject-matter experts in their own areas. Buyers reasonably ask a vendor to name the people who will do the work and to warn before changing them. The symmetrical commitment costs nothing and is rarely offered: name your own, and treat a change on your side as the same kind of event.

When these obligations go unmet the project does not fail in a way anybody can point at. It converts into waiting, and waiting is invisible on a status report. A question open for eleven days. A review meeting moved twice because the one person who can attend is travelling. A dataset promised in week two arriving in week seven, by which time the retrieval design it was meant to inform has been guessed at. An acceptance session that becomes a demo, because nobody qualified to judge the outputs was freed up to read any. Each is a week. None appears in a list of defects, and all of them arrive at the end as a date that moved.

The remedy is boring and it belongs in the agreement rather than the kickoff deck: a short schedule of buyer obligations with dates against them, and a written consequence when one slips. The consequence should be schedule relief rather than a penalty — the point is to make the dependency visible while it is still correctable, not to build a case. A proposal that names nothing at all the firm needs from you has either priced the absorption quietly or has not thought about it, and it is worth asking which.

One question at the end of a sales conversation settles whether any of this has been taken seriously: what do you need from us, by when, and what happens to the date if it is late. A firm that has run production AI answers with a list and a calendar, because it has been burned by every item on it. A firm that says the engagement is fully managed and requires nothing from you is describing something that cannot exist — the definition of a correct answer lives in your organisation, and so does whoever has to live with the wrong ones. The 150-branch student information system we built for Concordia Colleges ran 22 months across revenue and royalty rules, payroll, accounts, an integrated LMS and role-based portals for four kinds of user; nobody outside could have specified the per-branch royalty rules. Our AI development services page maps what the firm brings, and what AI development services actually include names the seven workstreams a scope should be written in — with these six obligations beside them, carrying the same dates.