K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / orchestrator / pilot-ops

Pilot Ops — szablony 5-day i 30-day pilota MVP

Operacyjny szkielet prowadzenia pilota ipIII: dwa gotowe szablony (5-day krótki proof-of-value oraz 30-day pilot rozszerzony), jawne kryteria sukcesu, timeline faza po fazie i struktura raportu końcowego. To wsparcie decyzji (decision support) — nie zastępuje przeglądu prawnego ani wewnętrznych procedur partnera. Doktryna: claim ≤ proof; elementy jeszcze nie zbudowane oznaczone jako ROADMAP.

Po co ta strona. Pilot to kontrolowany sprawdzian wartości (proof-of-value) na danych partnera lub danych syntetycznych — nie wdrożenie produkcyjne. Ta strona daje partnerowi i zespołowi K0NSULT wspólny szkielet: kto co robi, którego dnia, z jakim outputem i jak mierzymy sukces. Wszelkie działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych Rules of Engagement (RoE), na danych syntetycznych lub uzgodnionym zakresie.
Dwa szablony pilota. Jawne kryteria. Jeden raport końcowy.

Pilot ipIII sprawdza jedną tezę: czy warstwa evidence (import → incydent → evidence-package → retest → close) skraca czas od findingu do dowodliwego raportu u partnera. Poniżej szkielet operacyjny — 5-day dla szybkiego proof-of-value i 30-day dla pełniejszej oceny na realnych procesach zespołu. To MVP procesu, nie obietnica wyniku: mierzymy dokładnie to, co pokażemy logiem i endpointem.

OŚ PILOTA: intake + RoEonboardingprzebieg evidenceprzeglądraport końcowy + decyzja

Wybór szablonu

5-day pilot proof-of-value

Cel: szybko pokazać jeden pełny przebieg evidence na wybranym zestawie findings.

Zakres: 1 źródło importu (Burp/ZAP/Nessus/CSV), 1 incydent modelowy, 1 evidence-package.

Dane: syntetyczne lub anonimizowany fragment realnych findings za zgodą partnera.

Output: mini-raport końcowy + rekomendacja go/no-go dla 30-day.

30-day pilot pilot rozszerzony

Cel: ocena na powtarzalnym procesie zespołu (kilka cykli import→close).

Zakres: wiele źródeł, dedup, workflow remediacji, retest, raporty zbiorcze.

Dane: uzgodniony zakres realnych findings w granicach RoE + dane syntetyczne do testów.

Output: raport końcowy z metrykami + lista znanych ograniczeń dotykających partnera.

Timeline — 5-day pilot

Szablon skrócony. Kolumna Output = artefakt do odbioru danego dnia. Status procesu: MVP (szkielet, dopinany per partner).

FazaDzieńDziałanieOutput
IntakeD1Wypełnienie pilot-intake, ustalenie zakresu i podpisanie RoE. Wybór źródła findings.Uzgodniony zakres + podpisany RoE
OnboardingD2Dostęp do środowiska pilota, seed danych syntetycznych, walidacja importu z formatu partnera.Działający import 1 źródła
PrzebiegD3Import findings → utworzenie incydentu → złożenie evidence-package (manifest + sha256 + chain-of-custody).1 evidence-package (JSON)
RetestD4Domknięcie incydentu z dowodem (close-with-evidence), weryfikacja audit-logu.Incydent zamknięty + audit-log
RaportD5Mini-raport końcowy, omówienie wyników, rekomendacja go/no-go dla 30-day.Raport końcowy 5-day + decyzja

Timeline — 30-day pilot

Szablon rozszerzony, grupowany tygodniami. Zakłada powtarzalny przebieg i pomiar na kilku cyklach.

FazaDzień / tydzieńDziałanieOutput
Intake + RoED1–D3Pilot-intake, zakres, RoE, ustalenie metryk sukcesu z partnerem, plan danych (syntetyczne + uzgodniony realny zakres).Karta pilota + metryki bazowe
OnboardingTydzień 1Konfiguracja źródeł importu, dedup, mapowanie workflow remediacji do procesu zespołu.Środowisko pilota gotowe
Przebieg 1Tydzień 2Pierwsze cykle import→incydent→evidence-package→retest→close na realnym zakresie.Pierwsze evidence-packages + metryki cyklu
Przebieg 2Tydzień 3Kolejne cykle, raporty zbiorcze, test integracji z narzędziami partnera zależnie od zakresu.Raport zbiorczy + lista integracji
PrzeglądTydzień 4 (D22–D27)Zestawienie metryk vs kryteria sukcesu, spis napotkanych ograniczeń, przegląd prawny draftów jeśli dotyczy.Zestawienie metryk + rejestr ograniczeń
Raport końcowyD28–D30Raport końcowy pilota, rekomendacja (kontynuacja / zamknięcie / zmiana zakresu), zebranie feedbacku.Raport końcowy 30-day + decyzja

