Skip to content

Blog

Shadow IT z aplikacji AI: dobry znak w złym miejscu

Działy budują własne aplikacje w narzędziach AI. Dlaczego to zgłoszenie potrzeby, a nie zagrożenie, i gdzie te aplikacje powinny działać.

Kiedy w firmie mówi się o shadow IT, zwykle brzmi to jak problem. Ktoś wprowadził narzędzie, nie pytając nikogo. Dane leżą tam, gdzie nie powinny. IT sprząta po fakcie.

Narzędzia AI nadają temu tematowi nowy kształt. Działy nie korzystają już tylko z cudzego oprogramowania, budują własne. Kierowniczka sprzedaży w jedno popołudnie robi sobie zestawienie otwartych ofert. Kierownik zmiany na produkcji buduje aplikację do przekazywania zmian. Idzie szybko, działa i często omija IT.

Chcemy zaproponować inne spojrzenie.

Shadow IT to zgłoszenie potrzeby

Nikt nie buduje aplikacji po godzinach, bo sprawia mu przyjemność obchodzenie zasad. Ludzie budują, bo czegoś im brakuje. Bo istniejące oprogramowanie nie pasuje do procesu. Bo zgłoszenie do IT od miesięcy czeka na realizację. Bo arkusz z dwunastoma zakładkami już nie wystarcza.

Każda samodzielnie zbudowana aplikacja jest więc bardzo precyzyjnym zgłoszeniem potrzeby. Nie mówi tylko „potrzebujemy czegoś”, ale pokazuje, jak to ma wyglądać. To cenniejsze niż niejeden dokument z wymaganiami.

Kto odpowiada na to zakazem, traci właśnie tę wiedzę. Aplikacja nie znika. Staje się po prostu niewidoczna.

Co naprawdę jest trudne w aplikacjach AI działających w cieniu

Warto spokojnie nazwać, gdzie leżą trudności, bez straszenia:

  • Działają na prywatnych kontach. Gdy ta osoba odchodzi z firmy, aplikacja zawisa w próżni.
  • Udostępnianie to przekazanie linku. Kto ma link, widzi wszystko. Ról nie ma.
  • Nikt nie sprawdza, co robi zmiana. Kolejna poprawka może po cichu odsłonić coś, co wcześniej było ukryte.
  • Nie ma drogi powrotu. Gdy coś się zepsuje, ostatnia działająca wersja przepada.
  • IT nic nie widzi. Nie dlatego, że ktoś coś ukrywa, ale dlatego, że nie ma miejsca, w którym IT mogłoby to zobaczyć.

Żaden z tych punktów nie dotyczy pomysłu, który stoi za aplikacją. Wszystkie dotyczą miejsca, w którym ona działa.

Pozwolenie na budowanie

Nasze stanowisko jest proste: działy powinny móc budować. Wprost, oficjalnie, z poparciem. Pytanie nie brzmi, czy budują, tylko gdzie.

Dobre miejsce dla samodzielnie zbudowanych aplikacji zapewnia to, czego nikt nie powinien wymagać od działu merytorycznego:

  • Aplikacja działa w workspace firmy, z logowaniem przez konta firmowe.
  • Uprawnienia obowiązują według roli i są sprawdzane przy każdym dostępie.
  • Każda wersja jest testowana, zanim trafi na produkcję.
  • Każda wersja zostaje zachowana, a poprzednia jest o jedno kliknięcie.
  • Administratorzy widzą każdą aplikację i każdą zmianę.

Tak działa Openbase.one. Zespół opisuje własnymi słowami, czego potrzebuje i kto co może widzieć. Agent buduje aplikację, a Openbase.one pyta tylko o to, co wymaga decyzji merytorycznej. Każda wersja jest budowana i otwierana w prawdziwej przeglądarce jako każda osoba testowa. Wersja, której budowanie albo sprawdzenie się nie powiedzie, nie trafia na produkcję.

Kod aplikacji działa w izolacji i nie sięga ani do internetu, ani do innych workspace’ów. Aplikacje nie piszą SQL; każdy dostęp do danych jest sprawdzany względem workspace, aplikacji i uprawnień. Dziennik audytu zapisuje, kto co zmienił.

Co zmienia się dla IT

Zadanie IT się przesuwa. Zamiast oceniać każdą aplikację osobno, IT raz ustala zasady: jak ludzie się logują, czy hasła są dozwolone, czy zainstalowane aplikacje aktualizują się automatycznie, czy dopiero po akceptacji. Od tej pory te zasady obowiązują każdą nową aplikację.

To nie jest kontrola tylnymi drzwiami. To powód, dla którego IT w ogóle może powiedzieć „tak”. Kto wie, że każda nowa aplikacja działa w tych samych barierkach, nie musi obawiać się każdej z osobna.

Wyjście też jest uregulowane. Kod każdej waszej aplikacji leży jako repozytorium Git w workspace, a dane można wyeksportować. Nikt nie jest przywiązany do jednej osoby ani jednego narzędzia.

Co zostaje po stronie zespołu

Środowisko może sprawdzić, czy przełożony widzi wynagrodzenia. Nie oceni jednak, czy limit akceptacji w zakupach powinien wynosić 5000 czy 10 000 euro. To rozstrzyga zespół, który buduje aplikację, i to on ją zatwierdza. Tej odpowiedzialności nie da się zautomatyzować i nie powinno się tego robić.

Jeśli chcecie w tym wsparcia, dostaniecie je. Wsparcie platformy jest w cenie każdego planu. Dla waszych własnych aplikacji są umowy wsparcia z imiennymi osobami kontaktowymi i godzinami pomocy, a Premium obejmuje też przegląd nowych aplikacji przed wdrożeniem.

Budujcie dalej, ale tutaj

Najlepszą odpowiedzią na shadow IT z aplikacji AI nie jest zakaz ani inwentaryzacja. Jest nią propozycja: budujcie dalej, ale w miejscu, które firma widzi i w którym może wycofać zmiany. Jeśli macie już aplikację w innym narzędziu, po prostu opiszcie ją jeszcze raz, tym razem w workspace firmy.

A niektórych rzeczy w ogóle nie trzeba budować. Gotowe aplikacje, takie jak Pliki, Meet czy Wiki, pochodzą z App Store, który stale rośnie, i działają od razu po instalacji.

Ile to kosztuje

Openbase.one kosztuje za workspace. Użytkownicy i aplikacje są bez limitu w każdym planie, a licencji za aplikację nie ma. Możecie zacząć za darmo i bez karty kredytowej. Wszystkie szczegóły znajdziecie na stronie z cennikiem.

Opiszcie swoją pierwszą aplikację i zobaczcie, jak sprawdzona trafia na produkcję.

Zacznij za darmo

Zbudujcie aplikację, której wam brakuje.
Bezpiecznie od pierwszej wersji.

Rejestracja w 30 sekund, przez e-mail, Google lub Microsoft. Workspace jest gotowy od razu, bez konfiguracji i bez karty kredytowej.

Okres próbny z 15 € kredytów AI. Karta kredytowa nie jest wymagana.