skip to content W3C SVG

LHV tegi oma klientidele avaliku JSON-RPC 2.0 API

Publish date: Aug 3, 2026
Tags:

Sissejuhatus

LHV käivitas 15. juulil oma klientidele, sh eraklientidele, avaliku JSON-RPC 2.0 API.

Esimesed internetipangad ehitati Eestis 1996. aastal, ehk siis võttis 30 aastat, et jõuda brauseri-põhisest eraisikute internetipangast API-põhise eraisikute internetipangani, seda hoolimata sellest, et meie rahvusliku IT omamüüdiks on lõputu internetilembus ning programmeerivad lasteaialapsed.

Ah et miks te sellest API-st midagi kuulnud ei ole? Sest pressiteade ütleb midagi muud, pressiteade ütleb, et “LHV pakub nüüd esimese pangana Eestis enda klientidele võimalust ühendada pangakonto tehisintellekti tööriistadega.”

JSON-RPC 2.0

JSON-RPC 2.0 on kena väike raamistik RPC API-de koostamiseks. Kindlasti mitte ideaalne ja igasse olukorda sobiv, aga 95% kasutusjuhtude jaoks ühendab ta OpenAPI ja gRPC parimad omadused. Temal on ainult üks väike viga, nimelt võttis OpenAPI (et ta iseendale kurku kinni jääks) ühe või teise ajaloolise keerdkäigu tõttu kogu tähelepanu ja turuosa. Ja seetõttu ongi JSON-RPC ilus, aga ilma suurema hulga vajalike tööriistade ja muu ökosüsteemita.

Sellest hoolimata vaatasin ma kümmekond aastat tagasi lakke, lasin vilet ja otsustasin, et saagu nii, et üks popp tükk Eesti e-ühiskonnast jookseb suuresti JSON-RPC peal (tulenevalt liideste semantikast oleks OpenAPI olnud selle koha peal õudus kuubis).

Võimalik, et oli vale valik (ennekõike sellesama tööriistade puuduse tõttu), kuniks astus lavale MCP, Model Context Protocol.

Model Context Protocol

Model Context Protocol (MCP) on oma olemuselt lihtsamapoolne konventsioon selle kohta, kuidas kasutada JSON-RPCd selleks, et liidestada omavahel LLMe (õigemini mingit LLMi ümber olevat agenti või rakist) ja väliseid infosüsteeme.

Selles konventsioonis on mõned nüansid, mis (väidetavalt) teevad tema kasutamise LLMide liidestamiseks eriti sobivaks, aga selles kõiges pole midagi eriti erilist.

Järgnev on näide sellest, kuidas üle MCP LHV panga käest oma kontojääki küsida (pildil ei ole HTTP päiseid koos pääsutokeniga, sellest edaspidi).

----- Client >> MCP server -----
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_balances",
    "arguments": {
      "iban": "EE50XXXXXXXXXXXXXXXX"
    }
  },
  "id": 2
}
---------------------------------------

----- Client << MCP server -----
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"balances\":[{\"iban\":\"EE50XXXXXXXXXXXXXXXX\",\"availableBalance\":1234.56,\"settledBalance\":1234.56,\"reservedBalance\":0.00,\"currency\":\"EUR\"}],\"error\":null,\"success\":true}"
      }
    ],
    "isError": false
  }
}
---------------------------------------

Tõsi, siin on mõned nüansid, näiteks see, et kusagil ei ole kirjas, mis asi on availableBalance – on see sentides (hästi tavaline pangasüsteemides) või eurodes? On eeldus, et väli text antakse tervikuna LLMile närida ning LLM siis tuletab sealt ise, mis vaja, ka siis, kui see liides peaks iga päev muutuma. Paraku ütleb Hyrumi seadus, et kui üks asi on ükskord juba kirja pandud, siis peab ta nii jääma, ehk siis seda liidest võib üsna rahulikult käsitleda ka tavalise API-na, tuletades vajalike kohtade peal puuduva semantika ise. Ei ole “korrektne”, aga töötab.

MCP, isikutuvastus ja volitamine

