Infrastruktura za avtomatizacijo obračunavanja AI je raven merjenja, računovodstva, pravilnika in poročanja, ki omogoča finančno razložljivost delovnih obremenitev agentov. Odgovarja na težje vprašanje kot običajna API analitika: ne le, kaj se je zgodilo, ampak kdo bi moral plačati za to, ali je bilo dovoljeno pred izvršitvijo, kakšna je bila cena, ali je bremenitev dokončna in kako je usklajena z računi ponudnika.

To je pomembno, ker se agenti in avtomatizacije AI redko obnašajo kot preproste enkratne zahteve za klepet. Eno dejanje uporabnika se lahko razširi na več klicev modelov, klicev orodij, ponovnih poskusov, branja in pisanja predpomnjenega konteksta, izvajanje kode, iskanje datotek, spletno iskanje, ustvarjanje slik, pretočne odzive, asinhrona opravila in paketne vrstice. Brez trajne zasnove obračunavanja postanejo stroški vidni šele naknadno, ko jih je že težko pripisati ali razložiti.

Za posameznega razvijalca, ustanovitelja, svetovalca ali graditelja storitev ni treba, da se infrastruktura obračunavanja začne kot velik finančni sistem. Potrebuje jasen model za dogodke uporabe, dodeljevanje, cenovne različice, nadzor porabe in usklajevanje. Cilj je izogniti se pogosti pasti obravnavanja grafikonov kot računov ali nadzornih plošč ponudnika kot vira resnice za obračunavanje, usmerjeno k strankam.

Kaj vključuje infrastruktura za obračunavanje avtomatizacije AI

Celotna plast obračunavanja pokriva življenjski cikel od sprejema zahteve do končnega poročanja. Pred zagonom zahteve preveri, ali ima klicatelj dovoljenje, proračun, dostop do modela, dostop do orodja in dovolj pričakovanega stanja. Med izvajanjem beleži izbranega ponudnika, razrešen model, kategorije žetonov, dogodke orodja, ponovne poskuse, stanje toka in identifikatorje asinhronih opravil. Po izvedbi poravna dejansko uporabo, sprosti neuporabljene rezervacije, zabeleži prilagoditve in razkrije poročila.

Zaradi tega obsega se infrastruktura za obračunavanje razlikuje od opazovanja. Orodja za opazovanje lahko sledijo klicem modela in merijo zakasnitev, število žetonov in napake. Infrastruktura za obračunavanje mora ustvariti denarne zapise, ki jih je mogoče preveriti. Potrebuje nespremenljivost, idempotenco, različico cenovnega kataloga, decimalno varno aritmetiko, dovoljenja v obsegu najemnika in način za usklajevanje notranjih zapisov z API-ji ali računi za uporabo ponudnika.

Ista razlika velja za analitične nadzorne plošče. Tabela, ki prikazuje porabo po modelu, je uporabna, vendar ni dovolj za podporo vračil, sporov, marž preprodajalcev, predplačniških stanj ali računov strank. Za obračun je potrebna glavna knjiga. Analitiko je mogoče zgraditi iz te glavne knjige, vendar knjiga ne bi smela biti zasnovana z obratnim inženiringom iz grafikonov.

Življenjski cikel zahteve: ponudba, rezervacija, izvedba, poravnava, uskladitev

1. Sprejem in ponudba

Življenjski cikel obračunavanja se začne pred pošiljanjem ponudnika. Prehod ali aplikacija mora identificirati račun, najemnika, uporabnika, ključ API, potek dela, zagon agenta, vzdevek modela, zahtevana orodja in način poverilnic. Nato mora oceniti stroške z uporabo izbranega modela, končne točke, pričakovanega vnosa, največjega učinka, konfiguracije orodja in trenutne različice cenovnega kataloga.

Cena je pogosto negotova. Izhodna dolžina ni znana. Zastopniki se lahko odločijo za uporabo orodij. Gostovana orodja lahko uvedejo ločene stroške. Pretakanje je morda preklicano. Paketna opravila imajo lahko delne napake. Dobra ponudba zabeleži tako oceno kot negotovost, namesto da se pretvarja, da ima zahteva končno ceno, preden se izvede.

2. Rezervacija

