The procurement trap in enterprise AI

Nakup umetne inteligence v podjetjih pogosto nagradi najboljšo predstavitev, najširši seznam funkcij in najčistejšo zgodbo o prenosu tveganja. Past je v...

The procurement trap in enterprise AI

Predstavitev je dobila razpis

Zmagovalna predstavitev je bila čista. Uporabnik je zastavil vprašanje, sistem je odgovoril z navedbami, vmesnik je predlagal naslednji ukrep, nadzorna plošča pa je pokazala predvidene prihranke s samozavestjo, ki je običajno pridržana za letališko arhitekturo. Nabavna ekipa je opravila svoje delo, kot ga je opredeljeval postopek. Zahteve so bile zbrane, ponudniki ocenjeni, vprašalniki o varnosti izpolnjeni, pravne klavzule usklajene, izbrana rešitev pa je bila videti kot najzmogljivejša možnost. Vsak je lahko pokazal na dokument in rekel, da je bil postopek upoštevan.

Šest mesecev pozneje je bil postopek še vedno pravilen, delovanje pa izčrpano. Podatkovni priključki so delovali na vzorčnih virih, a so se mučili s pravim arhivom. Kakovost odgovorov je bila dobra v okolju ponudnika in nedosledna v notranjem delovnem toku. Ročni pregled je trajal dlje, kot je bilo pričakovano, ker nihče ni ovrednotil bremena dokazov. Ponudnik je imel načrt, kupec izjeme, operativa pa čakalno vrsto težav, ki niso sodile v prvotno tabelo zahtev. Nič ni bilo goljufivega. Nič ni bilo šokantnega. Nabavni postopek je kupil zmogljivost umetne inteligence in le delno pogoje, pod katerimi bi ta zmogljivost lahko postala delo.

To je nabavna past pri umetni inteligenci v podjetjih. Nabavni postopek je zasnovan za primerjavo izdelkov, zmanjšanje pravne izpostavljenosti, nadzor cene in dokumentiranje poštenosti. To so legitimni cilji. Toda vrednost umetne inteligence se pokaže v zapletenem prostoru med izdelkom in organizacijo: dostop do podatkov, preoblikovanje delovnih tokov, zajemanje dokazov, usposabljanje uporabnikov, obravnava izjem, posodabljanje modelov, varnostni položaj, integracijski dolg, revizijske zahteve, povratne zanke in odgovornost za rezultate. Če nabava ocenjuje viden izdelek, pogoje delovanja pa obravnava kot podrobnosti izvedbe, organizacija kupi obljubo in prejme projekt.

Past ni v tem, da so kupci nespametni. Večina kupcev dela s podedovanimi predlogami in resničnim pritiskom. Od njih se pričakuje, da omogočajo inovacije, zmanjšujejo tveganje, delujejo hitro, obvladujejo stroške, zadovoljijo varnost, spoštujejo predpise in se izognejo poznejši krivdi, kar je strnjen opis delovnega mesta s čustvenim razponom spenjalnika. Past je strukturna: umetna inteligenca v podjetjih se nabavlja kot programska oprema, obnaša pa se kot operativni model.

Nabava umetne inteligence vljudno spodleti, ko kupi privlačno površino in pusti drage pogoje delovanja za poznejše sestanke.

Nakup rezultata ni nakup izida

Podjetniški kupci pogosto vprašajo, ali sistem lahko ustvari izpis: povzetek, klasifikacijo, priporočilo, ekstrakcijo, osnutek, oznako tveganja, rezultat iskanja, analizo, dejanje poteka dela. To je razumno vprašanje in hkrati manjše vprašanje. Večje vprašanje je, ali lahko organizacija ta izpis spremeni v izid z dodeljeno odgovornostjo. Kdo ga prejme. Kaj z njim naredijo. Katere dokaze vidijo. Kdaj ga lahko zavrnejo. Kaj se zgodi, ko je napačen. Kako se napaka popravi. Kdo je lastnik metrike, ko prodajalec zapusti prostor.

Povzetek z umetno inteligenco ni izid. Delavec na primeru, ki s preverjenim povzetkom sprejme hitrejšo in bolje dokumentirano odločitev, je lahko izid. Ocena tveganja ni izid. Postopek triaže, ki primere pravično usmerja, beleži razloge in obravnava izjeme, je lahko izid. Odgovor klepetalnega robota ni izid. Zmanjšana obremenitev podpore brez zavajanja strank, izgube poti za eskalacijo ali ustvarjanja nevidne odgovornosti je lahko izid. Nabava mora kupiti pot od ustvarjenega izpisa do institucionalnega vedenja.

