Infrastruktura pod AI: API, chmura GPU, on-premises czy serwer dedykowany?

Infrastruktura pod AI to środowisko obliczeniowe dobrane do konkretnego obciążenia związanego z wnioskowaniem (inferencją) lub dostosowaniem modelu. Może korzystać z CPU, GPU, TPU lub innych akceleratorów. Wybór zależy od wielkości modelu, wymagań dotyczących opóźnienia, zmienności obciążenia, klasyfikacji przetwarzanych danych i dostępnych zasobów zespołu. SparkSome wspiera firmy w doborze i przygotowaniu infrastruktury AI.

Według raportu AI Index 2026 opublikowanego przez Stanford HAI, 88% respondentów badania McKinsey deklarowało, że ich organizacja wykorzystuje AI w co najmniej jednej funkcji biznesowej; rok wcześniej odsetek ten wynosił 78%. Dane pokazują rosnącą skalę adopcji, ale nie przesądzają o dojrzałości ani opłacalności poszczególnych wdrożeń. To deklaratywne wyniki ankiety, dlatego nie pozwalają określić, jaka część organizacji ma dojrzałe wdrożenia produkcyjne ani czy są one opłacalne.

Wraz z przejściem od eksperymentów do wdrożeń produkcyjnych wychodzą na jaw nowe wyzwania. Produkcyjne wdrożenie AI nie kończy się na jednorazowym uruchomieniu modelu. Wymaga obsługi bieżącego wnioskowania, monitorowania środowiska, kontroli kosztów oraz utrzymania całego rozwiązania. Dotychczasowe strategie IT często nie przystają do wymagań AI. Bez monitorowania wykorzystania zasobów i kosztu pojedynczego zadania wydatki na API lub chmurowe zasoby GPU mogą rosnąć wraz ze skalą wdrożenia. Koszty należy analizować na podstawie rzeczywistego obciążenia, liczby zapytań, wielkości modelu i wymaganego poziomu dostępności.

Do tego dochodzą wymagania prawne i umowne dotyczące przetwarzanych danych, a także wymagania związane z czasem odpowiedzi, dostępnością i niezawodnością systemu.

W tym artykule przyglądamy się czterem modelom infrastruktury do wnioskowania AI: gotowemu API modelu, instancjom GPU w chmurze publicznej, infrastrukturze on-premises oraz dedykowanej infrastrukturze w zewnętrznym centrum danych.

Co to jest infrastruktura pod AI? Definicja i zakres pojęcia

Infrastruktura pod AI to środowisko obliczeniowe dobrane do konkretnego zadania: wnioskowania z gotowego modelu, jego dalszego dostosowania (fine-tuning) lub rzadziej, trenowania od podstaw. Nie każde obciążenie AI wymaga serwera GPU. Mniejsze modele po kwantyzacji mogą działać na CPU, jeśli komputer dysponuje odpowiednią ilością pamięci, choć zwykle odbywa się to kosztem niższej przepustowości i dłuższego czasu odpowiedzi. Większe modele oraz zastosowania wymagające niskich opóźnień i wysokiej przepustowości zazwyczaj korzystają z GPU lub innych akceleratorów.

Warto rozróżnić dwa zasadniczo różne rodzaje obciążeń:

Trenowanie modeli bazowych od podstaw wiąże się z bardzo dużymi wymaganiami obliczeniowymi i może wymagać rozbudowanych klastrów GPU pracujących przez długi czas. Firmy znacznie częściej korzystają z gotowych modeli niż trenują je od podstaw. Dostosowanie rozwiązania do konkretnego zastosowania może obejmować między innymi mechanizm RAG (Retrieval-Augmented Generation, uzupełnianie kontekstu modelu o informacje z zewnętrznych źródeł wiedzy podczas wnioskowania) lub fine-tuning (dalsze trenowanie modelu na odpowiednio przygotowanych danych). Wybór podejścia zależy od potrzeb i specyfiki danych organizacji.

Inferencja (wnioskowanie) to użycie już gotowego modelu do bieżących zadań. Jest mniej zasobochłonna od trenowania od podstaw, ale przy dużych modelach językowych i wysokich wymaganiach dotyczących przepustowości i opóźnienia wymaga odpowiednio dobranego środowiska obliczeniowego.

Kluczową decyzją staje się więc: jaki model infrastruktury najlepiej odpowiada wymaganiom konkretnego zastosowania?

