Jak Solvro i PWr zamieniły "nieoficjalne" oprogramowanie w odpowiedzialną współpracę?

W połowie kwietnia 2026 roku mieliśmy przyjemność wziąć udział w iCHTS (International Conference on Human Technology and Society) jako prelegenci i przy okazji jako partner konferencji Craft. Dawid Linek zaprezentował case study zatytułowane "Shadow IT as an Innovation Engine", które opowiada historię naszego koła: od garażowego projektu tworzonego poza oficjalnymi kanałami uczelni, aż po wypracowanie wspólnie z Politechniką Wrocławską formalnego modelu współpracy. To dobra okazja, żeby opowiedzieć tę historię szerzej.

 

Kim jesteśmy? Krótka historia KN Solvro

KN Solvro powstało w 2018 roku jako małe koło naukowe skupiające studentów Politechniki Wrocławskiej z jedną wspólną ambicją: rozwiązywać prawdziwe, codzienne problemy za pomocą technologii. Skąd taka nazwa? Solvro - od angielskiego to solve, czyli rozwiązywać. Proste, ale trafne.

Przez pierwsze lata działaliśmy skromnie: kilkanaście osób, kilka projektów, mnóstwo entuzjazmu i niekoniecznie dużo doświadczenia. Tworzyliśmy aplikacje oddolnie, kierując się zasadą "od studentów dla studentów" - bo nikt lepiej niż student nie wie, czego brakuje na własnej uczelni. Interaktywna mapa kampusu, menu stołówki w telefonie, śledzenie wolnych miejsc parkingowych w czasie rzeczywistym, planery zajęć, zaawansowane systemy zarządzania wydarzeniami dla innych organizacji studenckich to tylko część tego, co wyszło spod naszych rąk.

Prawdziwy przełom nastąpił w 2024 roku. Solvro zaczęło się dynamicznie rozwijać  zarówno pod względem liczby członków, jak i skali realizowanych projektów. Dziś jesteśmy organizacją liczącą blisko 160 aktywnych członków, działamy na styku inżynierii oprogramowania, sztucznej inteligencji i budowania społeczności, a nasze aplikacje trafiają do tysięcy użytkowników na całej uczelni. Ale ta droga nie była usłana różami, ponieważ po drodze natknęliśmy się na coś, co świat korporacyjny zna doskonale pod nazwą Shadow IT.

Czym jest Shadow IT i dlaczego nas to dotyczy?

Shadow IT to termin z literatury naukowej opisujący systemy informatyczne, procesy i narzędzia tworzone poza wiedzą i kontrolą oficjalnego działu IT organizacji. Klasyczna definicja Rentropa i Zimmermanna (2012) brzmi:

"Shadow IT describes the supplement of "official" IT by several, autonomous developed IT systems, processes and organizational units, which are located in the business departments. These systems are generally not known, accepted and supported by the official IT department."

W firmach Shadow IT pojawia się, gdy pracownicy napotykają problem, na którego rozwiązanie centralny dział IT nie ma czasu, środków lub priorytetu. Zamiast czekać, tworzą własne narzędzia, takie jak arkusze kalkulacyjne, skrypty, małe aplikacje, które działają, ale istnieją poza jakimkolwiek nadzorem. Na uczelniach mechanizm jest dokładnie taki sam.

W naszym przypadku budowaliśmy aplikacje używane przez tysiące studentów i pracowników PWr, integrowaliśmy się z uczelnianymi systemami danych, przechowywaliśmy dane osobowe, a wszystko to w cieniu.

 

Plusy Shadow IT

Shadow IT ma swoje realne zalety i właśnie dlatego jest tak powszechne zarówno w firmach, jak i na uczelniach:

Napędza innowacje i kreatywność. Gdy mały, zwinny zespół studentów może w weekendy stworzyć aplikację, którą tysiące osób zaczyna używać już w poniedziałek (tak jak zrobiliśmy to z Testownikiem), to jest właśnie ta oddolna energia, której duże organizacje bardzo często po prostu nie mają.

Zwiększa zwinność i szybkość działania. Oficjalne projekty IT w dużych instytucjach trwają miesiącami. My byliśmy w stanie dostarczyć działające rozwiązanie w ciągu kilku tygodni, bo nie byliśmy ograniczeni biurokracją przetargową ani długimi cyklami decyzyjnymi.

Jest ściśle dopasowane do potrzeb użytkowników. Nikt nie zna potrzeb studenta lepiej niż inny student. Nasze aplikacje były projektowane przez ludzi, którzy sami z nich korzystali - stąd ich wysoka adopcja.

Przynosi realne efekty. Każda nasza aplikacja rozwiązywała konkretny, odczuwalny problem: brak transparentności oferty gastronomicznej, utrudniony dostęp do mapy kampusu, chaotyczne zarządzanie wydarzeniami. Użytkownicy to doceniali.

Minusy Shadow IT

Ale każda moneta ma dwie strony. I gdy nasze projekty zaczęły rosnąć, zderzylśmy się z ciemniejszą stroną nieformalności:

