Ešte pred niekoľkými rokmi bola odpoveď na otázku "kto napísal tento kód?" pomerne jednoduchá. Dalo sa ukázať na programátora, tím alebo software house, ktorý zodpovedal za konkrétny modul.
Dnes je situácia úplne iná.
Časť kódu môže vzniknúť ručne. Časť môže vygenerovať Copilot. Ďalší úsek vytvorí programátorský agent. Iný sa stiahne z open source knižnice. Ďalší bude externou závislosťou balíka. K tomu pribúdajú API, cloudové služby, hotové komponenty, frameworky a nástroje dodávané ďalšími firmami.
Systém funguje. Ale naozaj vieš, z čoho bol postavený?
Kód vygenerovaný AI sa neobjavuje vo vákuu
Rozvoj AI nástrojov na programovanie mení nielen spôsob písania softvéru. Mení aj štruktúru zodpovednosti za kód.
Programátor dnes môže agentovi opísať úlohu a následne získať hotovú funkciu, modul, testy, konfiguráciu alebo dokonca návrh architektonických zmien. Je to obrovské zrýchlenie práce.
Problém začína vtedy, keď vygenerovaný kód považujeme za "kód odnikiaľ".
AI totiž netvorí kód oddelene od celého programátorského ekosystému. Modely sú trénované na obrovských dátových súboroch a vygenerovaný fragment môže byť podobný existujúcim riešeniam, vzorom či verejne dostupnému kódu. Práve preto sa otázka pôvodu kódu, licencií a zodpovednosti stáva čoraz dôležitejšou.
To automaticky neznamená, že každý fragment kódu vygenerovaný AI porušuje niečiu licenciu. Znamená to však, že organizácia využívajúca AI v procese vývoja softvéru by mala pristupovať k pôvodu a overovaniu kódu ako k súčasti inžinierskeho procesu, nie ako k právnej zaujímavosti.
To už nie je iba teória
16. septembra 2026 odvolací súd 9. okruhu rozhodol o časti prípadu Doe v. GitHub, v ktorej programátori obviňovali GitHub, Microsoft a subjekty OpenAI okrem iného z využívania verejne dostupného kódu z GitHubu pri vytváraní a trénovaní nástrojov ako Copilot a Codex.
Jedno z nárokov sa týkalo DMCA a informácií o autorských právach. Súd potvrdil zamietnutie tohto konkrétneho tvrdenia. Zároveň sa prípad týka aj ďalších otázok súvisiacich s autorskými právami a open source licenciami.
Je to dôležité nie preto, že jeden rozsudok dáva jednoduchú odpoveď na otázku "či sa dá používať kód z AI".
Nedáva.
Dôležitejšie je, že spor ukazuje širší problém: vo svete AI sa hranica medzi kódom napísaným človekom, kódom vygenerovaným modelom a kódom pochádzajúcim z existujúceho softvérového ekosystému stáva čoraz ťažšie sledovateľnou.
A pre firmy vytvárajúce softvér to znamená potrebu lepšie riadiť tento proces.
Software supply chain, teda tvoj systém má oveľa viac "autorov"
V oblasti bezpečnosti softvéru sa už roky používa pojem software supply chain - dodávateľský reťazec softvéru.
Sú to všetky komponenty, nástroje, knižnice, závislosti a procesy, ktoré sa podieľajú na vzniku finálneho produktu.
NIST v tejto súvislosti poukazuje okrem iného na potrebu správy pôvodu komponentov, kontroly open source závislostí, monitorovania zraniteľností a používania SBOM, teda Software Bill of Materials.
SBOM možno vo veľkom zjednodušení prirovnať k zoznamu zložiek produktu.
Nepovie len "máme aplikáciu". Ukáže, aké komponenty sa nachádzajú vo vnútri.
Napríklad:
- aplikačný framework,
- externé knižnice,
- verzie jednotlivých balíkov,
- open source komponenty,
- nepriame závislosti,
- prvky dodávané externými dodávateľmi.
Vďaka tomu, keď sa objaví zraniteľnosť v konkrétnej knižnici, dá sa rýchlejšie zistiť, ktoré systémy ju používajú.
NIST zároveň upozorňuje na provenance, teda možnosť spätne dohľadať pôvod prvkov softvéru.
A práve tu AI pridáva ďalšiu úroveň zložitosti.
Pretože k existujúcemu reťazcu pribúda ďalší spôsob vzniku kódu.
Predstav si typický biznis systém
40 % kódu napísal tím.
20 % vzniklo s podporou AI.
Ďalšie fragmenty vygeneroval agent.
Niekoľko knižníc pochádza z open source.
Časť závislostí bola pridaná frameworkom.
Systém využíva API externého poskytovateľa.
Jeden komponent pochádza z balíka, ktorý nikto neaktualizoval už dva roky.
A dokumentácia závislostí?
Je niekde v repozitári.
Alebo neexistuje.
Systém funguje...
A práve preto je problém neviditeľný. Kým sa niečo nestane.
A potom sa objaví zraniteľnosť
Predpokladajme, že v jednej z knižníc sa odhalí vážna bezpečnostná chyba.
Otázka znie: Vieš, či ju tvoj systém používa?
Ak máš usporiadaný register závislostí, odpoveď môže byť otázkou minút.
Ak ho nemáš, začína sa manuálne prehľadávanie repozitárov, kontaktovanie programátorov, kontrola prostredí, verzií balíkov a nepriamych závislostí.
A teraz k tomu pridajme kód vygenerovaný AI.
Je známe, ktorý fragment vznikol pomocou ktorého nástroja?
Prebehlo code review?
Bol kód pokrytý testami?
Skontrolovali sa závislosti?
Overil niekto licenciu komponentu?
Dá sa reprodukovať proces, na základe ktorého vznikol konkrétny fragment?
To už nie sú otázky výlučne pre programátora.
Sú to otázky týkajúce sa riadenia technologického rizika firmy.
Najväčší problém nie je AI. Je ním absencia procesu
Bolo by ľahké urobiť z tohto článku varovanie pred umelou inteligenciou.
Bol by to však príliš jednoduchý záver.
AI môže veľmi výrazne zlepšiť produktivitu programátorského tímu.
Problém nastáva vtedy, keď firma zvýši tempo produkcie kódu, ale zároveň nezvýši kontrolu nad týmto kódom.
Je to trochu ako keby továreň zrazu vyrábala desaťkrát viac prvkov, ale nezvýšila kontrolu kvality, evidenciu materiálov ani kontrolu dodávateľov.
V software house je ekvivalentom takéhoto kontrolného systému okrem iného:
- code review
- automatické testy
- skenovanie závislostí
- SBOM
- monitorovanie zraniteľností
- kontrola open source licencií
- CI/CD s bezpečnostnými kontrolami
- správa repozitárov
- dokumentovanie architektúry
- sledovanie pôvodu komponentov
- jasné pravidlá využívania AI vo vývoji
NIST zároveň poukazuje na možnosť integrovať mechanizmy bezpečnosti dodávateľského reťazca priamo do CI/CD pipeline.
To je dôležitá zmena myslenia.
Bezpečnosť by nemala byť kontrolou vykonávanou až pred nasadením.
Mala by byť súčasťou procesu vzniku softvéru.
„Kto napísal tento kód?“ prestáva byť správnou otázkou
Vo svete tradičného vývoja sa bolo možné pýtať na autora.
Vo svete AI-assisted vývoja sa oveľa dôležitejšími stávajú otázky:
- Odkiaľ tento komponent pochádza?
- Akú má licenciu?
- Kto ho overil?
- Akú verziu používame?
- Aké má závislosti?
- Je stále udržiavaný?
- Poznáme jeho zraniteľnosti?
- Vieme obnoviť históriu zmien?
- Vieme, kde sa AI podieľala na jeho vzniku?
A predovšetkým:
- Je firma schopná dokázať, že má nad tým všetkým kontrolu?
Pretože zákazník predsa nekupuje „kód od AI“. Kupuje fungujúci systém. A zodpovednosť za tento systém stále nesie organizácia, ktorá ho dodáva a udržiava.
Kód môže byť automatický. Zodpovednosť nie
Je to pravdepodobne jedna z najdôležitejších zmien, ktoré AI prináša do software house-ov.
Programátor nezmizne. Jeho rola sa mení.
Čoraz častejšie nejde výlučne o napísanie určitého počtu riadkov kódu. Ide o navrhnutie riešenia, kontrolu vygenerovaných prvkov, hodnotenie rizika, testovanie, integráciu, bezpečnosť a údržbu celého systému.
Podobne sa firma nemôže obmedziť na otázku, či jej programátori používajú AI.
Mala by vedieť ako ju používajú, v akom procese, s akými kontrolami a ako to vplýva na celý životný cyklus softvéru.
Pretože o pár rokov nemusí znieť otázka: „Kto napísal tento systém?“
ale: „Viete odtiahnuť, z čoho a akým spôsobom bol postavený?“
Ak odpoveď znie „nie celkom“, problémom nie je nedostatok ďalšieho AI nástroja.
Problémom je nedostatok kontroly nad software supply chain.
