Polityka AI dla jednoosobowej firmy nie musi mieć dwudziestu stron, czternastu ról i komitetu, w którym siedzisz sam ze sobą i jeszcze jednym tabem. Ma opisywać rzeczywistą pracę: dozwolone zastosowania, dane, odbiór, dostawców i moment zatrzymania. Rejestr ma pokazywać, co się zmienia.
Dobry dokument jest krótki i używany. Nie przepisujesz go raz na zawsze. Zmieniasz przy nowym procesie, modelu, kliencie lub skutku. AI nie potrzebuje twojego podpisu pod każdym promptem. Proces potrzebuje odpowiedzialności.
Zacznij od jednej strony zasad
Napisz, do jakich zadań używasz AI i jakie skutki są dozwolone. Rozdziel szkic, publikację, zapis, wysyłkę i decyzję. Szkic maila nie powinien automatycznie uprawniać do wysyłki.
W polityce firmy możesz określić rzeczy zabronione, na przykład: dane wrażliwe bez oceny, automatyczne decyzje prawne, pełne uprawnienia, publikacja bez odbioru i zgadywanie źródeł. Zakaz powinien być konkretny, a nie ogólne „używaj odpowiedzialnie”.
Przy polityce stosuj zasady z artykułu o korzystaniu z AI w firmie. Wersja solo zachowuje ten sam sens bez korporacyjnych ról.
Rejestr zastosowań zamiast rejestru promptów
Zapisz proces, cel, model, dane, skutek, odbiór i właściciela. Nie przechowuj pełnych promptów i dokumentów. Rejestr ma pokazywać decyzje, nie tworzyć nową bazę poufności.
Dodaj datę, wersję i status: aktywny, pilotaż, ograniczony, wycofany. Przy zmianie modelu zapisz, czy proces wymaga nowego testu. Nie przenoś starej zgody na nowe funkcje.
Przy zastosowaniach stosuj zasady z artykułu o rolach AI Act w małej firmie. Rejestr pomaga oceniać procesy zamiast nazw narzędzi.
Dane, których nie wolno wrzucić domyślnie
Wypisz kategorie danych i źródła, które wymagają osobnej oceny: klienci, umowy, nagrania, zdrowie, rekrutacja, finanse i tajemnica. Nie zapisuj ich treści w polityce.
Dodaj dozwolone dane testowe i sposób przygotowania. Fikcyjne przypadki powinny zachowywać trudność procesu bez identyfikowania osób. To pozwala pracować bez produkcyjnego eksportu.
Przy danych stosuj zasady z artykułu o RODO i minimalizacji AI. „Bez danych osobowych” powinno wynikać z mapy, nie z nadziei.
Odbiór, który nie jest fikcją
Opisz, co sprawdzasz przy każdym typie wyniku: źródło, liczby, warunki, linki, ton, uprawnienia i skutek. Nie zapisuj „zawsze sprawdzam”, jeżeli nie masz czasu ani metody.
Przy publikacji przypisz, kiedy możesz pominąć pełny odbiór i kiedy jest on obowiązkowy. Wysokie ryzyko wymaga osobnej decyzji lub specjalisty. Solo nie oznacza powierzchowności.
Przy odbiorze stosuj zasady z artykułu o checkliście procesu AI. Polityka powinna prowadzić do testu, a nie ogólnej dobrej woli.
Dostawcy i wersje
Zapisz, z jakich narzędzi korzystasz, na jakim planie i do jakich procesów. Nie przenoś warunków prywatnego konta na klienta. Data odczytu warunków jest ważna.
Przy nowym dostawcy wykonaj mały test i sprawdź eksport, usuwanie, role i podwykonawców. Nie dodawaj go do wszystkich procesów automatycznie.
Przy onboardingu stosuj zasady z artykułu o kontroli dostawcy AI. Rejestr powinien ograniczać zakres od początku.
Uprawnienia i konta
Opisz minimalne role, MFA, tokeny i sposób odwołania. Nie zapisuj sekretów w polityce. Konto administratora nie jest domyślnym kontem roboczym dla każdego agenta.
Przy integracji sprawdź test odmowy. Agent do szkicu nie potrzebuje zapisu i publikacji. Przy zakończeniu procesu odwołaj token i sprawdź brak nowych operacji.
Przy dostępie stosuj zasady z artykułu o bezpieczeństwie kont AI. Solo również potrzebuje rozdzielenia ról.
Stop dla procesu i dla modelu
Zapisz, kiedy przerywasz pracę: wyciek, nieznany skutek, błąd krytyczny, konflikt źródeł, brak zgody, nowe uprawnienia i zła wersja. Nie czekaj na pełny raport.
Opisz, co zatrzymujesz: nowe zadania, zapis, publikację, wysyłkę lub cały proces. Fallback nie może omijać blokady. Notatka powinna pokazywać, co było w toku.
Przy zatrzymaniu stosuj zasady z artykułu o kill switch AI. Polityka powinna być użyteczna przy awarii, a nie tylko przed nią.
Incydent i kontakt
Zapisz, jak ograniczyć skutek, zachować dowody i poinformować właściwe osoby. Nie przechowuj pełnych danych w notatce incydentu. Identyfikatory i czas wystarczą na start.
Dodaj kontakt do właściciela klienta lub specjalisty zgodnie z procesem. Nie wysyłaj poufnych szczegółów do przypadkowego modelu przy analizie. AI nie jest twoim działem prawnym.
Przy reakcji stosuj zasady z artykułu o incydencie AI. Wersja solo wymaga konkretnych kroków, nie zespołu na zawołanie.
Przykład karty zastosowania
Przy tej karcie dopisz sytuację, w której nie użyjesz automatycznego szkicu, na przykład reklamację wymagającą sprawdzenia dokumentów. Wtedy odpowiedź przygotowuje człowiek, a rejestr pokazuje powód odstąpienia od zwykłej ścieżki.
Nazwa: przygotowanie odpowiedzi na pytania klientów. Cel: szkic. Dane: publiczna dokumentacja i bezpieczne zgłoszenie. Model i wersja: zapisane. Skutek: brak automatycznej wysyłki.
Odbiór: źródło, ton, termin, odbiorca i link. Stop: brak źródła, dane wrażliwe, nowe uprawnienia. Właściciel: ty. Przegląd: po zmianie modelu lub procesu.
Taka karta zajmuje kilka linijek i odpowiada na rzeczywiste pytania. Nie wymaga osobnego dokumentu dla każdego promptu.
Przykład wycofania procesu
Eksperyment z automatycznym follow-upem kończy się, bo zgody nie są jednoznaczne i odbiór kosztuje za dużo. Zapisujesz status wycofany, odwołujesz token i zatrzymujesz kolejkę.
Nie zostawiaj procesu jako „tymczasowo wyłączony” bez decyzji o danych i tokenach. Sprawdź zaplanowane wiadomości i kopie. Nowa wersja nie powinna go uruchomić przypadkiem.
Przy follow-upie stosuj zasady z artykułu o kontakcie bez spamu AI. Wycofanie jest częścią polityki.
Odbiór polityki przez kogoś spoza ciebie
Poproś zaufaną osobę o przeczytanie jednej strony i opisanie, co wolno, czego nie i kiedy zatrzymać. Nie tłumacz w trakcie. Jeżeli odpowiedzi są różne, uprość zasady.
Nie potrzebujesz formalnego audytu przy każdej zmianie. Potrzebujesz sprawdzenia, czy dokument jest zrozumiały i zgodny z pracą. Przy ryzyku skonsultuj specjalistę.
Otwórz rejestr i wybierz jedno zastosowanie. Wykonaj test zgodnie z zasadami. Polityka powinna działać poza folderem, a nie tylko wyglądać profesjonalnie.
Przegląd po nowym kliencie lub funkcji
Przy nowym typie danych, skutku lub modelu zaktualizuj kartę przed pracą. Nie przenoś starej zgody na inny proces. Nowa integracja może zmieniać rolę i ryzyko.
Zapisz, co pozostaje bez zmian. Nie przepisuj całego dokumentu dla jednego nowego dostawcy. Ogranicz pracę do zależnych części i testów.
Przy większym procesie Aeneia Audit pomaga zmapować dane i odpowiedzialność. Aeneia Design pomaga przygotować czytelną instrukcję.
Minimalny pakiet solo
Jedna strona zasad, rejestr zastosowań, lista dostawców, karta odbioru i instrukcja stop. To wystarcza na start. Nie twórz dodatkowych załączników bez potrzeby.
Dokument powinien być dostępny przy pracy i wersjonowany. Nie przechowuj sekretów ani pełnych danych. Linki do źródeł powinny działać.
Najlepsza polityka solo jest czytelna pod presją. Mówi, co robisz, czego nie i kiedy przestajesz. Nie wymaga komitetu z jednej osoby i dwóch kaw.
Zasady dla pracy z klientem
Przy każdym nowym projekcie zapisz, czy używasz własnych narzędzi, kont klienta czy obu. Nie przenoś danych między nimi bez oceny. Jeżeli klient wymaga konkretnego modelu, zaktualizuj rejestr i odbiór zamiast dodawać go do listy bez sprawdzenia.
Opisz, co wolno publikować w portfolio i case study. Zgoda na wykonanie pracy nie jest zgodą na pokazanie promptów, dokumentów i wyników. Przy zakończeniu projektu zachowaj tylko wymagane materiały i zamknij dostęp zgodnie z umową.
Wersja awaryjna jednej strony
Przygotuj krótką instrukcję dostępną bez logowania do wielu systemów: jak zatrzymać publikację, gdzie sprawdzić kolejkę, jakie konta odwołać i z kim skontaktować klienta. Nie umieszczaj w niej haseł ani tokenów.
Przetestuj, czy potrafisz wykonać ją na telefonie przy ograniczonym czasie. Jeżeli wymaga przypomnienia dziesięciu nazw paneli, uprość. Wersja awaryjna ma działać przy stresie, a nie być kolejnym dokumentem do analizowania w spokojnym tygodniu.
Rejestr decyzji, nie tylko zastosowań
Przy większych zmianach zapisz, dlaczego wybrałeś model, odbiór lub ograniczenie. To pozwala później odróżnić świadomą decyzję od przypadkowej konfiguracji. Nie przechowuj pełnych danych testowych i poufnych argumentów.
Przy nowej wersji porównaj, czy założenia nadal są prawdziwe. Jeżeli koszt lub ryzyko wzrosło, zaktualizuj status procesu. Nie zostawiaj starego „zaakceptowane” bez daty i właściciela. Rejestr powinien uczyć na decyzjach, a nie tylko przechowywać nazwy narzędzi.
Kiedy polityka jest zbyt długa
Jeżeli nie potrafisz znaleźć zasady w kilkanaście sekund, skróć ją lub dodaj właściwą nawigację. Nie zwiększaj dokumentu dla każdego nowego przypadku. Część procesów lepiej opisać w kartach zastosowań zamiast jednej wielkiej polityki.
Usuwaj ogólne frazy o odpowiedzialności i innowacji, które nie prowadzą do działania. Zostaw konkretne dane, skutki, role i stop. Dokument ma być używany, a nie udowadniać, że jednoosobowa firma potrafi napisać własny regulamin większy niż potrzebuje.
Zasady, które działają przy pośpiechu
Przygotuj trzy pytania przed każdym nowym zadaniem: jakie dane wrzucam, jaki skutek ma wynik i co sprawdzę przed użyciem. Jeżeli odpowiedzi są niejasne, nie zaczynaj od pełnego eksportu. Użyj fikcyjnego przypadku lub zatrzymaj proces.
Taki rytuał nie zastępuje pełnej oceny przy ryzyku. Pomaga jednak uniknąć automatycznego kopiowania briefu do pierwszego dostępnego modelu. Polityka powinna prowadzić do konkretnych nawyków, a nie tylko być podpisana w folderze z umowami.
Przegląd po incydencie
Zapisz, która zasada zawiodła i jak zmienić proces. Nie dokładaj nowej strony dla każdego problemu. Może wystarczy ograniczyć rolę, usunąć jedno źródło lub dodać test przed publikacją.
Po poprawce wykonaj zależny przypadek i jeden kontrolny. Zaktualizuj rejestr i datę. Jeżeli zasady były niejasne, skróć je zamiast dodawać kolejny wyjątek. Polityka ma uczyć się z błędów, a nie tylko rosnąć w objętość.
Aeneia Audit pomaga uporządkować proces i rejestr. Przy zasadach pomocny jest przewodnik Aeneia Signal.
Dobra polityka solo jest mała, prawdziwa i używana. Rejestr pokazuje zmiany, a stop działa przed skutkiem. Biurokracja może zostać przy większych zespołach.
Raz na jakiś czas otwórz dokument i wykonaj jeden proces zgodnie z nim. Zapisz, które zasady były zbędne lub niejasne, i uprość je. Nie dodawaj nowych pól tylko dlatego, że istnieją w cudzym szablonie. Rejestr ma odpowiadać na twoją pracę, a nie na oczekiwania firmy z innym ryzykiem i strukturą.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