Mõistagi ei taha me, et iga internetiühendusega tont saaks meie kontojääke näha ja selleks on vaja API poole pöörduja kuidagi tuvastada.

MCP näeb selleks ette täiesti standardse meetodi: OAuth koos mõnede lisavidinatega. Ääremärkus: kes iganes selle viidatud dokumendi kirjutas, ei peaks selliseid dokumente kirjutama. Ta ajab sassi autentimise ja volitamise ning kirjeldab täiesti tõsimeeli, et “turvameetmeid tuleb rakendada, kui nii on kombeks”. See on üks ebameeldiv tõdemus, et haibilainel sõitev AI-sektor ning pädev infoturve ei ole senimaani üksteist tantsule palunud.

LHV realiseerib selle kõik üsna kaunisti.

  1. well-known ressurss, mis kirjeldab, kuidas autentimine toimuma peaks: https://mcp.lhv.ai/.well-known/oauth-protected-resource/mcp
  2. OAuth authorization server: https://auth.lhv.ai – muuseas veidi bugine, aga las see praegu jääb. Interaktiivne kasutajaliides, kus kasutaja (füüsiline isik) saab ennast autentida, et OAuth kliendile (agendile) väljastataks asjakohased mandaadid.
  3. Kasutusel on autentimata OAuth 2.0 Dynamic Client Registration Protocol, ehk siis maakeeli: iga internetiühendusega tont saab endale LHV MCP süsteemis OAuth kliendi registreerida (klassikalises mudelis on see terve eraldi protseduur). Ega agentidega palju muud moodi ei saakski.
    • Olgu siis selle koha peal selgitatud, et puhttehnilises mõttes on “kliendi registreerimine” ekvivalentne “agendile isikukoodi väljastamisega”. Masinale või protsessile tekib unikaalne identifikaator.
  4. Pärast õnnestunud autentimist tehakse veebilehitsejas tavaline HTTP ümbersuunamine, mille tulemusena saab agent kätte OAuth authorization code ning selle alusel access tokeni ja refresh tokeni.
  5. Sealt edasi jätkub juba tavaline MCP kasutus, mille käigus on saadud access token kasutusel kui bearer token. Liida oma AI agenti, või kasuta Pythoni skriptist. Lisaks lühiajalisele access tokenile on kasutusel ka pikaajaline refresh token, mis võimaldab agendil toimetada pikemat aega, ilma et kasutaja peaks ennast uuesti autentima.

JWT kujul antud access tokeni keha on selline:

{
  "sub": "7XXXXX:2XXXXX",
  "auth_id": "07337f4b-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "auth_level": "STRONG",
  "iss": "https://auth.lhv.ai",
  "display_name": "OÜ ABCDEFG",
  "aud": "https://mcp.lhv.ai/mcp",
  "nbf": 1784804673,
  "user_id_authorized": 2XXXXX,
  "user_id_role": 7XXXXX,
  "scope": [
    "accounts:read",
    "transactions:read"
  ],
  "module_name": "SID",
  "exp": 1784805573,
  "iat": 1784804673,
  "jti": "83a7aa12-fec7-4082-bfd4-629ed98cbf77"
}

On oluline märkida, et selline token väljastatakse, kui eraisik autendib ennast pangale ja soovib esindada mingit teist isikut, antud juhul üht OÜ-d. Sellest edaspidi.

Jah, aga?

Ehk siis miks see oluline on? Tegivad beeta-teenusena ühe API või MCP serveri, mis sellest siis on? Mõnel põhjusel.

Demüstifikatsioon

Suurem osa sellest, millest praegune populaarne “AI” kokku käib, on üsna tavaline ja kusagilt mujalt pärit ning on oluline lõpetada selle kõige müstifitseerimine. (Igaks juhuks ütlen: LHV-le siin midagi pahaks panna ei saa, nende pressiteade peabki olema kirjutatud zeitgeisti arvestades.)

Natuke meenutab see mõne hea aasta tagust juttu, kuidas “pilv ja API” kõik üle võtavad, aga päeva lõpuks selgus ikka, et “pilv” on kellegi teise kallis arvuti ning “API” ükskõik mis kokkukäkitud integratsioon, mis kellelgi kuidagi parasjagu välja tuleb. Nagu ennegi.

