Zasady
Odpowiedzialność AI to proces dowodowy.
Traktujemy AI jak element systemu produkcyjnego: model + dane + integracja + człowiek + monitoring. Jeśli nie da się zbudować jasnych kryteriów poprawności i kontroli, to w danym miejscu AI po prostu nie ma sensu — nawet jeśli „działa” w demo.
W praktyce oznacza to, że zaczynamy od ryzyka i kosztu błędu, a dopiero potem wybieramy technologię. Projektujemy weryfikację (kto, kiedy, na jakiej podstawie), zasady użycia danych oraz sposób mierzenia efektu w procesie.
Bezpieczeństwo danych
Klasyfikacja danych, minimalizacja, kontrola dostępu, anonimizacja/pseudonimizacja tam, gdzie ma to sens.
Weryfikacja i testy
Protokół ewaluacji, testy regresyjne, analiza błędów i scenariusze brzegowe — nie tylko „średnia jakość”.
Nadzór człowieka
Human-in-the-loop/on-the-loop: jasne uprawnienia, eskalacje, możliwość nadpisania i zatrzymania działania.
Ślad audytowy
Logi, wersjonowanie (dane/model/prompt), rejestr ryzyk i protokoły testów — łatwe do odtworzenia po czasie.
Odporność i bezpieczeństwo
Model threat: prompt injection, wycieki danych, nadużycia narzędzi. Guardrails, walidacja i least‑privilege.
Mierzalny efekt
Mierzymy wynik w procesie (czas, błędy, koszty, SLA), a nie „jakość AI” w próżni.
AI Act
AI Act: zgodność zaczyna się od klasyfikacji ryzyka.
AI Act (rozporządzenie UE o sztucznej inteligencji) porządkuje świat AI podejściem opartym o ryzyko: inne obowiązki ma system o minimalnym wpływie, a inne rozwiązanie używane w obszarach wysokiego ryzyka. Dodatkowo znaczenie ma rola organizacji (np. dostawca vs wdrażający).
Ważne
To opis naszej metodyki technicznej i „compliance‑readiness”, nie porada prawna. W projektach o podwyższonym ryzyku pracujemy równolegle z prawnikiem/inspektorem ochrony danych po stronie klienta.
Poziom ryzyka
Niedopuszczalne (zakazane)
Praktyki, których nie wolno wdrażać (np. manipulacja, wykorzystanie wrażliwości, niektóre zastosowania biometrii).
Przykłady
- „Ukryte” wpływanie na decyzje użytkownika
- Profilowanie/ocena społeczna
- Automatyczne „polowanie” na podatność
Jak pracujemy
- Odrzucamy zastosowanie na starcie.
- Proponujemy alternatywę bez AI lub z inną architekturą.
Poziom ryzyka
Wysokie ryzyko
Systemy w obszarach o dużym wpływie na ludzi (lista domen w AI Act) — wymagają rygorystycznych procesów, dokumentacji i nadzoru.
Przykłady
- Rekrutacja i ocena pracowników
- Ocena zdolności kredytowej
- Edukacja / egzaminy
- Wybrane zastosowania w zdrowiu
Jak pracujemy
- Ustalamy rolę (dostawca vs wdrażający) i właściciela ryzyka.
- Projektujemy weryfikację, nadzór człowieka i ślad audytowy.
- Budujemy plan testów, monitoringu i obsługi incydentów.
Poziom ryzyka
Ograniczone ryzyko (transparentność)
Zastosowania wymagające jasnej informacji dla użytkownika (np. chatboty, generowanie treści, interakcja z człowiekiem).
Przykłady
- Asystent na czacie
- Generowanie podsumowań i odpowiedzi
- Tworzenie treści marketingowych
Jak pracujemy
- Dodajemy oznaczenia i instrukcje użycia (kiedy AI, kiedy człowiek).
- Wymuszamy weryfikację treści przy istotnych decyzjach.
- Minimalizujemy ryzyko halucynacji przez RAG/źródła i walidację.
Poziom ryzyka
Minimalne ryzyko
Zastosowania o niskim wpływie — bez dodatkowych obowiązków sektorowych z AI Act, ale nadal z dobrą praktyką inżynierską.
Przykłady
- Porządkowanie danych
- Klasyfikacja ticketów
- Wyszukiwanie podobnych spraw
Jak pracujemy
- Stosujemy testy regresyjne i monitoring KPI.
- Dbamy o prywatność danych i kontrolę dostępu.
Ramy
Na czym opieramy metodykę (oprócz doświadczenia)
AI Act jest punktem odniesienia regulacyjnym, ale w praktyce potrzebujesz też inżynierskich ram pracy: zarządzania ryzykiem, bezpieczeństwa i cyklu życia.
- AI Act (UE 2024/1689): klasy ryzyka, transparentność, obowiązki i dokumentacja.
- ISO/IEC 23894: zarządzanie ryzykiem AI (identyfikacja → ocena → mitigacja → monitoring).
- NIST AI RMF 1.0: Govern/Map/Measure/Manage jako „szkielet” oceny i kontroli.
- ISO/IEC 42001: system zarządzania AI (role, procesy, ciągłe doskonalenie).
- OWASP LLM Top 10: typowe podatności aplikacji opartych o LLM i kontrola integracji.
- ISO/IEC 27001: bezpieczeństwo informacji (gdy AI dotyka danych i procesów krytycznych).
Dla wielu zastosowań „biznesowych” najważniejszy jest praktyczny efekt: mieć proces ryzyka, udowodnioną jakość oraz możliwość odtworzenia decyzji. To się broni zarówno inżyniersko, jak i regulacyjnie.
Tekst rozporządzenia: EUR‑Lex.
Metodyka
Od hipotezy do produkcji: inżynieria, statystyka i kontrola.
Wdrożenie AI traktujemy jak eksperyment naukowy z odpowiedzialnością produkcyjną: jest hipoteza, jest protokół pomiaru, są kryteria akceptacji i jest system kontroli po uruchomieniu.
1. Definicja problemu
Cel, granice, koszt błędu
- Czy AI doradza, czy decyduje? (zawsze preferujemy tryb rekomendacji).
- Jak wygląda „błąd” i jaki ma koszt biznesowy / prawny / reputacyjny?
- Jakie są warunki brzegowe: dane wejściowe, kontekst, wyjątki, eskalacja do człowieka.
2. Klasyfikacja ryzyka
AI Act + ryzyka techniczne
- Mapujemy rolę organizacji (dostawca / wdrażający) i klasę ryzyka wg AI Act.
- Robimy analizę ryzyka: bezpieczeństwo, prywatność, stronniczość, nadużycia, drift.
- Ustalamy kryteria akceptacji i „stop‑loss” (kiedy wyłączamy funkcję).
3. Dane i reprezentatywność
Jakość, bias, minimalizacja
- Opisujemy źródła danych, definicje pól i reguły czyszczenia.
- Testujemy przesunięcie rozkładów (OOD/drift) i spójność etykiet.
- Rozdzielamy PII, ustawiamy retencję i ograniczamy dostęp (need‑to‑know).
4. Model i integracja
Dobór architektury + guardrails
- Zaczynamy od baseline’u i porównujemy modele na stałym protokole testowym.
- W aplikacjach LLM budujemy „warstwę kontroli”: źródła, walidacja, limity narzędzi.
- Projektujemy human‑override i procedury eskalacji.
5. Ewaluacja przed wdrożeniem
Testy, odporność, red‑team
- Walidacja metryk + analiza błędów (nie tylko „średnia jakość”).
- Testy przeciążeniowe, scenariusze brzegowe, testy bezpieczeństwa (prompt‑injection).
- Raport: co działa, czego nie umiemy obiecać, jakie są ryzyka rezydualne.
6. Monitoring i utrzymanie
Drift, incydenty, zmiany
- Monitorujemy KPI procesu + miary driftu danych i jakości (np. PSI, błędy krytyczne).
- Reagujemy na incydenty, utrzymujemy logi i wersjonowanie (model/dane/prompt).
- Okresowo powtarzamy testy, zwłaszcza po zmianach danych lub procesu.
Model myślenia
Ryzyko w systemie AI traktujemy jak oczekiwaną szkodę: E[szkoda] ≈ P(zdarzenie) × skutek. To wymusza rozmowę o kosztach błędów, a nie o „magii modelu”.
Walidacja
Metryki, protokoły testów i granice niepewności.
„Dobre AI” nie istnieje bez definicji jakości. Dobór metryk zależy od zadania, kosztu błędu i asymetrii ryzyka. Tam, gdzie konsekwencje są poważne, dokładamy warstwy: kalibrację, testy OOD i analizę stabilności.
Rozróżniamy też niepewność aleatoryczną (szum danych, losowość świata) i epistemiczną (brak wiedzy modelu, „nie znam tego”). Dla tej drugiej projektujemy zachowanie systemu: fallback, eskalację do człowieka i wyłączanie automatycznych akcji przy niskiej wiarygodności.
Modele predykcyjne
- Klasyfikacja: precision/recall, F1, AUROC/AUPRC (zależnie od niezbalansowania).
- Regresja: MAE/RMSE + analiza błędów krytycznych (np. percentyle).
- Ranking: NDCG/MRR/MAP (gdy liczy się kolejność).
- Kalibracja: czy „pewność” modelu znaczy to, co sugeruje (ECE/Brier).
Generatywne i LLM
- RAG: „groundedness”/zgodność ze źródłami + trafność wyszukiwania kontekstu.
- Faktyczność: oceny human + testy na zestawach referencyjnych (golden set).
- Bezpieczeństwo: toksyczność, ujawnianie danych, jailbreak rate w scenariuszach red‑team.
- Użyteczność: czas obsługi, spadek błędów, odsetek eskalacji do człowieka.
Protokół
Jak testujemy, żeby wynik był wiarygodny
Kluczowe jest nie tylko „ile procent”, ale czy wynik utrzyma się po zmianie danych, sezonowości i po wejściu użytkowników.
- Podział danych zgodny z czasem/procesem (out‑of‑time), a nie losowy, jeśli to ma znaczenie.
- Zestawy „golden”: przypadki krytyczne + scenariusze brzegowe (regresja).
- Testy stabilności i driftu (np. PSI/KL/Wasserstein) na danych wejściowych.
- Analiza błędów: grupy, źródła, reguły eskalacji i poprawki procesu.
- Walidacja „end‑to‑end”: czy wynik AI rzeczywiście poprawia KPI procesu.
Bezpieczeństwo
Aplikacje AI to nie tylko model. To wektor ataku.
W projektach z LLM najczęstsze ryzyka wynikają z integracji: prompt injection, wycieki danych, nadużycie narzędzi (tool abuse) i „halucynacje” prowadzące do działań w systemach zewnętrznych. Dlatego projektujemy threat model i kontrolę na poziomie aplikacji.
Typowe zagrożenia
- Prompt injection i data exfiltration (wyciąganie sekretów / danych).
- Nadużycie narzędzi: model wykonuje zbyt szerokie akcje w CRM/ERP/sklepie.
- Model/SDK supply‑chain: zmiana zachowania po aktualizacji dostawcy.
- Halucynacje w trybie „autopilot” (działanie bez potwierdzenia).
Warstwa kontroli
- Least‑privilege dla narzędzi + allow‑list akcji (zamiast „rób co chcesz”).
- Walidacja wejścia/wyjścia: schematy, reguły, blokady PII i sekretnych danych.
- Tryb potwierdzeń: człowiek akceptuje krytyczne kroki (human‑in‑the‑loop).
- Logowanie i detekcja nadużyć + rate limiting i izolacja środowisk.
Dane
Dane są częścią modelu. Bez governance nie ma jakości.
AI Act mocno akcentuje jakość danych (zwłaszcza w systemach o wyższym ryzyku), a w praktyce to właśnie dane najczęściej psują wyniki: brak reprezentatywności, zmiany w procesie, sezonowość, błędne etykiety. Dlatego zaczynamy od data governance i minimalizacji.
Minimalizacja i prywatność
- Dane wrażliwe i tajemnice firmy nie trafiają do promptów „z przyzwyczajenia”.
- Oddzielamy identyfikatory od treści (pseudonimizacja) i ustawiamy retencję.
- W razie potrzeby stosujemy redakcję PII, maskowanie, lokalne przetwarzanie.
- Kontrola dostępu i rejestr: kto, kiedy i po co widział dane w systemie.
Jakość i stronniczość
- Data dictionary: definicje pól i „prawda” biznesowa (żeby etykiety były spójne).
- Testy rozkładów i driftu: kiedy model dostaje inny świat niż ten, na którym był testowany.
- Analiza błędów w grupach + działania procesowe (czasem nie trzeba zmieniać modelu).
- Zasady aktualizacji: kiedy wolno retrain, kiedy wymagamy ponownej walidacji.
Dokumentacja
Techniczna „teczka” systemu: odtwarzalność, audyt i utrzymanie.
W praktyce zgodność (i spokój operacyjny) oznaczają artefakty: co to za system, na jakich danych działa, jak był testowany, jakie ma ograniczenia oraz jak reagujemy na incydenty. To szczególnie ważne, gdy wchodzimy w obszary podlegające AI Act.
Pakiet dokumentów
- System Card / opis zastosowania + granice i tryby awaryjne.
- Model Card (jeśli dotyczy): wersje, metryki, znane ograniczenia.
- Data Sheet: źródła danych, jakość, retencja, dostępy.
- Rejestr ryzyk + decyzje mitigacyjne + ryzyka rezydualne.
- Raport z ewaluacji (zestawy testowe, scenariusze, wyniki).
- Instrukcje dla użytkownika i zasady human oversight.
Ślad audytowy
- Wersjonowanie: model, prompt, narzędzia, konfiguracja i dane referencyjne.
- Logi wejść/wyjść (z redakcją PII) + identyfikacja kontekstu (RAG).
- Reprodukowalność testów: możliwość odtworzenia wyniku po miesiącach.
- Rejestr zmian + „gating”: co wymaga ponownej walidacji przed release.
Monitoring
Produkcja zmienia wszystko: drift, incydenty i „post‑market”.
Nawet świetnie przetestowany model może się „zepsuć”, gdy zmieni się proces, asortyment, zachowanie klientów albo integracje. Dlatego monitoring traktujemy jak część rozwiązania, a nie dodatek.
Co monitorujemy
- KPI procesu (czas obsługi, błędy, SLA, odsetek eskalacji do człowieka).
- Miary driftu danych (np. PSI/KL/Wasserstein) i zmiany jakości na golden setach.
- Sygnały bezpieczeństwa: próby prompt injection, podejrzane wzorce, nadużycia narzędzi.
- Incydenty i near‑miss: kiedy „prawie” doszło do błędu — to najlepsze źródło ulepszeń.
Granice
Kiedy AI „nie przechodzi” i co wtedy robimy.
Odpowiedzialność oznacza też umiejętność powiedzenia „nie”. Jeśli ryzyko jest nieproporcjonalne do zysku, brakuje danych albo nie da się zaprojektować kontroli, proponujemy rozwiązanie bez AI lub z inną techniką.
Typowe „no‑go”
- Brak właściciela ryzyka i procesu nadzoru (nikt nie podejmuje decyzji końcowej).
- Wymóg „autopilota” w krytycznych działaniach bez możliwości potwierdzeń.
- Dane są zbyt wrażliwe lub nie mamy podstawy/zgody na ich użycie.
- Brak mierzalnego KPI albo brak możliwości wiarygodnego testu na produkcji.
Co proponujemy zamiast
- Reguły i automatyzacje (deterministyczne), jeśli da się je jasno opisać.
- Lepsze dane: walidacje, słowniki, workflow, porządek w źródłach.
- Tryb „copilot”: AI podpowiada, człowiek decyduje (bez automatycznych akcji).
- Pilotaż z ograniczonym zakresem i mocnym monitoringiem (bez ryzyka skali).