Finalizacja złożonej sprzedaży B2B: jak sprawdzić gotowość do zobowiązania bez fałszywego poczucia postępu

Finalizacja złożonej sprzedaży jest kontrolowanym okresem, w którym wiele funkcji klienta i dostawcy doprowadza jeden dokładny obiekt do stanu możliwego do autoryzacji i wykonania. Może obejmować uzasadnienie biznesowe, budżet, zakupy, pakiet handlowy, przegląd prawny, bezpieczeństwo, prywatność, architekturę techniczną, zasoby wykonawcze, mobilizację, dane i kryteria odbioru.

Te strumienie nie kończą się w jednej kolejności. Część może być ukończona, część warunkowa, część otwarta, a część niewymagana dla danego typu zobowiązania. Wytyczne zarządzania projektami podkreślają znaczenie ról, zależności, monitorowania i kontroli zmian, a praktyka oceny harmonogramu — logiczne powiązania oraz aktualizację wpływu zmian.⁸⁹ H06 przenosi te zasady na końcową fazę sprzedaży, lecz nie twierdzi, że harmonogram przewiduje wynik komercyjny.

Finalizacja nie jest:

• biblioteką technik domykania;
• sposobem obchodzenia działu prawnego, bezpieczeństwa lub zakupów;
• liczeniem aktywności;
• systemem oceny „siły sponsora”;
• algorytmem intencji;
• automatycznym closed won;
• formalnym zatwierdzeniem za funkcję specjalistyczną;
• obowiązkiem doprowadzenia każdego procesu do podpisu.

Gdy nierozpoznana pozostaje obawa lub warunek, należy wrócić do diagnozy źródła obawy albo H03. Jeżeli strony nadal negocjują pakiet, właściwy jest H04. Gdy otwarty pozostaje proces, kanał albo award, potrzebny jest H05.

Rekord H06 nie powinien obejmować „całej transakcji”. Musi dotyczyć jednego dokładnego zobowiązania, jednej granicy zakresu i jednej wersji.

Prawidłowe przykłady:

zatwierdzenie płatnego pilota w dwóch zakładach
podpisanie umowy ramowej dla jednej spółki
wydanie purchase order na pierwszą partię urządzeń
autoryzacja budżetu wdrożenia na rok 2027
zgoda na przetwarzanie określonej kategorii danych
zatwierdzenie produkcyjnego uruchomienia w jednym kraju

Nieprawidłowe:

klient jest gotowy
transakcja jest prawie zamknięta
mamy zgodę organizacji
wdrożenie jest uzgodnione
dział zakupów nas wybrał

Minimalny rekord:

commit_type: "CMT-X"
exact_object: ""
in_scope: []
out_of_scope: []
version: ""
parties: []
decision_owner: ""
required_approvers: []
authorized_signatory: ""
veto_roles: []
decision_date_source: ""
effective_condition: ""
expiry_or_reopening_triggers: []

Precyzja zapobiega dziedziczeniu zgody z mniejszego zobowiązania do większego. Zgoda na discovery nie jest zgodą na pilot. Zgoda na pilot nie jest zgodą na wdrożenie produkcyjne. Budżet na licencję nie obejmuje automatycznie integracji.

Wykonanie testu nie oznacza spełnienia kryterium. Weryfikacja i walidacja odpowiadają na różne pytania: zgodność z wymaganiem oraz przydatność w zamierzonym kontekście użycia.¹⁰¹¹ System jakości powinien kontrolować wymagania, informacje, ocenę i zmiany, lecz samo odwołanie do normy nie zastępuje zatwierdzenia organizacji.¹²

Wybór lub award należy oddzielić od umowy i wdrożenia. Open Contracting Data Standard modeluje tender, award, contract oraz implementation jako odrębne etapy.¹³ Jurysdykcyjne przepisy zakupowe również rozdzielają award, finansowanie, typ umowy i zmianę, lecz nie mogą być automatycznie przenoszone na inny reżim prawny.¹⁴

RGK-1 — dokładne zobowiązanie i data decyzji

Zapisz typ, dokładne brzmienie, zakres, wersję, strony, datę, źródło daty, warunek wejścia w życie, konsekwencję opóźnienia, wygaśnięcie i wyzwalacz ponownego otwarcia. Data pochodząca wyłącznie z wewnętrznej prognozy sprzedawcy jest hipotezą.

RGK-2 — role, mandat i osoby zatwierdzające

