Agentický AI systém v poisťovni: Čo navrhnúť od prvého dňa a ako riadiť zmeny podľa AI Act

Autor: Michal Bystrický

EU AI Act je nariadenie EÚ, ktoré reguluje umelú inteligenciu podľa miery rizika a pri agentických systémoch v poisťovni nie je súlad len právna téma, je architektonická. Logovanie a ľudský dohľad patria do jadra od prvého dňa, lebo dodatočne ich už nedoplníš bez prepísania hotového riešenia. Rozhodnutia o súlade siahajú od high-risk klasifikácie cez samotný návrh až po vedomé riadenie zmien (hranice systému, podstatná zmena, change envelope) bez zbytočného nového posúdenia zhody.

Pri core poistných systémoch je zmena drahá. Bežia roky, často nad dátami a procesmi, ktoré musia byť vysvetliteľné, auditovateľné a regulačne obhájiteľné. Preto sa na agentickú AI nedá pozerať len ako na experimentálnu vrstvu nad existujúcim systémom.

V msg life Slovakia túto perspektívu poznáme z vývoja softvéru pre životné, dôchodkové a zdravotné poistenie. Pri agentických systémoch preto riešime súlad nie až na konci, ale už pri návrhu architektúry.

Kde agentický poistný systém spadá v EU AI Act

EU AI Act triedi systémy podľa miery rizika do štyroch úrovní a od nej odvíja povinnosti:

• Neprijateľné riziko — zakázané praktiky (článok 5), napríklad sociálne skórovanie či manipulatívne systémy.
• Vysoké riziko — systémy z prílohy III alebo z regulovaných produktov (príloha I); plný režim povinností (dokumentácia, posúdenie zhody, ľudský dohľad).
• Obmedzené riziko — povinnosť transparentnosti (článok 50), napríklad označiť, že používateľ komunikuje s AI alebo že obsah je vygenerovaný (viac v článku Generatívna AI).
• Minimálne riziko — bez osobitných povinností.

Pre poisťovňu je rozhodujúca druhá úroveň. Hodnotenie rizika a tvorba ceny pre fyzické osoby v životnom a zdravotnom poistení patrí do prílohy III — a agentický systém, ktorý túto funkciu plní, je preto vysoko rizikový. Tým sa dostávame k prvej praktickej otázke návrhu.

Širší prehľad, kde všade AI vstupuje do poistných procesov, nájdeš v článku AI v poisťovníctve.

Kedy je agentický systém high-risk

Poisťovacie systémy, ktoré hodnotia riziko a tvoria cenu pre fyzické osoby v životnom a zdravotnom poistení, sú high-risk. Spadajú pod prílohu III, bod 5(c), ktorý doslova hovorí o „AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance.“ Underwriting a pricing pri životnom a zdravotnom poistení sem patria priamo. Nie je to hraničný prípad, ktorý by sa dal obísť argumentom.

Článok 6(3) pripúšťa, že systém uvedený v prílohe III nemusí byť high-risk, ak nepredstavuje významné riziko pre zdravie, bezpečnosť alebo základné práva. Táto výnimka sa však neuplatní, ak systém vykonáva profilovanie fyzických osôb.

Pri underwritingu a pricingu v životnom alebo zdravotnom poistení systém typicky pracuje s údajmi o konkrétnej osobe alebo s odvodenými znakmi, z ktorých určuje jej riziko alebo cenu. Preto je argument o profilovaní veľmi silný. Poisťovňa by v takom prípade nemala stavať architektúru na predpoklade, že sa zmestí do výnimky z článku 6(3).

V praxi z toho plynie jednoduché pravidlo: ak systém určuje riziko alebo cenu pre konkrétneho človeka v životnom alebo zdravotnom poistení, plánuj ho ako high-risk. Výnimku nehľadaj ako skratku.

Klasifikácia AI systémov v poisťovníctve podľa EU AI Act

Čo odlišuje agenta od obyčajného LLM volania

Čo je agent ako koncept (autonómna entita nad LLM, ktorá plánuje, volá nástroje a koná smerom k cieľu) rozoberá samostatný článok agentická AI a slovníkové heslo AI agent. Tu stačí rozlíšiť jednu vec, ktorá je pre AI Act dôležitá. Na rozdiel od obyčajného volania modelu, ktoré vráti odpoveď na jeden vstup, agent medzi vstupom a výstupom urobí sériu vlastných rozhodnutí — a práve tú musí systém vedieť zaznamenať a dať pod dohľad.

