Jak przygotować karierę w IT na 10 lat do przodu: zawody, których AI szybko nie przejmie

Masz 28 lat, solidne podstawy w programowaniu i coraz częściej słyszysz, że „AI zabierze ci pracę”. W tym samym czasie szef prosi cię o wzięcie odpowiedzialności za krytyczny proces, którego nie da się po prostu przepisać przez generator kodu. Decyzja nie może czekać: którą ścieżkę wybrać, żeby twoja kariera IT miała sens także za 10 lat?

Brief decyzyjny: pytania, które chcesz szybko rozstrzygnąć

• Jakie zawody w IT są najbardziej odporne na automatyzację przez AI w najbliższej dekadzie?
• Kiedy dana ścieżka ma sens dla mnie (umiejętności, temperament, ryzyko), a kiedy nie?
• Jakie kryteria zastosować, by w tydzień wybrać kierunek i nie żałować?
• Jak wygląda plan na 90 dni, 12 miesięcy i 5 lat, żeby realnie zwiększyć szanse?
• Jak używać AI jako dźwigni, a nie kul crutch, który odbiera kompetencje?
• Jakie błędy najczęściej palą czas i pieniądze przy przebranżowieniu lub zmianie specjalizacji?

Zasady wyboru ról, których AI szybko nie przejmie

Przypadki z niejednoznacznością i odpowiedzialnością biznesową

Modele AI są świetne w znanych wzorcach, ale słabną przy niejednoznaczności wymagającej uzgodnień, kompromisów i formalnej odpowiedzialności. Role, które łączą aspekty techniczne z ryzykiem, regulacjami, etyką i negocjacjami, trudniej zautomatyzować. Przykład: decyzja, czy wdrożyć funkcję zbierającą dane geolokalizacyjne — to nie tylko kod; to analiza prawna, ocena ryzyka reputacyjnego i rozmowy z działem sprzedaży.

Mini-wniosek: im więcej negocjacji między działami i konsekwencji prawnych, tym bardziej odporna rola.

Silne ograniczenia świata fizycznego i bezpieczeństwa

Systemy działające w realnym świecie (robotyka, IoT, automotive, medtech) mają twarde ograniczenia: czasy reakcji, trwałość, bezpieczeństwo. AI pomaga projektować i testować, ale nie weźmie na siebie audytowalnej odpowiedzialności za bezpieczeństwo pacjenta czy kierowcy. W tych środowiskach wciąż kluczowa jest ekspertyza inżynierska, certyfikacje i testy w warunkach skrajnych.

Mini-wniosek: jeśli coś musi działać w 99,999% przypadków i podlega audytom, AI będzie wsparciem, nie zamiennikiem.

Integracja wielu systemów i wielu interesariuszy

Najtrudniejsze projekty w IT to nie pisanie nowych modułów, lecz łączenie istniejących: integracje z dostawcami, migracje danych, zgodność z politykami, wersjonowanie API, śledzenie wpływu zmian. Tu liczy się kontekst domenowy, historia decyzji, relacje i twarde kompromisy koszt/jakość/ryzyko.

Mini-wniosek: dług technologiczny to mur, który AI tylko punktowo poluzuje. Kierowanie pracą wokół tego muru — to rola dla ludzi.

Dane własne i wiedza domenowa

Modele ogólne nie znają twoich danych produkcyjnych, niuansów biznesu i nieformalnych zasad gry w twojej firmie. Im bardziej rola opiera się na unikalnych danych i osadzonym kontekście (finanse, telco, energetyka, opieka zdrowotna), tym trudniej ją sklonować. Dostępność, prywatność, mapowanie źródeł, lineage — to nadal praca ludzi.

Mini-wniosek: rola blisko „źródła prawdy” danych i decyzji ma wyższy próg automatyzacji.

Mapa ról IT odpornych na automatyzację w horyzoncie 10 lat

Cyberbezpieczeństwo i inżynieria bezpieczeństwa

Reagowanie na incydenty i analiza zagrożeń (Blue Team/IR)

Incident Response wymaga szybkich decyzji przy brakach danych, pracy z zespołami prawnymi i PR oraz oceny, co jest ważniejsze: ciągłość działania czy izolacja zagrożenia. AI potrafi podsunąć hipotezy, ale nie obroni ich w sądzie ani przed zarządem. Praktyka: playbooki, współpraca z SOC, analiza pamięci, korelacja logów, threat hunting, testy tabletop.

Warto, gdy: lubisz presję czasu, potrafisz myśleć scenariuszowo, nie boisz się niepełnych informacji. Uważaj, gdy: frustrują cię dyżury i praca zmianowa.

Bezpieczeństwo aplikacji i modelowanie zagrożeń (AppSec/Threat Modeling)