Rozdziel sponsora, właściciela decyzji, właściciela budżetu, właściciela zakupów, funkcjonalne osoby zatwierdzające, osobę podpisującą, właściciela wdrożenia, właściciela akceptacji i veto. Tytuł stanowiska nie dowodzi mandatu.

RGK-3 — ukończone i otwarte zależności

Każda materialna zależność potrzebuje typu, właściciela, osoby zatwierdzającej, kryterium, stanu CPL, dowodu, niewiadomych, następnego testu, wygaśnięcia i wyzwalacza ponownego otwarcia. Niewiadoma nie może zostać zamieniona w „status w toku” bez podstawy.

RGK-4 — zatwierdzenia i dowód wykonania

Zatwierdzenie musi wskazywać rolę, podstawę mandatu, zakres, wersję, datę, warunki, wyjątki, wygaśnięcie i wycofanie. Notatka, e-mail i status systemowy mogą być dowodem komunikacji, ale nie są automatycznie formalnym zatwierdzeniem. Dowód musi pasować do twierdzenia i zakresu.⁷

RGK-5 — gotowość komercyjna i kontraktowa

Rozdziel ofertę, pakiet gotowy do przeglądu, spójność komercyjną, zatwierdzenie prawne, zatwierdzenie kontraktu, podpis, umowę obowiązującą i purchase order. H06 zachowuje granicę H04: COMMERCIAL_ALIGNMENT_NOT_CONTRACT_COMMIT.

RGK-6 — gotowość w obszarze bezpieczeństwa, prywatności, techniki i zgodności

Każda domena ma własne wymagania, kryteria, ustalenia, wyjątki, działania naprawcze, ryzyko szczątkowe i osobę zatwierdzającą. Modele bezpieczeństwa wspierają ład i zarządzanie ryzykiem, ale certyfikat lub użycie modelu nie stanowią zatwierdzenia konkretnego rozwiązania.¹⁵¹⁶¹⁷

Prywatność wymaga celu, ról, zakresu danych, podstawy, środków, transferów, retencji i praw osób. Uwzględnianie ochrony danych w fazie projektowania działa przez cały cykl życia.¹⁸¹⁹²⁰

Dla AI potrzebne są rejestr zastosowań, zamierzone użycie, pochodzenie danych, nadzór człowieka, monitorowanie, obsługa incydentów i kontrola zmian. Obowiązki oraz daty stosowania AI Act trzeba sprawdzać na dzień wdrożenia.²¹²² NIST AI RMF, profil GenAI i ISO/IEC 42001 wspierają zarządzanie ryzykiem, ale nie tworzą autonomicznego prawa do zobowiązania.²³²⁴²⁵

RGK-7 — dostawa, wdrożenie, zasoby wykonawcze i akceptacja

Sprawdź obiecane i zarezerwowane zasoby wykonawcze, ludzi, środowiska, komponenty, dane, migrację, szkolenie, wsparcie, wycofanie zmiany, kryteria akceptacji i mandat do uruchomienia produkcyjnego. Zdolność operacyjna i ciągłość wymagają aktualnego dowodu.²⁶²⁷

RGK-8 — wspólne działania, właściciele i dowody

Plan jest wspólny dopiero po potwierdzeniu przez obie strony celu, właścicieli, zależności, dat, kryteriów ukończenia i prawa do zmiany. Cisza nie jest akceptacją.

RGK-9 — jakościowy wynik

Dozwolone są: doprecyzowanie, korekta, odroczenie, częściowe zobowiązanie, autoryzowane zobowiązanie, status quo, brak decyzji, niedopasowanie, odejście od szansy, wstrzymanie, zatrzymanie i wycofanie. Pól RGK nie sumuje się do wyniku punktowego.

Taksonomia DEP-0–DEP-15 — rodzaj zależności

Taksonomia CPL-0–CPL-11 — stan wykonania

Taksonomia APR-0–APR-14 — rodzaj zatwierdzenia

Taksonomia RDY-0–RDY-12 — domeny gotowości

Taksonomia EVD-0–EVD-13 — dowód wykonania

Taksonomia MAP-0–MAP-11 — status planu decyzji

Taksonomia FS-0–FS-11 — status końcowy i granica prognozy

Największym źródłem fałszywego poczucia postępu jest brak odpowiedzi na pytanie: co dokładnie ma zostać zatwierdzone?

Dobrze zdefiniowana ścieżka decyzji obejmuje:

1. dokładne zobowiązanie;
2. przygotowanie rekomendacji;
3. wymagane przeglądy;
4. osoby zatwierdzające;
5. osoba podpisująca;
6. warunki wejścia w życie.

Przykład:

Zobowiązanie:
CMT-2 — płatny pilot

Zakres:
jeden zakład, 90 dni, dwie linie

Właściciel biznesowy:
dyrektor produkcji

Osoba zatwierdzająca budżet:
CFO spółki lokalnej

Osoba zatwierdzająca bezpieczeństwo:
uprawniona rola dla środowiska testowego

Osoba podpisująca:
osoba zgodna z zasadami reprezentacji

Warunek wejścia:
formularz zamówienia + DPA + dostęp do środowiska testowego

Mandat należy ponownie sprawdzić po zmianie wartości, zakresu, jurysdykcji, spółki, terminu, odpowiedzialności, rodzaju danych albo modelu wdrożenia.

Słaby rekord:

Dział prawny — w toku
Bezpieczeństwo — prawie gotowe
Zakupy — formalność
Wdrożenie — po podpisie

Kontrolowany rekord:

dependency: "DEP-8 security"
owner: "security architecture lead"
approver: "risk acceptance authority"
criterion: "zamknięte findings high; zaakceptowane exceptions medium"
completion: "CPL-7 CHANGES_REQUIRED"
evidence: "security assessment v2.1"
next_test: "re-review po remediacji"
expiry: "90 dni albo materialna zmiana architektury"

Dowód ma być wystarczający dla dokładnego twierdzenia:

• log dowodzi wykonania czynności;
• raport testu dowodzi wyniku testu;
• zapis zatwierdzenia dowodzi zatwierdzenia;
• podpisany dokument dowodzi zawarcia określonego dokumentu;
• zapis akceptacji dowodzi odbioru w określonym zakresie.

Zarządzanie ryzykiem wymaga identyfikacji, oceny, postępowania z ryzykiem, właściciela i monitoringu, a nie ukrycia ryzyka w kolorze albo jednym wyniku punktowym.²⁶

Dowód należy otworzyć ponownie po zmianie zakresu, wersji, prawa, architektury, właściciela, zasobów wykonawczych, warunków albo po wycofaniu źródła.

Finalizacja handlowa obejmuje odrębne stany:

oferta przygotowana
oferta wysłana
pakiet handlowy uzgodniony
treść umowy uzgodniona
umowa zatwierdzona
umowa podpisana i obowiązująca
PO lub autoryzacja realizacji

Zakupy mogą mieć osobno:

kwalifikacja
przesłanie
ocena
wybór
award
przegląd lub okres zawieszenia
umowa
wdrożenie

Dlatego „wygraliśmy przetarg” nie określa jeszcze, czy istnieje finalny kontrakt, finansowanie, zakres, PO, zasoby wykonawcze i zgoda na start.

H05 ustanawia SELECTION_OR_AWARD_NOT_CONTRACT_COMMIT. H04 ustanawia COMMERCIAL_ALIGNMENT_NOT_CONTRACT_COMMIT. H06 dodaje:

SIGNED_CONTRACT_NOT_IMPLEMENTATION_READY

W regulowanym procesie interpretacja awardu, terminów, środków ochrony i skutków podpisu wymaga przeglądu prawnego i zakupowego właściwego dla sprawy.

Bezpieczeństwo może obejmować przyjęcie zgłoszenia, kwestionariusz, przegląd architektury, testy, ustalenia, działania naprawcze, wyjątek, akceptację ryzyka szczątkowego i formalne zatwierdzenie. Prywatność może obejmować role, cel, dane, podstawę, transfer, DPA, DPIA, retencję i prawa osób. Gotowość techniczna może obejmować kompatybilność, interfejsy, wydajność, niezawodność i możliwość wsparcia.

Nie wolno redukować tych domen do passed/pending. Trzeba rozdzielić:

przesłane
przegląd w toku
wymagane zmiany
warunkowo ukończone
ukończone z dowodem
wygasłe
ponownie otwarte

Polityki zapewnienia mogą wymagać testów oraz formalnej zgody przed wdrożeniem.²⁸ Secure-by-design traktuje bezpieczeństwo jako wymaganie biznesowe i element cyklu życia, ale nie zastępuje zatwierdzenia bezpieczeństwa po stronie klienta.²⁹

Podpis nie uruchamia automatycznie realizacji. Start może wymagać:

