Polityka prototypów — awans według ryzyka i dowodów

Polityka prototypów dla oprogramowania generowanego przez AI klasyfikuje każdy prototyp według ekspozycji (użytkownicy, dane, skutki zewnętrzne i odwracalność), a nie według narzędzia, które go zbudowało. Przed awansem wymaga sześciu rodzajów dowodów: zgody na użycie danych, wskazanego właściciela, testów, przeglądu bezpieczeństwa, obserwowalności i przećwiczonego wycofania. Takie połączenie daje pełne trzy punkty w pytaniu 16 CTO Scorecard.

Ta strona jest dla CTO odpowiedzialnego za pytanie 16 oraz dla lidera platformy lub tech leada, który ma zamienić politykę w działające mechanizmy. Typowa sytuacja: inżynier w jedno popołudnie napisał metodą vibe codingu kalkulator cen, żeby rozstrzygnąć spór z działem sprzedaży. Cztery miesiące później opiekunowie klientów wysyłają link do niego klientom, narzędzie czyta kopię CRM i działa na prywatnym koncie chmurowym tego inżyniera. Nikt nie zdecydował, że to produkcja. Stawała się nią stopniowo, użytkownik po użytkowniku.

Q16 · Paralelizm w skali zespołu: Jak zespół klasyfikuje i promuje szybko generowane prototypy?

Odpowiedź za maksymalną liczbę punktów: polityka według klas ryzyka, z kryteriami danych, własności, testów, bezpieczeństwa, obserwowalności i wycofania, które prototyp musi spełnić przed awansem.

Co daje ci ta polityka prototypów

Tabelę punktacji Q16, która pokazuje, czego brakuje każdej odpowiedzi i jaka jedna zmiana przenosi cię wyżej.
Cztery klasy ekspozycji — każda z techniczną granicą, która ją egzekwuje, a nie tylko z etykietą.
Plik rejestru prototype.yml i check CI, które możesz scommitować bez zmian.
Tabelę wyzwalaczy awansu, która mówi, jak wykryć każdy wyzwalacz bez polegania na czyjejś pamięci.
Bramkę awansu z sześcioma kryteriami, dowodem dla każdego wiersza i osobą, która go podpisuje.
Trzy prompty do skopiowania: sklasyfikuj prototyp, przeszukaj go pod kątem wyzwalaczy, zaudytuj wniosek o awans.

Prototypy budowane przez analityków, zespoły operacyjne i inne osoby spoza inżynierii potrzebują dodatkowych kontroli (zakup kreatorów aplikacji, karty zgłoszeń, twarde granice dla nie-inżynierów). Opisuje je strona oprogramowanie tworzone poza inżynierią, która używa tych samych czterech klas. Ta strona dotyczy samej polityki oraz tego, jak inżynieria ją egzekwuje i audytuje.

Ile punktów daje każda odpowiedź na Q16?

Scorecard przyznaje 0–3 punkty. Każdy krok w górę zastępuje deklarację kontrolą.

Punkty	Odpowiedź	Czego brakuje	Jak przejść wyżej
0	Nikt nie używa / brak polityki: szara strefa	Nikt nie wie, ile jest prototypów ani jakich danych dotykają	Załóż rejestr opisany niżej i przeprowadź jedno wyszukiwanie prototypów
1	Zakazane bez wyjątków	Inżynierowie i tak prototypują, tyle że na prywatnych kontach, których nie widzisz	Zastąp zakaz klasą „do wyrzucenia”: zatwierdzoną, odizolowaną i z datą wygaśnięcia
2	Dopuszczone do prototypów i marketingowych landing page’y, nie do produkcji	„Nie produkcja” nie ma definicji, więc nikt nie zauważa dnia, w którym przestaje to być prawdą	Zdefiniuj klasy według ekspozycji i zautomatyzuj wyzwalacze awansu
3	Polityka według ryzyka z kryteriami danych, własności, testów, bezpieczeństwa, obserwowalności i wycofania przed awansem	Na arkuszu odpowiedzi niczego; zostaje ryzyko, że polityka istnieje tylko na papierze	Potwierdzaj ją co kwartał procedurą weryfikacji opisaną niżej

