Crypto ·Serbian / Srpski

Šta se dešava kada AI dobije sopstveni novčanik?

Kada softverski modeli dobiju delegirano ovlašćenje novčanika, potrošnja postaje funkcija koja se poziva u kodu. Evo kako x402 mikro-plaćanja, stablecoin-i i polise upravljanja stvaraju ekonomske mreže za AI agente.

Konceptualni prikaz novčanika za AI agente koji prikazuje svetleću neuralnu mrežu povezanu sa kripto novčićima i blokčejn čvorovima plaćanja.

Pretpostavimo da je AI istraživački agent na pola puta izrade tehničkog izveštaja o naprednoj hemiji baterija.

Otkriva da mu je potreban naučni rad iza paywall-a, nekoliko minuta specijalizovanog računanja, pristup bazi patenata i prevod dokumenta sa japanskog.

Agent tačno zna šta mu treba.

Nezgodan deo je plaćanje toga.

U većini današnjih softverskih sistema, taj problem je rešen pre nego što je agent uopšte počeo sa radom. Čovek ili kompanija su otvorili račune, prihvatili uslove, kreirali API ključeve, povezali podatke o naplati i odlučili koje usluge softver sme da koristi.

Sada zamislite da agent otkrije uslugu koju niko nije unapred pripremio.

On zatraži skup podataka.

Server odgovara:

Ovo košta $0.004.

Agent proverava svoju polisu potrošnje. Dobavljač je dozvoljen. Cena je ispod njegovog limita po pozivu. Dnevni budžet i dalje ima prostora.

On autorizuje plaćanje, prima podatke i nastavlja sa radom.

Niko nije otvorio stranicu za plaćanje.

Zanimljiv deo nije to što je softver potrošio novac.

Zanimljivo je to što je plaćanje postalo deo same petlje izvršavanja softvera.

Softver je već mogao da troši

Softver pomera novac godinama.

Oglašivački sistemi se automatski nadmeću za prikaze. Trgovački algoritmi kupuju i prodaju finansijsku imovinu. Cloud aplikacije troše infrastrukturu koja može koštati hiljade dolara pre nego što čovek uopšte vidi račun.

Ali ovi sistemi obično deluju unutar finansijskog koridora koji im je neko unapred izgradio.

Kompanija je otvorila račun. Neko je prošao provere identiteta i usklađenosti (KYC). Povezan je način plaćanja. Prihvaćeni su ugovori. Postavljena su ograničenja. Izdate su identifikacione akreditivne kartice.

Softver može slobodno delovati samo unutar tog pripremljenog prostora.

To je važna razlika, jer zanimljiv problem za AI agente nije:

Može li softver da troši novac?

On to već može.

Teže pitanje je:

Može li softver kupiti nešto za šta tokom izvršavanja otkrije da mu je potrebno, a da čovek prethodno nije ugovorio taj odnos?

Kada novac postane poziv alata

Moderni AI agenti već komuniciraju sa spoljnim svetom putem alata (tools):

search_web()
translate_text()
query_database()
run_model()

Svaki alat izlaže neku mogućnost koju model nema sam po sebi.

Mašinski čitljiv sistem plaćanja dodaje još jednu mogućnost:

authorize_payment(amount, vendor, policy)

To ne pretvara AI u pravno lice. Novčanik softveru ne daje pasoš, kreditni rejting niti ugovorna prava.

Daje mu nešto uže: sposobnost autorizacije transakcija unutar pravila koja je neko drugi definisao.

Ta razlika je važna.

Novčanik ne pravi mašinu čovekom.

On pravi plaćanje pozivom funkcije.

Status 402 koji nikada nije postao sistem plaćanja

Veb decenijama ima neobičan statusni kod: HTTP 402 Payment Required .

Za razliku od poznatih kodova kao što su 200, 404 ili 500, sam HTTP nikada nije standardizovao kompletan tok plaćanja oko koda 402. U trenutnoj specifikaciji, on ostaje rezervisan za buduću upotrebu.

Protokoli kao što je x402 sada grade praktičnu semantiku plaćanja oko tog starog mesta .