Cztery modele infrastruktury AI: tabela porównawcza

Tabela posługuje się następującymi skrótami:

• CAPEX (capital expenditure, nakłady inwestycyjne na zakup środków trwałych),
• OPEX (operational expenditure, koszty operacyjne),
• MLOps (Machine Learning Operations, praktyki inżynieryjne łączące uczenie maszynowe z utrzymaniem systemów produkcyjnych).

Kryterium	API modelu	GPU w chmurze	On-premises	Dedykowana infrastruktura w zewnętrznym centrum danych
Czas do uruchomienia	Dostęp: minuty; integracja produkcyjna: zależna od zakresu	Dostęp: od minut; środowisko produkcyjne zależne od konfiguracji, limitów i dostępności zasobów	Zależny od dostępności sprzętu i zakresu wdrożenia	Zależny od dostępności sprzętu i zakresu infrastruktury
Nakłady inwestycyjne (CAPEX)	Zwykle brak CAPEX infrastrukturalnego	Zwykle brak CAPEX infrastrukturalnego	Wysokie	Zależne od modelu: zakup sprzętu wymaga CAPEX, wynajem zwykle nie
Model kosztowy	Za wykorzystanie, np. tokeny lub wywołania	Za czas i zasoby (OPEX)	Amortyzacja + utrzymanie	Zakup, wynajem lub abonament
Przewidywalność kosztów	Zależna od wykorzystania i stawek dostawcy	Niska lub zmienna, zależna od wykorzystania	Zależna od wykorzystania i pełnego TCO	Zależna od modelu finansowania i warunków umowy
Kontrola nad danymi	Zależna od dostawcy i planu	Zależna od usługi i konfiguracji	Wysoka, bezpośrednia	Określona architekturą i umową
Elastyczność skalowania	Wysoka, zależna od limitów i dostępności zasobów	Wysoka, zależna od limitów i dostępności zasobów	Ograniczona	Zależna od dostępności sprzętu i warunków dostawcy
Wymagany zespół IT	Integracja i zarządzanie kluczami	Kompetencje chmurowe i MLOps	Znaczący: infrastruktura i MLOps	Zależny od podziału odpowiedzialności między klienta, SparkSome i dostawcę
Czas odpowiedzi	Zmienna (sieć + model)	Zmienna: zależna od sieci, regionu, modelu i obciążenia	Zależna od architektury lokalnej	Zależna od lokalizacji centrum danych i sieci
Wymagania prawne i bezpieczeństwa	Wymaga analizy konkretnego procesu, rodzaju danych i zastosowanych zabezpieczeń	Wymaga analizy konkretnego procesu, rodzaju danych i zastosowanych zabezpieczeń	Wymaga analizy konkretnego procesu, rodzaju danych i zastosowanych zabezpieczeń	Wymaga analizy konkretnego procesu, rodzaju danych i zastosowanych zabezpieczeń
Działanie bez internetu	Zależne od usługi; wymaga łączności zewnętrznej	Możliwe bez publicznego internetu przez wybrane połączenia prywatne	Możliwe, jeśli tak zaprojektowano środowisko	Wymaga łączności z centrum danych, niekoniecznie publicznego internetu

Gotowe API modelu: kiedy to właściwy wybór?

Gotowe API modelu (np. OpenAI, Anthropic, Google, Mistral) to najprostszy punkt wejścia do wdrożeń AI. Firma integruje API ze swoją aplikacją i płaci za zużyte tokeny lub wywołania, bez konieczności zarządzania infrastrukturą.

API sprawdza się, gdy:

• Projekt jest w fazie eksperymentów lub pilota i nie wiesz jeszcze, jakie zasoby będą potrzebne
• Obciążenie jest nieregularne lub trudne do przewidzenia
• Chcesz szybko sprawdzić wartość AI przed podjęciem decyzji o infrastrukturze
• Twój zespół nie ma kompetencji do zarządzania środowiskiem obliczeniowym
• Jakość dostępnych modeli komercyjnych wystarczy do planowanego zastosowania

Co wziąć pod uwagę:

Przed integracją z zewnętrznym API należy ustalić, jakie dane będą przekazywane dostawcy, gdzie są przetwarzane i jak długo przechowywane. Jeżeli dostawca przetwarza dane osobowe jako podmiot przetwarzający w rozumieniu art. 28 RODO, konieczne jest ustalenie ról stron i zawarcie umowy powierzenia przetwarzania danych. Niektórzy dostawcy oferują ograniczoną lub zerową retencję dla wybranych usług i planów. Warunki należy sprawdzić dla konkretnej usługi, konfiguracji i umowy.

