To scenariusz ilustracyjny, nie historia klienta. Nie używa prawdziwej organizacji, prawdziwych osób ani deklarowanych wyników. Ma pokazać, jak executable Vendor Security pack Threada przeprowadziłby rutynowy security review od żądania do zapisanej decyzji. Każda surface opisana poniżej jest realną capability produktu; sytuacja jest wymyślona dla ilustracji.
Zespoły security spędzają zaskakująco dużą część tygodnia na review, które są głównie rutynowe, a czasem poważne. Nowe narzędzie SaaS potrzebuje sign-off. Vendor chce przetwarzać dane klientów. Ktoś prosi o wyjątek od stałej polityki. Większość z nich ma znany kształt; kilka wymaga prawdziwej kontroli. Trudną częścią rzadko jest analiza, lecz utrzymanie każdej review jako spójnej, ugruntowanej dowodami i zapisanej.
Tak ta praca działałaby przez Vendor Security pack Threada.
Kształt pracy
Vendor Security jest workspace packiem z archetypem case i trzema zdefiniowanymi intents:
- Vendor review: oceń nowego albo odnawiającego vendora względem polityki.
- Data processing review: oceń, czy vendor może przetwarzać konkretne dane.
- Security exception: obsłuż prośbę o odstępstwo od stałego control.
Reviewer nie musi decydować, który formularz otworzyć. Podaje intencję, a runtime zamienia ją w ustrukturyzowany WorkItem w kolejce security.
Walkthrough
Wyobraź sobie przychodzące żądanie: zespół chce przyjąć nowego vendora analytics, który otrzymywałby dane użycia produktu. W tym scenariuszu trafia ono przez skonfigurowany kanał intake i staje się WorkItem.
Intent. Reviewer, albo requester przez kanał, opisuje potrzebny wynik: “review this analytics vendor for data processing approval.” Runtime wyodrębnia vendora, kategorie danych w grze i początkowy risk flag, po czym zapisuje sprawę w kolejce Vendor Security.
Canvas. WorkItem otwiera się na adaptive canvas. Zamiast pustego formularza workspace składa pola potrzebne takiemu review: kategorie danych, lokalizację przetwarzania, subprocessors i właściwy policy profile. Tam, gdzie brakuje informacji, pyta dokładnie o nią, zamiast pokazywać niezróżnicowany questionnaire.
Evidence. Evidence drawer trzyma to, na czym assessment stoi: dokumentację przesłaną przez vendora, wcześniejsze review tego samego vendora i cytacje do obowiązującej polityki. Jeśli system nie może ugruntować konkretnej tezy, zapisuje fallback reason zamiast deklarować pewność, której nie ma. Reviewer widzi od razu, jak świeże jest każde źródło.
Controls. Tutaj review staje się decyzją. Zatwierdzenie data processing dla nowego vendora jest consequential action, więc przechodzi przez governowaną controls surface: proposal, potem jawna approval względem aktywnej policy version. Jeśli polityka wymaga drugiego zatwierdzającego dla tej kategorii danych, gate to egzekwuje. Nic nie wykonuje się po cichu.
Run log. Każdy krok narasta w run logu, intake, prośby o brakujące informacje, konsultowane dowody, approval i kto jej udzielił oraz finalny zapisany wynik. Ponieważ AI participant actions pojawiają się jako osobne actor events, log jasno pokazuje, które kroki obsłużył system, a które zdecydował człowiek.
Co zostaje zespołowi
Na końcu zespół security ma trzy rzeczy, które inaczej musiałby składać ręcznie:
- Spójny review. Ta sama intencja zawsze tworzy ten sam kształt workspace, więc review nie dryfują w rygorze między tygodniem zajętym i spokojnym.
- Ugruntowaną decyzję. Approval jest powiązana z konkretnymi dowodami i nazwaną policy version, a nie z pamięcią reviewera.
- Receipt. Cały review jest w zapisie, obronny dla auditora i czytelny dla kolejnego reviewera, który podejmie podobny case.
Rutynowe review idą szybko, bo workspace robi składanie. Poważne dostają pełną ludzką kontrolę, bo controls surface tego wymaga. Ten podział, automatyzować rutynę i kierować naprawdę trudne przypadki do ludzi, jest całym sensem.
Dlaczego publikujemy to jako scenariusz
Moglibyśmy ubrać to w historię sukcesu klienta z imponującym procentem. Nie zrobimy tego. Dopóki prawdziwy klient, który wyraził zgodę, nie udostępni prawdziwych wyników, wszystko, co tu drukujemy, jest ilustracją, i wolimy oznaczyć to uczciwie, niż sugerować dowód, którego nie mamy.
Realny jest pack. Vendor Security to instalowalny workflow na tym samym governowanym runtime co każdy inny pack Threada, z intents i pięcioma surfaces opisanymi wyżej. Jeśli chcesz zobaczyć wersję executable zamiast walkthrough, zacznij od pack catalog.