Ta pot prečka oddelke. Pravna služba skrbi za pooblastila in odgovornost. Varnost skrbi za dostop in izolacijo. Podatkovne ekipe skrbijo za izvor in kakovost. Operativa skrbi za čakalne vrste in kadre. Finance skrbijo za stroške in uresničitev koristi. Kadrovska služba lahko skrbi za oblikovanje dela. Skladnost skrbi za dokaze. Uporabniki skrbijo za to, ali sistem pomaga ali jih tiho naredi odgovorne za strojne ugibanja. Razpis, ki te skrbi obravnava kot polja za potrditev in ne kot vhodne podatke za oblikovanje, bo ustvaril elegantno dokumentacijo in krhko uvedbo.

Ta razlika spremeni tudi cene. Poceni orodje, ki zahteva drago preverjanje, ročno pripravo podatkov, po meri narejeno integracijo, dodatno upravljanje, nejasne dokaze in visoko podporo, je lahko drago. Dražje orodje z močnejšim izvozom, opazovanjem, oblikovanjem vlog, podatkovnimi pogodbami in nadzorom posodobitev je lahko cenejše za upravljanje. Nabava tega ne more videti, če primerja ceno licence, vse ostalo pa imenuje implementacija. Implementacija je tam, kjer projekti umetne inteligence hranijo svoje račune.

Kontrolni seznam raste okoli napačnega središča

Podjetniška nabava obožuje kontrolne sezname, ker kontrolni seznami ustvarjajo red in obrambno sposobnost. Ali sistem podpira enotno prijavo. Ali šifrira podatke. Ali zagotavlja revizijske dnevnike. Ali podpira naš jezik. Ali se integrira s sistemi za dokumente. Ali ponuja dostop na podlagi vlog. Ali ima zgodbo o upravljanju modelov. Ali podpira poročanje. Ta vprašanja so uporabna. Težava je v tem, da lahko da skrije veliko površino.

Da za revizijske dnevnike lahko pomeni surove tehnične dnevnike, ki zahtevajo strokovno razlago, in ne dokazov na ravni primera, ki jih lahko uporabi skladnost. Da za integracijo lahko pomeni, da API obstaja, ne pa, da je kupčev zapleten model vsebine razumljen. Da za dostop na podlagi vlog lahko pomeni vloge v izdelku, ne pa uskladitev z modelom pooblastil organizacije. Da za izvoz lahko pomeni, da podatki zapustijo sistem kot ploske datoteke brez izvora. Da za človeški nadzor lahko pomeni gumb za odobritev. Podjetniška umetna inteligenca je področje, kjer bi moralo mnogim odgovorom da slediti pokaži mi pod grdimi pogoji.

Kontrolni seznam bi moral rasti okoli operativnih vprašanj. Kateri dokazi morajo preživeti. Kateri viri podatkov so avtoritativni. Katera polja so preveč zastarela. Kateri primeri uporabe zahtevajo deterministične zapise. Katera dejanja zahtevajo odobritev človeka. Katere napake zahtevajo obvestilo. Katere spremembe zahtevajo ponovno oceno. Katere odvisnosti od dobaviteljev so sprejemljive. Katere pravice do izstopa so nepogajljive. Katere ekipe morajo spremeniti vedenje. Kateri nadzori bodo preizkušeni pred začetkom delovanja. Kontrolni seznam izdelka brez operativnega modela je nakupovalni seznam za kuhinjo, ki je nihče ni izmeril.

V nejasnih zahtevah je nenavadna tolažba. Ohranjajo razpis širok, zmanjšujejo konflikte in vsakomur omogočajo, da si predstavlja, da je njegova skrb vključena. Žal pa nejasne zahteve po oddaji naročila ne izginejo. Ponovno se rodijo kot zahtevki za spremembe, zamude, spori in predstavitve za usmerjevalni odbor z vedno bolj previdnimi glagoli. Natančnost se pred podpisom pogodbe zdi počasnejša. Pogosto pa je po njem veliko hitrejša.

Prenos tveganja je pogosto gledališče