Projektowanie bezpiecznych systemów to iteracje, kompromisy i dogłębne rozumienie architektury. AI wskaże typowe luki, ale nie zastąpi wspólnego warsztatu z zespołem, gdzie osądzasz ryzyko biznesowe, a nie jedynie techniczne. Core: przeglądy architektoniczne, SAST/DAST/IAST, SBOM, polityki CI/CD, edukacja devów, integracja security w backlogach.

Warto, gdy: lubisz wpływać wcześnie, zanim powstanie kod. Uważaj, gdy: wolisz czysty hands-on bez rozmów i warsztatów.

Inżynieria prywatności i zgodność danych (Privacy Engineering)

Łączenie wymogów prawnych (RODO, ePrivacy) z praktykami inżynierskimi: minimalizacja danych, anonimizacja, kontrola dostępu, retencja. AI nie zdejmie z ciebie odpowiedzialności za DPIA, ocenę ryzyka i dokumentację audytową. To rola przydatna w organizacjach data-driven, gdzie reputacja i kary finansowe są realnym ryzykiem.

Warto, gdy: masz cierpliwość do procedur i precyzyjną komunikację. Uważaj, gdy: unikasz formalności i dokumentacji.

Site Reliability Engineering i inżynieria platform

Niezawodność i zarządzanie ryzykiem produkcyjnym (SRE)

SRE balansuje innowację i stabilność: SLO/SLI, error budgets, chaos engineering, postmortems. AI przyspiesza debugowanie, ale ktoś musi określić ryzyko biznesowe przestoju, negocjować z productem i egzekwować standardy. Specyfika: praca na żywym organizmie, mentoring zespołów, ownerstwo incydentów.

Warto, gdy: lubisz rozwiązywać złożone problemy pod presją i budować standardy. Uważaj, gdy: unikasz dyżurów i masz niski próg stresu operacyjnego.

Platform Engineering i Developer Experience

Budujesz wewnętrzne platformy, które czynią wytwarzanie oprogramowania przewidywalnym i powtarzalnym. Tworzysz złote ścieżki (golden paths), szablony repo, polityki CI/CD, katalog usług, zarządzasz kosztami chmury. AI pomaga generować konfiguracje, ale nie zaprojektuje odpowiedzialności ani ładu procesowego.

Warto, gdy: lubisz narzędzia, automatyzację i myślenie w kategoriach produktu dla developerów. Uważaj, gdy: wolisz features dla użytkownika końcowego.

Data Engineering i MLOps

Inżynieria danych i jakość informacji

Budowanie solidnych kanałów danych (ingest, transformacje, katalogowanie, testy danych), zarządzanie schematami i dostępem. AI nie zna twojej semantyki biznesowej; ktoś musi zdefiniować „co znaczy aktywny klient”. Dodatkowo dochodzą kwestie kosztów i optymalizacji zapytań.

Warto, gdy: lubisz porządkować chaos i wiesz, że definicje danych to polityka organizacyjna. Uważaj, gdy: wolisz szybkie efekty zamiast metodycznej pracy.

Operacjonalizacja modeli: gdzie AI wspiera, a gdzie potrzebny jest człowiek

W piątek o 15:40 model rekomendacji zaczyna proponować rabaty tam, gdzie marża jest najniższa. Dashboard świeci na czerwono, a dział sprzedaży dzwoni bez przerwy. Trzeba zdecydować: wyłączyć model i przejść na zasady awaryjne, czy zaryzykować weekend na hotfixach.

MLOps i nadzór nad cyklem życia modeli

Tu łączysz infrastrukturę, dane i odpowiedzialność biznesową: wersjonowanie modeli, monitorowanie driftu, walidacje przed wdrożeniem, rollbacki, polityki eksploracji/eksploatacji. System może zaproponować retraining, ale nie rozstrzygnie, czy brak danych z kampanii świątecznej wypaczy prognozę popytu.

Warto, gdy: lubisz łączyć logikę danych z operacjami i potrafisz rozmawiać z product ownerem o ryzyku. Uważaj, gdy: interesuje cię wyłącznie research modeli, bez odpowiedzialności za incydenty i zgodność.

Mini-wniosek: jeśli decyzje modelu wpływają na przychody lub ryzyka regulacyjne, rola MLOps z silnym governance ma wysoki próg automatyzacji.

Responsible AI, audyt i zgodność modeli

Oceniasz uprzedzenia, przejrzystość, ścieżki wyjaśnienia, polityki retencji i zgód. To praca na styku prawa, etyki i inżynierii: testy sprawiedliwości, dokumentacja kart modelu, kontrola źródeł danych, procedury human-in-the-loop.

Warto, gdy: masz cierpliwość do dowodów i ścieżek audytowych, potrafisz zamienić wymóg regulacyjny na test techniczny. Uważaj, gdy: unikasz długiej dokumentacji i sporów o interpretację przepisów.

Mini-wniosek: im większa ekspozycja firmy na regulatorów lub media, tym stabilniejszy popyt na tę kompetencję.

Architektura i przywództwo techniczne w realiach kompromisów