Za predplačniške račune ali stroge proračune mora sistem rezervirati sredstva pred izvršitvijo. Rezervacija lahko temelji na največjem številu žetonov, pričakovani uporabi orodja, proračunu delovnega toka ali omejeni oceni. Če se zahteva konča pod rezervacijo, se neporabljeno stanje sprosti. Če preseže oceno, sistem bodisi zavrne dodatno delo, zahteva odobritev ali poravna presežek v skladu s pravilnikom.

Rezervacija je še posebej pomembna za agentske zanke. Če se omejitve porabe preverijo šele po izvedbi, lahko ponovna nevihta ali slabo omejena zanka načrtovanja požre denar, še preden ima obračunska plast možnost posredovati.

3.Zajem izvajanja

Med izvajanjem mora sloj obračunavanja zbirati uporabo iz metapodatkov odziva ponudnika, končnih dogodkov uporabe pretakanja, rezultatov asinhronih opravil, rezultatov paketnih vrstic, dogodkov gostujočih orodij in API-jev stroškov ponudnika, kjer so na voljo. Beležiti mora tudi stanja napak in odpovedi. Prekinitev povezave odjemalca med pretakanjem ni enaka napaki ponudnika in niti ni enaka dokončanemu odgovoru s končno uporabo.

Za merjenje uporabe agenta API je lahko enota stranke, ki jo je treba plačati, zagon agenta, medtem ko je poravnalna enota infrastrukture pogosto na nižji ravni: klic modela, priklic orodja, čas izvajanja vsebnika, pisanje v predpomnilnik, branje predpomnilnika, operacija pridobivanja ali paketni element. Ohraniti je treba obe ravni.

4. Poravnava in prilagoditev

Poravnava pretvori zajeto uporabo v denar z uporabo posebne različice cenovnega kataloga. Zapis mora vključevati osnovo stroškov, valuto, ceno na enoto, pribitek ali popust, ponudnika, razrešen model, razrede žetonov, orodne enote in ali je rezultat začasen ali končen.

Nekaterih stroškov ni mogoče dokončati takoj. Asinhrona opravila se dokončajo pozneje. API-ji za uporabo ponudnika lahko zaostajajo. Računi lahko vključujejo pozne popravke. Zahtevam za pretakanje po prekinitvi povezave morda manjka končna uporaba. Glavna knjiga mora podpirati stanja, kot so ocenjeno, končno, prilagojeno, povrnjeno in fakturirano. Izogibajte se prepisovanju zgodovine; pripnite zapise prilagoditev, tako da razlaga ostane nedotaknjena.

5. Uskladitev

Uskladitev primerja interne zapise o uporabi z nadzornimi ploščami ponudnika, stroškovnimi API-ji in računi. Razlike so običajne: ponudniki lahko zaokrožijo drugače, poročajo pozno, spremenijo sheme računov ali izpostavijo manj podrobnosti kot prehod, zajet ob času zahteve. Vzdržljiva notranja knjiga vam omogoča razlago stroškov strank, tudi če so poročila ponudnika združena ali zakasnjena.

V finance usmerjeni standardi, kot je FOCUS, lahko pomagajo normalizirati nabore podatkov o stroških v oblaku za dodelitev in povratne bremenitve, vendar zaračunavanje umetne inteligence običajno potrebuje dodatna polja za razrede žetonov, vzdevke modelov, gostujoča orodja, vedenje predpomnilnika, zagone agentov in poverilnice ponudnika način.

Kaj meriti za agente AI in avtomatizacije

Osnovno štetje žetonov ne zadostuje več. Sodobne delovne obremenitve umetne inteligence lahko vključujejo več plačljivih razsežnosti, od katerih ima vsaka različne cene, omejitve in potrebe po dodeljevanju.

  • Vhodni in izhodni žetoni: Osnova za klice besedilnega modela, vključno s pozivom, dokončanjem in ustvarjeno vsebino odgovora.
  • Predpomnjeni kontekst: Predpomnjen vnos, ustvarjanje predpomnilnika, branje predpomnilnika in pisanje v predpomnilnik imajo lahko različne hitrosti in se ne smejo strniti v običajne vhodne žetone.
  • Žetoni sklepanja ali skritega računanja: Nekateri modeli izpostavljajo ločene kategorije uporabe za razmišljanje ali notranje računanje.Tudi če so skriti pred uporabnikom, lahko vplivajo na stroške in omejitve.
  • Žetoni za vdelavo: Poteki dela za pridobivanje in indeksiranje pogosto uporabljajo modele za vdelavo z lastnimi cenami in potrebami po dodeljevanju.
  • Multimodalne enote: Slike, zvok, video in datoteke se lahko označijo z žetoni ali zaračunajo glede na način enote.
  • Gostovana orodja: Spletno iskanje, iskanje datotek, izvajanje kode, vsebniki, uporaba računalnika, ustvarjanje slik, ozemljitev in zunanji priključki lahko povzročijo stroške brez žetonov.
  • Dogodki agentov: Zagoni, koraki, klici orodij, predaje, subagenti, ponovni poskusi, odpovedi in zaščitna ograja dogodki določajo uporabne meje za dodeljevanje.
  • Paketni in asinhroni elementi: Paketno opravilo bi moralo ohraniti poravnavo za posamezno vrstico ali za posamezno postavko, vključno z neuspelimi postavkami in ponovno poskusenimi postavkami.