Postopki javnih naročil poskušajo prenesti tveganje. Pogodbe, garancije, odškodninske klavzule, ravni storitev, certifikati, zavarovanja, pogoji obdelave podatkov. To je pomembno. Zrelo naročanje to potrebuje. Toda podjetniška umetna inteligenca ustvarja tveganja, ki jih ni mogoče v celoti prenesti, ker živijo v kupčevem kontekstu. Dobavitelj lahko zagotovi orodje, zaščitne ukrepe, podporo in dokaze. Kupec je lastnik podatkov, delovnega toka, pooblastil, vedenja uporabnikov, poti eskalacije in odločitve, ki sprejme rezultat. Pogodba ne more oddati presoje, ki se dogaja znotraj institucije.

Tu nekatere organizacije postanejo preveč samozavestne. Dobavitelj je prestal varnostni pregled. Model ima dokumentacijo. Pogoji pokrivajo varstvo podatkov. Storitev ima zaveze o razpoložljivosti. Dobro. Zdaj pa: kdo odloča, ali se odgovor z nizko zanesljivostjo lahko uporabi v primeru z visokim vplivom. Kdo opazi, ko uporabniki prenehajo pregledovati. Kdo obravnava pritožbo stranke. Kdo preverja, ali se primeri za usposabljanje ujemajo z resničnim delom. Kdo ustavi sistem, ko se spremeni politika. Če je odgovor dobavitelj, kupec morda kupuje upravljavsko fantazijo. Če je odgovor nihče, je kupec kupil prihodnji incident.

Prenos tveganja ustvarja tudi izkrivljene spodbude, ko kupci od dobaviteljev zahtevajo, da prevzamejo odgovornost za stvari, ki jih lahko nadzoruje le kupec. Dobavitelj se odzove z izključitvami, previdno konfiguracijo, napihnjenimi cenami ali nejasnimi zavezami. Kupec se odzove z dodatnimi klavzulami. Sčasoma pogodba postane oblazinjen prostor okoli delovnega toka, ki ga nihče ni zasnoval. Na papirju zelo varno. V torek manj uporabno.

Boljši pristop je razporeditev tveganja. Poimenujte tveganje. Dodelite del, ki ga lahko nadzoruje dobavitelj. Dodelite del, ki ga mora upravljati kupec. Opredelite skupne preizkuse. Opredelite dokaze. Opredelite eskalacijo. Opredelite pravice do začasne ustavitve. Opredelite nadzor sprememb. To je manj zadovoljivo kot pretvarjanje, da je bilo tveganje izvoženo v stisnjeni datoteki. Je pa tudi bližje resničnosti, trmasti značilnosti uspešnega delovanja.

Tveganje nakupa je enostavno dokumentirati. Tveganje delovanja je težje, ker čaka v čakalnih vrstah, izjemah, kakovosti podatkov in človeškem vedenju.

Pilotni projekt ni nabavna enota

Številni nakupi umetne inteligence v podjetjih se začnejo s pilotnim projektom. Povsem razumljivo. Pilotni projekti zmanjšujejo negotovost in pomagajo ekipam pri učenju. Past pri nabavi se pojavi, ko pilotni projekt postane merilo dokazovanja. Pilotni projekt pogosto ščitijo izkušeni uporabniki, skrbno izbrani podatki, neposredna pozornost dobavitelja, poenostavljena integracija, začasno upravljanje in občinstvo, ki je pripravljeno spregledati pomanjkljivosti. Proizvodnja je drugačna. Proizvodnja vključuje obseg, fluktuacijo zaposlenih, revizije, robne primere, varnostne omejitve, vstopnice za podporo, pravila hrambe, spremenjene prioritete in uporabnike, ki se niso udeležili navdihujočega uvoda.

Pilotni projekt bi moral zato preizkušati predpostavke proizvodnje, ne le zmogljivosti izdelka. Ali lahko običajni uporabniki opravijo delovni proces. Ali kakovost odgovorov vzdrži na resničnih podatkih. Koliko časa je potrebnega za pregled. Kateri zapisi so potrebni za revizijo. Katere izjeme so pogoste. Katere integracijske točke so občutljive. Kaj se zgodi, ko je vir zastarel. Ali sistem zna pravilno zavrniti. Ali ga organizacija lahko podpira brez inženirjev dobavitelja v klepetu ves dan. Če ta vprašanja odložimo do odobritve širitve, je pilotni projekt gledališče z boljšimi prigrizki.

