Self-host vs. cloud: które rozwiązanie dla banku lub służby zdrowia?

Debata „cloud czy on-premise” trwa od 2010 roku. W zwykłych branżach cloud zdecydowanie wygrał — w 2026 roku trudno byś znalazł agencję marketingową lub e-sklep, który prowadzi własne serwery. W branżach regulowanych (banki, ubezpieczenia, szpitale, zamówienia publiczne) pytanie jest jednak nadal żywe i ma swoje dobre powody. W tym artykule przejdziemy przez aktualny stan regulacji, zrobimy porównanie TCO i pokażemy, kiedy faktycznie opłaca się self-host, kiedy cloud, a kiedy hybryda.

Kontekst regulacyjny — DORA, NIS2, RODO i przepisy sektorowe

Rok 2026 przyniósł do europejskiej przestrzeni konsolidację regulacji. Bankom i ubezpieczalniom rządzi DORA (Digital Operational Resilience Act), infrastrukturze krytycznej NIS2, całej UE ekosystem RODO i AI Act. Dla służby zdrowia doszły lokalne przepisy Ministerstwa Zdrowia oraz wytyczne sektorowe NBP dla fintech.

DORA od stycznia 2025 wymaga od instytucji finansowych pełnej kontroli nad łańcuchem dostawców ICT. Każdy dostawca chmury, który przetwarza „ważne funkcje”, musi mieć eksplicytną umowę z rights-to-audit, planem strategii wyjścia i wykazaną odpornością na awarie. NBP regularnie kontroluje, czy bank w czasie rzeczywistym potrafi wykazać, gdzie znajdują się jego dane, kto miał do nich dostęp i jak wyglądałaby 48-godzinna utrata dostawcy.

NIS2 od października 2024 rozszerza obowiązki także na większe placówki medyczne, wodociągi, energetykę i administrację publiczną. Kluczowy jest 24-godzinny incident response, 72-godzinne zgłoszenie i obowiązkowe MFA dla kont administratorskich.

RODO rozwiązuje ochronę danych osobowych. Dla danych medycznych (art. 9) i biometrii obowiązują surowsze zasady, w tym obowiązek DPIA (Data Protection Impact Assessment) przed wdrożeniem.

Wskazówka: Zanim zaczniesz decydować między cloud a self-host, poproś dział compliance lub prawnika o pisemną listę wymagań regulacyjnych, które musi spełniać Twoje rozwiązanie IT. Bez tej listy będziesz decydować na wyczucie, a nie na faktach.

Cloud — co naprawdę oznacza w środowisku regulowanym

Cloud w potocznym języku oznacza „gdzieś w internecie”. W świecie regulowanym jest to subtelniejsze. Wyróżniamy cztery warianty:

Public cloud — AWS, Azure, Google Cloud. Twoja aplikacja działa obok tysiąca innych. Dla branż regulowanych akceptowalny tylko przy regionach UE i przy spełnieniu wszystkich SCC (Standard Contractual Clauses), rozwiązań CLOUD Act i idealnie przez warianty „sovereign cloud” (Azure EU Data Boundary, AWS European Sovereign Cloud).

Private cloud — wydzielona infrastruktura u dostawcy chmury, ale tylko dla Ciebie. Droższe, ale pełna kontrola nad segmentacją sieci. Znacznie łatwiej obronić przed regulatorem.

Sovereign cloud — cloud pod jurysdykcją UE/PL, bez możliwości dostępu zagranicznych organów (CLOUD Act immune). W Polsce dostępny np. przez Polcom lub Chmurę Krajową.

SaaS na poziomie aplikacji — Modulario, Salesforce Financial Cloud, Epic (służba zdrowia). Dostawca rozwiązuje infra i aplikację. Najprostsze do adopcji, ale wymaga starannego vendor due diligence.

Dla banku i służby zdrowia w 2026 public cloud jest dopuszczalny — ale tylko przez wariant sovereign lub europejski regionalny z jasnym SCC RODO. PKO BP, Pekao, Santander i ING mają dziś części infrastruktury w Azure EU, ale nigdy nie w regionie USA.

Self-host — kontrola za cenę złożoności

Self-host (on-premise) oznacza, że infrastrukturę prowadzisz sam — Twoje serwery, Twoja serwerownia, Twój zespół, Twoje ryzyko. W 2026 self-host jest nadal istotny dla trzech scenariuszy:

  1. Surowe przepisy sektorowe. Na przykład wybrane instytucje wojskowe lub strategicznie ważne, gdzie regulator wprost wymaga wdrożenia air-gapped.
  2. Ogromne ilości danych. Jeśli codziennie generujesz 50 TB logów, cloud Cię finansowo zrujnuje; własny SAN/NAS ma sens ekonomiczny.
  3. Specjalistyczne legacy systemy. Istniejące mainframe core banking, których nie oferuje się w chmurze i których migracja kosztowałaby setki milionów.

