Przejdź do treści

Security review (przegląd bezpieczeństwa)

Definicja

Security review to uporządkowany przegląd systemu AI pod kątem ryzyk i zabezpieczeń: danych, narzędzi, promptów, logów i integracji.

Co to w zasadzie jest?

To kontrola: „czy to, co budujemy, nie zrobi nam krzywdy”. W AI warto sprawdzać:

  • czy nie wycieka PII,
  • czy narzędzia są ograniczone,
  • czy prompt injection jest uwzględniony,
  • czy logi są bezpieczne,
  • czy jest audit trail i monitoring.

Nie chodzi o „idealne bezpieczeństwo”, tylko o sensowne warstwy ochrony.

Praktyczne zastosowania (konkretne scenariusze)

Scenariusz 1: Checklista przed wdrożeniem

  • Cel: DLP, uprawnienia, testy ataków, logi.
  • Wejście: zmiana systemu albo nowa integracja.
  • Kroki: sprawdź ryzyka -> przetestuj zabezpieczenia -> opisz decyzję.
  • Rezultat: mniejsze ryzyko wdrożenia podatności.
  • Zabezpieczenie: checklista i właściciel ryzyka.

Scenariusz 2: Przegląd RAG

  • Cel: jakie źródła, kto je edytuje, jak walidujemy.
  • Wejście: zmiana systemu albo nowa integracja.
  • Kroki: sprawdź ryzyka -> przetestuj zabezpieczenia -> opisz decyzję.
  • Rezultat: mniejsze ryzyko wdrożenia podatności.
  • Zabezpieczenie: checklista i właściciel ryzyka.

Scenariusz 3: Przegląd agentów

  • Cel: ile narzędzi, jakie limity, gdzie akceptacja człowieka.
  • Wejście: zmiana systemu albo nowa integracja.
  • Kroki: sprawdź ryzyka -> przetestuj zabezpieczenia -> opisz decyzję.
  • Rezultat: mniejsze ryzyko wdrożenia podatności.
  • Zabezpieczenie: checklista i właściciel ryzyka.

Ryzyka i jak je ograniczać

Ryzyko 1: Review jest „na papierze”

  • Ryzyko: review jest „na papierze”.
  • Jak ograniczać: testy praktyczne, red teaming, scenariusze ataków.

Ryzyko 2: Review tylko raz, a system się zmienia

  • Ryzyko: review tylko raz, a system się zmienia.
  • Jak ograniczać: cykliczność (np. kwartalnie) i po dużych zmianach.

Ryzyko 3: Brak właściciela

  • Ryzyko: brak właściciela.
  • Jak ograniczać: przypisz rolę i proces.

Mapa powiązań

Diagram

flowchart LR
    A[Zasoby]
    B[Ryzyka]
    C[Zabezpieczenia]
    D[Testy]
    E[Decyzja]
    A --> B --> C --> D --> E

Diagram pokazuje uporządkowany przegląd ryzyk i zabezpieczeń przed wdrożeniem systemu.

Zadanie końcowe (po utworzeniu plików)

  1. Sprawdź, czy linki w „Mapa powiązań” prowadzą do istniejących plików w docs/pojecia/.
  2. Jeśli repo korzysta z ręcznej nawigacji w mkdocs.yml, dopisz te 10 haseł w sekcji „Hasła A–Z”.
  3. Zrób commit i push (najlepiej na branchu), a następnie PR do main.