Nowy klient chce integracji z pięcioma systemami rozliczeń, każdy w innej strefie czasowej i z innym SLA. Handlowiec mówi: „dostarczymy w kwartał”, a ty widzisz brak retry policy i chaos w kontraktach API. Ktoś musi przeprowadzić organizację przez te kompromisy.

Architekt/ka systemów z mandatem decyzyjnym

Decydujesz o granicach domen, kontraktach między usługami, standardach niezawodności, strategii migracji. AI wygeneruje diagramy, ale nie poprowadzi negocjacji z zespołami o budżet błędów czy priorytety długu.

Warto, gdy: lubisz przejmować odpowiedzialność za decyzje i potrafisz uargumentować koszty jakości. Uważaj, gdy: unikasz konfliktów i nie chcesz firmować ryzyka swoim nazwiskiem.

Mini-wniosek: architektura to gra interesów i konsekwencji — automatyzacja wspiera, ale nie podejmuje ostatecznych decyzji.

Technical Product Management (B2B/enterprise)

Mapujesz potrzeby klientów na roadmapy oparte o ograniczenia techniczne, koszty chmury, bezpieczeństwo i zgodność. AI ułatwi analizę feedbacku, nie zastąpi jednak decyzji „co nie wejdzie do wersji” i rozmów o kompromisach kontraktowych.

Warto, gdy: lubisz łączyć liczby, prototypy i rozmowy z biznesem. Uważaj, gdy: nie chcesz rezygnować z większości czasu na kodzenie.

Mini-wniosek: im bardziej złożone otoczenie klienta (legacy, compliance), tym rola PM-a technicznego jest trwalsza.

Badania i projektowanie tam, gdzie błąd kosztuje

Na warsztacie z użytkownikami systemu medycznego pada pytanie: „co jeśli pielęgniarka pomyli kolejność ekranów podczas resuscytacji?”. Makieta przestaje być ładnym obrazkiem — staje się procedurą.

UX Research/Service Design dla systemów krytycznych

Projektujesz flowy i interfejsy, które muszą działać pod presją: lotnictwo, energetyka, medtech, narzędzia dla specjalistów. AI wygeneruje warianty UI, ale nie przeprowadzi badań w realnym środowisku ani nie zrozumie nieformalnych procedur zespołów.

Warto, gdy: potrafisz pracować z użytkownikiem profesjonalnym i testować w warunkach polowych. Uważaj, gdy: interesuje cię głównie estetyka, nie zachowania i kontekst użycia.

Mini-wniosek: badania w domenach wysokiego ryzyka mają trwały popyt, bo zamieniają decyzje projektowe w odpowiedzialność operacyjną.

Decyzja w tydzień: prosta matryca wyboru

Krótka matryca pomaga odsiać kierunki „na papierze fajne”, ale niepasujące do twojego profilu. Najpierw zaznacz, co jest dla ciebie nieliniowym plusem, a co dyskwalifikuje ścieżkę.

• Jeśli co najmniej trzy „tak” pokrywają się z jedną ścieżką — zaplanuj 90-dniowy eksperyment w tym kierunku.
• Jeśli masz remis — wybierz tę z większym udziałem odpowiedzialności i kontaktu z decyzjami biznesowymi.
• Jeśli żadne „tak” nie pasuje — wróć krok wcześniej i doprecyzuj kryteria (np. tolerancję na on-call, preferencje komunikacyjne).

Plan działania: 90 dni, 12 miesięcy, 5 lat

90 dni: szybki eksperyment o niskim ryzyku

• Zakres: jeden projekt end-to-end (np. pipeline danych z testami jakości, model + monitoring, playbook SRE, warsztat threat modeling).
• Artefakty: repo z dokumentacją decyzji, diagram architektury, lista ryzyk i mitgacji, krótkie demo dla interesariuszy.
• Dowód wartości: metryka „przed/po” (SLO, koszt zapytań, czas detekcji incydentu, redukcja false positives w skanerze).

12 miesięcy: utrwalenie i mandat

• Certyfikacje mające ciężar decyzyjny w twojej domenie (np. ISO 27001 lead implementer, CCSK/CCSP, GCP/AWS Architect, DP-203, TÜV dla safety).
• Współprowadzenie inicjatywy przekrojowej: golden path w platformie, standard DPIA, governance modeli, katalog usług.
• Mentoring 1–2 osób i udział w przeglądach architektonicznych — to buduje wpływ, nie tylko umiejętność.

5 lat: skalowanie odpowiedzialności

• Przeniesienie ciężaru z „robię sam” na „projektuję zasady i nadzoruję wykonanie” (guildy, design authority, risk council).
• Rotacja przez pokrewne domeny, by poszerzyć horyzont (np. SRE → Platform Eng → Architektura; Data Eng → MLOps → Responsible AI).
• Budowa portfolio decyzji: zbiory postmortemów, case studies z kompromisów, rekomendacje od interesariuszy spoza IT.

AI jako dźwignia, nie kula u nogi

