Wdrażasz AI w firmie? Sprawdź, kiedy odliczysz koszty w ramach ulgi B+R, a kiedy fiskus zakwestionuje wydatek

• Co naprawdę bada fiskus
• Wdrożenie gotowego systemu to nie B+R
• Kiedy fiskus mówi „tak”
• Trzy scenariusze, trzy różne kwalifikacje
• Pułapka chmury obliczeniowej
• Dokumentacja, która obroni ulgę
• Cztery najczęstsze błędy
• Co zrobić dziś
• Powołane orzecznictwo
• Powołane interpretacje

Co naprawdę bada fiskus

Ulga B+R z art. 18d ustawy o CIT i analogicznego art. 26e ustawy o PIT premiuje wyłącznie koszty uzyskania przychodów poniesione na działalność badawczo-rozwojową. Definicja tej działalności, zawarta w art. 4a pkt 26 CIT, mówi o aktywności twórczej, podejmowanej systematycznie w celu zwiększenia zasobów wiedzy lub ich nowych zastosowań. Ustawodawca wprost wyłącza z prac rozwojowych rutynowe i okresowe zmiany. To właśnie ten zapis decyduje, że nie każdy „projekt AI” zasługuje na ulgę.

Przy projektach AI fiskus nie bada więc samej nowoczesności narzędzia, lecz charakter prac podatnika. Kluczowe jest to, czy firma formułuje własne hipotezy techniczne, eksperymentuje, prototypuje i mierzy się z niepewnością wyniku, czy tylko konfiguruje produkt dostarczony przez zewnętrznego dostawcę.

W praktyce stosuje się podwójny test. Najpierw należy ustalić, czy aktywność ma charakter twórczej, systematycznej pracy rozwojowej. Dopiero potem trzeba sprawdzić, czy konkretny wydatek mieści się w zamkniętym katalogu kosztów kwalifikowanych z art. 18d ust. 2 CIT. To na tym drugim etapie najczęściej pojawia się spór o faktury za API, abonamenty SaaS (oprogramowanie udostępniane w modelu subskrypcji przez internet) czy usługi chmurowe.

Organy podatkowe i sądy administracyjne weryfikują kryteria oceny twórczości z odwołaniem do międzynarodowego standardu OECD – Podręcznika Frascati (międzynarodowego podręcznika metodologicznego OECD dotyczącego pomiaru i kwalifikowania działalności badawczo-rozwojowej, dostępnego na stronie OECD: oecd.org). Ten wskazuje, że działalność B+R musi być jednocześnie nowatorska, twórcza, niepewna co do wyniku, systematyczna oraz możliwa do odtworzenia lub przekazania innym podmiotom. Sama nowoczesność technologii – nawet jeśli mowa o dużym modelu językowym – nie wystarczy, jeżeli brakuje hipotez badawczych i ryzyka porażki.

Wdrożenie gotowego systemu to nie B+R

Najbardziej restrykcyjna linia orzecznicza dotyczy właśnie wdrożeń gotowych rozwiązań. W bliźniaczych wyrokach z 25 sierpnia 2021 r. (sygn. akt II FSK 138/19 i sygn. akt II FSK 139/19) Naczelny Sąd Administracyjny zaakceptował stanowisko, że dostosowanie do potrzeb przedsiębiorstwa dostępnych na rynku rozwiązań typu workflow czy RFID nie stanowi działalności B+R, lecz ma charakter rutynowy. Wcześniejsze orzeczenie NSA z 9 października 2019 r. (sygn. akt II FSK 3589/17) prowadziło do podobnego wniosku: nabycie systemu komputerowego wraz z licencją od zewnętrznego dostawcy, nawet jeśli wspiera produkcję i zarządzanie, nie daje prawa do kosztów kwalifikowanych w uldze B+R.

Dla projektów AI to najważniejszy sygnał ostrzegawczy: innowacja organizacyjna lub procesowa nie jest jeszcze działalnością badawczo-rozwojową w rozumieniu art. 4a pkt 26 CIT.

Kiedy fiskus mówi „tak”

Korzystniejsza linia interpretacyjna obejmuje sytuacje, w których podatnik buduje własne rozwiązanie, a sztuczna inteligencja jest w nim elementem rozwijanym autorsko. Część korzystnych interpretacji zapadła formalnie na gruncie IP Box, ale pozostaje istotna dla ulgi B+R, ponieważ organ oceniał w nich te same przesłanki działalności badawczo-rozwojowej: twórczość, systematyczność, nierutynowość i wykorzystanie wiedzy do nowych zastosowań.