Zakaz punktuje wyżej niż brak polityki, bo przynajmniej deklaruje intencję. Punktuje niżej niż „dopuszczone do prototypów”, bo spycha pracę tam, gdzie nie możesz jej sprawdzić. Andrej Karpathy wyznacza granicę, którą rysuje ta polityka: „Vibe coding raises the floor. Agentic engineering is about extrapolating the ceiling” oraz „You are still responsible for your software, just as before” (opublikowany transkrypt jego wystąpienia na Sequoia Ascent, 2026-04-30).

Do której klasy należy prototyp?

Klasyfikuj według tego, do czego prototyp ma dostęp i na co wpływa, nigdy według wieku, rozmiaru ani narzędzia, które go napisało. Skrypt na 200 linii, który zapisuje do bazy rozliczeń, nie jest prototypem w żadnym istotnym sensie.

Klasa	Granica	Egzekwowanie techniczne	Wymagane dowody
Eksploracja do wyrzucenia	Dane syntetyczne lub zatwierdzona próbka, brak użytkowników spoza zespołu autora, brak zapisów do wspólnych systemów	Osobne konto lub projekt sandboksowy, żadnych produkcyjnych poświadczeń, ruch wychodzący ograniczony do rejestrów pakietów, brak publicznego URL	Cel, właściciel i data wygaśnięcia w rejestrze
Kontrolowany pilotaż	Wskazani użytkownicy w jednym zespole, zatwierdzone dane, odwracalne skutki	Firmowe repozytorium z CI, konto serwisowe o wąskim zakresie, SSO przed aplikacją, limit wydatków	Zaakceptowana specyfikacja, testy uruchamiane w CI, podstawowy monitoring, spisany plan wycofania, wskazany właściciel z inżynierii
System produkcyjny	Zależą od niego inne zespoły lub klienci, trwałe dane albo istotne skutki zewnętrzne	Standardowa ścieżka produkcyjna: pipeline wdrożeń, menedżer sekretów, dyżury	Pełna pętla AI-native SDLC i bramka awansu opisana niżej
Ścieżka zakazana	Sekrety w kodzie, niezatwierdzone dane osobowe lub regulowane, płatności, niszczący dostęp do wspólnych systemów	Blokowana przez kontrolę dostępu do danych i zarządzane ustawienia agentów, a nie przez osąd autora prototypu	Brak: zatrzymaj się i przenieś pracę na ścieżkę produkcyjną

Cztery klasy odpowiadają czterem poziomom ryzyka z governance i autonomii. Praca do wyrzucenia mieści się w poziomach 0–1, kontrolowany pilotaż dotyka poziomu 2, a wszystko w klasie produkcyjnej jest poziomem 3, gdy tylko obsługuje uwierzytelnianie, rozliczenia lub dane produkcyjne, niezależnie od rozmiaru kodu.

Jak wdrożyć politykę prototypów?

Opublikuj klasy i listę zakazów. Wpisz powyższą tabelę jako osobny punkt polityki korzystania z AI. Zapisz, że klasa wynika z ekspozycji i że rozpoczęcie prototypu do wyrzucenia nie wymaga niczyjej zgody. Usunięcie tego tarcia sprawia, że prototypy pozostają widoczne.
Daj klasie „do wyrzucenia” zatwierdzone miejsce. Utwórz sandboksowe konto lub projekt w chmurze, szablon repozytorium z plikiem rejestru i checkiem CI opisanymi niżej oraz przykładowy zbiór danych. Jeśli zatwierdzona ścieżka jest wolniejsza niż prywatne konto, ludzie wybiorą prywatne konto.
Rejestruj każdy prototyp w chwili utworzenia. Plik prototype.yml w katalogu głównym repozytorium jest wpisem w rejestrze. Centralny inwentarz to zaplanowane zadanie, które zbiera te pliki z całej organizacji, a nie arkusz, o który ktoś musi dbać.
Zautomatyzuj wyzwalacze awansu. Podłącz każdy sygnał z tabeli wyzwalaczy do alertu albo czerwonego checka. Wyzwalacz, który zależy od tego, czy autor coś zauważy, nie zadziała.
Prowadź awans jako bramkę, nie rozmowę. Prototyp wchodzi do klasy produkcyjnej dopiero wtedy, gdy każdy wiersz bramki awansu ma swój dowód i podpis. Zapisz decyzję „utwardzić na miejscu” albo „przebudować” wraz z uzasadnieniem.
Wycofuj po terminie i sprawdzaj sprzątanie. Prototyp po terminie dostaje nową datę albo zostaje wycofany. Wycofanie oznacza unieważnienie poświadczeń, usunięcie kopii danych, usunięcie domen i rekordów DNS, zamknięcie rozliczeń i zarchiwizowanie repozytorium wraz z zapisem decyzji.

