| Rodzaj danych | W narzędziu AI |
|---|---|
| kod open source | tak |
| kod objęty umową z klientem | tylko w narzędziu zatwierdzonym przez firmę |
| dane osobowe klientów | nigdy |
| klucze, hasła, tokeny | nigdy |
Jedna strona zasad zamiast zakazu, którego nikt nie przestrzega.
Zasady korzystania z narzędzi AI w zespole developerskim — żeby przyspieszenie pracy nie odbywało się kosztem kontroli nad kodem i danymi.
Zespół dalej pracuje szybciej — tylko w znanych granicach.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Zespół już używa asystentów AI, zwykle bez ustalonych zasad. Kod powstaje szybciej, ale nikt nie sprawdza, co wchodzi do podpowiedzi, skąd pochodzi wygenerowany fragment ani czy przeszedł te same kontrole co kod pisany ręcznie.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Zasady zamiast szarej strefy.
Ustalamy, co wolno wkleić do narzędzia AI, a czego nigdy — z uwzględnieniem danych klientów i kodu objętego umowami. Wygenerowany kod obejmujemy tym samym procesem sprawdzania co kod pisany ręcznie, bez wyjątków, bo pochodzenie fragmentu nie zmienia jego ryzyka. Porządkujemy dostępy asystentów i integracji, żeby dostawały tylko te uprawnienia, których naprawdę potrzebują. Zespół szkolimy na konkretnych przykładach zamiast wprowadzać ogólny zakaz, którego i tak nikt nie przestrzega.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Co wolno wkleić do narzędzia, a czego nigdy — z uwzględnieniem danych klientów.
RezultatKrótkie zasady: co wolno wkleić do narzędzia AI, a czego nigdy
Ten sam proces sprawdzania co dla kodu pisanego ręcznie, bez wyjątków.
RezultatWygenerowany kod objęty tymi samymi kontrolami co reszta
Asystent i integracje dostają tylko te uprawnienia, których naprawdę potrzebują.
RezultatUprawnienia asystentów i integracji zawężone do potrzebnych
Konkretne przykłady zamiast ogólnego zakazu, którego nikt nie przestrzega.
RezultatZespół przeszkolony na przykładach z Waszej pracy
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
| Rodzaj danych | W narzędziu AI |
|---|---|
| kod open source | tak |
| kod objęty umową z klientem | tylko w narzędziu zatwierdzonym przez firmę |
| dane osobowe klientów | nigdy |
| klucze, hasła, tokeny | nigdy |
Jedna strona zasad zamiast zakazu, którego nikt nie przestrzega.
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.21.2
hooks:
- id: gitleaksSekret nie trafi do repozytorium, niezależnie od tego, kto napisał kod.
Narzędzie dostaje tylko te uprawnienia, których naprawdę potrzebuje.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie.
Zakres ustalamy po rozmowie i diagnozie. Mniejsze wdrożenia zamykają się w kilku tygodniach, większe dzielimy na etapy, żeby efekt był widoczny po pierwszym.
Zwykle nie do całego. W większości przypadków wystarczy dostęp do konfiguracji procesu budowania i ustawień organizacji. Zakres ustalamy pisemnie przed startem.
Tak, ale nie na pełen etat. Potrzebujemy kontaktu z osobą, która zna system, i przeglądu naszych zmian. Reszta jest po naszej stronie.
Wpinamy się w to, co u Was działa. Wymiana narzędzia to najdroższy i najrzadziej potrzebny sposób poprawy bezpieczeństwa.
Nie. Pracujemy na standardach i narzędziach, które Wasz zespół zna albo szybko pozna — nie na autorskiej metodyce, którą rozumiemy wyłącznie my. Wszystko jest udokumentowane i przekazane.
Tak wpinamy kontrole, żeby działały w tle. Jeśli któraś zaczyna blokować pracę, dostrajamy ją albo zmieniamy jej miejsce w procesie.