1. Definicje: co podlega governance
W Luage (Compendium + Engine) rozróżniamy trzy poziomy artefaktów. Governance dotyczy tych,
które mają wpływ na zachowanie systemu w produkcji:
Polityka
Norma: „MUST/SHOULD”. Wersjonowana, ma ownera, przegląd i ślad audytowy.
Procedura
Kroki wykonawcze (workflow). Zazwyczaj łączy polityki z narzędziami i rolami.
Wzorzec / Szablon
Ułatwia wdrożenie (prompt, kontrakt, checklista). Podlega review, ale jest „narzędziem”.
Zasada: jeśli artefakt może zmienić wynik, ryzyko lub koszt działania systemu — musi mieć ownera,
wersję i ścieżkę zatwierdzania.
2. Role i odpowiedzialności
W praktyce governance działa tylko wtedy, gdy role są proste i powtarzalne. Rekomendowane minimum:
| Rola |
Odpowiedzialność |
Typowy artefakt |
| Owner polityki |
Treść i decyzja: co jest dopuszczalne, co nie, jakie są wyjątki. |
Policy doc, changelog, wyjątki. |
| Reviewer merytoryczny |
Jakość i wykonalność: czy da się to egzekwować w narzędziu i procesie. |
Checklist review, uwagi do PR. |
| Security/Compliance |
Ryzyko, dane, zgodność: gdzie są granice zaufania i kontrola. |
Akceptacja ryzyka, wymagane bramki. |
| AI Ops / Platform |
Egzekucja: bramki, audyt, regresje, monitoring. |
Policy-as-code, testy, logi. |
Jeżeli potrzebuje Pan/Pani formalizacji, użyj modelu odpowiedzialności.
Model RACI jest naturalnym uzupełnieniem tej procedury.
3. Workflow: od propozycji do publikacji
Poniższy cykl jest celowo klasyczny. Nie wygrywa „fajerwerkami”, wygrywa powtarzalnością.
1
Propozycja
Problem, cel, ryzyka, wpływ na użytkownika i narzędzie. Zawsze z przykładem.
2
Draft
Tekst polityki/procedury + propozycja testów regresji (minimum: 5 przypadków).
3
Review
Review merytoryczny + security/compliance + wykonalność w Engine.
4
Zatwierdzenie
Decyzja ownera + zapis w changelogu + wersja. Bez tego nie ma „prawa”.
5
Publikacja
Wejście w życie + komunikat + aktualizacja promptów/kontraktów + uruchomienie regresji.
6
Monitoring
Mierzymy zgodność i dryf. Jeżeli polityka nie jest mierzona, nie jest wdrożona.
7
Deprecjacja
Okno migracji, komunikat, usunięcie starych wariantów, zamknięcie wyjątków.
4. Wersjonowanie i kompatybilność
Polityki powinny mieć wersję i prostą semantykę zmian. Najczęściej wystarcza:
major (zmiana zachowania), minor (doprecyzowanie / nowe przypadki), patch (literówki, przykłady).
Wersjonowanie nie jest ozdobą — to gwarancja, że można powiedzieć: co obowiązywało wtedy.
Reguła: major bez migracji i regresji jest proszeniem się o incydent.
5. Wyjątki: jak akceptować ryzyko bez anarchii
Wyjątek to świadoma decyzja, że w konkretnym przypadku akceptujemy odstępstwo od polityki.
Żeby wyjątki nie zamieniły się w „drugą prawdę”, stosujemy trzy zasady:
- Wyjątek jest jawny — trafia do rejestru (kto, co, dlaczego, na jak długo).
- Wyjątek jest czasowy — ma datę wygaśnięcia i plan domknięcia.
- Wyjątek ma właściciela — ktoś odpowiada za skutki i powrót do standardu.
6. Audyt i regresje
W Luage „audyt” to nie jest jednorazowy dokument, tylko zdolność do odpowiedzi na pytanie:
dlaczego system odpowiedział tak, a nie inaczej.
To wymaga śladu (trace) i zestawu regresji.
| Mechanizm |
Co daje |
Minimalny standard |
| Trace ID |
Korelacja logów: prompt, kontekst, narzędzia, wynik. |
Jeden identyfikator od wejścia do odpowiedzi. |
| Regresje |
Wykrycie dryfu po zmianach (prompt/policy/model). |
Golden set + progi (block/warn). |
| Rejestr zmian |
Skąd się wzięła zmiana i kto ją zatwierdził. |
Changelog + link do PR/wniosku. |
| Rejestr wyjątków |
Kontrola odstępstw w czasie. |
Wygaśnięcie + owner + powód. |
7. Minimalna checklista governance
- Każda polityka ma ownera i wersję.
- Zmiany przechodzą przez review (merytoryczne + wykonalność + security).
- Jest changelog i rejestr wyjątków.
- Zmiana uruchamia regresje (minimum: golden set).
- Jest monitoring jakości i driftu (alerty, progi).
- Wyjątki są czasowe i domykane.
8. Powiązane