Ryzyko bezpieczeństwa i compliance. Gdy aplikacja zaczyna przetwarzać dane osobowe - imiona, adresy e-mail, numery indeksów - wchodzi w zakres RODO. My uczyliśmy się kodowania "na żywych organizmach", co szybko prowadzi do braku stabilności i błędów na produkcji.

Problemy z jakością inżynierską. Entuzjazm nie zastępuje doświadczenia. Kod pisany przez studentów uczących się rzemiosła bywa niejednolity, słabo udokumentowany i trudny w utrzymaniu.

Ryzyko ciągłości działania. To był jeden z największych lęków uczelni: co się stanie z aplikacją używaną przez tysiące osób, gdy jej twórca skończy studia i wyjedzie do pracy? Bez planu sukcesji, dokumentacji i backupów - aplikacja po prostu umrze wraz z absolwentem.

Problemy z własnością intelektualną. Gdy 20 studentów przez dwa lata buduje wspólnie aplikację, a potem każdy z nich kończy studia - kto jest właścicielem kodu? Czy prawa należą do uczelni, do koła naukowego, czy do każdego z programistów osobno? To pytania, które bez formalnych ustaleń pozostają w niebezpiecznej szarej strefie.

 

Procedura udostępniania aplikacji - Framework of Responsible Co-creation

Dwa lata intensywnego dialogu między KN Solvro a Działem Informatyzacji, Biurem Bezpieczeństwa Informacji, Działem Promocji, Działem Prawny, Działem Ochrony Własności Intelektualnej,  Wydziałem Informatyki i Telekomunikacji oraz innymi jednostkami uczelni przyniosły konkretny efekt: 2 kwietnia 2026 roku PWr oficjalnie opublikowała "Procedurę udostępniania aplikacji dla użytkowników Politechniki Wrocławskiej". To dokument, który zmienia zasady gry nie tylko dla nas, ale dla wszystkich kół naukowych i twórców oprogramowania działających w ekosystemie uczelni.

Procedura to nie biurokratyczna zapora, ale mapa drogowa odpowiedzialnego wdrożenia. Podczas wystąpienia na konferencji przedstawiliśmy ją jako framework złożony z 5 filarów i 10 konkretnych kroków, które prowadzą twórcę aplikacji od pomysłu do produkcji w sposób bezpieczny, transparentny i zgodny z prawem.

Filar 1 - Formalized Onboarding & Ownership

Jasne zasady od pierwszego dnia
Administracja wyprowadza nasz development z cienia. Zamiast działać po omacku, twórca aplikacji formalnie przedstawia swój projekt uczelni i od razu porządkuje kwestie, które wcześniej były źródłem największych problemów.

Krok 1. Złożenie wniosku. Każde wdrożenie zaczyna się od formalnego wniosku do Działu Informatyzacji (DZI). Wniosek musi zawierać nazwę i opis aplikacji, listę planowanych użytkowników, opis kluczowych funkcjonalności, informacje o architekturze i użytych technologiach, wymagane integracje z systemami uczelnianymi (np. USOS API, SSO). Szczególnie istotny dla kół naukowych jest wymóg określenia statusu praw autorskich i zakresu licencji udzielanej uczelni - koniec z niejasnością, czyja jest aplikacja po zakończeniu studiów.

Krok 2. Wstępna analiza i planowanie testów. DZI weryfikuje, czy aplikacja nie dubluje istniejących systemów uczelnianych, wstępnie ocenia ryzyko i określa wymagane testy oraz dokumenty. Etap kończy się rekomendacją Dyrektora DZI - pozytywną lub negatywną . Pozytywna rekomendacja to przepustka do kolejnych kroków.

Filar 2 - Institutional Guardrails

Bezpieczeństwo i zgodność jako fundament, nie przeszkoda
Zamiast pozostawiać twórcę samego z wymogami prawnymi i technicznymi, uczelnia buduje konkretne wymagania a student musi udowodnić, że jego aplikacja w nich mieści.

Krok 3. Analiza ryzyka. Twórca aplikacji przeprowadza pełną analizę ryzyka: identyfikuje przetwarzane zasoby (bazy danych studentów, plany zajęć itd.), wskazuje potencjalne zagrożenia (nieautoryzowany dostęp, wyciek danych, atak DoS), ocenia podatności i szacuje prawdopodobieństwo oraz wpływ każdego zagrożenia. Na tej podstawie dobiera strategię: mitygację (wdrażam zabezpieczenia), akceptację (świadomie przyjmuję ryzyko) lub unikanie (rezygnuję z ryzykownej funkcjonalności). Aplikacje przetwarzające dane osobowe wymagają dodatkowo konsultacji z Biurem Bezpieczeństwa Informacji.

Krok 4. Polityki dostępowe. Aplikacja musi mieć precyzyjnie zdefiniowane role użytkowników - administrator, student, pracownik - i jasno określone, co każda z nich może robić. Polityka dostępowa musi być spójna z regulacjami uczelnianymi i uwzględniać wymogi RODO dotyczące upoważnień do przetwarzania danych.