Poza tymi trzema scenariuszami self-host w 2026 jest finansowo i operacyjnie trudny do obrony. Powody:

  • Chroniczny brak SRE i specjalistów ds. bezpieczeństwa. Senior sysadmin z certyfikatami i 5-letnim doświadczeniem kosztuje w PL grubo 4 500 euro miesięcznie, a jest ich mało. Dostawca chmury ma ich tysiące.
  • Eksploatacja 24/7. Aplikacja bankowa musi działać 99,99% czasu. Dotrzymanie tego własnym zespołem oznacza minimum 4 osoby na rotacji — rocznie 200 000 euro na wynagrodzenia.
  • Patching i łatki zero-day. W 2025 wyszło 45 000 CVE. Czas reakcji przy self-hoście to dni, u dobrego dostawcy chmury godziny.

Wskazówka: Self-host, który „wydaje się tani”, zwykle ukrywa trzy pozycje — chłodzenie, redundantne łącza i specjalistów ds. bezpieczeństwa na rotacji 24/7. Jeśli Twój model TCO tych trzech pozycji nie zawiera, porównanie z chmurą nie jest fair.

Porównanie TCO — realne liczby z 2025

Zrobiliśmy 5-letni model TCO dla średniego regionalnego banku (pojemność 50 000 klientów, 250 użytkowników wewnętrznych, 1 TB danych miesięcznie, wymaganie 99,99% uptime).

Scenariusz A — self-host on-premise

Pozycja1. rokKolejne lata
Sprzęt (serwery, SAN, sieć)180 000 EUROdnowa 20% rocznie
Licencje OS, baza danych, backupy45 000 EUR35 000 EUR rocznie
Centrum danych + chłodzenie24 000 EUR24 000 EUR rocznie
Personel (4 osoby, 24/7)220 000 EUR230 000 EUR rocznie
Audyty bezpieczeństwa30 000 EUR20 000 EUR rocznie
Certyfikacje (ISO 27001)50 000 EUR15 000 EUR rocznie
Razem rok 1549 000 EUR
Średnia rocznie (5 lat)~360 000 EUR

Scenariusz B — EU sovereign cloud z aplikacją SaaS

Pozycja1. rokKolejne lata
Licencje SaaS (250 użytkowników)90 000 EUR95 000 EUR rocznie
Cloud infra dodatkowo (storage, backup)24 000 EUR26 000 EUR rocznie
Integracje i własny rozwój60 000 EUR30 000 EUR rocznie
Personel (2 osoby, administracja)130 000 EUR135 000 EUR rocznie
Audyty bezpieczeństwa20 000 EUR15 000 EUR rocznie
Razem rok 1324 000 EUR
Średnia rocznie (5 lat)~215 000 EUR

Oszczędność cloud w stosunku do self-host: ~40% w 5 lat, przy założeniu, że wybierzesz wariant EU sovereign z pełnym compliance.

Liczby obowiązują dla średniego banku. Dla mikrofintechu z 5 pracownikami cloud jest korzystniejszy 10:1. Dla dużego globalnego banku z własnym DC i już zbudowanym zespołem self-host może być korzystniejszy o 10-15%.

Data residency i sovereignty — najważniejsze pytanie

Gdzie fizycznie leżą Twoje dane? To pytanie, na które bank i służba zdrowia muszą sobie odpowiedzieć pisemnie przed każdą umową. W Polsce mamy trzy poziomy:

  1. Dane w PL — idealne dla krytycznych systemów administracji publicznej i służby zdrowia. Dostawcy: Polcom, Chmura Krajowa, niektóre wojewódzkie centra danych.
  2. Dane w UE — akceptowalne dla banków, jeśli dostawca zapewnia data residency guarantee i CLOUD Act immune. Dostawcy: Azure EU Data Boundary, AWS Frankfurt/Dublin z European Sovereign Cloud, OVHcloud.
  3. Dane poza UE — dopuszczalne tylko dla niekrytycznych funkcji z pełną anonimizacją i Standard Contractual Clauses.

Infrastruktura Modulario jest głównie hostowana w Azure Europe West (Amsterdam) z zapasową repliką w Azure Europe North (Dublin), obie pod EU Data Boundary. Dla klientów z branż regulowanych potrafimy zaoferować także wdrożenie w sovereign cloudzie PL.

Służba zdrowia — specyfika, której nie wolno zaniedbać