• nazwanego właściciela projektu;
• zespołu klienta;
• zarezerwowanych zasobów wykonawczych;
• planu;
• środowiska;
• danych;
• migracji;
• zabezpieczenia;
• zarządzania zmianą;
• szkolenia;
• wsparcia;
• wycofania zmiany;
• akceptacji;
• mandatu do uruchomienia produkcyjnego.

Wycena zasobów wykonawczych ma termin wygaśnięcia. Termin dostawy sprzed trzech miesięcy może być nieaktualny. Akceptację należy uzgodnić przed wykonaniem: co testujemy, względem czego, w jakim środowisku, na jakich danych, z jakim progiem i kto odbiera.

Pilot może przejść weryfikację i nie przejść walidacji. Może też zakończyć się technicznie, ale nie posiadać kryteriów odbioru.¹¹

Minimalny krok planu decyzji:

joint_objective: ""
seller_owner: ""
customer_owner: ""
dependency: "DEP-X"
required_inputs: []
completion_criterion: ""
planned_date: ""
date_source: ""
evidence: ""
status: "MAP-X / CPL-X"
right_to_change_or_decline: true

Plan nie jest wspólny, gdy został przygotowany wyłącznie przez sprzedawcę, klient nie potwierdził właścicieli, daty pochodzą z końca kwartału dostawcy, brak odpowiedzi jest traktowany jak zgoda albo plan nie ma ścieżki zmiany.

Status może pozostać UNILATERAL_DRAFT, przejść do korekty faktów, wspólnego przeglądu, zostać uzgodniony, zablokowany, zmieniony, częściowo ukończony, wygasły lub wycofany.

Dokumentacja popularnych CRM pokazuje, że etapy i kategorie prognozy są konfigurowalne, mapowalne i automatyzowalne.³⁰ Pole systemowe może więc zmienić się bez powstania zewnętrznego zobowiązania.

CRM zapisuje twierdzenie.
H06 testuje podstawę twierdzenia.
Tylko właściwy proces i uprawniona rola tworzą zobowiązanie.

Przed kategorią zobowiązania należy potwierdzić dokładne zobowiązanie, ścieżkę mandatu, wersję, zależności, dowody, granicę umowy i zakupów, blokady wdrożenia, autoryzację przez człowieka, wygaśnięcie i brak aktywnego wstrzymania.

AI może ekstrahować pola, wykrywać luki, nieaktualne dowody i różnice wersji. Nie może potwierdzać mandatu, nadawać zatwierdzeń, oznaczać closed won, przyjmować ryzyka, wysyłać zobowiązań ani uruchamiać wdrożenia.

1. Poczucie postępu z kalendarza: dużo spotkań bez zmiany CPL.
2. Poczucie postępu z dokumentów: wiele wersji bez jednej linii bazowej.
3. Poczucie postępu od sponsora: entuzjazm bez ścieżki mandatu.
4. Poczucie postępu z zakupów: award bez kontraktu lub PO.
5. Poczucie postępu z przeglądu: „pracujemy” bez kryteriów i zapisu zatwierdzenia.
6. Poczucie postępu z pilota: wykonany test bez akceptacji.
7. Poczucie postępu z podpisu: podpis bez zasobów wykonawczych i planu.
8. Poczucie postępu z CRM: zmiana etapu bez nowego dowodu.

Pytanie kontrolne brzmi:

Który materialny stan zmienił się od poprzedniego przeglądu, jakie kryterium zostało spełnione i jaki aktualny dowód to potwierdza?

Przykład 1. Enterprise SaaS: rozpoczęty przegląd bezpieczeństwa

Scena: Klient przesłał kwestionariusz bezpieczeństwa, odbyły się dwa spotkania techniczne, a CRM pokazuje etap „contracting”.

Klasyfikacja: DEP-8, CPL-6, APR-7, EVD-4; FS-1 lub FS-2.

Brak: Właściciel decyzji w obszarze bezpieczeństwa, kryteria, lista otwartych działań naprawczych, formalne zatwierdzenie dowodu i termin wygaśnięcia.

Wynik: DEFER_FOR_SECURITY_REVIEW + DO_NOT_FORECAST_AS_COMMIT.

Wniosek: Rozpoczęty przegląd nie oznacza zatwierdzenia.

Przykład 2. Maszyna przemysłowa: award bez uzgodnionej odpowiedzialności

Scena: Dostawca otrzymał informację o wyborze, ale umowa nadal zawiera otwarte limity odpowiedzialności i SLA.

