Specyfikacja projektu AI: szablon operatora

Przydatna specyfikacja projektu AI jest umową odbioru, a nie listą życzeń dotyczących narzędzi. Opisuje problem biznesowy i obserwowalny stan początkowy, proces objęty zakresem, wyraźne wyłączenia, dozwolone dane wejściowe oraz źródła mające autorytet. Określa oczekiwany wynik i testy potrzebne do jego przyjęcia. Wskazuje też osobę zatwierdzającą rezultat, zachowywane dowody i logi, przypadki zatrzymujące proces oraz właściciela dokumentu. Ostatnia część ustala datę przeglądu i jednoznaczną decyzję: wdrożyć, poprawić albo zatrzymać. Dostawca może wtedy zaproponować realizację, ale nie może po cichu zmienić definicji sukcesu.

Dlaczego projekt potrzebuje umowy odbioru?

Lista modeli, integracji i funkcji opisuje planowany zakup, ale nie mówi, co projekt ma udowodnić. Umowa stawia na pierwszym miejscu obserwowalny rezultat. Właściciel biznesowy, zespół techniczny i dostawca oceniają tę samą granicę.

Dokument nie musi przewidywać całej realizacji. Ma ujawniać rozbieżności. Niedozwolone wejście zostaje nazwane. Gdy dwa zatwierdzone źródła sobie przeczą, przypadek się zatrzymuje. Wynik wymagający akceptacji pozostaje szkicem, nawet jeśli ekran wygląda na gotowy.

NIST AI Risk Management Framework jest dobrowolny i ma pomagać organizacjom uwzględniać wiarygodność przy projektowaniu, rozwijaniu, używaniu i ocenie systemów AI. Jego rdzeń obejmuje Govern, Map, Measure i Manage. Powiązany Playbook zawiera sugerowane dobrowolne działania i nie jest listą kontrolną ani wymaganą kolejnością. Ten szablon jest odrębnym zaleceniem redakcyjnym i nie potwierdza certyfikacji, zgodności ani wystarczalności prawnej.

Jakie siedem części należy skopiować?

Skopiuj siedem nagłówków i wymagaj konkretnej odpowiedzi pod każdym z nich. Pusta, ogólna lub sporna odpowiedź wskazuje, że danego punktu nie da się jeszcze odebrać.

1. Problem i obserwowalny stan początkowy. Opisz problem bez wskazywania rozwiązania. Zapisz, co można obserwować dziś i jak powstanie ta sama obserwacja podczas przeglądu.
2. Proces w zakresie i wyłączenia. Nazwij zdarzenie początkowe, koniec, osoby lub systemy oraz wszystko, czego projekt nie może robić.
3. Dozwolone wejścia i autorytet źródeł. Wymień formaty i repozytoria. Ustal źródło nadrzędne oraz zatrzymanie przy braku autorytetu lub sprzeczności.
4. Format wyniku i kryteria odbioru. Określ pola, strukturę, język, wymagane odwołania, zakazane treści i warunki przyjęcia lub odrzucenia.
5. Zestaw testowy. Dodaj przypadki normalne, niekompletne, niejednoznaczne, sprzeczne i wrażliwe wraz z oczekiwanym zachowaniem.
6. Akceptacja, błąd, zatrzymanie i dowody. Nazwij punkt decyzji i ścieżkę zatrzymania. Ustal zachowywane wersje, źródła, decyzje, wyjątki i poprawki.
7. Właściciel i przegląd. Przypisz utrzymanie reguł, źródeł i testów, wyznacz datę i zapisz: wdrożyć w testowanej granicy, poprawić albo zatrzymać.

Praktyczny przewodnik France Num zaleca formalizowanie celów, ról i zasad, testowanie przed wdrożeniem, nadzór człowieka nad zadaniami wrażliwymi, identyfikowalność oraz bieżące utrzymanie instrukcji, konfiguracji i dokumentów. To praktyczne zalecenia, a nie wiążące prawo.

Jaką tabelę można wykorzystać w pracy?

Każdy wiersz oznacza decyzję, która musi pozostawić możliwy do sprawdzenia dowód.

Jak zbudować zestaw testowy?

Testuj granicę i odmowę, nie tylko poprawnie wyglądający przypadek normalny. Każdy przypadek ma wejście, oczekiwany wynik lub zatrzymanie, wynik rzeczywisty, osobę sprawdzającą i decyzję.

• Normalny: pełne dozwolone wejście z autorytatywnego źródła daje określony wynik do akceptacji.
• Niekompletny: brakuje pola lub źródła; luka zostaje wskazana, a nie wymyślona.
• Niejednoznaczny: możliwa jest więcej niż jedna interpretacja; potrzebna jest decyzja człowieka.
• Sprzeczny: dozwolone źródła się różnią; konflikt jest pokazany, a proces zatrzymany.
• Wrażliwy: przypadek należy do nazwanej kategorii wrażliwej lub wykracza poza zakres; nie dochodzi do nieuprawnionego działania.