Enota nakupa bi morala biti nadzorovan delovni segment. Segment vključuje primer uporabe, vire podatkov, pooblastila, uporabnike, postopek pregleda, dokaze, model podpore, proces sprememb in izhodno pot. Je ožji od strategije in širši od predstavitve. Mogoče ga je smiselno ovrednotiti, ker vsebuje stvari, ki ustvarjajo vrednost, in stvari, ki ustvarjajo stroške. Če segment deluje, širitev pomeni ponavljanje in prilagajanje znanega vzorca. Če deluje le orodje, širitev pomeni odkrivanje organizacije po eni odvisnosti naenkrat.

Zato bi morale metrike pilotnega projekta vključevati dolgočasne številke. Minute pregleda na primer. Odstotek popravljenih rezultatov. Primeri, zavrnjeni zaradi manjkajočih dokazov. Napake pri svežini virov. Število eskalacij. Razlogi za nestrinjanje uporabnikov. Popolnost izvoza. Incidenti, ki zahtevajo podporo dobavitelja. Čas za pojasnitev izpodbijanega rezultata. Te metrike so manj glamurozne od povečanja produktivnosti. So pa številke, ki določajo, ali produktivnost preživi.

Dostop do podatkov ni seznam povezovalnikov

Nabavni dokumenti pogosto sprašujejo, na katere sisteme se izdelek povezuje. To je nujno, a nezadostno. Povezovalnik so vrata. Ne pove vam, ali soba vsebuje označene police, aktualne zapise, zakonit dostop, dosledne identifikatorje, uporabne dokumente, ohranjen kontekst ali tla. Podatki v podjetjih redkokdaj vljudno čakajo. Vsebujejo zapuščinska polja, podvojene zapise, PDF-je s skrivnostmi, arheologijo SharePointa, oddelčne taksonomije, manjkajoče lastnike in datoteke z imenom končno, ker je optimizem obnovljiv.

Kupec mora razumeti, kaj sistem umetne inteligence potrebuje od podatkov, ne le kje podatki živijo. Ali potrebuje celotne dokumente ali izluščena polja. Ali potrebuje trenutno stanje ali zgodovinske posnetke. Ali potrebuje iskanje, ki upošteva dovoljenja. Ali potrebuje izvor podatkov. Ali potrebuje strukturirane oznake. Ali potrebuje širjenje izbrisov. Ali potrebuje pragove kakovosti podatkov. Ali potrebuje človeški popravek. Vsaka potreba spremeni stroške integracije in upravljanje. Povezovalnik, ki te potrebe ignorira, je le cev. Cevi so uporabne. Prav tako so razlog, da kleti poplavijo.

Dostop do podatkov ima pravne in družbene razsežnosti. Sistem lahko tehnično bere vir in še vedno nima pravice do uporabe za usposabljanje modela, analitiko, spremljanje zaposlenih ali avtomatizirano podporo pri odločanju. Uporabniki lahko zaupajo repozitoriju za en namen in nasprotujejo, ko njegova vsebina postane gorivo za drugega. Nabava, ki vpraša, ali se lahko povežemo, preden vpraša, ali smemo uporabljati, ustvarja prihodnja presenečenja. Presenečenje je slab mehanizem privolitve.

Dobro nakupovanje umetne inteligence zato vključuje skrbni pregled podatkov pred oddajo naročila ali vsaj pred širitvijo. Preverite neurejen korpus. Preizkusite izločanje. Preglejte dovoljenja. Izmerite podvajanje. Prepoznajte zastarela polja. Določite skrbnike podatkov. Preverite hrambo in soglasja. Razumejte, katerih podatkov ni mogoče premakniti. Ocenite stroške čiščenja. Če se zdi, da to delo zavlačuje nakup, ne pozabite, da bi nakup pozneje naletel na isto zmešnjavo, le da bi bila takrat priložena pogodba.

Upravljanje sprememb je izdelek

Poslovna umetna inteligenca ne ostaja nespremenjena. Modeli se posodabljajo. Pozivi se spreminjajo. Indeksi za iskanje se znova gradijo. Politike se premikajo. Viri podatkov se selijo. Uporabniki odkrivajo robne primere. Varnostna pravila se zaostrujejo. Prihajajo nove uredbe. Sistem, ki je prestal postopek naročanja, ni sistem, ki ga bo organizacija upravljala čez leto dni. Upravljanje sprememb zato ni administrativno breme okoli izdelka. Je del izdelka.