Wymagania prawne, umowne i wewnętrzna klasyfikacja danych powinny decydować o tym, jakie dane można przetwarzać u danego dostawcy.

Przy rosnącej skali zastosowania koszt tokenów może stać się istotną pozycją budżetową. Warto monitorować zużycie od początku i analizować TCO (całkowity koszt posiadania) w horyzoncie odpowiadającym planowanemu okresowi wykorzystania rozwiązania.

GPU w chmurze publicznej: kiedy to właściwy wybór?

Chmura publiczna (AWS, Google Cloud, Azure) oferuje dostęp do instancji GPU bez konieczności zakupu i utrzymania sprzętu. Płacisz za czas działania zasobów, co sprzyja skalowaniu obciążeń o zmiennym natężeniu.

W chmurze publicznej dostępne są zarówno środowiska współdzielone, jak i wybrane warianty dedykowane (dedykowane hosty, węzły sole-tenant). Zakres izolacji zależy od konkretnej usługi, modelu współdzielenia lub wydzielenia zasobów (tenancy) i konfiguracji.

Chmura GPU sprawdza się, gdy:

• Potrzebujesz dużej mocy obliczeniowej do trenowania lub dostosowywania modeli przy zmiennym natężeniu pracy
• Obciążenie jest zmienne (ruch sezonowy, kampanie, projekty czasowe)
• Chcesz szybko uruchomić środowisko bez inwestycji w sprzęt
• Nie chcesz kupować i utrzymywać własnego sprzętu, a Twój zespół posiada lub może pozyskać kompetencje potrzebne do zarządzania środowiskiem chmurowym i MLOps

Co wziąć pod uwagę:

Koszt korzystania z instancji GPU zależy przede wszystkim od typu instancji i czasu jej działania, a także od wykorzystanej pamięci masowej, usług sieciowych oraz transferu danych. Przy stałym i wysokim wykorzystaniu własna lub dedykowana infrastruktura może zapewnić niższy koszt jednostkowy. Wymaga to jednak obliczenia TCO dla konkretnego obciążenia, okresu eksploatacji i oczekiwanego poziomu dostępności, z uwzględnieniem energii, chłodzenia, licencji, serwisu, redundancji, pracy administratorów oraz cyklu wymiany sprzętu.

RODO nie zakazuje przetwarzania danych osobowych w chmurze. Wymaga odpowiedniej podstawy prawnej, zabezpieczeń, ustalenia ról stron oraz zgodnych z prawem transferów poza EOG. Jeżeli dostawca działa jako podmiot przetwarzający, konieczne jest również zawarcie umowy powierzenia przetwarzania danych. W Polsce wymagania NIS2 zostały wdrożone do ustawy o krajowym systemie cyberbezpieczeństwa (nowelizacja weszła w życie 3 kwietnia 2026 roku). Przepisy dotyczą zarządzania ryzykiem cyberbezpieczeństwa przez podmioty objęte ustawą i nie wprowadzają ogólnego zakazu korzystania z chmury.

On-premises: kiedy własna infrastruktura AI ma sens?

Infrastruktura AI zainstalowana we własnej serwerowni lub centrum danych daje wysoką, bezpośrednią kontrolę nad danymi i konfiguracją. Ta opcja może być finansowo atrakcyjna przy dużych, stałych obciążeniach, ale wymaga kalkulacji TCO uwzględniającej cały cykl życia infrastruktury.

On-premises sprawdza się, gdy:

• Przetwarzasz dane wymagające wysokiej kontroli dostępu wynikającej z przepisów, umów lub wewnętrznej oceny ryzyka
• System musi działać niezależnie od łącza internetowego lub sieci zewnętrznych
• Wymagasz przewidywalnego opóźnienia i bezpośredniej kontroli nad środowiskiem obliczeniowym
• Masz stałe, przewidywalne obciążenie przez cały rok
• Posiadasz lub możesz zbudować kompetentny zespół IT do utrzymania infrastruktury

Czas odpowiedzi w zastosowaniach wymagających przetwarzania w czasie rzeczywistym:

Jeżeli proces wymaga reakcji w ściśle określonym czasie, należy zmierzyć pełne opóźnienie: od pozyskania danych, przez wnioskowanie, do wyniku i działania systemu. Dla części zastosowań przemysłowych może to przemawiać za przetwarzaniem lokalnym lub przetwarzaniem brzegowym (edge computing), ale próg wymagany przez konkretny proces powinien wynikać z jego specyfiki, a nie z ogólnych reguł.

Wady on-premises:

Wysoki CAPEX na start. Konieczność posiadania własnych kompetencji do utrzymania, aktualizacji i monitorowania infrastruktury. Ograniczona elastyczność przy nagłym wzroście zapotrzebowania na moc obliczeniową. Odpowiedzialność za środowisko pozostaje po stronie organizacji, nawet jeżeli część prac związanych z jego utrzymaniem zostanie powierzona zewnętrznemu partnerowi.

Infrastruktura lokalna lub przetwarzanie brzegowe bywa właściwym wyborem, gdy kluczowe znaczenie mają przewidywalne opóźnienie, niezależność od łącza i bezpośrednia kontrola nad środowiskiem. Nie jest jednak jedyną opcją łączącą te cechy: warto rozważyć także dedykowane hosty w chmurze, kolokację sprzętu własnego, prywatną chmurę oraz architekturę hybrydową.

Serwer dedykowany w zewnętrznym centrum danych: kiedy warto go wybrać?

Dedykowana infrastruktura AI w zewnętrznym centrum danych może działać w kilku modelach. Firma może wynająć fizyczny serwer od dostawcy hostingu albo kupić własny sprzęt i umieścić go w wybranym centrum danych. Zakres usługi, podział odpowiedzialności, dostępność sprzętu, SLA oraz model rozliczeń zależą od wybranego dostawcy i umowy.

SparkSome może pomóc w analizie wymagań, doborze konfiguracji, porównaniu ofert zewnętrznych dostawców oraz zakupie i przygotowaniu serwera. Serwer jest instalowany w lokalizacji klienta albo w zewnętrznym centrum danych, zależnie od wybranego modelu.

Co może obejmować wsparcie SparkSome:

• analizę wymagań dotyczących wydajności, dostępności, bezpieczeństwa i skalowania;
• dobór konfiguracji serwera oraz infrastruktury sieciowej i pamięci masowej;
• porównanie ofert zewnętrznych dostawców hostingu i centrów danych;
• pomoc w zakupie lub zamówieniu odpowiedniego serwera;
• przygotowanie i wdrożenie środowiska obliczeniowego;
• monitoring i utrzymanie środowiska w zakresie ustalonym z klientem.

Ważne zastrzeżenia dotyczące prywatności i izolacji:

Dedykowany fizyczny serwer ogranicza część ryzyk związanych ze współdzieleniem zasobów obliczeniowych. Nie eliminuje jednak wszystkich ryzyk dotyczących danych: dostęp administracyjny, konfiguracja sieci, przechowywanie logów, zasady tworzenia kopii zapasowych, retencja danych i transfer administracyjny muszą być jasno określone w architekturze rozwiązania i umowie. Zakres faktycznej izolacji zależy od tego, które elementy środowiska są rzeczywiście dedykowane klientowi: serwer, pamięć masowa, sieć, system monitoringu i warstwa zarządzająca.

Zgodność z wymaganiami prawnymi, w tym z RODO, nie wynika automatycznie z faktu korzystania z dedykowanego sprzętu. Wymaga analizy celu i zakresu przetwarzania, podstawy prawnej, uprawnień dostępu, retencji, zabezpieczeń, umów i ewentualnie oceny skutków dla ochrony danych (DPIA, Data Protection Impact Assessment).

Serwer dedykowany w zewnętrznym centrum danych sprawdza się, gdy:

• Nie dysponujesz własną serwerownią lub nie chcesz utrzymywać sprzętu w swojej lokalizacji.
• Potrzebujesz dedykowanej mocy obliczeniowej i chcesz wybrać między zakupem, wynajmem lub modelem abonamentowym.
• Chcesz podzielić odpowiedzialność za utrzymanie środowiska między własny zespół, SparkSome i zewnętrznego dostawcę.
• Chcesz ograniczyć przekazywanie danych do zewnętrznych, współdzielonych API modeli i działać w środowisku z jasno określonymi zasadami dostępu.

Architektura hybrydowa: kiedy łączyć kilka modeli infrastruktury?