Pojednostavljena interakcija izgleda ovako:

  1. Agent traži resurs.
  2. Server odgovara sa `402 Payment Required` i mašinski čitljivim uslovima plaćanja.
  3. Agent proverava zahtev u odnosu na svoju polisu potrošnje.
  4. Ako je dozvoljeno, pruža autorizaciju plaćanja ili dokaz.
  5. Server verifikuje tok plaćanja i vraća resurs.

Važna stvar nije sam statusni kod.

To je nestanak rituala plaćanja na stranici za naplatu (checkout).

Cena, autorizacija i plaćanje mogu postati deo iste razmene zahteva i odgovora.

Ta ideja više nije čisto eksperimentalna. Infrastruktura zasnovana na x402 već je integrisana u alate za agente i cloud sisteme, uključujući AWS Amazon Bedrock AgentCore tokove plaćanja .

Zašto stablecoin-i odgovaraju ovom obrascu

Ako softver treba da donosi odluke o potrošnji, pomaže ako je obračunska jedinica predvidljiva.

Agent sa operativnim budžetom od $20 ne bi trebalo da razmišlja o stanju čija vrednost može oštro da oscilira dok zadatak traje.

To je jedan od razloga zašto se stablecoin-i vezani za dolar, poput USDC-a, prirodno uklapaju u eksperimente sa mašinskim plaćanjima.

Oni kombinuju poznatu denominaciju sa programabilnom autorizacijom i poravnanjem na blokčejnu. Standardi kao što su EIP-3009 i Permit2 takođe mogu podržati potpisane autorizacije plaćanja koje od agenta ne zahtevaju da ručno konstruiše svaku interakciju kao zasebnu transakciju novčanika .

Ali stablecoin-i ne čine sistem lišenim rizika.

Oni uvode rizik izdavaoca, rizik pametnog ugovora, rizik čuvanja (custody), rizik lanca i mogućnost gubitka pariteta koji bi trebalo da održavaju.

Poenta je jednostavno u tome da je stabilna jedinica slična dolaru lakša za buđetiranje softveru nego izuzetno volatilni token.

Problem mikro-plaćanja je uglavnom problem arhitekture

Mašinska plaćanja postaju posebno zanimljiva kada je stvar koja se kupuje sićušna.

Agentu možda treba jedan red iz baze podataka, jedno izvršenje modela, nekoliko sekundi računanja ili konverzija jednog dokumenta.

Tradicionalni maloprodajni sistemi plaćanja često uključuju fiksne ili minimalne troškove obrade, što nezavisno poravnanje svake sićušne kupovine čini ekonomski neisplativim.

Ali ni blokčejnovi ne čine mikroskopska plaćanja besplatnim.

Transakcije na lancu imaju sopstvene naknade i kašnjenja poravnanja.

Tako stvarni problem postaje arhitektonski:

Koliko režijskih troškova plaćanja bi trebalo da postoji za poziv usluge od $0.002?

Mreže niskih troškova, sponzorisanje gasa, posrednici (facilitators), grupisanje (batching), vaučeri i agregirano poravnanje mogu smanjiti te režijske troškove .

Rezultat ne mora biti jedna blokčejn transakcija za svaki API poziv.

Ono što je važno jeste da softver može doneti veoma malu ekonomsku odluku sada, dok sistem plaćanja u pozadini upravlja efikasnim poravnanjem.

Agent ne poseduje budžet

AI novčanik može zvučati autonomnije nego što zapravo jeste.

U razumnijoj arhitekturi, agent je bliži zaposlenom sa strogo kontrolisanom korporativnom karticom nego nezavisnom vlasniku kapitala.

Neko finansira račun.

Neko odlučuje šta agent sme da kupi.

Neko odlučuje koliko sme da potroši.

Moderni sistemi AI novčanika zato naglašavaju delegiranje ograničeno polisom umesto neograničene kontrole .

Budžet: $20/dnevno
Po kupovini: maks $0.50
Dozvoljeni dobavljači: odobrena lista
Ograničene akcije: blokirane
Ljudsko odobrenje: potrebno iznad praga

Ako agent naiđe na uslugu od $40 tokom zadatka, on ne postaje preduzimljiviji.

On staje i traži dozvolu.

To je verovatno korisniji model agentnih finansija: ne finansijska nezavisnost, već ograničeni ekonomski autoritet.

Zatim softver može početi da kupuje od softvera

Kada kupovina postane poziv funkcije, otvara se zanimljivija arhitektura.

