VIEW SPEECH SUMMARY
- Michał znalazł błąd w API banku i próbował go zgłosić, co spowodowało wizytę policji i postawienie mu zarzutów karnych (nieuprawniony dostęp do systemu, publikowanie narzędzi hakerskich).
- Przykłady międzynarodowe pokazują, że nawet działania edukacyjne czy testy bezpieczeństwa mogą prowadzić do poważnych konsekwencji prawnych.
2. Regulacje unijne i cyberbezpieczeństwo
- Dyrektywa NIS-2 nakłada obowiązki na różne branże do zgłaszania podatności w ciągu 90 dni.
- Warto szukać polityk vendorów dotyczących zgłaszania luk i w razie braku korzystać z pośredników (CERT, CIRT).
- Kontekst i cel użycia kodu mają znaczenie prawnokarne; sam kod nie jest przestępstwem, ale użycie może być.
3. AI Act i odpowiedzialność za systemy AI
- AI Act zakazuje manipulacji zachowaniem użytkowników oraz określa przypadki zakazane dla dostawców i deweloperów.
- Systemy AI wysokiego ryzyka wymagają nadzoru ludzkiego, ale wymogi nadzoru nie są szczegółowo określone.
- Odpowiedzialność spoczywa na twórcach, jeśli system może racjonalnie prawdopodobnie być użyty w zakazany sposób lub gdy nie reagują na błędy (halucynacje AI).
4. Regulacje w Stanach Zjednoczonych
- Digital Millennium Copyright Act zakazuje obchodzenia zabezpieczeń i publikowania narzędzi do tego służących.
- Computer Fraud and Abuse Act reguluje kwestie scrapowania danych i przekroczenia autoryzacji, co może być traktowane jako hakowanie czy kradzież.
- Przepisy amerykańskie są często bardziej restrykcyjne i oderwane od współczesnej rzeczywistości.
5. Bezpieczne praktyki testowania oprogramowania
- Nie generować i nie publikować fałszywych treści ani nie łamać zabezpieczeń siłowo.
- Unikać manipulacji konkurencją i tworzenia obraźliwych treści.
- Dokumentować intencje i zostawiać ślady działań wskazujące na cele edukacyjne lub poprawę bezpieczeństwa.
- Anonimizować dane i szczegóły zgłoszeń, by ograniczyć ryzyko odpowiedzialności.
6. Odpowiedzialność deweloperów i porady na przyszłość
- Obecnie brak jest przepisu o indywidualnej odpowiedzialności deweloperów, ale istnieje odpowiedzialność biurokratyczna.
- Warto korzystać z legalnej ochrony, usług prawnika lub formalnych programów bug bounty.
- Kluczowe jest prowadzenie dokumentacji, używanie disclaimerów i zabezpieczenie siebie poprzez transparentność działania.
Działania do podjęcia:
- Przed zgłoszeniem podatności sprawdzić politykę zgłaszania u vendora.
- Zachowywać dowody komunikacji i dokumentować proces zgłaszania.
- Unikać działań mogących być interpretowane jako łamanie prawa: siłowe łamanie zabezpieczeń, generowanie fałszywych danych, obraźliwe treści.
- Jeśli korzystacie z AI w projektach, monitorować działanie systemów wysokiego ryzyka i planować momenty interwencji ludzkiej.
- Rozważyć udział w programach bug bounty lub konsultacje prawne dla ochrony własnej działalności.
Końcowe przesłanie:
- Prawo w obszarze IT i AI to pole minowe, gdzie liczy się świadomość regulacji i działanie z ostrożnością.
- Kod jest wyrazem wolności słowa, ale cel i kontekst jego użycia mają kluczowe znaczenie.
- Odpowiednia dokumentacja i transparentność to najlepsze zabezpieczenia przed konsekwencjami prawnymi.
Czy kod może być nielegalny? Od exploitów po AI Act
16:00 - 16:30, 27th of May (Tuesday) 2025 / DEV ARCHITECTURE STAGE
Kod to język. Kod to życie (czasem). Kod to… dowód w sprawie karnej? W świecie, gdzie prawo nie nadąża za technologią, programiści czy developerzy coraz częściej wpadają w szarą strefę regulacyjną. Czy publikacja exploita jest wolnością słowa, czy naruszeniem prawa? Czy AI generujące „zły kod” może odpowiadać za skutki? I co z przepisami dotyczącymi cyberbezpieczeństwa, które mogą sprawić, że zwykła analiza systemu stanie się przestępstwem?
Podczas tej prelekcji omówię głośne przypadki zakazanych linii kodu – od DeCSS po narzędzia do jailbreakowania i reverse engineeringu, pokażę, jak różne kraje regulują publikację exploitów i narzędzi do pentestingu (USA, UE, Chiny), wyjaśnię, dlaczego AI może generować „nielegalny” kod i kto za to odpowiada, przeanalizuję znaczenie AI Actu, DSA czy Tyber Resillence Actu na życie (i zdrowie psychiczne) programistów oraz spróbuję znaleźć odpowiedź na pytanie: czy prawo powinno ingerować w to, co piszemy w edytorze kodu?