Przy przetwarzaniu danych osobowych CNIL ujmuje pracę wokół określenia celu, odpowiedzialności i podstawy prawnej, ochrony praw osób, minimalizacji i kontroli danych oraz środków bezpieczeństwa. Takie projekty wymagają odpowiedniego przeglądu prawnego i prywatności; szablon nie jest poradą prawną i nie dowodzi zgodności z RODO.

Jak wygląda wypełniony przykład fikcyjny?

Poniższy proces kierowania wewnętrznych zgłoszeń jest hipotetyczny i nie obiecuje wzrostu produktywności.

1. Problem. Wewnętrzne zgłoszenia trafiają do wspólnej skrzynki. Datowana próbka zawiera tekst, kategorię wybraną przez człowieka i zespół docelowy.
2. Zakres. Proces zaczyna się od zgłoszenia i kończy propozycją skierowania. Nie odpowiada, nie zmienia rekordów, nie przydziela pracy ani nie obsługuje zgłoszeń zewnętrznych.
3. Wejścia. Dozwolone są tekst, zatwierdzona lista kategorii i zatwierdzony katalog zespołów. Katalog rozstrzyga nazwy celów. Brak kategorii lub celu zatrzymuje proces.
4. Wynik. Szkic zawiera identyfikator, proponowaną kategorię i cel, cytowany wpis katalogu oraz krótkie uzasadnienie. Odbiór wymaga wszystkich pól i oparcia w źródłach.
5. Testy. Zestaw obejmuje jasne zgłoszenie lokalowe, zgłoszenie bez lokalizacji, opis oznaczający dostęp albo sprzęt, sprzeczne wskazania kategorii i katalogu oraz zgłoszenie wrażliwe. Oczekuje się szkicu, stopu z powodu braku, decyzji człowieka, stopu przy konflikcie i stopu wrażliwego.
6. Akceptacja. Koordynator skrzynki przyjmuje, poprawia lub odrzuca. Przypadki niepełne, niejednoznaczne, sprzeczne, wrażliwe i poza zakresem nie są kierowane. Zachowuje się wersje, szkic, decyzję, wyjątek i poprawkę.
7. Właściciel. Operacje utrzymują kategorie, katalog i testy. Datowany przegląd kończy się decyzją: wdrożyć w granicy, poprawić albo zatrzymać.

Ten dokument jest bardziej konkretny niż ogólny przykład projektu sztucznej inteligencji. Wcześniejszy wybór procesu opisuje metoda automatyzacji firmy z AI.

Jakie sygnały ujawniają listę życzeń dostawcy?

Specyfikacja jest słaba, gdy precyzyjnie opisuje produkt, ale mgliście opisuje odbiór.

• zaczyna od platformy zamiast problemu;
• obejmuje cały dział bez wyłączeń;
• mówi o „danych firmy” bez źródeł i autorytetu;
• wymaga jakości bez formatu i kryteriów;
• testuje tylko korzystne przykłady;
• wspomina człowieka bez wskazania osoby i decyzji;
• żąda logów bez określenia dowodów;
• nie opisuje zatrzymania i przekazania;
• nikt nie odpowiada za źródła, testy i datę przeglądu.

Kiedy wdrożyć, poprawić albo zatrzymać?

Decyzja jest krótka, ponieważ dowody zostały już określone.

• Wdrożyć: testy dają sprawdzalne wyniki, kryteria są spełnione, zatrzymania działają, człowiek akceptuje, a właściciel przyjmuje wyłącznie testowaną granicę.
• Poprawić: problem jest aktualny, lecz brakuje reguły, wejścia, źródła, kryterium, testu lub ścieżki akceptacji. Umowę należy zmienić i ponownie przetestować.
• Zatrzymać: nie da się ustalić wejść lub autorytetu, wyniku nie można ocenić, zatrzymanie zawodzi albo nikt nie przyjmuje odpowiedzialności.

Wdrożenie nie rozszerza zakresu. Nowe wejście, źródło, wynik lub działanie zmienia umowę i wymaga testów oraz przeglądu.

Najczęstsze pytania

Jak napisać specyfikację? Jako umowę odbioru ze stanem, zakresem, wejściami, wynikiem, testami, akceptacją, zatrzymaniami, dowodami i właścicielem.

Jakie elementy zawiera? Siedem części: problem; zakres; źródła; wynik; testy; akceptacja, zatrzymania i dowody; utrzymanie i przegląd.

Jakie są etapy? Spisać, przygotować przypadki, testować w granicach, przejrzeć dowody i zdecydować o wdrożeniu, poprawie lub zatrzymaniu.

Czy potwierdza zgodność? Nie. Według CNIL projekty z danymi osobowymi wymagają odpowiedniego przeglądu prawnego i prywatności.