Mis ei tähenda, et päriselt suur LLM ei oleks muljetavaldav saavutus või et “pilv” ei oleks paradigmanihet tekitanud. Aga jätkem müstifikatsioonid müstikutele ja olgem insenerid.

Kui me tahame olla “maailma kõige targem majaehitaja rahvas” (vrdl: “kõige AI-targem rahvas”), ei saa me leppida Soome kataloogidest pärit majade ostmisega, vaid tuleb ise õppida ära vähemalt see, kuidas maju ehitatakse, isegi kui kõiki materjale ise toota ei suuda (vrdl: ei saa sõita selle seljas, mida AI-müügiinimesed meile räägivad, vaid tuleb ise debuger kätte võtta ning ka mõtlemise värgendust rakendada).

Ja siis see teine teema

LHV MCP server on päris tore kaasus, mille pealt mõtelda, mida kogu selle “AI-agentidele isikukoodid” ideega peale hakata. Seda eriti seetõttu, et plaani õigustavates tekstides on siin ja seal LHV nimi läbi käinud kui võimalik näite-kaasus, aga paradoksaalsel kombel räägib, vähemalt minumeelest, nende tore MCP-projekt kõigele sellele otse vastu.

Aga natuke tuleb alustada sellest, mida ma olen teada saanud selle kohta, kust see idee pärit on ja miks seda tegema peaks. Igaks juhuks ma kellelegi ei viita, sest kõik see on juba minu enda seeditud arusaam.

Mida teha üritatakse, kui pakutakse välja, et AI-agentidele tuleb anda isikukoodid?

Kui hästi laia pintsliga tõmmata, siis:

  • On vaja teha nii, et eraisikute (sh e-residentide) agendid saaks riigi ja ka eraettevõtete infosüsteemides mingit (esialgu väga piiratud hulka) toiminguid teha. Aus soov. Miks esimene internetipanga API 30 aastat aega võttis, ei tea (kuigi oskan oletada).
  • Sama aus on eeldus, millega arvestatakse: riigi IT-süsteemides kogu selle asja “korralikult” realiseerimine võtaks asjade praeguse seisu juures lõpmatult palju aega ja raha või et siis lausa natukene rohkem.
  • Siiski on mõte, et kusagil peab olema mingi capability based access control, et saaks näiteks öelda, et “mingi kapitaalne viga on, ükski agent täna pangatehinguid teha ei saa”. Ehk siis mingi keskne juhtimismehhanism.
  • On oluline, et rõhk on ärikasutusel: ei ole kuigi tähtis, vähemalt esialgu, et füüsiline isik saaks volitada oma agenti mingeid füüsilise isiku asju tegema. Ja sellel mündil on teine külg: juriidiliste isikute käsitlus infosüsteemides on reeglina selline, et seal juba on mingi õiguste delegeerimine füüsilistele isikutele – seega on eeldus, et füüsilise isiku moodi AI-agendi haldamine sellises süsteemis oleks üsna lihtne.
  • Samal ajal paistab kusagil silmapiiril kiirelt lähenev rahvusvaheline konkurents e-residentsuse osas, mis juba ka agentide liidestamist hõlmab. Väidetavalt tegelevad sellega kõik maailma suuremad äri-tõmbekeskused.
  • Kasu prognoositakse sellest kahekülgset: riigilõivud teenuse avamise eest ning üldine majandustegevuse elavdamine koos kõige kaasnevaga.

Selle juures on vaja lahendada mõned tehnilised probleemid (mittetäielik nimekiri):

  • Kuidas agent autentida?
  • Kuidas teisendada agendi esitatud mingisugune mandaat füüsilise isiku identiteediks ning õigusteks ja volitusteks?
  • Kuidas agent süsteemidega liidestub?

Variant A: masinal on isikukood

Alustame lihtsamast, ehk siis agendi mandaadist. Seda on sellises mudelis tõesti päris lihtne lahendada: tekitame rahvastikuregistrisse seose, samalaadselt nagu näiteks lapse ja vanema vahel. Ilmselt peaks see seos olema ka transitiivne, ehk siis minu agent võib esindada ka minu last, aga see on juba detail.

