Technologia w due diligence: co inwestor powinien wiedzieć przed przejęciem spółki

Zdjęcie: koszty, biznes, pieniądze

Spółka może mieć rosnące przychody, stabilnych klientów i przekonujący produkt, a jednocześnie skrywać technologiczny rachunek, który staje się widoczny dopiero po zmianie właściciela.

To ryzyko nabiera znaczenia wraz z odbudową rynku M&A. PwC szacuje, iż wartość globalnych transakcji może w 2026 roku sięgnąć 4 bln dolarów, o około 13 proc. więcej niż rok wcześniej. Jednocześnie liczba transakcji ma spaść o podobną skalę. Kapitał koncentruje się więc na większych aktywach, a presja na trafną wycenę rośnie. Szczególnie w software, gdzie AI zmienia modele biznesowe, bariery wejścia i ocenę przyszłej przewagi konkurencyjnej.

W takich transakcjach technologia nie jest już technicznym dodatkiem do due diligence. Może zmienić wartość aktywa, ekonomię integracji i termin osiągnięcia zakładanych synergii.

Dług technologiczny pojawia się w wycenie za późno

Dobrze pokazuje to badanie KPMG przeprowadzone wśród 135 specjalistów zajmujących się transakcjami technologicznymi. Tylko 27 proc. respondentów uznało rozwiązanie problemu długu technologicznego za wysoki priorytet podczas oceny spółki przed transakcją. Na etapie planowania integracji odsetek wzrósł do 68 proc., a po przejęciu wynosił 67 proc.

Problem nie powstaje więc po podpisaniu umowy. Wtedy zaczyna kosztować.

Dług technologiczny może oznaczać monolityczną architekturę trudną do skalowania, przestarzały stack, niedostateczne testy, manualne wdrożenia, słabą dokumentację albo produkt zależny od kilku osób znających jego najważniejsze elementy. System może sprawnie obsługiwać obecny biznes, ale nie wytrzymać dwukrotnego wzrostu ruchu, ekspansji na kolejny rynek czy integracji z platformą nabywcy.

EY wskazuje właśnie skalowalność, architekturę, dług techniczny, koszty hostingu i zdolność zespołu R&D do wykonania roadmapy jako obszary, które mogą bezpośrednio podważyć założenia inwestycyjne w transakcjach software’owych. Problemy z integracją często ujawniają się dopiero wtedy, gdy trzeba połączyć dwa środowiska, ujednolicić produkty lub wdrożyć wspólną infrastrukturę.

Kod może mieć inną wartość, niż wynika z prezentacji

Osobnym problemem jest to, co faktycznie znajduje się w kodzie przejmowanej spółki. Współczesny software jest zbudowany z tysięcy zależności, bibliotek i komponentów tworzonych poza organizacją.

Black Duck przeanalizował w 2026 roku 947 komercyjnych baz kodu. Open source występował w 98 proc. z nich, przynajmniej jedną podatność wykryto w 87 proc., a konflikty licencyjne w 68 proc. Jeszcze mocniejsze są dane dotyczące samych projektów M&A: open source występował we wszystkich analizowanych transakcjach, 94 proc. obejmowało kod z konfliktami licencyjnymi, a 97 proc. zawierało niezałatane podatności.

To nie jest wyłącznie kwestia cyberbezpieczeństwa. Licencja może ograniczać sposób dystrybucji produktu, wymuszać ujawnienie części kodu albo prowadzić do sporu o własność intelektualną. Podobne ryzyko powstaje przy kodzie tworzonym przez freelancerów, software house’y i coraz częściej narzędzia generatywnej AI.

Wartość „własnej technologii” może więc wyglądać inaczej po sprawdzeniu jej pochodzenia.

Cyberbezpieczeństwo może zostać przejęte razem ze spółką

Kupujący przejmuje nie tylko serwery i aplikacje, ale także ich historię: niewygaszone konta administratorów, błędne konfiguracje chmury, niezałatane systemy, klucze API, zewnętrznych dostawców oraz potencjalne ślady wcześniejszych włamań.

Deloitte zwraca uwagę na szczególnie niebezpieczny okres bezpośrednio po przejęciu. Zmiany uprawnień, łączenie sieci i reorganizacja polityk bezpieczeństwa tworzą przejściowe luki, a sama informacja o transakcji może zwiększać zainteresowanie atakujących.

W praktyce słaby poziom zabezpieczeń przejmowanej firmy może wymusić natychmiastowe inwestycje, zanim jej systemy zostaną bezpiecznie podłączone do infrastruktury grupy.

Chmura może ukrywać problem z marżą

W przypadku SaaS jednym z najbardziej niedocenianych elementów jest ekonomika infrastruktury. Rosnące przychody nie muszą oznaczać rosnącej rentowności, o ile koszty obliczeń, przechowywania danych lub zewnętrznych API zwiększają się niemal liniowo wraz z wykorzystaniem produktu.

Dlatego sama informacja o tym, iż spółka działa „w chmurze”, mówi niewiele. Istotne są architektura, wykorzystanie zasobów, zależność od konkretnego dostawcy, możliwość migracji oraz relacja kosztów hostingu do wzrostu przychodów. EY traktuje już tę analizę jako jeden ze standardowych elementów technologicznego due diligence spółek software’owych.

Do tego dochodzi AI. Od 2 sierpnia 2026 roku Komisja Europejska i organy krajowe rozpoczęły egzekwowanie kolejnej części AI Act, w tym nowych obowiązków dotyczących przejrzystości. W spółkach rozwijających produkty oparte na AI przedmiotem transakcji stają się więc również dane treningowe, pochodzenie modeli, zależności od zewnętrznych dostawców i zdolność do spełnienia wymagań regulacyjnych.

Technologiczne due diligence coraz mniej przypomina sprawdzanie, czy produkt działa. Znacznie ważniejsze jest ustalenie, czy jego architektura, kod, dane i zespół są w stanie dostarczyć wzrost wpisany w wycenę.

Najbardziej kosztowne problemy technologiczne zwykle nie zatrzymują sprzedaży przed transakcją. Zaczynają obniżać jej wartość po zamknięciu.