Krok 7. Regulamin aplikacji. Aplikacje dostępne szerokiemu gronu odbiorców lub przetwarzające dane osobowe muszą mieć regulamin napisany prostym, zrozumiałym językiem. Regulamin określa zasady dostępu, prawa i obowiązki użytkowników i administratorów, zasady przetwarzania danych zgodnie z RODO, a jeśli aplikacja korzysta z AI - również zgodność z unijnym AI Act.

Filar 3 - Safe-to-Connect Infrastructure

Oficjalne API zamiast prowizorycznych obejść. Zamiast zmuszać studentów do budowania  wokół systemów uczelnianych, DZI udostępnia standardowe, bezpieczne punkty integracji. Podłączamy się do ekosystemu uczelni oficjalnie i bezpiecznie.

Krok 5. Integracje. Twórca aplikacji definiuje formalne punkty styku z innymi systemami - USOS, poczta uczelniana, Active Directory, system TETA. Dla każdej integracji określa protokół komunikacji, format danych, zasady bezpieczeństwa i procedury obsługi błędów. Po wdrożeniu DZI może zdecydować o podłączeniu aplikacji do uczelnianego systemu monitoringu Zabbix lub systemu kolejkowego OTOBO.

Filar 4 - Resilience & Continuity

Aplikacja musi przeżyć swojego twórcę To było jedno z największych obaw uczelni wobec Shadow IT: student kończy studia, wyjeżdża do pracy i aplikacja, z której korzystają tysiące osób, po prostu przestaje działać. Ten filar odpowiada na ten problem wprost.

Krok 6. Plan ciągłości działania. Każda aplikacja musi mieć udokumentowany plan ciągłości obejmujący klasyfikację krytyczności BIA (niska / średnia / wysoka), parametry odtwarzania - RTO (maksymalny czas niedostępności) i RPO (maksymalna dopuszczalna utrata danych) - strategię backupów i archiwizacji z określoną częstotliwością i miejscem składowania, plan Disaster Recovery oraz jasno zdefiniowane role i odpowiedzialności po stronie twórcy. Dzięki temu aplikacja nie umiera razem z dyplomem jej autora.

Filar 5 - Collaborative Quality Assurance

Zatwierdzenie aplikacji do produkcji to nie pojedynczy "stempel" z działu IT. To wspólna odpowiedzialność wielu jednostek, które patrzą na aplikację z różnych perspektyw: technicznych, prawnych, wizerunkowych i dostępności.

Krok 8. Testy bezpieczeństwa. Zależnie od profilu ryzyka aplikacja może wymagać analizy statycznej kodu, automatycznego skanowania podatności, testów penetracyjnych symulujących ataki oraz przeglądu konfiguracji serwerów.

Krok 9. Testy wydajności. Sprawdzenie, jak aplikacja radzi sobie pod normalnym i ekstremalnym obciążeniem: testy obciążeniowe, przeciążeniowe i stabilnościowe.

Krok 10. Zgoda na udostępnienie produkcyjne. Finalny dokument zgody musi zostać podpisany przez: opiekuna koła naukowego, Dział Wsparcia Aktywności Studenckiej, Biuro Bezpieczeństwa Informacji (IOD/IBI), ZBI (WCSS), administratora systemów informatycznych wydziału, Dział Promocji, Dział Dostępności (WCAG) i Dział Informatyzacji.

To nie jest brama blokująca innowację, a  wspólna sieć bezpieczeństwa. Zgoda podlega weryfikacji co 12 miesięcy, a naruszenia bezpieczeństwa lub brak reakcji na zgłoszenia mogą skutkować wyłączeniem aplikacji z produkcji.

Innowacja z instytucją, nie przeciwko niej

Historia Solvro to dowód na to, że Shadow IT nie musi być wrogiem, a  może być punktem wyjścia do czegoś dużo lepszego. Zamiast konfrontacji, wybraliśmy dialog. Zamiast blokowania, uczelnia stworzyła ramy dla odpowiedzialnej innowacji. Zamiast działać w cieniu, działamy teraz w pełnym świetle, teraz z pełnym wsparciem instytucji i realnymi zasobami.

Dziś KN Solvro jest największym kołem naukowym na Politechnice Wrocławskiej i jednocześnie największą tego typu organizacją w Polsce. Współpracujemy na poziomie lokalnym, krajowym i międzynarodowym, zdobywamy nagrody na międzynarodowych hackathonach oraz kształcimy kolejnych inżynierów, którzy wychodzą z Solvro gotowi na zawodowe wyzwania.

Ale przede wszystkim nadal tworzymy aplikacje od studentów dla studentów. Tylko teraz robimy to odpowiedzialnie, trwale i z pełną świadomością, że dobre oprogramowanie to nie tylko dobry kod, ale też dobra governance.

"W świecie AI narzędzia do budowania są teraz w rękach każdego. Naszym zadaniem nie jest odbieranie tych narzędzi, ale budowanie bezpiecznych ram, w których można z nich korzystać odpowiedzialnie." - Dawid Linek

 

Artykuł powstał na podstawie wystąpienia Dawida Linka na konferencji iCHTS (kwiecień 2026) oraz dokumentacji wewnętrznej KN Solvro i Procedury udostępniania aplikacji dla użytkowników Politechniki Wrocławskiej z dnia 02.04.2026 r.