Dôležité je rozlíšiť dve roviny. Agent je jedna autonómna entita. Agentický systém je širší pojem – môže to byť celý tím alebo swarm viacerých agentov, ktorých koordinuje orchestrátor. Pre AI Act je rozhodujúce práve toto širšie chápanie, pretože zákon hodnotí systém ako celok, nie izolovaný komponent. Toto rozlíšenie je kľúčové pri určovaní hraníc systému aj pri posudzovaní zmien.

Dôležitá je ešte jedna vrstva. Model, na ktorom agent stojí, môže podliehať vlastným pravidlám ako general-purpose AI model (GPAI model) podľa kapitoly V AI Act. Nás však v tomto článku zaujíma najmä úroveň systému, ktorý okolo modelu postavíš. Práve tam vznikajú architektonické rozhodnutia o logovaní, dohľade, hraniciach systému a riadení zmien.

Digitalizácia16 min.

Prečítaj si aj:

Ako funguje umelá inteligencia: Využitie a kľúčové oblasti AI

Prečítaj si náš článok o umelej inteligencii, v ktorom sa dozvieš, čo to je, aké má benefity a aké riziká sú s ňou spojené.

Čo musí byť v jadre od prvého dňa

Byť high-risk znamená viac než logovanie a dohľad. Patrí sem aj systém manažmentu rizík, technická dokumentácia, systém manažmentu kvality, transparentné informácie pre používateľa, presnosť, robustnosť a kybernetická bezpečnosť. To všetko musí byť súčasťou návrhu a životného cyklu systému.

Nie všetky povinnosti však zasahujú do architektúry rovnako hlboko. Niektoré vieš priebežne rozvíjať cez procesy, dokumentáciu a governance. Dve rozhodnutia sú však pri agentickom systéme najťažšie spätne opraviteľné: logovanie celej cesty a účinný ľudský dohľad (human oversight).

Pri návrhu máš ešte slobodu. A presne preto sú tieto dve rozhodnutia kritické. Ak ich nedáš do jadra teraz, neskôr ich už nebudeš dopĺňať jednoduchou procesnou úpravou. Budeš meniť samotný tok rozhodovania.

Ak si máš z tejto časti odniesť jednu vetu, nech je to táto: logovanie a dohľad patria do jadra od prvého dňa.

Logovanie celej cesty (článok 12)

Pri klasickej službe ti na audit stačí zrekonštruovať vstup a výstup. Pri agentovi to nestačí. Medzi vstupom a výstupom urobí celú sériu vlastných rozhodnutí. Keď neskôr niekto namietne, prečo dostal klient práve takú cenu, samotný výsledok ti nepovie nič. Odpoveď je v ceste. A presne tento záznam od teba článok 12 vyžaduje.

Článok 12(2) nehovorí len o jednom účele logovania. Pri high-risk AI systéme majú logy pomôcť najmä v troch situáciách: keď treba identifikovať riziko alebo možnú podstatnú zmenu systému, keď poskytovateľ vykonáva post-market monitoring a keď prevádzkovateľ sleduje systém počas reálneho používania. Pri agentickom systéme preto nestačí uložiť iba výsledok. Logovanie musí zachytiť aj cestu, ktorá k nemu viedla.

Do logu patrí cesta a tá sa skladá zo štyroch typov udalostí:

• Volania nástrojov (tool calls): Čo agent zavolal, s akými parametrami a čo dostal späť.
• Rozhodovacie kroky: Kde sa cesta vetvila a ktorú vetvu agent zvolil.
• Zásahy do behu (override): Kde zasiahol človek alebo nadradený systém, čo zmenil a kedy.
• Udalosti životného cyklu: Spustenie, ukončenie, reštart, zmena konfigurácie behu.

Rozhodovací krok zaznamenávaš ako nedeterministický: uložíš vstup, výstup a kontext, ale nie deterministické „pravidlo“, ktoré k výberu viedlo. Často žiadne explicitné pravidlo neexistuje. Cieľom je rekonštruovateľnosť cesty, nie ilúzia, že každý krok má čitateľnú logickú podmienku. Pokiaľ ide o nástroje: konvencie OpenTelemetry GenAI dnes pokrývajú aj MCP a tool-calling telemetriu, ale dedikovaný „agent-span“ štandard neexistuje. Agentické trasovanie ide cez konvencie pre nástroje, nie cez hotový štandard pre agentov.

Nejde teda o ukladanie skrytého „uvažovania“ modelu. Ide o rekonštruovateľnú prevádzkovú stopu – aký vstup dostal, čo zavolal, aký výstup vrátil, v akom kontexte konal a kde do behu zasiahol človek.