Volituste süsteemi kontekstis tekib siin aga kohe esimene küsimus, mis igal kogenud arhitektil kõrvad murelikult liikuma paneb: meil tekib küllalt keerukas kolmnurk füüsilise isiku õigustest, sellest mida agent füüsilist isikut esindades teha võib ning millised kirjed võivad olla volituste süsteemis volituste objekti ja agendi otseste suhete kohta (kuivõrd agent “näeb välja” nagu füüsiline isik). Nende kolme õla vahel võivad esineda fundamentaalsed konfliktid. Siin tuleb mängu üks vana tõdemus, nimelt et ühe asja kasutamine mitmeks otstarbeks on tarkvara maailmas üks tavalisemaid pahanduste allikaid. Kui meil on mingi “isik”, kes saab olla ainult volitatav ning kellel ei ole isiklikku õiguslikku staatust, siis peaks ta kuuluma täiesti omaette klassi, teda ei tohiks identifitseerida samamoodi kui füüsilist isikut, kes võib olla nii volitatav kui volitaja. Süsteemi struktuur ei tohiks võimaldada olekuid, mis on nonsenss.

  • Ärge palun pakkuge välja, et “üheksa isikukoodi alguses on eristaja”. Identifikaatoritesse mingite eritähendusega positsioonide sissekirjutamine on ka halb mõte ja jah, see kehtib ka tänase isikukoodi vormingu kohta. Pidagem meeles, et see on pärit NSVL-ist, kus “privaatsus” oli tundmata mõiste. Lätlased ravisid selle lastehaiguse endal välja.

Kuidas agent süsteemiga liidestub? On suur eeldus, et isikukood lihtsustab asju. Kogu tänane praktiline liidestumine infosüsteemidesse töötab mingil viisil HTTP baasil, seega peame tegema eelduse, et meil on mingi HTTP-põhine liidestus. On oluline tähele panna, et HTTP kasutus liidestusteks sõltub olulisel määral sellest, kuidas seda liidestust kasutatakse: inimkasutuseks mõeldud veebibrauserite HTTP kasutusel ja HTTP-põhistel masin-masin API liidestustel on märkimisväärsed erinevused. Kas me seame eesmärgiks, et agent on rohkem nagu masin või hoopis rohkem nagu inimene? Eeldame, et rohkem nagu inimene, sest ainult see variant kannaks edasi ideed, et meil on võimalik olemasoleva infrastruktuuri baasil midagi lihtsasti saavutada. Sobib – panna AI-agent ekraanikaabitsuse abil inimest simuleerima on suhteliselt lihtne, kui vaja, võtame mõnest kohast CAPTCHA ära.

Me oskame nüüd volitada ja oskame liidestada, aga kuidas me agenti, kes käitub nagu inimene, autendime?

Eesti eID süsteemis (hõlmates ka e-residente) autenditakse inimesi ühel kolmest viisist: ID-kaart (digi-ID), Mobiil-ID või Smart-ID. Kusagilt on tulemas ka digikukkur. Füüsiline kaart ei ole agentide kontekstis ilmselt üldse teemaks, Mobiil-ID samal põhjusel (SIM!) ka mitte, seega jääks üle Smart-ID (teatud modifikatsioonidega) ja mingid hüpoteetilised uued variandid, näiteks mingi soft token, mis simuleerib ID-kaarti. Lisaks võib midagi kunagi tekkida digikukru-maailmas. Ja räägime hetkel ainult autentimisest, ärme räägime digiallkirja andmisest. Smart-ID modifitseerimine nõuaks, et üks eraettevõte hakkab oma (rangelt sertifitseeritud ja reguleeritud) teenust oluliselt muutma ning soft token nõuab, et riik oleks üldse nõus sellist asja tunnustama, paraku ei ole tugevate autentimisvahendite tunnustamine päris niisama et “tahame ja teeme”. Aga oletame, et me saame sellega kuidagi hakkama.