Co zawiera rejestr prototypów?

Scommituj ten plik w katalogu głównym każdego repozytorium z prototypem. Check CI poniżej kończy się błędem, gdy brakuje pola albo minęła data wygaśnięcia. Dzięki temu „powinniśmy przejrzeć stare prototypy” zamienia się w czerwony build.

name: pricing-calculator
class: controlled-pilot        # disposable | controlled-pilot | production | forbidden
owner: anna.nowak              # konkretna osoba, nigdy alias zespołu
engineering_owner: team-revenue-platform   # wymagany od controlled-pilot wzwyż
purpose: Let account managers quote volume discounts without a spreadsheet.
users: account-managers-emea (14 people)
data_read: [crm-replica:internal]
data_written: none
external_effects: none         # e-mail, płatności, zapisy do API stron trzecich albo none
credentials: svc-pricing-calc (read-only, secrets manager)
public_url: false
expiry: 2026-12-15
last_trigger_review: 2026-09-26

Dodaj ten workflow do szablonu repozytorium prototypów. Nie potrzebuje sekretów i tylko czyta repozytorium.

name: prototype-register
on:
  pull_request:
  schedule:
    - cron: '17 6 * * 1'   # w każdy poniedziałek, żeby wygasł także nieruszany prototyp
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - name: Check class, owner, and expiry
        run: |
          test -f prototype.yml || { echo "prototype.yml is missing"; exit 1; }
          for key in class owner expiry; do
            grep -Eq "^${key}: *[^ #]" prototype.yml || { echo "prototype.yml has no ${key}"; exit 1; }
          done
          if grep -Eq '^class: *forbidden' prototype.yml; then
            echo "Forbidden class: move this work to the production path"; exit 1
          fi
          if grep -Eq '^class: *(controlled-pilot|production)' prototype.yml; then
            grep -Eq '^engineering_owner: *[^ #]' prototype.yml || { echo "engineering_owner is required for this class"; exit 1; }
          fi
          expiry=$(sed -n 's/^expiry: *\([0-9-]*\).*/\1/p' prototype.yml)
          [[ "$expiry" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]] || { echo "expiry must be an unquoted YYYY-MM-DD date"; exit 1; }
          if [[ "$(date -u +%F)" > "$expiry" ]]; then
            echo "Expired on ${expiry}: renew with a new date or retire"; exit 1
          fi

Uruchomienie według harmonogramu jest ważniejsze niż uruchomienie przy pull requeście. Prototyp, którego nikt nie dotyka, to właśnie ten, który wygasa po cichu. GitHub wysyła powiadomienie o nieudanym uruchomieniu według harmonogramu tylko osobie, która jako ostatnia zmieniła linię cron, więc kieruj tę porażkę także do właściciela z rejestru, na przykład krokiem, który otwiera issue przypisane do osoby z pola owner. W repozytorium publicznym GitHub wyłącza zaplanowane workflow po 60 dniach bez aktywności w repozytorium, dlatego trzymaj repozytoria prototypów jako prywatne albo niech centralne zadanie inwentaryzacji oznacza wyłączone workflow.

Jakie zdarzenia powinny uruchamiać przegląd awansu?

Wyzwalaczem awansu jest każda zmiana ekspozycji. Każdy wyzwalacz potrzebuje sygnału wykrycia, który nie zależy od autora.

