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ń

• Red teaming → testy ofensywne w ramach review.
• DLP / PII → ochrona danych.
• Prompt injection / Prompt guard → ochrona promptów.
• Audit trail / Observability → widoczność i odpowiedzialność.
• Mini-przepływ: Zasoby → ryzyka → zabezpieczenia → testy → decyzja

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.