The AI Vendor: What You Are Buying and What the Agreement Says

When a component is vendor-hosted the buyer is buying an answer, not a component. The vendor runs it, changes it and measures it, and the buyer sends an input and receives an output. Nothing about accountability moves with it: the buyer still answers for what the output did to a customer. The ability to see, to test and to be told is what changes, and an agreement is the only place those three are settled.

Every difficulty in the arrangement follows from one lopsided fact. The accountability sits on one side of a boundary and the component sits on the other. The buyer cannot read it, cannot test it except by watching what comes back, and does not control the day it changes. Each of those three absences produces one section of a sensible agreement, and an agreement silent on any of them has left the buyer answerable for something it cannot examine.

What is actually being bought when a component is vendor-hosted?

A wedding caterer has an identical shape, and nobody finds it confusing. The host tastes the food, agrees a price, and the food arrives. The host does not see the kitchen, does not know which supplier the paneer came from this week, and does not know that the head cook changed in March. If a guest is unwell afterwards, the guest telephones the host, not the kitchen. The host bought a set of dishes at a time and a place. The host did not buy any ability to look inside.

A vendor-hosted serviceA component the buyer uses and somebody else runs, changes and measures, reached by sending an input and receiving an output. is that arrangement with data instead of dinner. At Sumeru Bank Limited, invented, the retail intake chain holds nine separately built components, and exactly one of them runs this way: component 2, the liveness check that decides whether the selfie image on an application belongs to a live human being in front of the handset. The other eight were built by the bank. For component 2 the bank sends an image and receives one word back, and there is nothing between those two things that the bank can look at.

Little of that depends on the component and almost all of it on the arrangement. The vendorThe supplier of a bought service. can be any supplier of any bought service, and its name changes nothing. A claim about a particular product dates within months. The shape of the arrangement does not date, and the shape decides what the bank will be able to say later.

What does not cross the boundary, and who answers for the output?

Here is the sentence people skip past, so read it twice. The vendor runs the component. The bank refused the applicant. The two are not descriptions of one event; they are two separate facts, and only the second has a customer attached to it. When one of the 620 telephones to ask why, nobody transfers the call across the boundary. There is nobody on the other end who has ever heard of that applicant, and no arrangement anybody can sign changes that.

Buying a component moves the work, moves the cost and moves the expertise, and moves none of the answering. The split is not a legal subtlety but a practical one. Any complaint shows it immediately: the person across the desk wants to know what happened to their application, and every sentence beginning with the words our vendor is heard as an evasion, correctly. So the useful question at purchase time is never whether the vendor is competent. The useful question is what the bank will be able to say, later, on a day when somebody asks.

Two things follow. First, the buyer needs a way to look, or it will be accountable for something it cannot describe. Second, the looking has to be settled in writing before the arrangement starts. Afterwards the buyer is asking a favour rather than exercising a term. Everything that follows works those two sentences out in detail.

What does the Vendor Assessment ask, and in what order?

A Vendor AssessmentThe set of questions a buyer puts before an arrangement is signed, and puts again while it runs, about what is bought and what can be seen. is a list of questions, put before anything is signed and put again while the arrangement runs. Sumeru Bank Limited settled on twelve. The twelve are that bank's own list and nobody's prescribed one, and twelve is a deliberate size. Three questions is a conversation and forty is a form nobody completes honestly. Twelve fits on one side of a sheet, and fitting on one sheet is the practical test of whether a checklist gets used or admired.

The order matters more than the count. The twelve run in three groups. Questions 1 to 5 settle what is being bought and what happens to the buyer's data. Questions 6 to 8 settle what the buyer can be shown, told and reported. Questions 9 to 12 settle what happens when things go wrong, who answers, what may be tested and what comes back at the end. Every question after the fifth is about the buyer's ability to look, and that is the half of the list that gets dropped when a purchase is being rushed through.

Questions 1 to 5: what is being bought, and what happens to the buyer's data?

Question 1 sounds trivial and is not. A component, a service and an outcome are three different purchases with three different failure modes. A buyer of a component is responsible for running it. A buyer of a service has somebody else run it and has bought availability. A buyer of an outcome has bought a promise about results. Of the three purchases that is the only one that can be silently wrong for months. Sumeru Bank Limited bought a service: an image goes in, an answer comes back, and the bank made no purchase of any particular rate of correctness.

Question 2 is the honest one. Can somebody at the bank, with nobody from the vendor present, describe the component in one sentence and name what it must not be used for? If not, the bank cannot supervise it and cannot explain it, and the sales material does not count as an answer. Questions 3, 4 and 5 then follow the data. Does it learn, and from whose data. What leaves the bank and what becomes of it. And whether what the bank sends improves something the vendor sells to somebody else.