Ponudniki že izpostavljajo številne od teh dimenzij na različne načine. Nekateri ponujajo kategorije žetonov, kot so nepredpomnjeni vhod, predpomnjeni vnos, ustvarjanje predpomnilnika in izhod. Nekateri izpostavljajo cene klica orodja ali čas izvajanja vsebnika. Nekateri prehodi omogočajo vnose stroškov na ravni zahteve po meri za vhodne žetone, izhodne žetone, branje predpomnilnika in pisanje v predpomnilnik. Praktični zaključek je preprost: načrtujte svojo shemo uporabe za več plačljivih razsežnosti že od začetka.

Meje dodeljevanja, ki se ne smejo prezgodaj strniti

Sledenje stroškov agenta AI je odvisno od ohranjanja pravih identifikatorjev. Če si veliko strank deli en ključ API ali če potek dela ni vezan na zagon agenta, postanejo poročila o stroških ugibanja. Uporabna knjiga lahko odgovori na vprašanja, kot so katera stranka, ključ, uporabnik, potek dela, zagon agenta, vzdevek modela, razrešen model ponudnika, orodje in poverilnica ponudnika so povzročili bremenitev.

Pogosta dimenzija dodeljevanja vključuje račun, najemnika, stranko, uporabnika, API ključ, projekt, potek dela, zagon agenta, zahtevo, poskus ponovnega poskusa, vzdevek modela, razrešen model, ponudnika, poverilnico ponudnika, obračunsko pot, orodje, regija in kataloška različica cen. V scenarijih preprodajalcev ali partnerjev boste morda potrebovali tudi ID-je strank na nižji stopnji, stanja v denarnici, načrte oznak, sklice na račune in ključe za idempotenco za denarne operacije.

To je eden od razlogov, da se mnogi proizvajalci sčasoma premaknejo z izvornega zaračunavanja ponudnika na model prehoda ali nadzorne ravnine. Večmodelni API prehod za ekipe lahko ohrani dosledno dodeljevanje med ponudniki, modeli, ključi in uporabniki, ko nadzorne plošče ponudnika nimajo istega objektnega modela.

Način poverilnic je odločitev o zaračunavanju

Način poverilnic določa, kdo je komercialno odgovoren za uporabo ponudnika. Promet, ki ga financira prehod, promet po lastnem ključu, ključi ponudnika, vezani na najemnika, združeni ključi ponudnika in promet, ki ga financira preprodajalec, imajo različna pravila za usklajevanje in marže.

BYOK lahko ohrani neposredno razmerje ponudnika in zmanjša dvoumnost označevanja, vendar je lahko poročanje razdrobljeno po računih v lasti strank. Združene poverilnice ponudnika poenostavljajo usmerjanje in nabavo, vendar zahtevajo močno dodelitev glavne knjige, tako da uporaba enega najemnika ne postane nevidna znotraj skupnega računa. Promet, financiran s prehodom, omogoča poenotena predplačniška stanja in nadzor nad maržami, vendar mora prehod vzdrževati kataloge cen, poverilnice ponudnika in postopke usklajevanja.

Zabeležite vir poverilnic in pot obračunavanja ob vsakem dogodku uporabe. To ni le varnostno področje. Določa, ali je zapis bremenitev stranke, prenosni strošek ponudnika, dogodek nadaljnje prodaje z maržo ali dogodek uporabe, ki bi moral biti prikazan samo v analitiki.

Kontrole porabe za agentske delovne obremenitve