Naročnik bi moral vprašati, kako se predlagajo, preizkušajo, odobrijo, sporočajo, umaknejo in dokazujejo spremembe vedenja. Ali lahko kupec odloži posodobitev modela. Ali je mogoče spremembe pozivov različiti. Ali je mogoče spremembe iskanja primerjati. Ali je mogoče pakete politik zakleniti. Ali lahko dobavitelj zagotovi opombe ob izdaji, ki se nanašajo na operativno tveganje in ne na marketinško poezijo. Ali je mogoče primere z velikim vplivom pred napredovanjem preizkusiti z regresijskimi testi. Ali lahko organizacija vidi, katere primere je sprememba prizadela. Brez teh pravic kupec ni kupil sistema. Naročil se je na gibanje.

Notranje spremembe so prav tako pomembne kot dobaviteljeve. Oddelek spremeni obrazec. Ekipa za politike popravi smernice. Podatkovna ekipa spremeni ime polja. Vodja spremeni zasedbo. Pravna razlaga se premakne. Sistemi umetne inteligence segajo čez te meje, zato lahko majhne notranje spremembe premaknejo rezultate. Naročanje tega ne more rešiti samo, lahko pa zahteva operativni model, ki zaznava in upravlja gibanje. Če vsako spremembo obravnavamo kot lokalno izboljšavo nekoga drugega, postane delovni tok umetne inteligence hodnik, kjer se vrata odpirajo naravnost v ljudi.

Dobro upravljanje sprememb daje inovacijam pot. Ne blokira posodobitev. Posodobitve naredi pregledne. Ekipe lahko hitreje izboljšujejo modele in delovne tokove, ko vedo, kako preizkusiti, odobriti in obnoviti. Nasprotje upravljanja sprememb ni agilnost. Je neobvladljiv odmik s koledarjem izdaj.

Programska oprema je le del nakupa. Operativna pogodba odloča, ali programska oprema postane vrednost ali dobro dokumentiran vir sestankov.

Uporabniki niso cilj sprejemanja

Nabava uporabnike pogosto obravnava kot ciljno skupino za uvajanje. Usposobite jih, predstavite koristi, merite uporabo, slavite prvake, odpravljajte trenja. Del tega je koristnega. Toda uporabniki so tudi nadzorne točke, strokovnjaki na svojem področju in sistemi za zgodnje opozarjanje. Če sistemu ne zaupajo, morda nasprotujejo spremembam. Morda pa tudi zaznavajo, da delovnemu procesu primanjkuje dokazov, pooblastil, časa ali popravil. Nabavni proces, ki uporabnike vidi predvsem kot ljudi, ki jih je treba prepričati, bo spregledal informacije, ki jih nosijo.

Pred nakupom se pogovorite z ljudmi, katerih delo bo prevzelo rezultate umetne inteligence. Vprašajte, kakšne dokaze potrebujejo za ukrepanje. Kateri primeri so nevarni. Katera podatkovna polja so nezanesljiva. Katere izjeme požirajo čas. Katerih odločitev ne bi prenesli na druge. Katere napake bi bile sramotne, škodljive ali nezakonite. Kateri deli trenutnega procesa so neformalni, ker se formalni sistem nikoli ni naučil resničnosti. Ti odgovori niso odpor do sprememb. So zahteve z odtisi prstov.

Po nakupu naj povratne informacije uporabnikov napajajo nadzor sprememb in dokaze. Popravke, preglasitve, eskalacije in razloge za zavrnitve je treba meriti in obravnavati. Če uporabniki sistem ignorirajo, ugotovite, ali je napačen, počasen, mu ne zaupajo, je slabo nameščen, ni usklajen s spodbudami ali je preprosto manj uporaben, kot prikazuje nabavna zgodba. Sama uporaba je slab pokazatelj vrednosti. Ljudje uporabljajo slabe sisteme, ko so k temu prisiljeni, in se izogibajo dobrim sistemom, ko jih okoliški proces kaznuje za uporabo presoje.

Uporabniki si zaslužijo tudi jasnost. Če so rezultati umetne inteligence svetovalni, to povejte. Če so obvezni, povejte, kdo je lastnik odločitve. Če so preglasitve dobrodošle, jih ne kaznujte kot odstopanje. Če so dokazi obvezni, dajte čas za njihov pregled. Umetna inteligenca v podjetjih odpove, ko uporabniki postanejo človeški blažilniki med samozavestnim orodjem in nejasno institucijo. To ni uvajanje. To je izolacija.

Preizkus izhoda mora potekati pred vstopom