Saime järgneva:

  • Erikujulise isikukoodi, mida hallatakse rahvastikuregistris, koos seosega “omanikule”.
  • Volituste süsteemi, millest osa on rahvastikuregistris, osa aga kusagil teenusepakkujate (nii avalike kui eraõiguslike) juures.
  • Erilise autentimisvahendi, mis simuleerib inimeste poolt kasutatavaid.
  • Liidestuse, mis simuleerib inimkasutust.
  • See kõik, peale autentimisvahendi, kõlab tegelikult päris lihtsasti lahendatavana, vähemalt seni, kuni me eirame kõiki teiseseid efekte, mis sellest tulenevad.

Aga probleem on selles, et see kõik on kohmakas ja eripärane ning ei täida sugugi seda eesmärki, mida sellest loodetakse, eriti e-residentsuse kontekstis.

Vahemäng: Rain Lõhmus tordisööjaid ei palka

LHV tundub endiselt veidi olevat säherdune käbeda mentaliteediga organisatsioon, nagu kunagi oli Hansapank (kuigi muremärgid on õhus) ja vähemalt osaliselt selle tulemusena ongi meil selline MCP server, nagu eespool kirjeldatud.

Kui Sa siiamaani lugeda viitsisid, tunnistan üles: postituse pealkiri on puhas trollimine ja provokatsioon. Nad ei teinud API-t, nad tegid MCP serveri.

Mõned täiendused tolle MCP-serveri varasema kirjelduse juurde.

Kui vaadata enne näidatud JWT tokenit, siis on seal näha kaks väärtust: 7XXXXX ja 2XXXXX.

2XXXXX on autenditud füüsilise isiku tunnus. See ei ole isikukood.

7XXXXX on füüsilise isiku poolt esindatava OÜ tunnus. See ei ole äriregistri kood.

Liides kasutab isikute identifitseerimiseks mingit pangasisest identifikaatorite süsteemi, mis on riiklikest identifikaatoritest lahti ühendatud, aga õigupoolest on see rohkem lokaalse tähtsusega projekteerimisotsus, mismoodi parasjagu parem teha on. Riigi infosüsteemides on pigem mõistlik kasutada isikukoodi.

Lisaks on seal tokenis veel kaks välja: auth_id ja jti. Need on vastavalt autentimisprotsessi ID ja tokeni ID. Need on täpselt need väljad, mille abil agent üheselt algse isiku külge siduda, selle asemel et minna rahvastikuregistrisse pseudoisikuid looma. Jälg sellest, millises protsessis need identifikaatorid väljastati, jääb kuhugi maha ja on leitav.