Kontrole porabe so najučinkovitejše, ko delujejo pred odpremo in ostanejo vidne med izvajanjem.Podpirati morajo predplačniške preglede stanja, omejitve na ključ, proračune na uporabnika, proračune najemnikov, proračune delovnih tokov, sezname dovoljenih modelov, dovoljenja orodij, mehka opozorila, trde zavrnitve in začasne preglasitve.

Kontrole na ključ so še posebej uporabne, ker se ključi API pogosto preslikajo v aplikacije, stranke, avtomatizacije ali okolja. Ko ima vsak ključ jasnega lastnika in proračun, je mogoče brezhiben potek dela ustaviti brez zamrznitve celotnega računa. Za podrobnejšo obravnavo omejitev v obsegu ključa glejte LLM API omejitve porabe po ključu.

Kontrole porabe potrebujejo prednostni model. Na primer, stanje na računu je lahko zunanja meja, proračun najemnika je lahko pod njo, ključna zgornja meja je lahko pod najemnikom in proračun poteka dela je lahko pod ključem. Preglasitve morajo biti časovno omejene, revidirane in jasno navesti, na katero plast vplivajo.

Dobre kontrole prav tako ločijo opozorila od zavrnitev. Dolgo delujoč agent bo morda potreboval mehka opozorila pri 50, 80 in 95 odstotkih proračuna, čemur bo sledila elegantna zavrnitev dodatnih klicev orodij ali korakov modela. Nenadna ukinitev vseh dejavnosti lahko prepreči prekomerno porabo, vendar lahko pusti delovna mesta v zmedenih stanjih, razen če izvršilna plast ve, kako se pravilno ustaviti.

Knjiga uporabe: glavni predmet zaračunavanja

Knjiga je sistem zapisov. Vsaka vrstica glavne knjige mora predstavljati trajno uporabo ali denarni dogodek z dovolj konteksta za kasnejšo revizijo. Vrstica glavne knjige mora vključevati vsaj časovni žig, račun, najemnika ali stranko, uporabnika, kjer je na voljo, API ključ, ID zahteve, ID izvajanja agenta, ponudnika, razrešen model, končno točko, kategorije žetonov, enote orodja, status, valuto, ceno na enoto, različico kataloga, ceno, oznako, stanje poravnave in referenco za uskladitev.

Za izvedbo uporabite zapise samo za dodajanje za finančne dogodke. Izogibajte se posodabljanju končne bremenitve na mestu. Če ponudnik pozneje sporoči popravek, ustvarite prilagoditveno vrstico, ki se sklicuje na izvirnik. Če je vračilo izdano, ga zabeležite kot ločeno gibanje denarja. To močno olajša podporo strankam in usklajevanje računov.

Uporabite decimalno varno aritmetiko za denar in visoko natančna številska polja za uporabo. Napake pri zaokroževanju s plavajočo vejico so nesprejemljive v dobroimetju, denarnicah preprodajalcev ali izvozih računov. Uporabite tudi ključe idempotence za polnitev kredita, zajem spletnega trnka, asinhrono poravnavo, ročne prilagoditve, zagotavljanje strankam in operacije partnerja API. Ponovni poskus zahteve za spreminjanje ne bi smel ustvariti podvojenih dobropisov ali podvojenih bremenitev.

Različica cenovnega kataloga

Cene modela se spremenijo. SKU-ji ponudnika se spremenijo. Vzdevki modela so ponovno označeni. Razvijajo se stopnje orodij, stopnje predpomnilnika, modifikatorji regij, paketni popusti in trgovski pribitki. Zgodovinska uporaba bi morala ostati razložljiva po vseh teh spremembah.

Katalog cen mora vključevati preslikave SKU modela, ponudnika, končno točko, kategorijo žetona, vrsto orodja, enoto, valuto, datum veljavnosti, datum poteka, če je znan, paketno raven, vedenje predpomnilnika, modifikator regije, politiko označevanja ali popusta in izvor izvora. Poravnava mora shraniti uporabljeno različico kataloga, ne le trenutno ime modela.

To je pomembno za vzdevke modela. Če aplikacija pokliče generični vzdevek, kot je prednostni model kodiranja ali model hitrega klepeta, zapis zaračunavanja še vedno potrebuje model razrešenega ponudnika, uporabljen v času izvajanja. V nasprotnem primeru preteklih stroškov po spremembi pravil usmerjanja postane nemogoče razložiti.