W służbie zdrowia cloud ma dwie główne bariery: historyczny sceptycyzm i konkretne lokalne przepisy. Sektor medyczny wymaga:

  • Szyfrowanie AES-256 w spoczynku i w ruchu.
  • End-to-end audit trail — każdy wgląd do dokumentacji medycznej musi być rejestrowany, kto, kiedy i z jakiego powodu.
  • Integracja z NFZ i ubezpieczeniami zdrowotnymi przez interfejs P1.
  • Eksploatacja ZUS PUE lub elektronicznych legitymacji do logowania.

Nowoczesne SaaS dla służby zdrowia (szpitalne systemy informacyjne, oprogramowanie ambulatoryjne) w 2026 zapewniają wszystkie te wymagania out-of-the-box. Self-host wymaga dostawcy, który rozumie specyfikę, lub własnego zespołu — co przy pojemności mniejszych szpitali nie jest realne.

Wskazówka: Przy wyborze SaaS dla przychodni lub polikliniki nie polegaj tylko na deklaracjach marketingowych. Poproś o dokumentację z ostatniego testu penetracyjnego i kopię DPIA. Jeśli dostawca ich nie ma, to sygnał ostrzegawczy.

Sektor finansowy — DORA w praktyce

Sektor finansowy musi od stycznia 2025 spełniać DORA — a dostawca chmury jest z tym związany umową, którą kontroluje NBP. Minimum, co umowa musi zawierać:

  • Rights to audit — bank ma prawo w dowolnym momencie wykonać audyt u dostawcy (zwykle przez stronę trzecią jak KPMG lub PwC).
  • Exit strategy — szczegółowy plan, jak bank opuści dostawcę w 90 dni bez utraty danych.
  • Incident notification — dostawca powiadamia bank w ciągu 2 godzin o poważnym incydencie.
  • Data location guarantee — dane pozostają w konkretnych regionach.
  • Sub-contractor transparency — bank widzi łańcuch sub-dostawców i może zawetować.

Dostawcy chmury, którzy tego nie potrafią zapewnić, są dla banku nieakceptowalni. Modulario, AWS EU, Azure EU i wybrani lokalni dostawcy te wymagania spełniają.

Scenariusz hybrydowy — najczęstsza odpowiedź

W praktyce większość banków i placówek medycznych kończy na hybrydzie. Krytyczne systemy core (core banking, dokumentacja medyczna) w sovereign cloudzie lub on-premise, pozostałe systemy (e-mail, ERP, HR, marketing) w public cloudzie z UE data residency.

Dla małej firmy fintech zwykle opłaca się public EU cloud od pierwszego dnia. Dla średniego banku hybryda będzie naturalna — core banking pozostanie w istniejącym DC, ale wszystko inne (CRM, HR, ERP, dokumenty) migruje do chmury. Oszczędność to zwykle 30-45% w 5 lat, a jednocześnie zachowuje się pełną zgodność z DORA.

Drzewo decyzyjne — 5 kroków

Jeśli decydujesz, którą drogę wybrać, idź według następujących pięciu kroków:

  1. Zidentyfikuj krytyczność systemu. Czy to core (płatności, dokumentacja medyczna), czy wspierający (HR, marketing)?
  2. Pytaj regulatora. Masz od NBP/MZ/UODO pisemne stanowisko lub rozporządzenie sektorowe, które Cię wiąże?
  3. Zmapuj dane. Gdzie są dane osobowe? Czy są medyczne lub biometryczne (art. 9 RODO)?
  4. Zrób model TCO na 5 lat. Wlicz także wynagrodzenia zespołu, audyty, certyfikacje.
  5. Rozważ hybrydę. W większości przypadków to optimum.

Podsumowanie — 2026 należy do chmury, ale z warunkami

W środowisku regulowanym 2026 cloud dawno nie jest już „niebezpieczną obcością”. Wręcz przeciwnie, przy właściwym wyborze (EU sovereign, dostawca zgodny z DORA, immunitet CLOUD Act) cloud jest bezpieczniejszy niż większość wdrożeń on-premise — właśnie dlatego, że dostawcy inwestują w bezpieczeństwo o rzędy wielkości więcej, niż może sobie pozwolić średni bank.

Self-host zachowuje swoje miejsce tam, gdzie regulator bezpośrednio wymaga wdrożenia air-gapped, lub gdzie objętość danych czyni cloud ekonomicznie niekorzystnym. W pozostałych przypadkach cloud — szczególnie w postaci hybrydowej — jest racjonalnym wyborem.

Jeśli jesteś z branży regulowanej i chcesz, by ocenić Twoją sytuację, napisz do nas. Przygotujemy pisemne stanowisko z drzewem decyzyjnym, modelem TCO i konkretną rekomendowaną architekturą dla Twojego przypadku. Konsultacja trwa 60 minut i jest bezpłatna — wychodzisz z jasną drogą.