Dyrektor Krajowej Informacji Skarbowej w interpretacji indywidualnej z 4 marca 2024 r. (sygn. 0111-KDIB1-3.4010.742.2023.2.JKU) potwierdził, że platforma informatyczna do zarządzania nieruchomościami, wykorzystująca algorytmy AI do przewidywania awarii i problemów eksploatacyjnych, może spełniać przesłanki działalności B+R. Decydujące były twórczy charakter rozwiązania, systematyczność prac i ukierunkowanie ich na nowe zastosowania.

Podobnie organ podszedł do oprogramowania wykorzystującego uczenie maszynowe do automatycznego podejmowania decyzji i generowania rekomendacji – w interpretacji indywidualnej z 14 lutego 2024 r. (sygn. 0113-KDIPT2-2.4011.868.2023.2.AKU) Dyrektor KIS uznał, że tworzenie autorskich funkcji niedostępnych w gotowych produktach, wymagające iteracyjnego procesu projektowego i testowania, mieści się w zakresie ulgi B+R. Istotny był także dodatkowy wniosek: algorytmy AI nie muszą powstawać od zera, by projekt został uznany za badawczo-rozwojowy. Wystarczy, że w procesie ich zastosowania powstają oryginalne rozwiązania problemów technicznych.

Interpretacja indywidualna Dyrektora KIS z 25 kwietnia 2025 r. (sygn. 0114-KDIP3-1.4011.236.2025.2.EC) pokazuje natomiast, że twórczy charakter prac może obejmować cały zespół projektowy: od projektowania algorytmów, przez analizy i scenariusze testowe, po dokumentację techniczną oraz interfejsy użytkownika. Na potrzeby ulgi B+R do kosztów osobowych można więc włączyć także analityków, projektantów UX i testerów, jeśli ich praca jest integralną częścią procesu twórczego.

Trzy scenariusze, trzy różne kwalifikacje

Różnice między projektami AI najlepiej widać w konkretnych przykładach.

Scenariusz 1. Własny model uczenia maszynowego do predykcji awarii w zakładzie produkcyjnym, trenowany na własnych danych z czujników. Spółka formułuje hipotezy o przyczynach awarii, eksperymentuje z różnymi architekturami sieci, metodami walidacji i metrykami precyzji. Część prototypów nie spełnia założonych KPI i zostaje odrzucona. To klasyczny przykład prac rozwojowych, w którym kwalifikowane mogą być wynagrodzenia inżynierów danych, materiały, sprzęt specjalistyczny oraz amortyzacja własnej infrastruktury wykorzystywanej do prac.

Scenariusz 2. Integracja komercyjnego API dużego modelu językowego z istniejącym systemem obsługi klienta. Programiści konfigurują prompty, tworzą polityki bezpieczeństwa, ustawiają mechanizmy ponawiania prób i monitoring. Nie powstaje własny model ani autorska logika decyzyjna. To typowa praca wdrożeniowo-integracyjna, która – zgodnie z linią orzeczniczą NSA dotyczącą gotowego oprogramowania – nie kwalifikuje się do ulgi B+R.

Scenariusz 3. System decyzyjny, w którym gotowy model językowy jest tylko jednym z komponentów większej autorskiej logiki: własnego retrievera, rerankera, mechanizmów kontroli jakości i procedur awaryjnych. Spółka prowadzi serie testów A/B, dokumentuje benchmarki i iteracyjnie zmienia założenia. Tu kwalifikacja jako B+R jest możliwa do obrony – pod warunkiem rzetelnej dokumentacji wkładu własnego, odróżniającego prace twórcze od standardowej integracji.

Pułapka chmury obliczeniowej

W interpretacji indywidualnej z 13 marca 2026 r. (sygn. 0111-KDIB1-3.4010.7.2026.3.AN) Dyrektor KIS przyjął niekorzystne dla podatnika podejście do wydatków na chmurę obliczeniową. Organ uznał, że takie wydatki nie wchodzą do katalogu kosztów kwalifikowanych z art. 18d ust. 2 CIT, nawet jeśli sama działalność software house’u czy spółki AI ma charakter badawczo-rozwojowy.

Logika fiskusa jest tu formalna: abonament za usługę chmurową nie jest ani materiałem, ani odpisem amortyzacyjnym od środka trwałego, ani inną kategorią wymienioną w ustawie. Bezpieczniejsza niż próba „dopasowania” go do nieadekwatnej pozycji może być ścieżka amortyzacyjna – jeśli nabyte prawo rzeczywiście spełnia warunki wartości niematerialnej i prawnej z art. 16b CIT.

Dokumentacja, która obroni ulgę