Wyzwalacz	Sygnał wykrycia	Reakcja
Użytkownicy spoza zespołu właściciela	Logi SSO lub dostępu pokazują nowe grupy; aplikacja pojawia się na wspólnym kanale lub w wiki	Przegląd w ciągu tygodnia; klasa co najmniej kontrolowany pilotaż
Dane klientów, osobowe lub regulowane	Wniosek o dostęp do danych, nowe połączenie ze sklasyfikowanym magazynem albo pole w schemacie pasujące do twoich wzorców danych osobowych	Wstrzymanie do czasu, aż zespół odpowiedzialny za prywatność danych zatwierdzi to użycie
Zapisy do wspólnego systemu lub trwały stan	Nowy katalog migracji bazy danych, prośba o uprawnienia zapisu dla konta serwisowego	Bramka awansu przed kolejnym wydaniem
Skutki zewnętrzne: e-mail, płatności, zapisy u stron trzecich	SDK płatności lub poczty w zależnościach; wywołania do nowych domen	Zakazane do czasu przejścia bramki; płatności od razu trafiają na ścieżkę produkcyjną
Inny system od niego zależy	Inne repozytorium wywołuje jego API lub importuje jego pakiet; pojawia się w katalogu usług	Bramka awansu; w tym samym tygodniu wskazany zostaje właściciel z inżynierii
Publiczna ekspozycja	Nowy rekord DNS, publiczny URL albo wyłączone SSO	Najpierw ogranicz dostęp do sieci wewnętrznej lub SSO, potem przegląd
Obowiązek wsparcia	Ktoś inny niż autor dostaje alert albo prośbę o naprawę	Bramka awansu; prototyp już stał się produkcją

Wiek nie jest wyzwalaczem. Dwuletni wewnętrzny notatnik na danych syntetycznych może na zawsze pozostać w klasie „do wyrzucenia”, jeśli regularnie odnawia datę wygaśnięcia. Dwudniowa aplikacja z logowaniem dla klientów nie może.

Co prototyp musi udowodnić przed awansem?

Bramka awansu sprawdza sześć kryteriów z odpowiedzi punktowanej najwyżej w Q16. Każde kryterium ma dowód, który recenzent może sprawdzić bez czytania kodu linia po linii, oraz wskazaną osobę, która go podpisuje.

Kryterium	Dowód	Kto podpisuje
Dane	Każdy magazyn, z którego prototyp czyta i do którego pisze, jest sklasyfikowany, klasyfikacja dopuszcza to użycie, a żadna kopia danych produkcyjnych nie leży poza zatwierdzonym miejscem	Właściciel danych lub lider ds. prywatności
Własność	Usługa ma właściciela w inżynierii, jest w grafiku dyżurów tego zespołu, a autor przekazał notatki o zachowaniu	Engineering manager zespołu-właściciela
Testy	Kryteria akceptacji wyprowadzone z prawdziwych przykładów obecnego zachowania, każde pokryte testem, który działa w CI i pada, gdy zachowanie się zepsuje	Tech lead zespołu-właściciela
Bezpieczeństwo	Uwierzytelnianie i autoryzacja na każdej ścieżce, brak sekretów w kodzie i paczkach klienckich, zależności potwierdzone w publicznym rejestrze, przegląd bezpieczeństwa diffu bez otwartych problemów wysokiej wagi	Recenzent bezpieczeństwa
Obserwowalność	Śledzenie błędów, logi z ustawioną retencją i jeden alert na awarię, którą użytkownicy zauważyliby najpierw	Lider dyżurów zespołu-właściciela
Wycofanie	Spisany plan wycofania lub wyłącznik, przećwiczony raz poza produkcją, z czasem, jaki to zajęło	Lider dyżurów zespołu-właściciela