Kiedy korzystać agresywnie

• Generowanie szkiców: polityki CI/CD, definicje alertów, skeletony testów danych, drafty DPIA — potem przejście do weryfikacji eksperckiej.
• Symulacje i what-if: testy chaosu, obciążenia, wpływu driftu; AI przyspiesza hipotezy, ty decydujesz o progu ryzyka.
• Repo wiedzy: podsumowania logów, grupowanie incydentów, wstępne mapy zależności.

Kiedy hamować

• Decyzje o akceptacji ryzyka, zgodności prawnej i zmianach kontraktów API — wymagają osoby z mandatem i kontekstem.
• Diagnoza incydentów z niepełnymi danymi — AI może konfabulować; najpierw weryfikacja i triangulacja źródeł.
• Automatyczne wdrożenia zmian w politykach bezpieczeństwa i uprawnieniach — stosuj zasadę dwuparafkowości (4-oczy) i change advisory.

Krótka lista kontrolna decyzji

• Czy rola ma realny kontakt z ryzykiem i decyzją „go/no-go” w biznesie?
• Czy będziesz pracować na unikalnych danych i kontekście domenowym, a nie na ogólnych tutorialach?
• Czy przewiduje się audyty, SLA lub regulacje, które wymagają ścieżek dowodowych?
• Czy ścieżka pozwala rosnąć od „wykonawcy” do „projektanta zasad” w 2–3 lata?
• Czy akceptujesz typowy rytm pracy (on-call, warsztaty, dokumentacja) — bez samooszukiwania się?

Telefon dzwoni w drodze na lunch: dwie oferty, obie „pilne”. Otwierasz notatkę z listą kontrolną i sprawdzasz, gdzie faktycznie będziesz mieć wpływ na „go/no‑go”. Na rozmowie dopytujesz: kto zatwierdza wyjątki bezpieczeństwa, jakie są SLO i kto za nie odpowiada, jak wygląda postmortem i co się z nim dzieje po tygodniu. Jeśli słyszysz „u nas bez papierologii, wszystko na zwinność” przy projektach finansowych lub medycznych — to czerwona flaga. Gdy rekruter mówi, że „AI zrobi resztę”, dopytaj o budżet na testy odporności i monitoring; brak konkretów oznacza, że rola może być dekoracyjna.

Checklistę przełóż na zobowiązania w pierwszym kwartale: jeden mierzalny wynik, trzy artefakty, jeden przegląd z decydentem spoza IT. Przykładowo: wdrażasz SLO z error budgetem, playbook na najczęstszy incydent i krótki raport ryzyka dla właściciela procesu. Jeśli nie możesz tego zrobić, bo brakuje dostępu do danych, mandatu albo czasu interesariuszy — zmień środowisko, nie cel. Decyzje bez ścieżki dowodowej wyglądają dobrze tylko w prezentacji.

Wybór środowiska pracy: gdzie decyzje naprawdę ważą

Masz na biurku dwa NDA: startup AI z obietnicą „shipujemy co tydzień” i integrator w energetyce z plikiem wymagań na 30 stron. W jednym kuszą szybkie efekty, w drugim — ciężar odpowiedzialności. Które środowisko lepiej zgra się z twoją tolerancją na ryzyko i stylem pracy?

Startup produktowy

• Daje przewagę, gdy: chcesz szybko budować portfel decyzji, nie boisz się niedoskonałych danych, lubisz łączyć rolę techniczną z discovery.
• Uważaj, gdy: brak procesu zmian i brak klientów enterprise — nauczysz się tempa, ale nie zbudujesz ścieżek dowodowych.
• Decyzyjne kryterium: czy jest płacący klient z SLA i realnym feedbackiem z produkcji?

B2B/SaaS na etapie skalowania

• Daje przewagę, gdy: szukasz równowagi między wpływem a infrastrukturą (SLO, postmortemy, backlog długu).
• Uważaj, gdy: „enterprise” to tylko slajd — brak kontraktów i audytów oznacza mało materiału do nauki poważnych kompromisów.
• Decyzyjne kryterium: czy istnieją formalne bramki (design review, CAB) i czy można je współtworzyć?

Integrator/konsulting w sektorze regulowanym

• Daje przewagę, gdy: chcesz zrozumieć compliance od kuchni, negocjować zewnętrzne kontrakty i prowadzić wielozespołowe zmiany.
• Uważaj, gdy: projekty są staff-augmentacją bez mandatu decyzyjnego — zostaniesz wykonawcą cudzych ryzyk.
• Decyzyjne kryterium: czy umowa projektowa daje ci wpływ na standardy (SOW zawiera SLO, kryteria jakości, ścieżki eskalacji)?

Duża organizacja z platformą wewnętrzną

• Daje przewagę, gdy: chcesz budować „golden path”, polityki i reusable komponenty dla wielu zespołów.
• Uważaj, gdy: platforma istnieje tylko w nazwie, a zespoły ją obchodzą — nauczysz się polityki, nie decyzji.
• Decyzyjne kryterium: czy masz budżet na standardy (SAST/DAST, quality gates, obserwowalność) i wsparcie leadershipu przy egzekucji?