W projektach zakwalifikowanych jako B+R organy zwracają uwagę na kompletność dokumentacji. Nie chodzi o prezentacje dla zarządu czy mapy drogowe produktu – te pokazują korzyści biznesowe, nie twórczość techniczną. Liczy się zapis realnego eksperymentu: testowane hipotezy, przyjęte metryki, wyniki negatywne i momenty zmiany założeń.

Pomocnym elementem dokumentacji może być także opinia o innowacyjności wdrożenia, przygotowana przez niezależną jednostkę naukową, uczelnię albo eksperta branżowego. Taka opinia nie przesądza automatycznie o prawie do ulgi, ale może wzmocnić argumentację podatnika, że projekt wykracza poza rutynową konfigurację gotowego narzędzia. W projektach AI takimi dowodami mogą być dane, których firmy IT zwykle nie traktują jako materiału podatkowego: historia repozytorium kodu, logi treningu modeli, wersjonowanie zbiorów danych i promptów, raporty z benchmarków oraz decyzje stop/go z przeglądów technicznych.

Równolegle trzeba wdrożyć trzy warstwy ewidencji wymaganej przepisami. Po pierwsze – ewidencję czasu pracy z rozbiciem na projekty i typy zadań (B+R kontra utrzymanie). Po drugie – osobne konta księgowe odzwierciedlające kategorie z art. 18d ust. 2 CIT. Po trzecie – mapowanie zadań technicznych na dowody projektowe. Art. 9 ust. 1b CIT wprost nakazuje wyodrębnienie kosztów B+R w księgach, a art. 18e CIT wymaga ich wykazania w zeznaniu.

Cztery najczęstsze błędy

W praktyce ulga B+R najczęściej bywa kwestionowana z powodu kilku błędów.

1. Utożsamienie transformacji cyfrowej z B+R. Projekt może być duży, kosztowny i nawet „AI-owy”, a mimo to nie przekroczyć progu twórczej działalności rozwojowej, jeśli sprowadza się do parametryzacji gotowego produktu.

2. Pomieszanie poziomów analizy. Projekt może być B+R, ale konkretny wydatek – abonament SaaS, opłata API, zwykła faktura B2B – może nie mieścić się w katalogu z art. 18d ust. 2 CIT.

3. Brak rozdziału prac rozwojowych od utrzymania. Jeśli w timesheetach obok projektowania modelu pojawiają się bugfixy, support, migracje i konfiguracja produkcyjna bez klasyfikacji, organ ma prostą drogę do zakwestionowania znaczącej części odliczenia.

4. Traktowanie dokumentacji biznesowej jako wystarczającej. Prezentacja dla zarządu czy opis korzyści dla klienta nie zastąpią dokumentów dowodzących niepewności technicznej i eksperymentalności prac.

Co zrobić dziś

Doradcy podatkowi i CTO zarządzający projektami AI powinni przyjąć kilka zasad.

• już na początku projektu warto formalnie zakwalifikować go jako rozwój własnego rozwiązania albo wdrożenie cudzego narzędzia.
• prace B+R, wdrożenie, utrzymanie oraz opłaty za gotowe narzędzia należy rozdzielić księgowo i kontraktowo.
• przy zewnętrznych modelach lub API linię obrony trzeba budować wokół własnego wkładu technicznego: architektury, eksperymentów i walidacji.
• wydatki na licencje, SaaS i API warto oceniać konserwatywnie albo zabezpieczyć interpretacją indywidualną.

Sztuczna inteligencja nie odbiera projektowi statusu B+R – ale też go automatycznie nie przyznaje. Dla fiskusa liczą się twórczość, niepewność wyniku, systematyczność prac i prawidłowe przypisanie kosztów. Największe ryzyko tkwi dziś właśnie w szczegółach: chmurze, API, licencjach i dowodach pokazujących, że firma nie tylko wdrożyła technologię, lecz rzeczywiście ją rozwijała.

Powołane orzecznictwo

– wyrok NSA z 25 sierpnia 2021 r., sygn. akt II FSK 138/19 i sygn. akt II FSK 139/19

– wyrok NSA z 9 października 2019 r., sygn. akt II FSK 3589/17

Powołane interpretacje

• interpretacja indywidualna Dyrektora KIS z 4 marca 2024 r., sygn. 0111-KDIB1-3.4010.742.2023.2.JKU
• interpretacja indywidualna Dyrektora KIS z 14 lutego 2024 r., sygn. 0113-KDIPT2-2.4011.868.2023.2.AKU
• interpretacja indywidualna Dyrektora KIS z 25 kwietnia 2025 r., sygn. 0114-KDIP3-1.4011.236.2025.2.EC
• interpretacja indywidualna Dyrektora KIS z 13 marca 2026 r., sygn. 0111-KDIB1-3.4010.7.2026.3.AN