Minimum retencie logov je šesť mesiacov: pre poskytovateľa podľa článku 19 a pre prevádzkovateľa podľa článku 26(6). Pri finančných inštitúciách však AI Act počíta aj so sektorovými pravidlami, napríklad DORA alebo Solvency II. Ak sa na teba vzťahujú osobitné predpisy s vlastnými požiadavkami na uchovávanie záznamov, logy udržiavaš ako súčasť dokumentácie podľa príslušného finančného alebo sektorového rámca.

Pointa je jednoduchá: AI Act nepridáva logovanie do prázdneho priestoru. V poisťovni sa napája na existujúci compliance režim. Nie je to voľná výnimka z logovania, ale pripomienka, že retenciu logov musíš zosúladiť aj so sektorovými pravidlami.

A jeden častý mýtus na záver: append-only ani kryptografické reťazenie nie sú požiadavkou článku 12. Zákon žiada, aby logovanie umožnilo tri účely a aby logy existovali po stanovenú dobu, nie aby bolo úložisko nemenné. Append-only je odporúčaný nadštandard pre dôveryhodnosť audit trailu, nie litera zákona.

Odporúčame ti:

Logovanie navrhni do jadra od prvého dňa a pokry všetky tri piliere článku 12(2), nie len post-market monitoring. Append-only ber ako nadštandard a nedaj sa dotlačiť dodávateľom, že nemenné úložisko je „požiadavka AI Actu“. Nie je.

Ľudský dohľad nie je podpis (článok 14)

Keď tím rieši „ľudský dohľad“ nad agentom, zvyčajne skončí pri jednej vete: na konci to ešte odsúhlasí človek. Schvaľovacie tlačidlo, podpis pod výstupom. Vyzerá to ako dohľad. V zmysle článku 14 to však dohľad nie je.

Článok 14 žiada, aby bol systém navrhnutý tak, aby ho človek vedel účinne dozorovať a v prípade potreby zasiahnuť. Kľúčové slovo je „účinný“ a má jeden tvrdý test: človek musí mať reálnu možnosť rozhodnutie zmeniť, nielen ho odkliknúť.

AI Act rozdeľuje ľudský dohľad medzi dve roly. Podľa článku 14 má poskytovateľ navrhnúť systém tak, aby ho človek vedel účinne dozorovať. Podľa článku 26(2) má prevádzkovateľ zveriť dohľad osobám, ktoré majú potrebnú kompetenciu, autoritu a podporu.

Ako analógia pomáha rozhodnutie SCHUFA (C-634/21) k článku 22 GDPR. Súdny dvor EÚ v ňom riešil situáciu, keď automatizované skóre zásadne ovplyvní následné rozhodnutie tretej strany. Z toho plynie praktický záver: formálny ľudský podpis nestačí, ak sa človek v praxi len spolieha na výstup systému.

Pri agentickom underwriterovi platí rovnaká logika. Ak agent vyprodukuje hodnotenie a človek ho len odklikne, lebo nemá čas, informácie alebo právomoc ho zmeniť, nejde o účinný dohľad. Rozhoduje agent a podpis je len formálna vrstva.

Tu sa dohľad mení z odseku v smernici na konkrétny kód. Pri agentovi s nevratnými akciami ber tieto vzory ako minimum:

• Approval gate pred nevratnou akciou: Zarážka v kóde tesne pred krokom, ktorý sa nedá vziať späť (odoslať rozhodnutie klientovi, poslať platbu, zamietnuť krytie). Agent dobehne k bodu, ale ďalej nepokračuje, kým akciu nepotvrdí oprávnený človek.
• Stop funkcia: Beh musíš vedieť bezpečne zastaviť. V praxi to znamená definované zastavovacie body plus kompenzáciu už spustených nevratných akcií (čisté „tvrdo ukončiť proces kdekoľvek“ uprostred volania nástroja zvyčajne nie je realizovateľné).
• Eskalačná cesta: Keď si agent nie je istý, definovaná cesta posunie rozhodnutie človeku s vyššou autoritou.
• Audit trail: Bez záznamu nemá dozorca na čom postaviť rozhodnutie. Approval gate, ktorý nezaznamená, čo agent navrhol a čo človek schválil, je z hľadiska dohľadu prázdny.

Odporúčame ti:

Účinný dohľad otestuj jednou otázkou: má človek reálne čas, informácie a právomoc rozhodnutie zmeniť, nielen ho odkliknúť? Approval gate, stop funkciu, eskalačnú cestu aj audit trail zabuduj do systému, nie do procesu okolo neho.

Keď systém už beží: kde sú hranice „jedného systému“ (článok 6)