W praktyce wiele organizacji nie musi wybierać jednego modelu dla całości wdrożenia AI. Architektura hybrydowa pozwala łączyć zalety różnych podejść i dostosowywać infrastrukturę do konkretnych zastosowań.

Przykładowe konfiguracje hybrydowe:

• Testowanie przez API, produkcja lokalnie: firma eksperymentuje z gotowym API modelu, a po potwierdzeniu wartości przenosi produkcyjne wnioskowanie na dedykowaną infrastrukturę
• Dane wrażliwe lokalnie, analizy pomocnicze w chmurze: wrażliwe dane pozostają w środowisku z kontrolowanym dostępem, a mniej krytyczne analizy lub obciążenia pomocnicze korzystają z zasobów chmurowych
• Stałe obciążenie dedykowane, szczyty w chmurze: bazowe obciążenie utrzymuje dedykowana infrastruktura, a przy nagłym wzroście zapotrzebowania uruchamiane są dodatkowe zasoby chmurowe
• Przetwarzanie brzegowe dla czasu rzeczywistego, chmura dla przetwarzania wsadowego: systemy wymagające niskiego opóźnienia działają lokalnie, podczas gdy zadania niewymagające natychmiastowej reakcji przetwarzane są w chmurze.

Podejście hybrydowe wymaga starannej architektury, jasnego podziału danych według klasyfikacji i wymagań oraz przemyślanego zarządzania tożsamością i dostępem. Dobrze zaprojektowane pozwala zoptymalizować zarówno koszty, jak i profil ryzyka.

Trzy przykładowe scenariusze doboru infrastruktury AI

Poniższe opisy to przykładowe scenariusze ilustrujące typowe wzorce doboru infrastruktury. Nie są opisami konkretnych realizacji. Rzeczywiste wymagania, koszty i efekty zależą od specyfiki organizacji, danych i zastosowania.

Scenariusz 1: Firma usługowa – AI w modelu API

Firma z sektora usług biznesowych obsługuje zmienne natężenie zapytań i przetwarza dokumenty zawierające dane, które zgodnie z analizą prawną i klasyfikacją wewnętrzną mogą być przetwarzane u wybranego dostawcy API. Firma wdraża chatbota opartego na zewnętrznym API modelu oraz moduł analizy dokumentów.

Zalety tego podejścia: szybkie uruchomienie bez inwestycji w infrastrukturę, skalowanie realizowane po stronie dostawcy w granicach dostępnych limitów oraz brak konieczności samodzielnego zarządzania środowiskiem obliczeniowym.

Ryzyka do zarządzania: rosnące koszty przy wzroście skali, zależność od zewnętrznego dostawcy, konieczność ustalenia ról stron i (jeżeli dostawca przetwarza dane osobowe jako podmiot przetwarzający) zawarcia umowy powierzenia przetwarzania danych. Przy stabilizacji obciążenia warto ponownie przeanalizować TCO i rozważyć przeniesienie do dedykowanej infrastruktury.

Scenariusz 2: Zakład produkcyjny – AI on-premises lub przetwarzanie brzegowe

Zakład produkcyjny wdraża system wizji komputerowej do kontroli jakości na linii produkcyjnej. Wymagania obejmują niskie i przewidywalne opóźnienie dla każdego etapu przetwarzania od pozyskania obrazu do wyniku, niezależność od łącza zewnętrznego oraz wysoką bezpośrednią kontrolę nad środowiskiem.

Zalety tego podejścia: brak zależności od sieci zewnętrznej, przewidywalne opóźnienie, wysoka bezpośrednia kontrola nad danymi produkcyjnymi i konfiguracją systemu.

Ryzyka do zarządzania: wysoki CAPEX, konieczność utrzymania kompetencji wewnętrznych lub partnera serwisowego, ograniczona elastyczność przy zmianie skali. Decyzja o on-premises lub przetwarzaniu brzegowym powinna być poprzedzona pomiarem rzeczywistego opóźnienia wymaganego przez proces i obliczeniem TCO dla konkretnej konfiguracji w horyzoncie od 3 do 5 lat.

Scenariusz 3: Firma z ograniczeniami danych – serwer w zewnętrznym centrum danych