Mini-wniosek: wybieraj środowisko, które wymusza ścieżki dowodowe (SLA, audyty, CAB) i daje ci realny wpływ na zasady gry, nie tylko na implementację.

Rzemiosło decyzji: artefakty, które bronią się przy audycie

Na przeglądzie architektury zderzają się opinie. Ktoś wyciąga ADR z analizą ryzyk i SLO z budżetem błędów — spór zamienia się w wybór pomiędzy kosztami.

• ADR z wariantami i kosztami ryzyka — używaj, gdy decydujesz o zmianach nieodwracalnych; nie twórz ADR do refaktora nazwy zmiennej.
• SLO/SLI + error budget — wdrażaj tam, gdzie są klienci i pieniądze; w fazie discovery wystarczy prosty cel czasu odpowiedzi.
• Runbook + playbook incydentu — przygotuj dla top 3 awarii; nie kataloguj wszystkiego, skup się na czasach detekcji i eskalacji.
• Rejestr ryzyk z właścicielami — prowadź dla ryzyk prawnych, finansowych, bezpieczeństwa; nie zamieniaj w listę życzeń bez dat i osób.
• DPIA/Threat Modeling — stosuj, gdy dotykasz danych wrażliwych lub krytycznych procesów; nie używaj szablonu bez warsztatu z właściwymi ludźmi.
• Testy chaosu/kosztów — uruchamiaj po minimalnym hardeningu i zgodzie na wstrząsy; nie rób w piątek po południu.

Mini-wniosek: artefakt ma sens, gdy skraca spory i przyspiesza akceptację ryzyka. Jeśli nikt na jego podstawie nie zmienia decyzji — to papier, nie narzędzie.

Umiejętności, których AI nie skompresuje do szablonu

W piątek wieczorem leci incydent, dashboardy krzyczą, a dane są niepełne. Ktoś musi ustawić priorytety, przyjąć ryzyko i zakomunikować klientom, co dalej.

• Framing problemu — definiowanie, co jest naprawdę „down”, a co jest szumem; ćwicz przez pisanie krótkich notek „sytuacja–ryzyko–opcja–decyzja”.
• Negocjacja zakresu — zamiana „zróbmy wszystko” na „dostarczmy minimum, które obniża ryzyko”; trenuj przez timeboxing i CRQ (critical request question).
• Decyzje pod niepewnością — priorytetyzacja działań bez pełnych danych; stosuj zasady progu odwracalności (one-way door vs two-way door).
• Postmortem bez obwiniania — zamiana wniosków w action items z właścicielem i datą; bez tego kultura strachu pożera SLO.
• Rozmowa z audytorem/regulatorem — tłumaczenie techniki na kontrolę; przygotuj „mapę kontroli” procesu z dowodami z logów i ticketów.
• Model koszt–ryzyko — łączenie faktur chmurowych, SLO i kar umownych; naucz się liczyć marginalny koszt niezawodności.

Mini-wniosek: te kompetencje powstają w praktyce pod presją. Traktuj je jak mięśnie — regularnie dźwigaj małe ciężary, zanim przyjdzie produkcyjny kryzys.

Stos narzędzi: minimalny zestaw na rok

Budżet nie rośnie, oczekiwania tak. Zamiast kolejnej wtyczki, dobierz kategorie, które realnie skracają czas decyzji i audytu.

• Obserwowalność z korelacją zdarzeń — bierz, gdy masz wieloservice’owe środowisko; poczekaj, jeśli monolit i brak on-call.
• Kontrola jakości danych (profiling, reguły, lineage) — bierz, gdy raporty lub modele decydują o pieniądzach; odpuść, jeśli dane to jedynie cache do UI.
• IaC z policy-as-code — bierz, gdy liczysz na spójność i szybkie audyty; poczekaj, gdy infrastruktura jest stała i mała.
• Repo decyzji (ADR/Design Docs) w wersjonowaniu — zawsze; to najtańszy wzmacniacz mandatu.
• Bezpieczne środowisko testów chaosu/obciążenia — bierz po uzgodnieniu limitów wpływu; nie rób ad-hoc w produkcji.
• Ewaluacja LLM/ML (metryki, guardraile) — bierz, gdy model dotyka klientów lub treści ryzykownych; odpuść w prototypach bez danych wrażliwych.

Mini-wniosek: kategorie > narzędzia. Najpierw ustal, jaki dowód potrzebujesz, dopiero potem wybieraj produkt.

Rozpoznaj tytuł bez mocy: jak odsiać pozory wpływu

Oferta brzmi: „Staff Engineer, bez biurokracji”. Pytasz o SLO, change management i właściciela ryzyk — zapada cisza.