Następnie zespół-właściciel zgłasza zmianę jak każdą inną, z dołączonym pakietem dowodów. Zapis awansu stwierdza utwardzić na miejscu albo przebudować i podaje powód. Utwardzaj, gdy kod da się przenieść do firmowego repozytorium, stos technologiczny pasuje do tego, co utrzymuje twoja platforma, a przegląd bezpieczeństwa znajduje pojedyncze problemy. Przebudowuj, gdy problemy bezpieczeństwa są systemowe albo model danych nie udźwignie realnej skali. Przy przebudowie zachowaj kryteria akceptacji, a kod wyrzuć: prototyp już zapłacił za odkrycie, co oprogramowanie ma robić. Pełną tabelę „utwardzić czy przebudować” znajdziesz na stronie oprogramowanie tworzone poza inżynierią.

Jak przeprowadzić przegląd prototypu w każdym z narzędzi?

Prompty z następnej sekcji działają w każdym z trzech agentów. Różni się to, jak utrzymać sesję przeglądu w trybie tylko do odczytu i skąd pochodzi druga opinia.

Zacznij przegląd w trybie tylko do odczytu poleceniem claude --permission-mode plan, wklej prompt i pozwól agentowi raportować bez edycji. Dla kryterium bezpieczeństwa uruchom /security-review na diffie gałęzi, a /code-review, gdy utwardzona wersja jest już pull requestem.

Na kanale latest (v2.1.283+) interaktywne sesje Claude Code w terminalu i VS Code startują w trybie auto, w którym akcje zatwierdza klasyfikator, a nie inżynier, chyba że plik ustawień ustawia disableAutoMode albo model sesji nie obsługuje trybu auto; claude -p nadal startuje w trybie Manual. W sandboksie dla prototypów do wyrzucenia to rozsądne. Aby wyłączyć ten tryb w całej organizacji, ustaw permissions.disableAutoMode: "disable" w ustawieniach zarządzanych (sprawdzone na v2.1.283).

Uruchom przegląd z profilem uprawnień tylko do odczytu: codex -c default_permissions=":read-only" (profile uprawnień są w wersji beta, sprawdzone na Codex CLI 0.157.1). Dla pull requesta z utwardzoną wersją codex review --base main recenzuje gałąź nieinteraktywnie i nadaje się na krok CI.

Administratorzy przypinają profil uprawnień i ograniczają serwery MCP dla wszystkich przez requirements.toml, więc sesja prototypu nie sięgnie do niezatwierdzonego serwera. Plik opisuje strona o zarządzanej polityce agentów.

Prompty do klasyfikacji i awansu prototypów

Pierwszy prompt uruchamiaj, gdy prototyp powstaje lub zostaje odnaleziony, drugi według harmonogramu, a trzeci, gdy ktoś wnioskuje o awans. Wszystkie trzy działają tylko do odczytu.

Read this repository without modifying any file. Determine:
- who can reach it (auth, SSO, public URLs, deploy config);
- every data store it reads or writes, and whether any field looks like
  personal, customer, or payment data;
- every external effect (email, payments, third-party API writes);
- every credential it uses and where that credential is stored.

Then classify it as disposable, controlled-pilot, production, or forbidden,
using these rules: forbidden if secrets are in code, payments are possible,
or personal data is used without an approval reference; production if other
teams or customers depend on it or it writes durable shared state;
controlled-pilot if named users inside one team use it on approved data;
otherwise disposable. Output a filled prototype.yml and, separately, the
file and line that justify each field.

Compare the current state of this repository with prototype.yml. Report,
with file and line or commit as evidence, every graduation trigger that has
fired since last_trigger_review:
1. users or groups beyond those listed;
2. new data stores, migrations, or write scopes;
3. new dependencies that send email, take payments, or call third-party APIs;
4. new public URLs, DNS records, or removed authentication;
5. other repositories or services that call this one.
If none has fired, say so and list what you checked. Do not edit files.

Audit this graduation request against six criteria: data, ownership,
tests, security, observability, rollback. For each criterion, state PASS,
FAIL, or MISSING EVIDENCE, and cite the file, CI run, or document that
supports it. Specifically check that every acceptance criterion maps to
a test that runs in CI, that no secret appears in code or client bundles,
that every dependency exists on its public registry, and that the rollback
note names a command or switch and a rehearsal date. End with the
missing items only, ordered by risk. Do not change any code.

Jak udowodnić, że polityka działa, bez czytania każdego prototypu?