Firma przetwarza dane objęte szczególnymi wymaganiami prawnymi lub umownymi. Chce wdrożyć system oparty na LLM, korzystający z firmowej bazy wiedzy przez mechanizm RAG, bez przekazywania zapytań do zewnętrznych, współdzielonych API modeli. Jednocześnie nie dysponuje własnym centrum danych ani kompetencjami do samodzielnego doboru i przygotowania infrastruktury GPU. SparkSome pomaga określić wymagania, dobrać serwer i wybrać zewnętrzne centrum danych, w którym infrastruktura może zostać uruchomiona.

Zalety tego podejścia: ograniczenie ekspozycji danych na zewnętrzne, współdzielone usługi modelowe, możliwość wyboru modelu zakupu lub wynajmu sprzętu oraz przeniesienie części odpowiedzialności na zewnętrznego dostawcę i partnera technologicznego.

Ryzyka do zarządzania: zakres i warunki hostingu wymagają precyzyjnego określenia w umowie. Dedykowany sprzęt nie zastępuje pełnej oceny zgodności z wymaganiami prawnymi dotyczącymi przetwarzanych danych. Konieczne jest określenie zasad dostępu administracyjnego, retencji logów, tworzenia kopii zapasowych i reagowania na incydenty.

Schemat decyzyjny wyboru infrastruktury AI

Wybór modelu infrastruktury AI nie zależy od jednego pytania. Poniższy zestaw pytań pomaga ustrukturyzować analizę:

1. Jakie dane i modele będą przetwarzane?

Zidentyfikuj klasę danych, ich wrażliwość i wymagania wynikające z przepisów, umów i wewnętrznej polityki bezpieczeństwa.

2. Jakie wymagania prawne, umowne i bezpieczeństwa dotyczą tego przetwarzania?

Oceń przepisy, w tym RODO, ustawę o krajowym systemie cyberbezpieczeństwa wdrażającą NIS2 oraz regulacje sektorowe. Ustal, czy konieczne jest zawarcie umowy powierzenia (jeżeli dostawca działa jako podmiot przetwarzający), przeprowadzenie DPIA (Data Protection Impact Assessment, ocena skutków dla ochrony danych) oraz jakie są wymagania dotyczące lokalizacji przetwarzania.

3. Jaki czas odpowiedzi i przepustowość są wymagane?

Zmierz pełne opóźnienie od pozyskania danych do wyniku i działania systemu. Czy wymagania dotyczące czasu odpowiedzi mogą być spełnione przez infrastrukturę zdalną, czy konieczne jest lokalne lub brzegowe przetwarzanie?

4. Jak zmienne jest obciążenie?

Duże wahania obciążenia przemawiają za elastycznością chmury lub API. Stałe i przewidywalne obciążenie może uzasadniać inwestycję w dedykowaną infrastrukturę.

5. Jaki jest wymagany poziom dostępności oraz cele RTO i RPO?

RTO (Recovery Time Objective) to maksymalny akceptowalny czas odtworzenia systemu po awarii; RPO (Recovery Point Objective) to maksymalna akceptowalna utrata danych mierzona czasem. Określ te wartości przed wyborem architektury i poziomu redundancji.

6. Czy rozwiązanie musi działać bez łączności zewnętrznej?

Jeżeli system musi działać bez jakiejkolwiek łączności zewnętrznej, konieczna może być infrastruktura lokalna lub przetwarzanie brzegowe. Jeśli wymagane jest jedynie uniezależnienie od publicznego internetu, można rozważyć również prywatne łącze do zewnętrznego centrum danych.

7. Jakie kompetencje posiada zespół?

Każdy model infrastruktury wymaga innych kompetencji: integracja API, zarządzanie chmurą i MLOps, utrzymanie infrastruktury on-premises lub współpraca z dostawcą hostingu.

8. Jak wygląda TCO w perspektywie od 3 do 5 lat?

Porównaj całkowity koszt posiadania dla każdego scenariusza, uwzględniając CAPEX, OPEX, koszty energii, chłodzenia, licencji, serwisu, pracy administratorów, redundancji, pamięci masowej i backupu oraz cyklu wymiany sprzętu.

9. Jakie są wymagania dotyczące skalowania?

Czy skala jest znana i stabilna, czy trudna do przewidzenia? Jak szybko organizacja musi reagować na zmiany zapotrzebowania?

10. Kto odpowiada za sprzęt, system, model, aplikację i dane?

Precyzyjny podział odpowiedzialności musi być jasny przed wyborem modelu infrastruktury. Różne modele infrastruktury oznaczają inny podział obowiązków między dostawcą a klientem.