Klasyfikacja: CMT-6, DEP-5, CPL-7, APR-5/APR-6; FS-2.

Brak: Jedna wersja umowy, właściciel redline’ów, mandat do odstępstw i ostateczna osoba podpisująca.

Wynik: DEFER_FOR_CONTRACT_REVIEW + DO_NOT_MARK_CLOSED_WON.

Wniosek: Award nie jest zatwierdzonym kontraktem.

Przykład 3. Pilot AI: zakończony test bez akceptacji kryteriów

Scena: Pilot działał 30 dni, lecz strony nie uzgodniły wcześniej jakości, miary fałszywych trafień ani sposobu odbioru.

Klasyfikacja: CMT-2, DEP-14, CPL-4, EVD-7; brak APR-13.

Brak: Bazowe kryteria akceptacji, metoda walidacji, właściciel wyniku i udokumentowane wyjątki.

Wynik: REVISE_ACCEPTANCE_PLAN + DEFER_FOR_ACCEPTANCE_EVIDENCE.

Wniosek: Pilot zakończony nie oznacza, że spełnił potrzeby użytkownika.

Przykład 4. Budżet zatwierdzony, ale brak mandatu do podpisu

Scena: Sponsor potwierdza środki i termin, lecz umowę może podpisać tylko członek zarządu po przeglądzie komitetu.

Klasyfikacja: CMT-5, DEP-2, APR-2 complete, APR-14/APR-6 open.

Brak: Forum, data, wymagany pakiet, quorum i ostateczna osoba podpisująca.

Wynik: DEFER_FOR_AUTHORITY_CONFIRMATION.

Wniosek: Pozytywny sponsor nie jest autoryzacją zobowiązania.

Przykład 5. Plan decyzji przygotowany wyłącznie przez sprzedawcę

Scena: Plan ma daty i zadania klienta, ale klient nie potwierdził właścicieli ani zależności.

Klasyfikacja: MAP-1, CPL-3, EVD-0; FS-1.

Brak: Weryfikacja faktów, prawo do zmiany lub odmowy, bilateralni właściciele, kryteria wykonania.

Wynik: MUTUAL_ACTION_FACT_CHECKED albo REVISE_DEPENDENCY_MAP.

Wniosek: Jednostronny plan nie jest wspólny i nie może służyć jako sekwencja nacisku.

Przykład 6. PO oczekiwane, ale finansowanie nie zostało zwolnione

Scena: Zakupy mówią, że PO „powinno wyjść w piątek”, lecz finanse nie potwierdziły źródła środków.

Klasyfikacja: CMT-10 pending, DEP-3, CPL-0/CPL-4, APR-2 open.

Brak: Autorytatywny rekord budżetu, właściciel, kwota, okres i warunki wydania PO.

Wynik: DEFER_FOR_BUDGET_APPROVAL + DO_NOT_CLAIM_APPROVAL.

Wniosek: Oczekiwana czynność nie jest dowodem wykonania.

Przykład 7. Spójność komercyjna po zmianie zakresu

Scena: Strony uzgodniły cenę, ale klient później dodał kraj, integrację i wyższy SLA.

Klasyfikacja: CMT-7 wcześniejsze, DEP-4/DEP-5/DEP-10 reopened, CPL-11.

Brak: Diff semantyczny, nowa wycena, zasoby wykonawcze, odpowiedzialność i zatwierdzenia.

Wynik: REOPEN_DEPENDENCY + REVISE_COMMERCIAL_PACKAGE + REVISE_CONTRACT_VERSION.

Wniosek: Materialna zmiana unieważnia dziedziczoną spójność.

Przykład 8. Dostawa urządzenia: termin produkcyjny utracił ważność

Scena: Oferta wskazywała dostawę w 12 tygodni, ale zatwierdzenie trwało 10 tygodni i termin nie został zarezerwowany.

Klasyfikacja: DEP-12, CPL-10, EVD-3 stale; FS-2.

Brak: Aktualne potwierdzenie zasobów wykonawczych, komponenty, transport, właściciel i nowa data.

Wynik: REVISE_DELIVERY_OR_CAPACITY_PLAN + DO_NOT_START_IMPLEMENTATION.

Wniosek: Dawne potwierdzenie zasobów wykonawczych ma termin wygaśnięcia.

Przykład 9. Migracja danych bez ustalonego właściciela jakości

Scena: Umowa jest podpisana, lecz nie ustalono źródeł danych, kryteriów czyszczenia i odpowiedzialności za błędy.