Buyers skip the fifth question more often than any of the other eleven. The component improves over time sounds like a benefit rather than a question. Improvement is not a property of a component. Improvement describes somebody fitting something to something, and the second something may belong to the buyer. An arrangement where the buyer's customers' images make the component better for every other buyer is a perfectly ordinary arrangement, and the point is that the buyer decided it rather than discovered it.

Questions 6 to 8: what can the buyer be shown, told and reported?

Group two is where the arrangement stops being a purchase and starts being a relationship the buyer has to live inside. Question 6 asks what the buyer can be shown about one output, and within what time. Not the component, not the method, one output: this applicant, this image, this refusal, on this date. Question 7 asks about the notice periodHow far ahead of a change to the component the vendor tells the buyer, measured in working days before the change lands., meaning how far ahead of a change the buyer is told. Question 8 asks what performance measure the vendor reports, on whose population, and how often. A number measured on everybody else's customers is a fact about everybody else.

Whether these three are pleasant extras or the whole decision turns on a single question about the output, and it is worth asking out loud before the assessment starts. Does the output reach a customer without a person deciding? For component 2 the answer is yes: 620 applications were refused in the month and no human being read any of them before the applicant was told. Compare component 8, the drafting assistant, whose output is a first draft that somebody signs. There, a person stands between the answer and the world, and that person is a check the agreement did not have to provide.

Questions 9 to 12: what happens when it breaks, and what comes back?

Group three is the group everybody thinks they have covered. Question 9, unavailability, is the easiest clause in the whole assessment to write. Unavailability is easy to define and impossible to miss: nothing comes back, an alarm sounds within seconds, and somebody is telephoned. Question 10 names the person inside the buyer who is accountable for what the bought component produced. Question 11 asks what the buyer may run as an independent testA check the buyer can run itself on the live service, without asking the vendor for the result or taking the vendor's word for it., and how often. Question 12 asks about the exitThe end of the arrangement: what data and records come back to the buyer, in what form, and by when..

Unavailable and wrong are two different failures, and an agreement that answers only the first has covered the one that announces itself and left the one that does not. A service that is down for an hour costs the bank an hour. A service that is up and answering, and answering wrongly, costs the bank every applicant it touched until somebody noticed, and nothing at all draws attention to it. At Sumeru Bank Limited that difference is measurable: the unavailability route was written before go-live, and the remedy for being wrong took nine weeks to obtain.

What is a Data Processing Agreement for, and which of the twelve does it settle?

A Data Processing AgreementThe part of an arrangement that settles what data leaves the buyer, what may be done with it while it is away, and what returns at the end. follows the data rather than the service. The agreement answers what leaves, what may be done with it while it is away, and what comes back or is destroyed at the end. In the assessment's numbering it settles questions 4, 5 and 12, and that is genuinely useful: those three are exactly the questions a buyer cannot answer to anybody, internally or externally, without a document to point at.

Three of twelve is a quarter of the assessment. Buyers make one systematic mistake about the other three quarters, so what those quarters contain is worth stating precisely. A buyer that has a data agreement in place will often say the vendor arrangement is covered. A data agreement settles what happens to the data and settles nothing about what the buyer may see, be told or test. A data agreement is therefore one part of an assessment and not a substitute for one. A bank can hold an excellent data agreement and still be unable to say why one applicant was refused.

One nuance worth carrying. The agreement behind component 2 answered question 4 as far as what data leaves, and stopped short of where it lands and what is kept there afterwards. Leaving and landing are separate questions with separate answers, and where data is allowed to sit is a subject of its own.

What did the agreement behind component 2 answer, and what did it leave out?

Now put the twelve against a real document. The arrangement behind component 2 at Sumeru Bank Limited answered 5 of the 12 assessment questions, being 41.7 per cent. The five were question 1, what is being bought, question 2, what it does, question 4, what data leaves, question 9, what happens when the service is unavailable, and question 12, what happens at the end. Read that list on its own and it sounds like a reasonable document. An arrangement that sounds reasonable is worth studying rather than mocking.

Seven were unanswered, and three of the seven turned out to matter: question 6, what the bank could be shown about one output, question 7, what notice would precede a change, and question 11, what the bank could test independently. All three are about the buyer's ability to look, and every difficulty that follows is a consequence of holding the accountability while being unable to look. Nobody dropped them out of carelessness. Questions 6, 7 and 11 were dropped because at signing time they are the abstract ones, and the concrete ones are about price, uptime and data.

What could the bank establish about its own rejections, and what could it not?

Component 2 rejected 620 of the month's 10,000 applications. The bank reviewed 200 of those by hand, being 32.3 per cent of them, and found 31 genuine applicants among them, being 15.5 per cent. Applied to the whole 620 at the same rate that is about 96 people who should have got through and did not. All of that the bank established from its own records, without the vendor's help. Reviewing an application and the image attached to it is entirely within the bank's own walls.