Poročanje in API-ji, obrnjeni k strankam

Poročanje, obrnjeno k strankam, bi moralo izpostaviti tako agregate kot neobdelane dogodke uporabe. Agregati pomagajo uporabnikom razumeti porabo glede na dan, model, ključ, uporabnika, najemnika, potek dela, vrsto orodja, vedenje predpomnilnika in zagon agenta. Neobdelani dogodki pomagajo pri obravnavanju sporov, odpravljanju napak in povratni bremenitvi.

API-ji za poročanje morajo uporabljati stabilno razvrščanje, označevanje kazalcev na strani, pooblastilo v obsegu najemnika, redakcijo, varno pred takojšnjim pozivom, in izrecna stanja poravnave. Navesti morajo, ali so vrednosti ocenjene, končne, prilagojene ali fakturirane.Če je uskladitev računov končana, razkrijte referenco, ki podpori omogoča, da stranki vidno bremenitev poveže s postopkom notranje uskladitve.

Pri izdelkih, ki preprodajajo dostop z umetno inteligenco, postane poročanje strank na nižji stopnji del površine izdelka. Graditelj, ki izvaja AI API platformo preprodajalcev, potrebuje ključe v obsegu stranke, dobropise denarnice, poročila o uporabi, omejitve, pravila o maržah in idempotentne operacije zagotavljanja, ne le skupne porabe ponudnika.

Zasebno varovani obračunski zapisi

Zapisi obračunavanja bi morali biti uporabni brez privzetega shranjevanja neobdelanih pozivov. Za večino finančnih vprašanj potrebujete metapodatke: ID-je, model, število žetonov, orodne enote, časovne žige, status, cenovno različico in dimenzije pripisovanja. Shranjevanje celotnih pozivov lahko povzroči tveganje glede zasebnosti, hrambe in skladnosti, ki se mu je mogoče izogniti.

Obstajajo upravičeni primeri podpore in zlorabe, kjer lahko omejen zajem vsebine pomaga, vendar bi to morala biti ločena odločitev pravilnika s kontrolami hrambe, urejanjem, beleženjem dostopa in pričakovanji strank. Knjiga obračunavanja bi morala ostati na prvem mestu metapodatkov, da bi lahko delovala v strožjih načinih zasebnosti.

Odločitve o gradnji ali nakupu

Izvorno obračunavanje ponudnika je najpreprostejše izhodišče. Deluje, ko ste edini uporabnik, obstaja en ponudnik, ni preprodaje, ni notranjih povratnih bremenitev in ni potrebe po časovnih omejitvah zahtev, ki presegajo kvote ponudnika. Pokvari se, ko potrebujete dodeljevanje na stranko, proračune na ključni ravni, poročanje o poteku dela, poenotena stanja ali abstrakcijo ponudnika modela.

Obračunavanje na ravni prehoda omogoča enoten nadzor med ponudniki, vendar ustvarja operativno odgovornost. Vzdrževati morate cenovne kataloge, normalizirati uporabo ponudnika, obravnavati robne primere, specifične za ponudnika, usklajevati račune in podpirati spore. To delo se splača, ko uporaba umetne inteligence postane del izdelka ali storitve in ne strošek zaledne pisarne.

Predplačniško obračunavanje omejuje tveganje negativnih posledic in poenostavlja težko uveljavljanje, vendar zahteva rezervacije, vedenje pri neuspešnem plačilu, zadržanje stanja in jasno upravljanje asinhronih opravil. Naknadno obračunavanje je bolj gladko za zaupanja vredne stranke, vendar povečuje kreditno tveganje in naredi spremljanje v realnem času pomembnejše.

Model Gate je ustrezen, ko gradbenik želi OpenAI-združljiv dostop med modeli z enotnim obračunavanjem, API-upravljanjem ključev, analitiko uporabe, nadzorom skupine, Telegram operativnimi poteki dela in partnerjem API avtomatizacijo.Širše arhitekturno načelo še vedno velja za vse prehode ali nize ponudnikov: ohranite glavno knjigo neodvisno, eksplicitno in združljivo.