Kryteria sukcesu

Ustalane z partnerem podczas intake i mierzone dowodliwie (log, endpoint, artefakt). Poniżej domyślny zestaw — dostosowywany per pilot.

Dowodliwość rdzeń

Każdy zamknięty incydent ma evidence-package z manifestem, sha256 i chain-of-custody, weryfikowalny w audit-logu.

Miara: % incydentów z kompletnym pakietem = cel 100% w zakresie pilota.

Czas cyklu wydajność

Czas od importu findingu do dowodliwego raportu. Punkt odniesienia = obecny proces partnera zmierzony w intake.

Miara: skrócenie względem baseline (kierunek, nie obietnica konkretnej liczby).

Powtarzalność 30-day

Proces działa na kilku cyklach bez ręcznego łatania; dedup i workflow remediacji obsługują realny wolumen zakresu.

Miara: liczba cykli zakończonych bez interwencji poza procesem.

Zaufanie zespołu jakościowa

Feedback zespołu partnera: czy raporty są czytelne, czy dowody wytrzymują wewnętrzny przegląd.

Miara: ustrukturyzowany feedback przez /feedback.

Sukces ≠ „system klasy bankowej". Pozytywny pilot potwierdza wartość warstwy evidence w zakresie MVP — nie oznacza, że domknięte są elementy z rejestru znanych ograniczeń (OIDC/JWKS, mTLS, PAdES/TSA, multi-tenant). Te pozostają ROADMAP i wchodzą do raportu końcowego jako świadome granice.

Szkielet raportu końcowego pilota ROADMAP — generator

Poniżej struktura dokumentu. Ręczne wypełnienie jest dostępne dziś jako MVP. Automatyczny generator raportu z metryk to ROADMAP — nie deklarujemy go jako działający.

1. Streszczenie decyzyjne — cel pilota, zakres, jedno zdanie rekomendacji (kontynuacja / zmiana zakresu / zamknięcie).
2. Zakres i RoE — źródła findings, rodzaj danych (syntetyczne / uzgodniony realny zakres), granice testu.
3. Przebieg — co zostało wykonane dzień po dniu / tydzień po tygodniu, z linkami do artefaktów (evidence-packages, audit-log).
4. Metryki vs kryteria sukcesu — tabela: kryterium, baseline, wynik, dowód (log/endpoint/artefakt).
5. Napotkane ograniczenia — które pozycje z known-limitations dotknęły partnera i jak.
6. Rekomendacja i następne kroki — go/no-go, proponowany zakres kolejnego etapu, otwarte pytania.
7. Załączniki — evidence-packages, zrzuty audit-logu, feedback zespołu.

Rozdział ról

RolaStronaOdpowiedzialność
Sponsor pilotaPartnerZakres, dostęp do danych, decyzja go/no-go.
Zespół operacyjnyPartnerUruchamia cykle na własnym procesie, dostarcza feedback.
Lead pilotaK0NSULTOnboarding, prowadzenie timeline, raport końcowy.
Przegląd prawnyK0NSULT + partnerWeryfikacja draftów do organów przed wysyłką (decision support, nie porada prawna).

Start pilota

1 · Zgłoś zakres

Wypełnij formularz pilota — ustalimy szablon (5-day / 30-day), źródła i dane.

→ /pilot-intake

2 · Poznaj model współpracy

Rola partnera, granice RoE i sposób odbioru artefaktów.

→ /partner

3 · Zostaw feedback

Ustrukturyzowany feedback z przebiegu zasila kryteria sukcesu i raport końcowy.

→ /feedback

Granica etyczna i prawna. Pilot prowadzimy defensywnie (GRC / blue). Bez nieautoryzowanych skanów, bez exploitacji, bez hack-back. Elementy AI-security / arena wyłącznie na danych syntetycznych i po RoE. Legal Trigger Engine i wszelkie mapowania obowiązków to wsparcie decyzji, nie porada prawna — drafty do organów przechodzą przegląd prawny przed wysyłką.

Powiązane: co ipIII jeszcze NIE robi → /known-limitations · macierz statusów wszystkich elementów → /status-matrix · zgłoszenie zakresu pilota → /pilot-intake.