Then it stopped. Ask why those 31 failed and the bank has no answer available. Question 6 was never answered. The bank sends an image and receives a pass or fail outputAn answer with nothing between it and the input that the buyer can inspect: no score, no reason, no record of what was weighed., and there is no score, no reason and no record of what was weighed. The bank had instead a pattern in what it had sent: all 31 were low-light images taken on a low-specification handset. Cathy O'Neil, in Weapons of Math Destruction, makes the general version of this point, that a component's errors rarely fall evenly across the people it touches.

A pattern in the inputs is a finding about the applications, not a finding about the component, and confusing the two is how a review ends up recommending something it has no evidence for. The bank could say what kind of application tended to be refused. The bank could not say whether the component was reading darkness, or resolution, or something else entirely. Question 11 was unanswered too, so the bank could not check either. The remedy the review recommended, a second route for a rejected applicant to prove they were real, took nine weeks to obtain. Question 9's answer covered the service being unavailable and had nothing to say about the service being wrong.

What did a change nobody was told about cost, in applications?

In month 5 the vendor changed the component. The bank learned of it in month 6, 15 working days after the change, from a release noteA published note describing what a vendor has altered in a service, usually issued after the alteration is already live. that somebody happened to read. Nobody concealed anything and nobody behaved badly. The agreement had simply never said when the bank would be told. Question 7 was one of the seven that went unanswered, and a vendor cannot comply with a term nobody wrote.

Now do the arithmetic, and watch an abstract clause turn into a number of human beings. Component 2 sees all 10,000 applications a month, spread over 20 working days, being 500 a working day. The bank's own test of a changed liveness component takes 4 working days, and it cannot begin that test until it is told there has been a change. Notice arriving 15 working days late means 15 days of not knowing plus 4 days of testing, being 19 working days, and 500 times 19 is 9,500 applications. Nine thousand five hundred files, being 95 per cent of a month's volume, met a component the bank had not tested and did not know had changed.

Read the clause the other way round and it becomes a purchasing decision rather than a legal one. Every working day of notice is worth exactly 500 applications. Four working days of notice, matching the length of the bank's own test, brings the exposure to zero. The test finishes exactly as the change lands. Ten working days of notice brings it to zero with six days left over to object before anything happens at all. There is no cleverness in this. The whole of it is one multiplication, and nobody performs it before signing.

What has to be true before the arrangement ends, rather than after?

Question 12 is last on the list and first in practice, and the reason is uncomfortable rather than clever. All the leverage a buyer holds exists before the first input is sent. At that moment the vendor wants the arrangement and the buyer can walk away at no cost. Once data has been flowing for two years, the buyer cannot walk away without a plan, and the plan depends on things only the vendor can provide. A buyer negotiating an exit while leaving is negotiating with nothing. The records and the data it needs are already on the other side of the boundary.

Anybody who has moved house with a deposit at stake knows this shape. The time to agree what counts as fair wear is the day the keys are taken, not the day they are handed back with the van outside. The agreement behind component 2 did answer question 12, and it is worth saying plainly that this was the arrangement's genuine strength: what came back, in what form and by when were all settled before the first image was ever sent.

Three things make an exit answer real rather than decorative. What comes back, meaning the records of what was decided and not only the data that was sent. In what form, meaning something the bank can read with its own systems rather than a format only the vendor uses. And by when. An exit with no date is a wish. Test the answer with one question: if the arrangement ended next month, could the bank still explain a refusal made last year? If not, the exit clause covers data and not accountability, and accountability never crossed the boundary in the first place.

How does a buyer actually use the twelve questions in practice?

The twelve are not an audit performed once and filed. In a bank that has settled into this, they get used in four places, and it is worth naming them because the list on its own looks like paperwork. Before signing, they are the negotiation: every unanswered question is either a term to ask for or a risk to accept in writing, and the difference between those two is the whole job. At approval, whoever signs off the use case reads the answers rather than the sales material. In the register entry, the field recording whether a use case was built or bought points straight back at this assessment. And at re-approval the same twelve are asked again. The answers age between one approval and the next.

The scale is worth keeping in view. Across Sumeru Bank Limited a sweep found 14 uses in all, and 4 of those 14 sit inside a bought service rather than something the bank built, being 28.6 per cent. Of the 5 uses the register had missed entirely, 3 were bought, being 60.0 per cent. The proportion is no accident: something bought arrives as a charge on a ledger, and something built inside a spreadsheet arrives as nobody's project. Bought things are easier to find than built things and harder to look inside, and a buyer that assumes the opposite gets both halves wrong.

Now the cost, honestly stated. Somebody always asks. Putting twelve questions to a vendor and recording the answers is a few days of one person's time. Set that against a chain that cost Rs 2,40,00,000/- to build once and costs Rs 65,00,000/- a year to run, on the invented bank's own figures, and the assessment is not the expensive part of anything. The expensive part is the nine weeks it took to obtain a second route for refused applicants, and the month of decisions nobody can now describe.