Izhod je najbolj zanemarjena nabavna zahteva, ker nihče ne želi razpravljati o koncu na začetku. A prav pri izhodu moč kupca postane resnična. Ali lahko organizacija odide z nedotaknjenimi podatki, metapodatki, pozivi, konfiguracijami, zapisi o vrednotenju, revizijskimi dnevniki, povratnimi informacijami uporabnikov, rezultati modelov, sledmi popravkov in dokazi o izbrisu? Ali lahko izklopi sistem, ne da bi izgubila zmožnost pojasniti pretekle odločitve? Ali lahko preide na drugo orodje, ne da bi morala zaposlene prositi, naj po eno stran naenkrat posnamejo zaslonske posnetke spomina institucije?

Preizkus izhoda mora biti praktičen. Pred širitvijo izvozite reprezentativen vzorec. Obnovite ga drugje. Preverite identifikatorje, časovne žige, poreklo, dovoljenja, priloge, popravke in zapise o odločitvah. Preverite, ali so dokazi še berljivi. Preverite, ali jezik pogodbe ustreza tehnični resničnosti. Če je izvoz počasen, izgubljiv ali odvisen od posebnega dela dobavitelja, ovrednotite to odvisnost. Upanje ni izhodna strategija. Je razpoloženje s slabim nadzorom različic.

Pravice do izhoda izboljšajo tudi trenutni odnos. Ko so podatki in zapisi prenosljivi, dobavitelji tekmujejo s storitvijo in vrednostjo namesto z ujetostjo. Kupci se manj bojijo poštenega vrednotenja. Notranje ekipe lahko načrtujejo z mislijo na zamenjavo. Arhitektura postane čistejša, ker mora biti pomen izrecen. Izhod ni pesimizem. Je higiena.

Čaka nas nabavni pregovor, ki ga je treba še zapisati: nikoli ne kupite sistema umetne inteligence, ki ga ne morete zapustiti, ne da bi pozabili, zakaj ste ga uporabljali. Za skodelico je predolg, kar je verjetno dobro. Skodelice imajo v pisarniški kulturi že tako dovolj odgovorov.

Nakup naj preide od dokaza k pogodbi in obratovanju, ne da bi pri tem izgubil neprijetna dejstva, odkrita na poti.

Ubežati pasti

Ubežati nabavni pasti ne zahteva junaške prenove. Zahteva premik središča nakupa od izdelka k delovnemu sistemu. Ozko opredelite primer uporabe. Zgodaj preizkusite resnične podatke. Ovrednotite trud za pregled. Zahtevajte dokaze, ki odgovarjajo na institucionalna vprašanja. Obvladovanje sprememb obravnavajte kot osnovno zahtevo. Kupite izstopne pravice. Vključite uporabnike kot domenske priče. Dodelite lastništvo rezultatov. Izmerite breme popravkov in izjem. Od dobaviteljev zahtevajte, da sistem pokažejo v neugodnih razmerah, saj podjetniška programska oprema večino svojega zrelega življenja preživi prav v neugodnih razmerah.

To bo nabavo na začetku naredilo manj urejeno. Razkrilo bo konflikte, ki so jih kontrolni seznami prej skrivali. Lastniki podatkov bodo odkrili obveznosti. Pravna služba bo potrebovala operativne podrobnosti. Varnost bo zahtevala dokaze. Obratovanje bo zahtevalo kadre. Finance bodo videle stroške, ki so prej prežali v grmovju. Dobro. Skriti strošek je še vedno strošek, le samovšečen.

Cilj ni trajno upočasniti nakupovanje. Cilj je narediti nakupovanje dovolj pošteno, da se lahko izvajanje premakne. Jasna operativna pogodba zmanjša poznejše spore. Preizkušena podatkovna pot zmanjša presenečenja pri integraciji. Realen model pregleda zmanjša gledališče uvajanja. Delujoč izstop zmanjša strah. Nabava postane način za ustvarjanje pogojev za vrednost namesto obreda, ki izbere najprepričljivejšo obljubo.

Zmagovalna predstavitev v uvodni zgodbi ni bila napačna. Bila je nepopolna. Pokazala je odgovor, ne institucije okoli odgovora. Nabava podjetniške umetne inteligence se mora naučiti kupiti tisto plast, usmerjeno k instituciji: dolgočasne pravice, evidence, vloge, teste in izstope, ki sposobnost spremenijo v urejeno delo. V nasprotnem primeru bo razpis še naprej izbiral sisteme, ki so ob oddaji videti dokončani in začnejo postajati resnični šele, ko so vsi že pogodbeno zavezani. To je drag način, da izvemo, kaj bi boljše vprašanje lahko odkrilo že prej.