Hankehangete lõks ettevõtete tehisintellektis
Demo võitis hankemenetluse
Võitnud demo oli puhas. Kasutaja esitas küsimuse, süsteem vastas viidetega, liides soovitas järgmist tegevust ja juhtpaneel näitas prognoositud kokkuhoidu enesekindlusega, mis on tavaliselt reserveeritud lennujaamaarhitektuurile. Hankemeeskond oli teinud oma töö nii, nagu protsess seda ette nägi. Nõuded koguti, müüjad hinnati, turvaküsimustikud täideti, õiguslikud klauslid läbi räägiti ja valitud lahendus nägi välja kõige võimekam variant. Igaüks võis viidata failile ja öelda, et protseduuri on järgitud.
Kuus kuud hiljem oli protseduur endiselt korrektne, kuid tegevus oli kurnatud. Andmeühendused töötasid näidisallikatega, kuid vaeplesid päris arhiiviga. Vastuste kvaliteet oli müüja keskkonnas hea ja sisemises töövoos ebaühtlane. Inimülevaade võttis oodatust kauem aega, sest keegi polnud tõenduskoormuse hinda arvestanud. Tarnijal oli teekaart, ostjal erandid ja operatsioonil järjekord probleeme, mis ei mahtunud algsesse nõuete tabelisse. Miski polnud petturlik. Miski polnud šokeeriv. Hankeprotsess oli ostnud AI-võimekuse ja ainult osaliselt ostnud tingimused, mille korral see võimekus saaks muutuda tööks.
See on hankelõks ettevõtete AI-s. Ostuprotsess on üles ehitatud toodete võrdlemiseks, õigusliku riski vähendamiseks, hinna kontrollimiseks ja õigluse dokumenteerimiseks. Need on õigustatud eesmärgid. Kuid AI väärtus ilmneb toote ja organisatsiooni vahelises segases keskosas: andmejuurdepääs, töövoo ümberkujundamine, tõendite kogumine, kasutajakoolitus, erandite käsitlemine, mudeliuuendused, turvahoiak, integratsioonivõlg, auditinõuded, tagasisideahelad ja tulemuste omandus. Kui hankemenetlus hindab nähtavat toodet, käsitledes töötingimusi rakendusüksikasjadena, ostab organisatsioon lubaduse ja saab projekti.
Lõks ei seisne selles, et ostjad oleksid rumalad. Enamik ostjaid töötab päritud mallide ja reaalse survega. Neilt oodatakse innovatsiooni võimaldamist, riski vähendamist, kiiret tegutsemist, kulude kontrolli, turvalisuse rahuldamist, regulatsioonide järgimist ja hilisema süüdistuse vältimist, kompaktne ametikirjeldus, mille emotsionaalne ulatus on nagu klammerdajal. Lõks on struktuurne: ettevõtete AI ostetakse nagu tarkvara, kuid käitub nagu tegevusmudel.
Väljundi ostmine ei ole tulemuse ostmine
Ettevõtete ostjad küsivad sageli, kas süsteem suudab väljundit toota: kokkuvõte, klassifikatsioon, soovitus, väljavõte, mustand, riskimärgis, otsingutulemus, analüüs, töövoo toiming. See on mõistlik küsimus ja ka väike küsimus. Suurem küsimus on, kas organisatsioon suudab selle väljundi muuta tulemuseks, millega kaasneb vastutus. Kes selle kätte saab. Mida nad sellega teevad. Milliseid tõendeid nad näevad. Millal võivad nad selle tagasi lükata. Mis juhtub, kui see on vale. Kuidas viga parandatakse. Kes omab mõõdikut pärast seda, kui müüja on ruumist lahkunud.
AI kokkuvõte ei ole tulemus. Töötaja, kes kasutab kontrollitud kokkuvõtet kiirema ja paremini dokumenteeritud otsuse tegemiseks, võib olla tulemus. Riskiskoor ei ole tulemus. Triaažiprotsess, mis suunab juhtumeid õiglaselt, salvestab põhjused ja käsitleb erandeid, võib olla tulemus. Vestlusroboti vastus ei ole tulemus. Vähendatud tugikoormus ilma kliente eksitamata, eskaleerimisteid kaotamata või nähtamatut vastutust tekitamata võib olla tulemus. Hangetes tuleb osta tee genereeritud väljundist institutsionaalse käitumiseni.
See tee ületab osakondade piire. Õigusosakond hoolib volitusest ja vastutusest. Turvalisus hoolib juurdepääsust ja isoleeritusest. Andmemeeskonnad hoolivad päritolust ja kvaliteedist. Operatsioon hoolib järjekordadest ja personalist. Rahandus hoolib kuludest ja kasu realiseerimisest. Personaliosakond võib hoolida töö kujundusest. Vastavus hoolib tõenditest. Kasutajad hoolivad sellest, kas süsteem aitab või teeb nad vaikselt vastutavaks masina oletuste eest. Pakkumiskutse, mis käsitleb neid muresid märkeruutudena, mitte disaini sisenditena, toodab elegantse paberimajanduse ja habras juurutuse.
See eristus muudab ka hinnakujundust. Odav tööriist, mis nõuab kallist ülevaatust, käsitsi andmete ettevalmistamist, kohandatud integratsiooni, täiendavat haldust, ebaselgeid tõendeid ja suurt tuge, võib olla kallis. Kallim tööriist, millel on tugevam eksport, jälgitavus, rollikujundus, andmelepingud ja uuenduste kontroll, võib olla odavam käitada. Hangetes seda ei nähta, kui võrreldakse litsentsihinda, nimetades ülejäänut juurutamiseks. Juurutamine on koht, kus AI-projektid oma arveid hoiavad.
Kontrollnimekiri kasvab vale keskme ümber
Ettevõtete hanked armastavad kontrollnimekirju, sest kontrollnimekirjad loovad korra ja kaitstuse. Kas süsteem toetab ühekordset sisselogimist. Kas see krüpteerib andmeid. Kas see pakub auditilogisid. Kas see toetab meie keelt. Kas see integreerub dokumendisüsteemidega. Kas see pakub rollipõhist juurdepääsu. Kas sellel on mudelihalduse lugu. Kas see toetab aruandlust. Need küsimused on kasulikud. Probleem on selles, et jah võib peita suure pinna.
Jah auditilogidele võib tähendada tooreid tehnilisi logisid, mis nõuavad spetsialisti tõlgendust, mitte juhtumitasandi tõendeid, mida vastavus saab kasutada. Jah integratsioonile võib tähendada, et API on olemas, mitte et ostja segast sisumudelit mõistetakse. Jah rollipõhisele juurdepääsule võib tähendada rolle tootes, mitte vastavust organisatsiooni volitusmudelile. Jah ekspordile võib tähendada, et andmed lahkuvad tasapinnaliste failidena ilma päritoluta. Jah inimjärelevalvele võib tähendada kinnitamisnuppu. Ettevõtete AI on koht, kus paljudele jah-vastustele peaks järgnema näita mulle inetutes tingimustes.
Kontrollnimekiri peaks kasvama operatiivküsimuste ümber. Millised tõendid peavad säilima. Millised andmeallikad on autoriteetsed. Millised väljad on liiga aegunud. Millised kasutusjuhud nõuavad deterministlikke kirjeid. Millised toimingud vajavad inimese kinnitust. Milliste vigade korral tuleb teatada. Millised muudatused nõuavad uuesti hindamist. Millised tarnijasõltuvused on vastuvõetavad. Millised lahkumisõigused on läbirääkimatud. Millised meeskonnad peavad käitumist muutma. Milliseid kontrolle testitakse enne kasutuselevõttu. Toote kontrollnimekiri ilma operatiivmudelita on ostunimekiri köögi jaoks, mida keegi pole mõõtnud.
Hägusates nõuetes on omamoodi veider mugavus. Need hoiavad hanke laiahaardelisena, vähendavad konflikte ja lasevad kõigil ette kujutada, et nende mure on kaetud. Kahjuks ei kao hägused nõuded pärast hanke võitmist. Nad sünnivad uuesti muudatustaotluste, viivituste, vaidluste ja juhtrühma slaididena, millel on järjest ettevaatlikumad tegusõnad. Täpsus tundub enne lepingut aeglasena. Pärast seda on see sageli palju kiirem.
Riski üleandmine on sageli teater
Hankeprotsessid püüavad riski üle anda. Lepingud, garantiid, hüvitised, teenindustasemed, sertifikaadid, kindlustus, andmetöötluse tingimused. Need on olulised. Küps ostmine vajab neid. Kuid ettevõtete tehisintellekt loob riske, mida ei saa täielikult üle anda, sest need elavad ostja kontekstis. Tarnija saab pakkuda tööriista, kaitsemeetmeid, tuge ja tõendeid. Ostja omab andmeid, töövoogu, volitusi, kasutajakäitumist, eskalatsiooniteed ja otsust, mis võtab väljundi kasutusele. Leping ei saa välja tellida otsustusõigust, mis toimub institutsiooni sees.
Siin muutuvad mõned organisatsioonid liiga enesekindlaks. Müüja läbis turvakontrolli. Mudelil on dokumentatsioon. Tingimused katavad andmekaitse. Teenusel on tööaja lubadused. Hea. Nüüd, kes otsustab, kas madala usaldusväärsusega vastust võib kasutada suure mõjuga juhtumis. Kes märkab, kui kasutajad lõpetavad ülevaatamise. Kes tegeleb kliendi väljakutsega. Kes valideerib, et koolitusnäited vastavad tegelikule tööle. Kes peatab süsteemi, kui poliitika muutub. Kui vastus on tarnija, võib ostja osta valitsemisfantaasiat. Kui vastus on mitte keegi, on ostja ostnud tulevase intsidendi.
Riski üleandmine loob ka perversseid stiimuleid, kui ostjad paluvad tarnijatel vastutust võtta asjade eest, mida saab kontrollida ainult ostja. Tarnija vastab välistuste, ettevaatliku konfiguratsiooni, paisutatud hindade või hägusate kohustustega. Ostja vastab rohkemate klauslitega. Lõpuks muutub leping polsterdatud ruumiks ümber töövoo, mida keegi pole kavandanud. Paberil väga ohutu. Teisipäeval vähem kasulik.
Parem lähenemine on riski jaotamine. Nimetage risk. Määrake osa, mida tarnija saab kontrollida. Määrake osa, mida ostja peab haldama. Määratlege ühised testid. Määratlege tõendid. Määratlege eskalatsioon. Määratlege peatamisõigused. Määratlege muudatuste kontroll. See on vähem rahuldustpakkuv kui teeselda, et risk on zip-failina eksporditud. See on ka tegelikkusele lähemal, mis on eduka tegevuse visa omadus.
Piloot ei ole ostuüksus
Paljud ettevõtete tehisintellekti ostud algavad pilootprojektiga. See on mõistlik. Pilootprojektid vähendavad ebakindlust ja aitavad meeskondadel õppida. Hankelõks ilmneb siis, kui pilootprojektist saab tõestuse ühik. Pilootprojekti kaitsevad sageli ekspertkasutajad, kureeritud andmed, otsene müüja tähelepanu, lõdvendatud integratsioon, ajutine haldus ja publik, kes on valmis ebatäiuslikkust andestama. Tootmine on teistsugune. Tootmises on maht, töötajate voolavus, audit, äärejuhtumid, turvapiirangud, tugipiletid, säilitusreeglid, muutunud prioriteedid ja kasutajad, kes ei osalenud inspireerival avakoosolekul.
Pilootprojekt peaks seetõttu testima tootmiseeldusi, mitte ainult toote võimekust. Kas tavakasutajad suudavad töövoogu läbida. Kas vastuse kvaliteet püsib reaalsete andmete puhul. Kui palju ülevaatusaega on vaja. Milliseid kirjeid on auditi jaoks vaja. Millised erandid on sagedased. Millised integratsioonipunktid on haprad. Mis juhtub, kui allikas on aegunud. Kas süsteem oskab korrektselt keelduda. Kas organisatsioon suudab seda toetada ilma, et müüja insenerid terve päeva vestluses oleksid. Kui need küsimused lükatakse edasi kuni mastaabikinnituse järgsesse aega, on pilootprojekt teater paremate suupistetega.
Ostuühik peaks olema kontrollitud operatiivne lõik. Lõik hõlmab kasutusjuhtu, andmeallikaid, volitusi, kasutajaid, ülevaatusprotseduuri, tõendusmaterjali, tugimudelit, muudatuste protsessi ja väljumisteed. See on kitsam kui strateegia ja laiem kui demo. Seda saab sisukalt hinnata, sest see sisaldab asju, mis loovad väärtust, ja asju, mis loovad kulusid. Kui lõik töötab, tähendab mastaapimine teadaoleva mustri kordamist ja kohandamist. Kui töötab ainult tööriist, tähendab mastaapimine organisatsiooni avastamist üks sõltuvus korraga.
Seetõttu peaksid pilootprojekti mõõdikud sisaldama igavaid numbreid. Ülevaatuseminutid juhtumi kohta. Väljundite protsent, mida parandati. Juhtumid, millest keelduti puuduvate tõendite tõttu. Allika värskuse tõrked. Eskalatsioonide arv. Kasutajate erimeelsuste põhjused. Ekspordi täielikkus. Intsidendid, mis nõuavad tarnija tuge. Aeg, mis kulub vaidlustatud väljundi selgitamiseks. Need mõõdikud on vähem glamuursed kui tootlikkuse kasv. Need on ka numbrid, mis määravad, kas tootlikkus püsib.
Andmejuurdepääs ei ole liitmike loend
Hankedokumendid küsivad sageli, milliste süsteemidega toode ühendub. See on vajalik, kuid mitte piisav. Liitmik on uks. See ei ütle teile, kas ruumis on märgistatud riiulid, ajakohased kirjed, seaduslik juurdepääs, järjepidevad identifikaatorid, kasutatavad dokumendid, säilitatud kontekst või põrand. Ettevõtte andmed ootavad harva viisakalt. Neis on pärandvälju, duplikaatkirjeid, saladusi sisaldavaid PDF-e, SharePointi arheoloogiat, osakondade taksonoomiaid, puuduvaid omanikke ja faile nimega final, sest optimism on taastuv ressurss.
Ostja peab mõistma, mida tehisintellektisüsteem andmetelt vajab, mitte ainult seda, kus andmed asuvad. Kas see vajab täisdokumente või ekstraheeritud välju. Kas see vajab hetkeseisu või ajaloolisi hetktõmmiseid. Kas see vajab õigusteadlikku otsingut. Kas see vajab päritolu. Kas see vajab struktureeritud silte. Kas see vajab kustutamise levikut. Kas see vajab andmekvaliteedi lävesid. Kas see vajab inimese parandusi. Iga vajadus muudab integratsiooni kulusid ja haldust. Liitmik, mis neid vajadusi ignoreerib, on lihtsalt voolik. Voolikud on kasulikud. Need on ka põhjus, miks keldrid üle ujutatakse.
Andmejuurdepääsul on juriidilised ja sotsiaalsed mõõtmed. Süsteem võib tehniliselt allikat lugeda ja siiski puudub tal õigus seda kasutada mudeli treenimiseks, analüütikaks, töötajate jälgimiseks või automatiseeritud otsustustoeks. Kasutajad võivad usaldada hoidlat ühel eesmärgil ja vaielda vastu, kui selle sisu muutub kütuseks teise jaoks. Hange, mis küsib kas saame ühendada enne küsimist kas tohib kasutada, loob tulevikuüllatusi. Üllatus on kehv nõusolekumehhanism.
Hea tehisintellekti ostmine hõlmab seega ka andmete hoolsuskontrolli enne hankelepingu sõlmimist või vähemalt enne laiendamist. Uuri korratu andmekogu läbi. Testi väljavõtet. Kontrolli õigusi. Mõõda dubleerimist. Tuvasta aegunud väljad. Nimeta andmehaldurid. Kontrolli säilitust ja nõusolekut. Mõista, milliseid andmeid ei saa liigutada. Hinda puhastamise hinda. Kui see töö tundub ostu edasilükkamisena, meenuta, et ost oleks sama segaduse hiljem niikuinii leidnud, ainult lepinguga kinnitatuna.
Muudatuste haldus on toode ise
Ettevõtete tehisintellekt ei jää paigale. Mudelid uuenevad. Päringud muutuvad. Otsinguindeksid ehitatakse ümber. Poliitikad nihkuvad. Andmeallikad liiguvad. Kasutajad avastavad erijuhtumeid. Turvaeeskirjad karmistuvad. Uued määrused jõuavad kohale. Süsteem, mis läbis hankemenetluse, ei ole see süsteem, mida organisatsioon aasta hiljem opereerib. Muudatuste haldus ei ole seega halduslik lisakoormus toote ümber. See on osa tootest.
Hanked peaksid küsima, kuidas käitumismuudatusi kavandatakse, testitakse, heaks kiidetakse, teatatakse, tagasi pööratakse ja tõendatakse. Kas ostja saab mudeli uuendust edasi lükata. Kas päringumuudatusi saab versioonida. Kas otsingumuudatusi saab võrrelda. Kas poliitikapakette saab kinnistada. Kas tarnija suudab pakkuda väljalasketeateid, mis on seotud operatiivse riskiga, mitte turundusliku luulega. Kas suure mõjuga juhtumeid saab enne kasutuselevõttu regressioonitestida. Kas organisatsioon näeb, milliseid juhtumeid muudatus mõjutas. Ilma nende õigusteta pole ostja ostnud süsteemi. Ta on tellinud liikumise.
Sisemine muudatus on sama oluline kui tarnija muudatus. Osakond muudab vormi. Poliitikameeskond vaatab juhendi üle. Andmemeeskond muudab välja nime. Juht muudab personalikoosseisu. Õiguslik tõlgendus nihkub. Tehisintellektisüsteemid asuvad nende piiride vahel, nii et väikesed sisemised muudatused võivad väljundeid liigutada. Hange ei suuda seda üksi lahendada, kuid see võib nõuda toimimismudelit, mis tuvastab ja haldab liikumist. Kui iga muudatust koheldakse kellegi teise kohaliku täiustusena, muutub tehisintellekti töövoog koridoriks, kus uksed avanevad pidevalt inimeste pihta.
Hea muudatuste haldus annab innovatsioonile tee. See ei blokeeri uuendusi. See muudab uuendused loetavaks. Meeskonnad saavad mudeleid ja töövooge kiiremini parandada, kui nad teavad, kuidas testida, heaks kiita ja taastada. Muudatuste halduse vastand ei ole agility. See on haldamata triiv väljalaskekalendriga.
Kasutajad ei ole kasutuselevõtu sihtmärgid
Hanked käsitlevad kasutajaid sageli kui kasutuselevõtu sihtmärke. Koolita neid, suhtle hüvedest, mõõda kasutust, tähistage tšempione, eemaldage hõõrdumine. Osa sellest on kasulik. Kuid kasutajad on ka kontrollpunktid, valdkonnaeksperdid ja varajase hoiatamise süsteemid. Kui nad süsteemi ei usalda, võivad nad muutustele vastu seista. Samuti võivad nad tuvastada, et töövoog ei paku tõendeid, volitusi, aega ega parandusvõimalusi. Hankeprotsess, mis näeb kasutajaid peamiselt veenda vajavate inimestena, jätab märkamata info, mida nad endas kannavad.
Enne ostmist rääkige inimestega, kelle töö neelab AI väljundit. Küsige, milliseid tõendeid nad tegutsemiseks vajavad. Millised juhtumid on ohtlikud. Millised andmeväljad on ebausaldusväärsed. Millised erandid kulutavad aega. Milliseid otsuseid nad ei delegeeriks. Millised vead oleksid piinlikud, kahjulikud või ebaseaduslikud. Millised osad praegusest protsessist on mitteametlikud, sest formaalne süsteem pole kunagi reaalsust õppinud. Need vastused ei ole muutusele vastuseismine. Need on nõuded sõrmejälgedega.
Pärast ostmist peaks kasutajate tagasiside toitma muudatuste haldust ja tõendusmaterjali. Parandusi, ülekirjutusi, eskalatsioone ja keeldumise põhjuseid tuleks mõõta ja arutada. Kui kasutajad süsteemi ignoreerivad, uurige välja, kas see on vale, aeglane, usaldamatu, halvasti paigutatud, stiimulitega vastuolus või lihtsalt vähem kasulik kui hanke lugu. Üksinda kasutus on kehv väärtuse mõõdik. Inimesed kasutavad halbu süsteeme, kui nad on sunnitud, ja väldivad häid süsteeme, kui ümbritsev protsess karistab neid otsustusvõime kasutamise eest.
Kasutajad väärivad ka selgust. Kui AI väljund on nõuandev, öelge seda. Kui see on kohustuslik, öelge, kes otsustab. Kui ülekirjutused on teretulnud, ärge karistage neid kui kõrvalekallet. Kui tõendid on kohustuslikud, andke aega nende ülevaatamiseks. Ettevõtte AI ebaõnnestub, kui kasutajatest saavad inimlikud puhvrid enesekindla tööriista ja ebaselge institutsiooni vahel. See ei ole kasutuselevõtt. See on isoleerimine.
Väljumistest peaks toimuma enne sisenemist
Väljumine on kõige tähelepanuta jäetud hankenõue, sest keegi ei taha alguses lõpust rääkida. Ometi on väljumine koht, kus ostja võim reaalseks muutub. Kas organisatsioon saab lahkuda andmete, metaandmete, viipade, konfiguratsioonide, hindamisprotokollide, auditilogide, kasutajatagasiside, mudeliväljundite, parandusjälgede ja kustutamistõenditega, mis on puutumatud. Kas see saab süsteemi välja lülitada ilma kaotamata võimet selgitada varasemaid otsuseid. Kas see saab migreeruda teise tööriista ilma, et töötajad peaksid institutsiooni mälu ekraanipiltide kaupa üles jäädvustama.
Väljumistest peaks olema praktiline. Enne skaleerimist eksportige esinduslik osa. Taastage see kusagil mujal. Kontrollige identifikaatoreid, ajatempleid, päritolu, õigusi, manuseid, parandusi ja otsusprotokolle. Veenduge, et tõendid jäävad loetavaks. Kontrollige, kas lepingukeel vastab tehnilisele reaalsusele. Kui eksport on aeglane, kaotustega või sõltub tarnija eritööst, hinnake seda sõltuvust. Lootus ei ole väljumisstrateegia. See on meeleolu, millel on kehv versioonikontroll.
Väljumisõigused parandavad ka praegust suhet. Kui andmed ja protokollid on teisaldatavad, konkureerivad tarnijad teenuse ja väärtuse, mitte vangistuse alusel. Ostjad muutuvad vähem kartlikuks ausa hindamise suhtes. Sise meeskonnad saavad kujundada asendamist silmas pidades. Arhitektuur muutub puhtamaks, sest tähendus peab olema selgesõnaline. Väljumine ei ole pessimism. See on hügieen.
On olemas hanke vanasõna, mis ootab kirjutamist: ärge kunagi ostke AI süsteemi, millest te ei saa lahkuda unustamata, miks te seda kasutasite. See on kruusi jaoks liiga pikk, mis on ilmselt hea. Kruusid on kontorikultuuris niigi piisavalt vastutavad.
Lõksust välja pääsemine
Hankelõksust välja pääsemine ei nõua kangelaslikku ümberleiutamist. See nõuab ostmise keskme nihutamist tootelt töösüsteemile. Määratlege kasutusjuhtum täpselt. Testige reaalseid andmeid varakult. Hinnastage ülevaatusetöö. Nõudke tõendeid, mis vastavad institutsionaalsetele küsimustele. Käsitlege muudatuste haldust esmase nõudena. Ostke väljumisõigused. Kaasake kasutajad valdkonna tunnistajatena. Määrake tulemuste omanik. Mõõtke parandus- ja erandikoormust. Pange tarnijad süsteemi näitama koledates tingimustes, sest koledad tingimused on need, kus ettevõttetarkvara veedab suurema osa oma täiskasvanuelust.
See muudab hankimise alguses vähem korralikuks. See toob pinnale konfliktid, mida kontrollnimekirjad varem varjasid. Andmeomanikud avastavad kohustusi. Õigusosakond vajab operatiivset üksikasjalikkust. Turvalisus küsib tõendeid. Operatsioon küsib personali. Rahandus näeb kulusid, mis varem põõsastes ootasid. Hea. Varjatud kulu on ikkagi kulu, ainult et enesega rahulolev.
Eesmärk ei ole muuta ostmist igaveseks aeglasemaks. Eesmärk on muuta ostmine piisavalt ausaks, et rakendamine saaks liikuda. Selge toimimisleping vähendab hilisemaid vaidlusi. Testitud andmetee vähendab integratsiooniüllatusi. Reaalne ülevaatusmudel vähendab kasutuselevõtu teatri. Töötav väljumine vähendab hirmu. Hankimisest saab viis väärtuse tingimuste loomiseks, mitte riitus, mis valib kõige veenvama lubaduse.
Avastusloo võidudemo ei olnud vale. See oli puudulik. See näitas vastust, mitte institutsiooni vastuse ümber. Ettevõtte tehisintellekti hankimine peab õppima ostma seda institutsioonile suunatud kihti: igavaid õigusi, andmeid, rolle, teste ja väljumisi, mis muudavad võimekuse juhitud tööks. Muidu valib hange jätkuvalt süsteeme, mis näevad välja valmis auhinna andmise hetkel ja hakkavad reaalseks muutuma alles siis, kui kõik on juba lepinguliselt seotud. See on kallis viis õppida seda, mida parem küsimus oleks varem leidnud.