Pri multi-agent architektúre zákon neposudzuje jednotlivé moduly, ale funkciu systému ako celku (článok 6): tri mikroslužby, ktoré spoločne produkujú jedno cenové rozhodnutie, sú jeden high-risk systém bez ohľadu na to, koľko kontajnerov či repozitárov majú. Na živom systéme to má priamy dôsledok pre každú zmenu.

Návrh je jedna vec, živý systém druhá. Pri agentovi prichádzajú zmeny často, skoro pri každom nasadení, a slobodu návrhu vymeníš za disciplínu. Prvá otázka pri už nasadenom systéme znie: Čo vlastne tvoj systém je? Bez toho nevieš posúdiť, čo je ešte jeho zmenou.

Predstav si diagram: orchestrátor, tri sub-agenti, pár mikroslužieb, každá vo vlastnom kontajneri a repozitári. Pre teba sú to tri komponenty. Pre zákon to môže byť jeden high-risk systém. Keď inžinier zistí, že nejaká funkcia spadá do high-risk kategórie, prvá reakcia býva reflexná: rozdelím to na moduly pod prahom. Je to elegantné a nefunguje to. AI Act neposudzuje tvoje moduly. Posudzuje funkciu, ktorú systém ako celok plní, a jej účinok na konkrétneho človeka. Prah si neposunieš tým, že kód rozsekáš na menšie súbory.

Príklad z praxe: Tri mikroslužby: prvá obohatí vstupné dáta, druhá vypočíta rizikový profil, tretia z neho odvodí cenu poistky. Tri repozitáre, tri kontajnery, možno tri tímy. Technicky je nesporné, že spoločne produkujú jedno cenové rozhodnutie, ani jedna sama o sebe výslednú cenu nedá. Takáto zostava sa preto posudzuje ako jeden high-risk systém, aj keď beží v troch kontajneroch. Nie preto, že tri kontajnery sú „technicky jeden systém“, ale preto, že ich spoločný výstup materiálne určuje rozhodnutie o človeku. To, že diagram má tri rámčeky, je pre toto posúdenie irelevantné.

Dôsledok je zásadný: ak tie „tri samostatné“ mikroslužby tvoria z pohľadu zákona jeden systém, potom zmena ktoréhokoľvek komponentu je zmenou celku. Nepretrénoval si „len tú druhú službu“. Zmenil si systém.

Kedy je zmena podstatná

Podstatná zmena je podľa článku 3(23) zmena AI systému, ktorá súčasne (1) nebola pokrytá pôvodným posúdením zhody a (2) ovplyvňuje súlad s AI Act alebo mení zamýšľaný účel. Ak spĺňa obe podmienky, systém sa správa, akoby šlo o nový systém, a musíš preň urobiť nové posúdenie zhody, teda celý cyklus, nie iba aktualizáciu dokumentácie. To je drahé a pomalé.

Pri agentovi je situácia iná, pretože sa mení takmer stále (model drift). Každá z týchto úprav môže zmeniť správanie systému: pretrénovanie modelu, výmena modelu za novší checkpoint, zmena promptu (systémový prompt je de facto časť logiky), zmena teploty, zmena RAG-korpusu, uvoľnenie guardrailov, integrácia nového nástroja. Keby každá z nich automaticky znamenala podstatnú zmenu, posudzoval by si zhodu pri každom sprinte. Otázka teda neznie, či sa agent mení. Mení sa takmer vždy. Rozhodujúce je, ktoré zmeny si už predvídal a podchytil, a ktoré sú naozaj nové.

Digitalizácia22 min.

Prečítaj si aj:

AI v poisťovníctve: Využitie v praxi a trendy

Zaujíma ťa oblasť AI v poisťovníctve? Prečítaj si náš najnovší článok, v ktorom ti o nej povieme viac.

Change envelope ako praktický rámec

Tu pomáha change envelope – vopred vymedzený priestor pre zmeny, s ktorými počítaš už pri prvom posúdení zhody. Opiera sa o článok 43(4) v spojení s prílohou IV a definíciou podstatnej zmeny v článku 3(23).

Pre vývojový tím z toho plynie, že plánované zmeny nestačí riešiť až pri deployi. Už v technickej dokumentácii treba popísať, aké typy zmien očakávaš, kde sú ich hranice a ako overíš, že nemenia zamýšľaný účel ani rizikový profil systému. Môže ísť napríklad o úpravy modelu, systémového promptu, RAG-korpusu, konfigurácie alebo guardrailov, ak sú vopred popísané a posúdené.

Ak zmena zostane v týchto hraniciach, nemusí automaticky znamenať nové posúdenie zhody. Ak ich prekročí, treba posúdiť, či už nejde o podstatnú zmenu.