• Kto zatwierdza wyjątki bezpieczeństwa i na jakiej podstawie? Brak nazwisk i kryteriów = brak realnej władzy.
• Jakie są SLO i jak mierzycie ich dotrzymanie? Słyszysz „mamy monitoring” — to nie to samo.
• Jak wygląda CAB/design review i kto może zablokować wdrożenie? Jeśli „nikt”, to ty ponosisz ryzyko cudzych decyzji.
• Czy istnieje budżet na spłatę długu i kto nim zarządza? Zero budżetu = wieczny pożar.

Na rozmowie prosisz o przykładowy postmortem i wzór wniosku o wyjątek bezpieczeństwa. Rekruter mówi, że „nie przechowują takich dokumentów”, ale „jest kultura odpowiedzialności”. Brzmi ładnie, lecz brak śladów po decyzjach oznacza, że przy pierwszym sporze zostaniesz bez amunicji.

Daj sobie 90 dni na weryfikację wpływu. W pierwszych 30 dniach zmapuj ścieżkę zmiany: kto zgłasza, kto ocenia, kto akceptuje, jak mierzycie efekt. Do 60. dnia przeforsuj niewielką zmianę wymagającą CAB lub przeglądu bezpieczeństwa i sprawdź, czy faktycznie przechodzi przez bramki. Do 90. dnia przejmij odpowiedzialność za konkretny wskaźnik (np. SLO komponentu lub błąd danych) wraz z budżetem na poprawę. Jeśli na którymkolwiek etapie brak ci dostępu do logów, budżetu lub decydenta — to nie jest rola z mocą, tylko wizerunkowa plakietka.

Role odporne na automatyzację: kiedy wejść, kiedy odpuścić

Rekruter kusi „Prompt Engineerem” z bonusami za kreatywne prompty. Na sąsiednim spotkaniu słyszysz o roli odpowiedzialnej za incydenty i zgodność wdrożeń. Jedna brzmi świeżo, druga pachnie ciężarem odpowiedzialności.

SRE/Incident Commander

• Daje przewagę, gdy: pociąga cię presja i porządkowanie chaosu, chcesz uczyć się kompromisów koszt–ryzyko w realnym czasie.
• Uważaj, gdy: organizacja nie ma on-call ani budżetu na niezawodność — zostaniesz operatorem, nie decydentem.
• Decyzyjne kryterium: czy istnieje error budget i formalny proces zarządzania incydentami z uprawnieniem do blokady wdrożeń?

Bezpieczeństwo + GRC/Threat Modeling

• Daje przewagę, gdy: lubisz łączyć prawo z techniką, potrafisz przekładać kontrole na architekturę i odwrotnie.
• Uważaj, gdy: rola to wyłącznie „policy theater” bez dostępu do repo i CI/CD — będziesz pisać PDF-y, nie kształtować systemy.
• Decyzyjne kryterium: czy możesz wymuszać kontrole (policy-as-code, bramki) i akceptować ryzyka z podpisem sponsora?

Architekt integracji w złożonych domenach

• Daje przewagę, gdy: lubisz negocjować interfejsy i SLA między działami i dostawcami; to gra o konsekwencjach kontraktowych.
• Uważaj, gdy: „architekt” oznacza rysowanie diagramów po fakcie; bez wpływu na backlog i budżet nie zbudujesz track recordu.
• Decyzyjne kryterium: czy masz mandat do definiowania standardów integracji (wersjonowanie, kontrakty, SLO) i ich egzekucji?

MLOps/AI Evaluation & Governance

• Daje przewagę, gdy: modele wpływają na klientów, a ty potrafisz zbudować ewaluację, guardraile i ścieżki odwołań.
• Uważaj, gdy: praca to „klejenie promptów” bez metryk i danych produkcyjnych — to zwinne R&D, nie kompetencja długoterminowa.
• Decyzyjne kryterium: czy jest proces model risk management (metryki, drift, incidenty modelowe) osadzony w SDLC?

TPM ds. ryzyka i zgodności

• Daje przewagę, gdy: potrafisz prowadzić wielozespołowe zmiany i zamieniać wymagania regulacyjne w plan release’ów.
• Uważaj, gdy: TPM to kalendarz i statusy; bez odpowiedzialności za decyzje ryzyka zostaniesz koordynatorem spotkań.
• Decyzyjne kryterium: czy posiadasz prawo do akceptacji/eskalacji ryzyk i wpływ na priorytety w roadmapie?

Product Manager platformy/infrastruktury

• Daje przewagę, gdy: chcesz łączyć discovery z politykami technicznymi (golden path, budżet na jakość) i mierzysz adopcję standardów.
• Uważaj, gdy: „produkt” to narzędzia bez klientów wewnętrznych i KPI — nie zbudujesz narracji wartości.
• Decyzyjne kryterium: czy masz zdefiniowanych użytkowników, SLO platformy i budżet na egzekucję standardów?

Mini-wniosek: wybieraj role, w których twoja decyzja zmienia poziom ryzyka lub kosztu, a dowód tej zmiany jest mierzalny i audytowalny.