Klasyfikacja: CMT-9 complete, DEP-13/DEP-14 open, RDY-10/RDY-11 incomplete.

Brak: Właściciel danych, akceptacja, wycofanie zmiany, bezpieczeństwo/prywatność i zasoby.

Wynik: REVISE_IMPLEMENTATION_PLAN + DO_NOT_START_IMPLEMENTATION.

Wniosek: Podpis nie jest gotowością wdrożeniową.

Przykład 10. Postępowanie publiczne: informacja o awardzie przed zawarciem umowy

Scena: Wykonawca otrzymał oficjalny wynik, ale obowiązujące kroki, terminy i warunki zawarcia umowy pozostają otwarte.

Klasyfikacja: CMT-6, DEP-6/DEP-7/DEP-5; FS-2.

Brak: Weryfikacja prawna i zakupowa właściwa dla sprawy, finalna umowa, mandat i data wejścia w życie.

Wynik: DEFER_FOR_PROCUREMENT + DEFER_FOR_LEGAL_REVIEW + DO_NOT_MARK_CLOSED_WON.

Wniosek: H06 nie interpretuje terminów ani środków prawnych; zapisuje otwarte zależności i wykonuje przekazanie.

Wyniki nie tworzą rankingu. Zobowiązanie nie jest automatycznie lepsze niż uzasadnione odroczenie, niedopasowanie albo odejście od szansy.

Reguły użycia wyników

• co najmniej jeden wynik główny;
• maksymalnie trzy wyniki pomocnicze;
• każdy wynik ma właściciela i podstawę;
• READY_FOR_H08_PRE_COMMIT_REVIEW nie jest zobowiązaniem;
• COMMIT_AUTHORIZED_WITH_SCOPE wymaga autoryzacji przez człowieka;
• wynik zatrzymania ma pierwszeństwo przed automatyzacją;
• wynik po zmianie może zostać wycofany;
• brak wyniku sprzedażowego nie oznacza braku wartości procesu.

Wersja 15-minutowa:

1. dokładne zobowiązanie i CMT;
2. data oraz źródło;
3. właściciel decyzji, osoby zatwierdzające, osoby podpisujące i prawo weta;
4. trzy najważniejsze DEP;
5. CPL i dowody;
6. granica umowy i zakupów;
7. blokada wdrożenia;
8. status planu decyzji;
9. FS;
10. główny wynik i przekazanie.

Minimalna karta:

commit:
  type: "CMT-X"
  exact_object: ""
  version: ""
  decision_date: ""
  date_source: ""

authority:
  decision_owner: ""
  approvers: []
  signatory: ""
  veto_roles: []

dependencies:
  - type: "DEP-X"
    owner: ""
    completion: "CPL-X"
    criterion: ""
    evidence: ""
    expiry: ""

mutual_action:
  status: "MAP-X"

forecast:
  status: "FS-X"
  authorized_by: ""

outcome:
  primary: "OUT-XX"
  handoff: ""

Przekazanie do H04 następuje przy otwartym pakiecie negocjacyjnym. Przekazaniem do H05 — przy otwartym procesie zakupowym. Do H07 — gdy brak zobowiązania wymaga diagnozy. Do H08 — gdy rekord jest kompletny do przeglądu przed zobowiązaniem.

READY_FOR_H08_PRE_COMMIT_REVIEW nie oznacza zatwierdzonej prognozy.

RGK-1–RGK-9 nie jest prawem, standardem certyfikującym, modelem statystycznym, algorytmem przewidywania podpisu, zatwierdzeniem bezpieczeństwa, zatwierdzeniem prywatności, certyfikatem akceptacji ani automatyczną polityką prognozy.

Nie każda zależność musi być zamknięta. Może być niewymagana, warunkowa lub świadomie zaakceptowana, ale podstawa, mandat, zakres, warunki, ryzyko szczątkowe i wygaśnięcie muszą być jawne.

Nie należy przenosić:

• standardów technicznych jako uniwersalnych reguł sprzedaży;
• polityki jednej instytucji jako prawa ogólnego;
• przepisów jednej jurysdykcji na inną;
• certyfikatu organizacji na zatwierdzenie rozwiązania;
• wyniku pilota na każdy kontekst;
• statusu CRM na zewnętrzny fakt;
• klasyfikacji AI na autoryzację przez człowieka.

Stan prawny, regulacyjny i AI wymaga sprawdzenia na dzień użycia, szczególnie harmonogram stosowania AI Act.²¹²²