Buď však opatrný s rozsahom. Čl. 43(4) cieli v prvom rade na systémy, ktoré sa po nasadení ďalej učia. Neber to ako plošné oprávnenie na akúkoľvek úpravu. Čím viac sa zmena vzďaľuje od toho, čo si dopredu presne popísal, tým skôr ide o podstatnú zmenu.

Change envelope nie je pojem zo zákona. Je to pracovné označenie pre vopred vymedzený priestor zmien podľa článku 43(4) a prílohy IV. Voči regulátorovi preto vždy odkazuj na konkrétne ustanovenie, nie na samotné označenie.

Rozlíšenie zmien podľa hraníc change envelope 

V praxi môže ísť napríklad o úpravy modelu, promptu, RAG-korpusu alebo konfigurácie, ale iba vtedy, ak boli vopred popísané, posúdené a zostanú v stanovených hraniciach.

Change envelope ako praktický rámec

Prečo to celé riešiť? Lebo bez vopred vymedzeného priestoru pre zmeny zostávajú dve cesty a obe sú zlé:

1. Systém sa mení potichu: Tím nasadzuje zmeny promptov, vymieňa modely, dopĺňa RAG bez toho, aby ktokoľvek sledoval, či už nejaká zmena prekročila hranicu. Funguje to až do auditu.
2. Posudzuje sa každá aktualizácia: Z opatrnosti tím vyhlási za podstatnú zmenu všetko a vývoj sa zastaví. Change envelope je cesta medzi nimi: vopred a transparentne povieš, ktoré zmeny si predvídal a v akých medziach, a získaš priestor systém zlepšovať v stanovených medziach.

Odporúčame ti:

„Change envelope“ je len pracovné označenie. V dokumentácii a voči regulátorovi vždy odkazuj na konkrétne ustanovenie (článok 43(4) + príloha IV). Inak strácaš oporu presne vtedy, keď ju najviac potrebuješ.

Časová os: Termíny sa hýbu, povinnosti nie

EU AI Act je nariadenie, preto na Slovensku platí priamo. Pri high-risk AI systémoch z prílohy III však dnes nestačí poznať iba pôvodný termín. V roku 2026 treba sledovať aj zmeny, ktoré prináša Digital Omnibus.

Pôvodne sa pri high-risk AI systémoch z prílohy III počítalo s aplikačným termínom 2. august 2026. Digital Omnibus však prináša politicky dohodnutý odklad pre samostatné high-risk AI systémy na 2. december 2027 a pre high-risk AI systémy integrované do regulovaných produktov na 2. august 2028. Tento odklad je však politicky dohodnutý, nie právoplatný. Kým ho EÚ nezverejní v Úradnom vestníku, pre prílohu III formálne platí pôvodný termín 2. august 2026.

Pre architektúru poistného systému to neznamená, že môžeš čakať. Termín sa môže posunúť, ale povaha problému zostáva rovnaká. Logovanie, ľudský dohľad, hranice systému a riadenie zmien nie sú dodatkom k dokumentácii. Sú súčasťou návrhu systému. Ak ich nenavrhneš včas, neskôr nepôjde o doplnenie dokumentácie, ale o zásah do architektúry systému.

Prehľad termínov pre high-risk AI systémy podľa EU AI Act 

Pred rozhodnutím o posúdení zhody si vždy over aktuálne právne účinné znenie v primárnom zdroji, najmä v EUR-Lex a v Úradnom vestníku EÚ. Pri AI Act nestačí vedieť, aký dátum sa používa v prezentáciách. Rozhoduje to, čo je právne účinné.

Odporúčame ti:

Čo je agentická AI ako koncept, vysvetľuje článok Agentic AI: Ako agenti menia spôsob práce s technológiami. Tento text naň nadväzuje regulačno-architektonickým uhlom.. Jednotlivé pojmy sú vysvetlené v našom AI slovníku.

Checklist pre architekta

Pred návrhom alebo úpravou agentického AI systému v poisťovni si polož tieto otázky:

Kontrolné otázky pre návrh agentického AI systému v poisťovni 

Zdieľaj článok

Agentický AI systém v poisťovni: Čo navrhnúť od prvého dňa a ako riadiť zmeny podľa AI Act

Michal Bystrický

V msg life Slovakia pôsobím ako softvérový inžinier s praxou pri vývoji poistných systémov. Venujem sa návrhu a súladu agentických AI systémov v poisťovníctve a píšem o tom, ako sa regulačné požiadavky EU AI Act premietajú do reálnej architektúry. Som autorom video série S Michalom o AI na YouTube kanáli msg life Slovakia, v rámci ktorej sa zameriavam na viaceré aspekty agentického programovania.