Ko infrastruktura misli namesto nas: odvisnost od omrežij, oblakov in avtomatiziranih sistemov
Omrežja, računalništvo v oblaku (ang. *cloud computing*) in avtomatizacija nam prihranijo ogromno dela, vendar hkrati skrijejo odvisnosti. Kako razumeti enotne točke odpovedi (ang. *single points of failure*), vezanost na ponudnika (ang. *vendor lock-in*), avtomatizacijsko pristranskost in tehnološko odpornost brez tehnološke avtarkije?
Ko telefon sam predlaga pot, ko prijava v službo zahteva oddaljeni strežnik, ko dokument obstaja samo v oblaku in ko programski sistem razvršča, komu je treba nameniti pozornost, se ne zanašamo več samo na posamezno napravo. Zanašamo se na verigo omrežij, identitetnih storitev, podatkovnih centrov, programskih vmesnikov in avtomatiziranih odločitev. Večina te infrastrukture deluje tako dobro, da jo opazimo šele, ko odpove.
To je velika prednost sodobne tehnologije. Računalništvo v oblaku (ang. cloud computing) omogoča hitro skaliranje, delitev virov, oddaljen dostop in storitve, ki bi jih posamezna organizacija težko zgradila sama. Avtomatizacija pa lahko zmanjša rutinsko delo, hitreje zazna anomalije in usklajuje sisteme, ki so za ročno upravljanje preveč kompleksni. Toda ista abstrakcija, ki poenostavi uporabo, lahko skrije tudi odvisnosti.
Ko ena prijavna storitev odpre deset drugih sistemov, en ponudnik gosti podatke tisočev organizacij, en programski vmesnik povezuje plačila ali logistiko in en algoritem usmerja človeško pozornost, postane vprašanje odpornosti pomembnejše od vprašanja, ali tehnologija deluje v običajnem dnevu. Vprašati moramo, kaj se zgodi ob izpadu, napačni konfiguraciji, kibernetskem napadu, spremembi poslovnih pogojev ali preprosto ob napačni avtomatizirani odločitvi.
Cilj zato ni tehnološka avtarkija in tudi ne vrnitev v čas pred omrežji. Bolj zrelo vprašanje je: koliko odvisnosti razumemo, koliko alternativ imamo in ali lahko pomembno funkcijo ohranimo, ko običajna pot odpove? Tehnološka odpornost ni življenje brez infrastrukture. Je sposobnost, da infrastruktura ostane orodje, ne neopazna točka, brez katere ne moremo več delovati.
Oblak ni nikjer — je računalnik nekoga drugega v zelo velikem sistemu
NIST definira računalništvo v oblaku (ang. cloud computing) kot model, ki omogoča omrežni dostop na zahtevo do skupnega bazena nastavljivih računalniških virov, ki jih je mogoče hitro dodeliti in sprostiti. Njegove ključne lastnosti so samopostrežna uporaba, širok omrežni dostop, združevanje virov, hitro prilagajanje zmogljivosti in merjena storitev. To je tehnični model, ne metafora o podatkih, ki bi lebdeli nekje zunaj fizičnega sveta.
Za uporabnika se fizična plast namenoma skrije. Dokument se sinhronizira, aplikacija se zažene, strežnik dobi več pomnilnika in storitev ostane dostopna brez tega, da bi vedeli, na katerem disku ali v katerem podatkovnem centru trenutno teče. Prav ta abstrakcija je vir uporabnosti. Omogoča, da se organizacija osredotoči na svojo nalogo, ne na vsak kabel, disk in ventilator.
Toda abstrakcija ne odpravi fizične infrastrukture in pogodbenega razmerja. Pod njo ostanejo elektrika, optična vlakna, usmerjevalniki, podatkovni centri, identitetni sistemi, programske knjižnice in ponudniki. Ko odvisnost postane nevidna, jo je lažje zamenjati za samoumevno lastnost sveta.
Digitalna storitev je veriga, ne en strežnik
Sodobna aplikacija lahko navzven izgleda kot ena storitev, v resnici pa je sestavljena iz številnih plasti. Uporabnik najprej potrebuje omrežje in razreševanje imen, nato identiteto in avtentikacijo, aplikacija pa lahko uporablja zunanje podatkovne zbirke, zemljevide, plačilne sisteme, analitiko, komunikacijske API-je in storitve tretjih ponudnikov. Vsaka plast lahko deluje pri drugem podjetju.
Zato porazdeljen sistem ni samodejno sistem brez enotne točke odpovedi. Lahko imamo več aplikacijskih strežnikov in več podatkovnih centrov, vendar vsi uporabljajo isti identitetni ponudnik, isti DNS, isto knjižnico ali isti nadzorni sistem. Če odpove skupna odvisnost, navidezno neodvisni deli odpovejo skupaj. V inženirstvu je to primer skupnega načina odpovedi: redundanca ne pomaga, če imajo rezervni deli isti vzrok okvare.
Najpomembnejše odvisnosti zato niso vedno tiste, ki porabijo največ denarja ali procesorske moči. Pogosto so to majhne storitve, ki sedijo na križišču sistema: prijava, certifikati, konfiguracija, časovna sinhronizacija, DNS ali API, brez katerega preostala aplikacija ne zna nadaljevati.
.jpg)
Koncentracija prinese učinkovitost — in sistemsko izpostavljenost
Veliki ponudniki lahko zgradijo infrastrukturo, ki je za posamezno organizacijo ekonomsko ali tehnično nedosegljiva. Razpršeni podatkovni centri, specializirane varnostne ekipe, avtomatsko skaliranje in globalna omrežja so resnične prednosti. Zato koncentracija ni nastala samo zaradi tržne moči, ampak tudi zaradi ekonomije obsega in zahtevnosti upravljanja.
Ista koncentracija pa pomeni, da veliko organizacij deli iste zunanje odvisnosti. Evropski bančni organ je v poročilih 2025 in 2026 posebej opozoril na naraščajočo odvisnost finančnega sistema od tretjih ICT ponudnikov, zlasti storitev računalništva v oblaku in plačilnih storitev, ter na možne sistemske posledice, kadar pomembne funkcije slonijo na majhnem številu velikih ponudnikov.
To ne dokazuje, da je velik ponudnik manj zanesljiv od lastnega strežnika. Pogosto je ravno nasprotno. Pokaže pa razliko med verjetnostjo posamezne odpovedi in posledico skupne odpovedi. Zelo zanesljiva komponenta lahko še vedno predstavlja veliko sistemsko tveganje, če je od nje hkrati odvisnih ogromno drugih sistemov.
Vezanost na ponudnika (ang. *vendor lock-in*) ni samo pogodba, ampak arhitektura
Odvisnost od ponudnika se pogosto pokaže šele takrat, ko želimo oditi. Podatke je morda mogoče izvoziti, aplikacije pa ne; aplikacijo je mogoče preseliti, vendar uporablja lastniške baze, identitetne funkcije, vrste sporočil ali analitična orodja, ki pri drugem ponudniku nimajo neposredne zamenjave. Tehnična migracija lahko zahteva mesece dela, čeprav na papirju 'podatki pripadajo stranki'.
NIST je interoperabilnost in portabilnost že zgodaj opredelil kot ključni zahtevi zrelega okolja računalništva v oblaku. Portabilnost pomeni, da lahko podatke in aplikacije premaknemo med sistemi z razumnimi stroški; interoperabilnost pa, da različne storitve lahko sodelujejo prek skupnih specifikacij. To sta lastnosti arhitekture, ne samo pravni pravici.
Tudi evropski Data Act je v to področje posegel neposredno: ponudnikom podatkovnih procesnih storitev nalaga zmanjševanje ovir pri preklopu, zahteve glede izvoza podatkov in odprtih vmesnikov ter postopno odpravo stroškov za prehod in prenos podatkov. Že potreba po takšni zakonodaji pokaže, da možnost izstopa ni samoumevna lastnost digitalnega trga.
Ko avtomatizacija ne izvaja samo naloge, ampak usmerja presojo
Infrastruktura 'misli namesto nas' predvsem v funkcionalnem, ne zavestnem smislu. Sistem razvrsti opozorila, izbere pot, predlaga diagnozo, filtrira vsebino, odobri transakcijo ali določi, kateri primer zahteva človeško pozornost. S tem ne postane oseba, vendar prevzame del selekcije, ki jo je prej opravljal človek.
To je koristno, ker je pozornost omejena. Problem nastane, ko predlog sistema postane de facto odločitev. Raziskave avtomatizacijskega pristranskega zaupanja kažejo, da ljudje lahko preveč sledijo avtomatiziranemu priporočilu in spregledajo napako, zlasti kadar je preverjanje zahtevno, obremenitev visoka ali sistem večino časa deluje pravilno. Zanesljiv sistem lahko paradoksalno zmanjša vadbo za trenutek, ko se zmoti.
Zato 'human in the loop' ni dovolj, če je človek prisoten samo formalno. Če nima časa, podatkov, pooblastila ali znanja za preverjanje, je njegov klik lahko le ritual potrditve. Človeški nadzor je resničen šele, ko lahko priporočilo razumljivo preveri in ga po potrebi zavrne.
Izpad ni edini način izgube nadzora
Tehnološko odvisnost pogosto povezujemo z dramatičnim izpadom podatkovnega centra, vendar so poti do nedostopnosti širše. Napačna konfiguracija lahko prekine storitev brez okvare strojne opreme; ukraden račun lahko zaklene legitimnega lastnika; sprememba API-ja lahko podre integracijo; pogodbeni spor ali blokada računa lahko ustavi poslovni proces; izguba ključev lahko naredi šifrirane podatke nedostopne.
Tudi kibernetska varnost sama lahko ustvarja odvisnosti. Sodobni pristopi, kot je zero trust, pravilno odstranjujejo implicitno zaupanje in zahtevajo eksplicitno preverjanje identitete ter dostopa. Toda identitetna infrastruktura zato postane kritični del delovanja. Varnostna arhitektura mora razmišljati tudi o razpoložljivosti, ne samo o tem, kdo sme vstopiti.
NIST-ov okvir kibernetske odpornosti zato govori o sposobnosti sistema, da neugodne pogoje pričakuje, prenese, se po njih obnovi in se jim prilagodi. To je širše od preprečevanja napada. Sistem je odporen, če pomembna funkcija preživi tudi takrat, ko del infrastrukture ni več zaupanja vreden ali ni več dosegljiv.
Rezerva, ki je ne znamo uporabiti, ni prava rezerva
Redundanca je osnovno orodje odpornosti, vendar sama številka 'imamo dva' ne pove dovolj. Dve kopiji podatkov v istem računu, isti regiji ali istem ponudniku lahko izginejo zaradi istega incidenta. Dva omrežna priključka po isti fizični trasi lahko odpovesta skupaj. Rezervni sistem, ki ni bil nikoli preizkušen, lahko obstaja samo v dokumentaciji.
NIST-ova priporočila za načrtovanje neprekinjenega delovanja (ang. contingency planning) zato vključujejo alternativno opremo, alternativna mesta obdelave, obnovitev podatkov in celo začasne ročne postopke. Ključna beseda je preizkušanje. Varnostna kopija postane del odpornosti šele, ko vemo, da ga lahko obnovimo v času, ki je za funkcijo še sprejemljiv.
Pomemben je tudi degradirani način delovanja. Ni treba, da rezervna pot zagotavlja vse funkcije. Bolnišnica, logistični center ali majhno podjetje lahko potrebuje predvsem sposobnost, da ob izpadu še vedno vidi ključne podatke, sprejema osnovne odločitve in beleži dogodke za poznejšo sinhronizacijo. Odpornost ni nujno popolna kopija normalnega dne; pogosto je sposobnost varnega preživetja do obnove.
Lokalna alternativa ne pomeni tehnološke avtarkije
Kritika odvisnosti hitro zdrsne v drugo skrajnost: vse moramo gostiti sami, vse podatke hraniti lokalno in se izogibati zunanjim storitvam. Za večino ljudi in organizacij bi bil tak pristop dražji, težje vzdržljiv in pogosto manj varen. Velik ponudnik lahko zagotovi znanje, redundanco in odziv, ki jih majhna ekipa preprosto nima.
Bolj uporaben cilj je selektivna lokalna sposobnost. Kritični podatki imajo lahko preverjeno lokalno ali neodvisno varnostno kopijo; bistvena funkcija lahko ima način brez povezave (ang. offline); identiteta lahko vsebuje varne postopke za izredni dostop; aplikacija lahko uporablja odprte formate; nekatere obremenitve lahko ostanejo lokalne, druge pa v oblaku. Hibridna arhitektura je lahko kompromis, ne ideološka sredina.
Enako velja za uporaba več oblakov (ang. multi-cloud). Uporaba dveh ponudnikov je koristna samo, če drugi res predstavlja neodvisno pot. Če oba uporabljata isti identitetni sistem, isti DNS ali isti zunanji API, lahko 'več oblakov' še vedno skriva eno točko odpovedi. Arhitekturna raznolikost je pomembnejša od logotipov na diagramu.
Možnost izstopa je varnostna in politična lastnost sistema
Sistem, iz katerega lahko izstopimo samo z ogromnimi stroški, nam v praksi omejuje izbiro. To velja za podjetje, ki ne more preseliti podatkov, in za posameznika, ki ne more izvoziti svojih informacij ali opraviti ključne storitve brez enega računa. Zato je izhodna možnost več kot konkurenčna tema; je del odpornosti in razmerja moči.
Dobro zasnovan izstop ima več plasti: podatki so v dokumentiranem in uporabnem formatu; obstaja seznam odvisnosti; dostopne so ključne konfiguracije in ključi; alternative so bile vsaj občasno preizkušene; pogodba določa postopek prenehanja; ljudje pa vedo, kako nadaljevati, ko avtomatizacija ni na voljo. To ne pomeni, da je selitev lahka. Pomeni, da ni praktično nemogoča.
Evropski Data Act in NIST-ovi standardi za računalništvo v oblaku oba poudarjajo interoperabilnost in portabilnost prav zato, ker teh lastnosti trg ne zagotovi avtomatično. Tehnološka svoboda ni odsotnost odvisnosti; je možnost, da odvisnost zamenjamo, omejimo ali prekinemo brez izgube vsega, kar smo v sistem vložili.
Ko infrastruktura postane nevidna, mora biti načrt za njeno odsotnost viden
Sodobna družba ne more realistično delovati brez omrežij, oblaka, programske opreme in avtomatizacije. Prav tako ni razloga, da bi se jim odpovedala samo zato, ker ustvarjajo odvisnosti. Toda visoka uporabnost ni isto kot neskončna zanesljivost, in priročnost ni isto kot nadzor.
Najbolj zrela arhitektura zato ne vpraša samo, ali storitev danes deluje. Vpraša tudi: od česa je odvisna, kaj se zgodi ob odpovedi, koliko časa lahko čakamo, katere podatke moramo imeti drugje, kdo lahko preglasi avtomatizirano odločitev in kako bomo odšli, če ponudnik ali tehnologija nekoč ne bosta več ustrezala našim potrebam.
Ko infrastruktura 'misli namesto nas', je njena največja nevarnost pogosto prav to, da izgine iz naše zavesti. Odpornost jo ponovno naredi vidno. Ne zato, da bi vsak človek postal sistemski administrator, ampak da bistvene funkcije, odločitve in podatki ne bi bili talci ene nevidne poti. Dober sistem nam prihrani delo. Odporen sistem nam poleg tega pusti možnost, da nadaljujemo, ko običajni sistem ne more.
Viri in nadaljnje branje
- THY-REALITY — Kibernetika: od povratne zanke do človeka v sistemu / Cybernetics: From Feedback Loops to the Human in the System (LOCKED): feedback, regulation, human-system loops and distributed control.
- THY-REALITY — Roboti in avtomatizacija: kdo dela, kdo odloča in kdo ima koristi? / Robots and Automation: Who Works, Who Decides and Who Benefits? (LOCKED): automation, algorithmic management and human authority.
- THY-REALITY — Opazovalec in model: koliko naš opis oblikuje to, kar vidimo? / Observer and Model: How Much Does Our Description Shape What We See? (LOCKED): models, measurement and epistemic limits.
- Mell, P.; Grance, T. — The NIST Definition of Cloud Computing. NIST SP 800-145, 2011.
- Sokol, A.; Hogan, M. — NIST Cloud Computing Standards Roadmap. NIST SP 500-291r2, 2013: interoperability and portability requirements.
- Badger, L. et al. — US Government Cloud Computing Technology Roadmap. NIST SP 500-293, 2014: secure, interoperable, reliable cloud services and provider switching.
- Ross, R. et al. — Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST SP 800-160 Vol. 2 Rev. 1, 2021.
- Swanson, M. et al. — Contingency Planning Guide for Federal Information Systems. NIST SP 800-34 Rev. 1: alternate processing, recovery and manual fallback.
- Rose, S.; Borchert, O.; Mitchell, S.; Connelly, S. — Zero Trust Architecture. NIST SP 800-207, 2020.
- NIST NCCoE — Implementing a Zero Trust Architecture. NIST SP 1800-35, 2025: distributed resources across on-premises and multiple clouds.
- European Commission — Data Act Explained, Chapter VI: switching between data processing services, portability, open interfaces and removal of switching barriers.
- European Commission — Results of the Study on Interoperability of Data Processing Services, 2026.
- European Banking Authority — Risk Assessment Report, June 2026: dependency on third-party ICT/cloud providers and operational-resilience concentration risks.
- European Banking Authority — Risk Assessment Report, December 2025: outsourcing and concentration dependencies in cloud and payment systems.
- Parasuraman, R.; Manzey, D. H. — Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 2010, 381–410.
- Goddard, K.; Roudsari, A.; Wyatt, J. C. — Automation Bias: A Systematic Review of Frequency, Effect Mediators, and Mitigators. Journal of the American Medical Informatics Association 19(1), 2012, 121–127.
- Lyell, D.; Coiera, E. — Automation Bias and Verification Complexity: A Systematic Review. Journal of the American Medical Informatics Association 24(2), 2017, 423–431.
- Tabassi, E. — Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023.
- Chandramouli, R.; Butcher, Z. — A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST SP 800-207A, 2023.