Saime järgneva:

  • Mingit isikukoodi ei ole. Isegi äriregistri koodi ega inimeste isikukoodi ei kasutada. Viisakas, decoupling on hea.
  • Volituste süsteemi, mis arvatavasti põhineb äriregistri andmetel, võimalik et ka panga sisemisel volituste süsteemil (ei ole süvenenud, ei ole ka liiga oluline siinkohal).
  • Volituste süsteemi peal on lisakiht, mis läbi OAuthi skoopide mehhanismi deklareerib avalikult, et agendil on kindlal viisil piiratud õigused võrreldes inimesega, kellele ta kuulub.
  • Täiesti standardse autentimisviisi, mis läbi standardsete mehhanismide suunatakse kohta, kus inimene saab kohalikke eripärasid (Smart-ID jms) rakendada (https://auth.lhv.ai/). Masinale pole vaja kohalikke eripärasid tutvustada.
  • AI/LLM-süsteemidele loomuliku masinliidestuse.

Selle juures on üks nüanss, mida tasub tähele panna: ma ütlesin Claude Code’le ühe või kahe lausega, et tee mulle Pythoni skript, mis realiseerib selle MCP serveri kliendi. Ja ta tegi, esimese korraga, ilma ühegi tuvastatava veata, ning vahepeal ekraanile pritsitud “arutlemine” viitas kõik sellele, et mudelisse on kogu sellealane tarkus sisse treenitud.

On üks asi, mida ma olen väheortodoksse tehnikuna hindama õppinud: ära kunagi uju vastuvoolu, kui üks asi on juba voolama pandud. Kui meil on AI-maailmas olemas MCP, mis rakendab turvameetmena OAuthi, siis see on see, mille järgi tuleb joonduda. Muidu on võimalus kulutada palju aega, palju raha ning saada mitte midagi. Äge kohalik eripära on kiluvõileib, kodukootud autentimisprotokoll ei ole äge.

On täiesti omaette küsimus, kui hea või halb on MCP spetsifikatsioonina, aga sellest tähtsam on see, et ta on olemas ja kasutatav. Minu rangelt isiklik seisukoht on, et MCP tänasel kujul on päris ohtlik plönn, kasvõi sellepärast, millise kvaliteediga on nende juba mainitud dokumentatsioon.

Lähme korraks eesmärgi juurde tagasi: see asi peab olema kasutatav välismaistele e-residentidele. Kiipkaardiga digi-ID ja muud veidrused on nende jaoks rohkem probleem kui võimalus (vaadake pidevaid probleeme meie DigiDoci kvaliteedi ja ühilduvusega ning ekstrapoleerige). Kui meil on eesmärgiks palju välismaiseid agente, tuleb teha nagu välismaal ning välismaal on MCP ja OAuth.

Lisanüanss: ka LHV pakub liidestusvariantidena välja LLMi-pakkujate veebiliidesed. See on tähtis, sest kui mingitele laua alla Mac Mini sisse punutud agentidele on võimalik kohalikke autentimisvahendeid selgitada, siis palju õnne, kui tahate sama Anthropicu hostitava agendiga teha.

Mida me sellest siis järeldame?

Variant B: teeme X-tee otsa MCP konverteri

Kõlab brutaalselt, aga päriselt ka. (Konverteri, mitte sügavalt integreeritud MCP toe, sest on usutav, et kui see agendimöll ei sure, siis tuleb MCP asemele midagi paremat.)

Seal on miljon pisiasja, mille peale tuleb mõtelda, see ei tule päris ilma projekteerimata kätte, aga me saame päris mitu toredat tulemit:

  • Liidestus on AI agentidele loomulik.
  • Autentimine on masin-masin autentimise maailmale loomulik.
  • Volituste piiramine on standardsel viisil sisse ehitatud.
    • See EI tähenda, et volitamine kui selline oleks standardsel viisil sisse ehitatud - ühtegi päriselt standardset volitamise raamistikku ei ole olemas, sellega tuleb igal juhul tegeleda. Aga OAuth annab läbi skoopide mehhanismi võimaluse tekitada agendile simese taseme “kaelarihm”.
  • Eripärane kohalik autentimine on lokaliseeritud kasutajaliidesesse.
  • Me ei lähe alusmüüre raputama mingi haibiga, mis võib olla 8-18 kuu pärast pildilt kadunud.
  • Eelmine tähendab seda, et meil ei ole “agentide isikukoode”, sest vajalikule tulemusele on võimalik jõuda lihtsamalt ja standardsemalt.

Kust ma võtan 8-18 kuud? Sõltumata sellest, kust arvama hakata, on kogu see AI-agendi teema väga-väga värske ning Lindy reegel ütleb meile, et tehnoloogia elab keskeltläbi veel niikaua, kuni ta juba elanud on. Vt. ka Talebi “Antifragile”, ta kirjutab sellest nähtusest pikemalt.

Kui teravaid elamusi tahate, meenutage seda NFT-spetsialistidest AI-spetsialistideks kehastunutele. Või võtke Google Trends lahti ning vaadake “NFT” ja “AI agent” graafikuid.

LLMid ei kao kuhugi, aga kogu selle agendimängu osas ma nii kindel poleks, see jõuab veel mitu korda muutuda, enne kui päriselt kasulikuks hakkab.

Päris mitu vajalikku tükki on ka olemas:

  • TARA. Hetkel on küll tegu OpenID Connecti identiteeditarnijaga, aga OAuth on selles mootoris sees, liiga suuri samme ei ole vaja astuda. Seejuures ei pea kasutama ju sedasama TARA, võib ka uue paigaldada.
  • Standardne liidestus üle X-tee.
  • Ja loomulikult kogu maailma agendi-ökosüsteem, mis ei pea mitte midagi Eesti-spetsiifilist lisama.

Tehtagu.

Aga palun projekteeritagu läbi. Kui ma kunagi varem arvasin, et OAuth on üks paljudest võimalustest, siis nüüd arvan ma, et kui tahta midagi sellist teha, siis peab olema OAuth kasutusel. Aga see ei käi nii, et võtame riiulist mingi FOSS monstrumist OAuth pinu, jookseme kuidagi käima ja hakkame kasutama. See värk tuleb läbi mõtleda, soovitavalt selliste inimeste osavõtul, kes on OAuthi standardeid mõttega lugenud ning ka mõnd koledat ämbrit lähedalt näinud.

Aga igal juhul tundub see olevat see variant, kuidas saab agendile viisakalt õmmeldud korraliku kaelarihma anda.

Variant C: seesama mis eelmine, aga seda teeb erasektor

Ja nüüd küsimus, mis mind närib: miks on seda kõike vaja teha riigi sees? Et me saaks järgmise e-residentsuse, kus hoobeldakse riigilõivude koguse, mitte SKT osakaalu ega kapitali akumulatsiooni mahuga?

Riigieelarve on miinuses, igasuguste riigistruktuuride personal paisub nagu pärmi peal ja nüüd hakkame veel üht asja riigi sees tegema? Seejuures veel teenust, mis on suunatud pigem riigist välja.

Aga mis siis, kui joonistaks enne tehnilist arhitektuuri hoopis natuke äriarhitektuuri? Ja küsiks – kas seda kõike saaks teha eraettevõte või mitu? Ilmselt on mingid asjad, mida peaks tegema ka riik - on need siis X-tee tehnilised muudatused, seadusandluse muudatused vms - aga seda oleks ilmselt suhteliselt vähe, võrreldes toore tehnilise tööga, mida võib sobivate raamide olemasolul teha ükskõik kes.

Riigikapitalism ei tohiks mingil juhul eesmärk olla ning tark oleks hoida tehniline eksperimenteerimine e-riigi tuumikust eemal. Eksperimenteerige parem EHR-iga, see saab sellest ainult paremaks minna.

E-residentsus ise on natuke teise kujuga nähtus, seal on endiselt vajalik, et selle jämedad otsad on PPA käes - aga praegu pole näha ühtegi head põhjust, miks just riigiaparaat peaks agentide liidestamise oma südameasjaks tegema.

Ei oleks paremat tõestust massilise agendi-liidestamise idee headusest, kui see, et kellelgi õnnestub sellega kasumit teenida.

Kokkuvõtteks

Kui on mingi usk, et seda agendimängu tuleb mängida, tuleb käised üles käärida ja projekteerima hakata ning seejuures silmas pidada, misasi on täna levinud “AI-agent” ja kuidas ta maailma sööb.

Tehtagu.

Mina ei usu, et seda mängu tuleb mängida ja seetõttu tegema ei torma, aga kui kellelgi on selles osas mingeid detailsemaid küsimusi, on võimalik ilmselt viisil või teisel neile vastata.

Küsimusi ja väiteid teemal “see kõik on Reformierakonna valimiskampaania” ignoreerin, isegi kui need küsimused tekivad mul endal. Eks see selgub 215 päeva pärast.

Kartaago tuleb hävitada

Kui on üks asi, mis seisab Eesti ning insenertehnilistest lahendustest tuleneva jõukuse või et siis “võimsa arengu” vahel, on see meie põhikooli reaalainete-õpetuse täiesti kohutav seis.

Ja ma pean silmas seda, et kõik peavad saama matas oma tulbad ära teha, pädeva õpetaja järelvalve all. Ja et keemias ei oleks probleeme, eriti arvestades seda, kuidas kogu ootus majanduskasvule kipub nihkuma IT-tilulilu pealt biokeemiale, materjaliteadusele ja muule.

Et meil oleks see ühiskondlik põhi, mis peaks vastu, kui harimatud üritavad ennast peale suruda – ajalugu õpetab, et see kipub lolli järjekindlusega ikka juhtuma.

Ükski lobarobot, videotund ega huviharidus seda ei kompenseeri. Eriti viimane on väga tarvilik, aga mitte piisav. Põhi peab olema lai ja tugev.