Pogoste napake pri implementaciji

  • Obravnavanje analitike kot knjige obračunavanja in poznejše odkritje, da grafikoni ne podpirajo računov, povračil, sporov ali uskladitev.
  • Štetje samo vhodni in izhodni žetoni, medtem ko manjkajo predpomnjeni žetoni, gostujoča orodja, izvajanje kode, vsebniki, shramba, multimodalni vnosi, asinhrone vrstice in paketni popusti.
  • Neuspešno beleženje razrešenega modela in različice cenovnega kataloga, uporabljene pri poravnavi.
  • Uporaba ključev API v skupni rabi med številnimi najemniki, kar uniči dodeljevanje in omeji porabo neučinkovito.
  • Preverjanje proračunov po izvajanju ponudnika namesto pred odpošiljanjem ali rezervacijo.
  • Predpostavimo, da pretakanje vedno vrne končno uporabo, tudi ko odjemalci prekinejo povezavo ali ponudniki ne uspejo med odzivom.
  • Poravnava paketnih opravil samo na ravni opravila in izguba dodeljevanja na ravni vrstic za ponovne poskuse in neuspele elementov.
  • Mešanje prometa, ki ga financira BYOK, prehod in prodajalec, brez beleženja vira poverilnic in poti zaračunavanja.
  • Prepisovanje končnih stroškov namesto dodajanja prilagoditvenih zapisov.
  • Uporaba aritmetike s plavajočo vejico za stanja, kredite, cene ali račune skupne vrednosti.
  • Ponovni poskus mutiranja kredita, ključa, webhooka ali operacij omejitve brez ključev za idempotenco.
  • Izpostavitev poročil o uporabi strank brez dovoljenj v obsegu najemnika, stabilnega označevanja strani in redakcij, varnih pred pozivom.

Praktična začetna arhitektura

A pragmatična prva različica je lahko majhna, vendar mora imeti prave meje. Začnite s prehodom API ali zahtevajte vmesno programsko opremo, ki identificira račun, ključ, vzdevek modela in potek dela. Dodajte različicsko tabelo cen. Ustvarite tabelo dogodkov uporabe za neobdelane odgovore ponudnika in tabelo glavne knjige za dogodke poravnanega denarja. Dodajte preverjanja stanja pred tiskom, dostopa do modela, dostopa do orodja in ključnega proračuna. Nato sestavite poročila iz glavne knjige, namesto da bi poročila obravnavali kot vir resnice.

Ko delovne obremenitve postanejo bolj posredniške, dodajte ID-je izvajanja agentov, zapise dogodkov orodij, pretočne stanja, poravnavo asinhronih opravil, zadržanja rezervacij, zapise prilagoditev in uvoze usklajevanja iz API-jev ali računov za stroške ponudnika. Za primere uporabe partnerjev ali preprodajalcev dodajte objekte strank na nižji stopnji, ključe v obsegu stranke, kredite denarnice, idempotentna polnjenja in izvoze uporabe, vidne strankam.

Ključno načelo načrtovanja je ohranjanje podrobnosti v času izvajanja. Za nadzorne plošče in račune lahko kadar koli pozneje združite podatke. Ne morete zanesljivo rekonstruirati konteksta najemnika, poverilnic, modela, orodja, predpomnilnika ali cenovne različice, potem ko so bili prvotni podatki zahteve zavrženi.

Zaključek

Infrastruktura avtomatiziranega zaračunavanja AI je tista, ki dejavnost posrednika spremeni v razložljive finančne evidence. Nahaja se med izvajanjem med izvajanjem in financami, zajema uporabo, preden se podrobnosti izgubijo, uveljavlja politiko porabe, preden se denar porabi, in izdeluje poročila, ki jim stranke, podpora in operaterji lahko zaupajo.

Trajni vzorec je ponudba, rezervacija, izvedba, poravnava in uskladitev. Merilni žetoni, predpomnjeni kontekst, orodja, asinhrono delo, ponovni poskusi in agent se izvajajo ločeno. Ohranite meje dodeljevanja. Cene različic. Način poverilnice obravnavajte kot polje za obračun. Zgradite nadzorne plošče iz glavne knjige, ki je samo za dodajanje, in ne obratno.

Za preproste poskuse so morda dovolj nadzorne plošče ponudnika. Za resnično avtomatizacijo, izdelke, usmerjene k strankam, storitve preprodajalcev in notranja orodja s smiselno porabo postaneta ustrezna knjiga uporabe in plast nadzora porabe osrednja infrastruktura, ne pa finančna naknadna misel.