Portfolio dowodów: z czego składa się „mandat na lata”

Panel awansowy pyta o konkret: „Pokaż decyzję, którą podjąłeś, i jej efekt po 6 miesiącach”. CV nie wystarczy, liczy się ślad.

• „Przed–po” dla SLO i kosztu: wykres wypalenia error budgetu przed zmianą i po niej, z linkiem do ADR oraz diffów w IaC/pipeline.
• Akceptacje ryzyk: przykładowy wyjątek bezpieczeństwa z datą wygaśnięcia, warunkami i planem domknięcia; podpis sponsora biznesowego.
• Postmortem z wdrożonymi akcjami: 3–5 działań z właścicielami, statusami i metrykami efektu (np. skrócony MTTR).
• Mapa kontroli: powiązanie wymagań (np. ISO 27001, NIST, EBA, DORA) z konkretnymi dowodami w systemach (logi, PR, ticket).
• Ewaluacja LLM/ML: karty modelu, metryki ryzyka (toxicity/PII/leakage), procedury retrainingu i mechanizm roll-backu.
• „Decyzje trudne”: jedna sytuacja z realnym kompromisem (koszt vs ryzyko), gdzie odrzucono popularne rozwiązanie — z uzasadnieniem.

Jak to zebrać bez łamania NDA? Anonimizuj nazwy, trzymaj artefakty w prywatnym repo, a do publicznego portfolio dawaj zrzuty z zaczernionymi identyfikatorami i opis procesu zamiast danych wrażliwych.

• Kiedy publikować: gdy artefakt uczy sposobu pracy (szablon ADR, checklista CAB, matryca ryzyk) bez ujawniania tajemnic.
• Kiedy nie: gdy dowód odsłania topologię sieci, wewnętrzne klucze, warunki kontraktów lub wrażliwe metryki finansowe.

Mini-wniosek: buduj teczkę decyzji tak, by obca osoba mogła zrozumieć problem, warianty, kryteria i efekt — bez kontekstu firmowego.

Certyfikaty i nauka: inwestuj, gdy spełniają warunek biznesowy

Szef daje 10 tys. na szkolenia. Kuszą modne kursy AI, ale za rogiem czeka audyt i przetarg z wymaganiami formalnymi.

• Kiedy tak: gdy klienci lub regulatorzy wymagają potwierdzeń (RFP, audyt, due diligence) albo awans wymaga „papieru” zgodnie z polityką HR.
• Kiedy nie: gdy nie masz miejsca na praktykę — bez wdrożenia w pracy cert szybko traci wartość i pamięć mięśniową.

Co najczęściej otwiera drzwi w rolach odpornych na automatyzację:

Które certyfikaty zwracają koszt i kiedy

Masz budżet, dwa terminy audytów i mail od sprzedaży: „Klient pyta o uprawnienia i zgodność”. Decyzja nie brzmi „co jest modne?”, tylko „co odblokuje deal albo awans”.

• Cloud + zabezpieczenia chmury (AWS SAP/Pro, AWS Security Specialty, GCP PCA, Azure Architect Expert)
  • Kiedy tak: gdy zarządzasz landing zone, multi-account/tenant i politykami (SCP/OPA) oraz masz IaC w repo.
  • Kiedy nie: gdy produkt działa na jednym PaaS bez dostępu do konfiguracji i brak planu na multi-region.
  • Kryterium dowodu: RFP klienta lub audyt proszą o architekturę chmury i kontrolę dostępu na poziomie org.
• Bezpieczeństwo i GRC ((ISC)² CISSP/CC, ISACA CISM/CISA, ISO/IEC 27001 Lead Implementer/Auditor)
  • Kiedy tak: gdy twoja rola łączy polityki z wdrożeniem (kontrole w CI/CD, przegląd wyjątków, audyty dostawców).
  • Kiedy nie: gdy pracujesz wyłącznie w kodzie jednej usługi bez wpływu na kontrole organizacyjne.
  • Kryterium dowodu: wymagania klienta/regulatora jasno wskazują certyfikacje osób w projekcie lub roli.
• Prywatność danych (IAPP CIPP/E, CIPM, ISO/IEC 27701)
  • Kiedy tak: gdy przetwarzacie dane osobowe w UE/UK, masz wpływ na rejestrowanie podstaw prawnych i DPIA.
  • Kiedy nie: gdy produkt to czysto techniczny komponent B2B bez danych osobowych.
  • Kryterium dowodu: w pipeline sprzedażowym pojawiają się pytania DPA/SCC i żądania roli DPO/ownerów kontroli.
• SRE/Operacje (ITIL 4 MP, CKA/CKAD, HashiCorp Terraform Associate, Observability Foundations)
  • Kiedy tak: gdy zarządzasz klastrami/K8s, SLO i budżetem błędów oraz masz wpływ na change management.
  • Kiedy nie: gdy cała produkcja to managed SaaS bez waszej operacyjnej odpowiedzialności.
  • Kryterium dowodu: on-call i CAB należą do twojego zespołu, a audyt pyta o procesy incydentowe.