Istraživački agent može otkriti da mu je potreban OCR. OCR usluga može zahtevati specijalizovani jezički model. Ta usluga može zahtevati privremeno računanje.

Umesto da jedna kompanija unapred drži pretplate na svaki mogući alat, usluge bi mogle sve više kupovati uske mogućnosti jedne od drugih kako su im potrebne.

Istraživački agent
    ↓ plaća
Usluga pretrage patenata
    ↓ plaća
OCR usluga
    ↓ plaća
Prevodilački model

Ova vrsta mašinskog lanca snabdevanja se i dalje razvija i još uvek nije podrazumevani način na koji se AI sistemi grade.

Ali programabilno plaćanje to čini tehnički lakšim.

Zanimljiva promena je modularnost: usluga ne mora nužno imati dugoročni odnos naplate sa svakom drugom uslugom koju bi jednog dana mogla koristiti.

Može otkriti mogućnost, proceniti njenu cenu, kupiti je i nastaviti dalje.

Plaćanje je lakši deo

Sada pretpostavimo da istraživački agent plati drugoj usluzi $0.02 da sumira naučni rad.

Plaćanje funkcioniše savršeno.

Pitanje koje odmah sledi je mnogo teže:

Da li je sažetak uopšte dobar?

Priznanica sa blokčejna dokazuje da se novac pomerio.

Digitalni potpis može dokazati koja je usluga vratila rezultat.

Nijedno ne dokazuje da je odgovor bio tačan.

Tu se mašinska trgovina direktno sudara sa istim problemom koji se pojavljuje kod blokčejn orakla: kriptografija može verifikovati dokaze i poreklo, ali ne može magično verifikovati proizvoljne tvrdnje o svetu.

Tržištima mašina-mašini stoga je potrebno više od mreža za plaćanje.

Mogu im biti potrebni sistemi reputacije, potvrde (attestations), escrow ugovori, redundantni provajderi, mehanizmi sporova, automatski testovi, verifikabilno računanje ili ljudska eskalacija.

Plaćanje rešava poravnanje.

Ono ne rešava poverenje.

Opasan deo je dozvola

Očigledan naučno-fantastični strah je AI sa novčanikom koji divlja.

Neposredniji inženjerski neuspesi su manje dramatični.

Greška u ponovnom pokušaju (retry bug) mogla bi kupiti isti API rezultat deset hiljada puta.

Napad ubrizgavanjem instrukcija (prompt-injection) mogao bi pokušati da ubedi agenta da je neovlašćeno plaćanje deo njegovog zadatka.

Zlonamerna usluga mogla bi vratiti dinamički naduvanu cenu automatskom kupcu.

Kompromitovani potpisni ključ mogao bi softversku ranjivost pretvoriti u direktan finansijski gubitak.

Agent bi jednostavno mogao iscrpeti svoj budžet na pola puta kroz posao.

Nijedan od ovih scenarija ne zahteva odbeglu inteligenciju.

Zahtevaju samo uobičajene softverske greške kombinovane sa sposobnošću potrošnje.

Zato budžeti, liste dozvoljenih dobavljača, polise transakcija, granice čuvanja i pravila eskalacije postaju važniji kako plaćanja postaju lakša.

Kda novac postane poziv funkcije

Većim delom istorije veba, ekonomski odnosi su uspostavljani pre nego što je softver počeo da radi koristan posao.

Nalog je postojao prvi.

Pretplata je postojala prva.

Način plaćanja je postojao prvi.

Softver je delovao unutar tih granica.

Agentna plaćanja počinju da obrću taj redosled.

Softver prvo može naići na potrebu, drugo otkriti cenu, i treće odlučiti da li je ovlašćen da kupi rešenje.

To je suptilna promena, ali duboka.

Novčanik ne pretvara AI u ekonomskog građanina.

On pomera još jednu odluku — da li je ovo vredno plaćanja? — unutar petlje izvršavanja.

I kada plaćanje postane izvršno, najvažnije pitanje više nije:

Može li AI da plati?

Već:

Ko mu je dao dozvolu i koliko smo rasuđivanja spremni da delegiramo sa novcem?

1reads
Helpful0 Comments 0 Tipped0
Written bymirex

· 7 min read

Conversation

Comments 0

No comments yet

Start the conversation.