Dowody są strukturalne, więc CTO sprawdza liczby i wyjątki, a nie kod.

Pokrycie rejestru. Porównaj repozytoria i projekty chmurowe znalezione podczas wyszukiwania (system kontroli wersji, lista aplikacji w SSO, rozliczenia chmury) z repozytoriami, które mają prototype.yml. Każda luka zostaje zarejestrowana albo wycofana.
Czerwone buildy po terminie. Policz zaplanowane checki rejestru, które się nie powiodły i zostały naprawione w ciągu dwóch tygodni. Czerwony check, którego nikt nie naprawia, oznacza błędne pole właściciela.
Zapisy awansu. Każda usługa w klasie produkcyjnej, która zaczynała jako prototyp, ma zapis bramki z sześcioma podpisami i decyzją „utwardzić czy przebudować”.
Ekspozycja bez właściciela. Liczba prototypów z użytkownikami spoza zespołu właściciela i bez engineering_owner przy każdym przeglądzie kwartalnym powinna wynosić zero.
Kompletność wycofań. Dla próbki wycofanych prototypów potwierdź, że poświadczenia już nie działają, a domeny nie mają już aktywnych rekordów DNS.

Raportuj te pięć punktów co kwartał. To także dowody, o które poprosi recenzent scorecardu, gdy deklarujesz trzy punkty w Q16.

Co psuje się w polityce prototypów i jak to naprawić?

„Tymczasowa” produkcja. Prototyp zdobywa użytkowników, dane i zależność, a nikt nie ogłasza, że to produkcja. Naprawa: traktuj wyzwalacz „obowiązek wsparcia” jako rozstrzygający. Jeśli w tym miesiącu naprawiał go ktoś inny niż autor, uruchom bramkę awansu teraz i wskaż właściciela w tym tygodniu.

Rejestr staje się formularzem, którego nikt nie wypełnia. Inżynierowie go pomijają, bo jest oddzielony od pracy. Naprawa: dodaj plik do szablonu repozytorium, a check CI do domyślnej ochrony gałęzi, tak aby utworzenie prototypu tworzyło też wpis w rejestrze.

Sandbox dla prototypów do wyrzucenia jest zbyt restrykcyjny. Inżynierowie wracają na prywatne konta. Naprawa: zmierz, ile trwa uruchomienie zatwierdzonego prototypu, i całkowicie usuń zgody z tej klasy. Kontroluj poświadczenia i dane, a nie samo rozpoczęcie pracy.

Awans trwa kwartał. Zespoły przestają o niego prosić, a prototypy niepostrzeżenie wchodzą w użycie. Naprawa: publikuj medianę czasu od wyzwalacza do decyzji bramki i utrzymuj niewielką rotację właścicieli z inżynierii, którzy mogą przejąć awansowaną usługę.

Utwardzanie na miejscu przenosi skróty prototypu na produkcję. Naprawa: kryteria bezpieczeństwa i danych są zero-jedynkowe, a nie doradcze. Problem systemowy (brak autoryzacji, sekrety w historii, dane osobowe w logach) zmienia decyzję na przebudowę.

Po wycofaniu zostają aktywne poświadczenia. Repozytorium jest zarchiwizowane, ale konto serwisowe i rekord DNS nadal istnieją. Naprawa: wycofanie jest zakończone dopiero wtedy, gdy check potwierdzi, że poświadczenie nie działa, a rekord DNS domeny już nie istnieje, i ten wynik trafi do rejestru.

Dokąd dalej z polityką prototypów

Oprogramowanie tworzone poza inżynierią Te same cztery klasy dla analityków i zespołów operacyjnych, z zakupem kreatorów aplikacji i twardymi granicami.

Governance i autonomia Cztery poziomy ryzyka i decyzja człowieka, której wymaga każdy z nich.

Pakiet dowodów Co musi udowodnić pull request zmiany, która przechodzi na produkcję.

Szablon polityki korzystania z AI Gdzie umieścić punkt o prototypach i jak egzekwować pozostałe punkty.

Wróć do klucza odpowiedzi CTO Scorecard, aby przejść do pozostałych pytań z sekcji „Paralelizm w skali zespołu”.