• AI Governance i ewaluacja (IAPP AIGP, NIST AI RMF praktyka, Responsible AI kursy z ewaluacją modeli)
  • Kiedy tak: gdy modele wpływają na klientów/treści i masz mandat na metryki ryzyka, guardraile i roll-back.
  • Kiedy nie: gdy „AI” to prototypy bez danych wrażliwych i brak ścieżki do produkcji.
  • Kryterium dowodu: wewnętrzna polityka żąda model cards, testów toksyczności/PII i rejestru incydentów modelowych.

Mini-wniosek: bierz certyfikaty tam, gdzie potwierdzają prawo do decyzji i uwiarygadniają cię przy audycie lub RFP; w innym wypadku przeznacz budżet na praktykę i artefakty.

Przepięcie ścieżki w 6–12 miesięcy: plan decyzyjny

Backendowiec mówi: „U nas już wszystko robi AI, ja tylko weryfikuję PR-y”. Szuka kierunku, który w CV zamienia się w dowody decyzji — nie w kolejne linijki stacku.

SRE/Incident w 6 mies.

• Minimalny pakiet dowodów:
  • 1 usługa z SLO i error budgetem wdrożonym w dashboardzie + polityka blokady wydania przy wypaleniu.
  • Runbook + ćwiczenie DR/chaosu z ograniczeniem wpływu i raportem.
  • Postmortem z akcjami i mierzalnym skróceniem MTTR.
• Wejdź, gdy: masz on-call, dostęp do monitoringu/IaC i zgodę na bramki w CI.
• Odpuść, gdy: platforma to „czyjeś SaaS”, a ty nie możesz dotknąć polityk zmian.

Bezpieczeństwo/GRC w 6–9 mies.

• Minimalny pakiet dowodów:
  • Threat model kluczowego przepływu + 2 wprowadzone kontrole (np. SAST gate, SBOM w pipeline).
  • Proces wyjątków bezpieczeństwa z podpisem sponsora + rejestr wygasania wyjątków.
  • Mapa kontroli ISO/NIST → dowody w systemach (PR, ticket, log audytowy).
• Wejdź, gdy: masz prawo do egzekwowania polityk (policy-as-code) i widoczność w CI/CD.
• Odpuść, gdy: oczekują „PDF-ów o kulturze”, ale nie wpuszczają do repo i bramek.

MLOps/AI Evaluation w 6–9 mies.

• Minimalny pakiet dowodów:
  • Harness ewaluacyjny dla LLM/ML z zestawem testów regresji (toxicity/PII/leakage/groundedness).
  • Guardraile runtime (rate limiting, PII scrubber, policy checker) + mechanizm roll-backu.
  • Model card i procedura retrainingu z progiem driftu.
• Wejdź, gdy: produkt używa modeli w kontakcie z klientem i masz dostęp do danych/telemetrii.
• Odpuść, gdy: „AI” to demo na konferencję bez ścieżki do produkcji.

TPM/PM Platformy w 6–12 mies.

• Minimalny pakiet dowodów:
  • Golden path dla deployu z mierzoną adopcją (np. % usług na standardzie).
  • Backlog jakości z budżetem i SLA wdrożeń platformowych.
  • RFC deprecjacji narzędzia + plan migracji z ryzykami i pomiarem efektu.
• Wejdź, gdy: definiujesz KPI platformy i masz budżet na egzekucję standardów.
• Odpuść, gdy: „produkt” to lista ticketów bez użytkowników i SLO.

Architekt integracji w 6–9 mies.

• Minimalny pakiet dowodów:
  • Kontrakty API z wersjonowaniem i testami consumer-driven + plan zgodności wstecznej.
  • Uzgodnione SLO integracji i dashboard błędów kontraktowych.
  • Proces change management dla interfejsów z akceptacją obu stron.
• Wejdź, gdy: możesz definiować standardy integracji i egzekwować je w pipeline.
• Odpuść, gdy: nikt nie ma własności nad interfejsami, a zmiany dzieją się „po cichu”.

Mini-wniosek: plan 6–12 mies. to zestaw artefaktów, nie tytułów — każdy element musi być linkowalnym dowodem decyzji i jej efektu.

Kiedy zmienić firmę, a kiedy budować mandat na miejscu

Dwie oferty: w jednej 20% wyższa pensja, ale „nie mamy formalnych procesów, działamy szybko”. W drugiej — SLO, CAB i budżet na jakość, za to mniej błysku w stacku. Którą wybrać?

• Zostań i buduj, jeśli spełniasz 5/7:
  • Masz dostęp do logów, CI/CD i IaC bez proszenia trzech działów.
  • Istnieją SLO i error budget lub jest zgoda, by je wprowadzić w jednej usłudze w 60 dni.