88 lines
5.1 KiB
Markdown
88 lines
5.1 KiB
Markdown
# Für Freigeber und Prüfer
|
|
|
|
Diese Anleitung ist für alle, die Aktionen der KI prüfen: Freigeber und Admins eines Workspace, globale Approver und Reviewer von Pull Requests.
|
|
|
|
In der Plattform gibt es zwei Arten der Prüfung:
|
|
|
|
- **Freigabeanträge:** Einzelne Tool-Aufrufe, die vor der Ausführung eine Entscheidung brauchen. Sie werden in der Plattform unter *Freigaben* entschieden.
|
|
- **Code-Review:** Code-Änderungen der KI landen als Pull Request im Git-Server und werden dort geprüft. Dafür gibt es keinen Antrag in der Plattform.
|
|
|
|
## Wer entscheidet
|
|
|
|
| Freigabestufe | Wer entscheidet |
|
|
| --- | --- |
|
|
| Workspace | Admins und Freigeber dieses Workspace |
|
|
| Globaler Approver | Nur globale Approver (vom Plattform-Admin unter *Nutzer* bestimmt), auch ohne Mitglied des Workspace zu sein |
|
|
|
|
Die Stufe legt der Plattform-Admin je Tool fest. Zusätzlich kann das **Vier-Augen-Prinzip** gelten: Dann darf nicht dieselbe Person entscheiden, die die Aktion ausgelöst hat. Ohne Vier Augen ist eine Selbstfreigabe möglich; sie wird im Audit-Log als *Selbstfreigabe* vermerkt.
|
|
|
|
## Wann ein Antrag entsteht
|
|
|
|
Ein Antrag entsteht, wenn die KI ein Tool aufruft, für das eine Freigabe nötig ist:
|
|
|
|
- Der Plattform-Admin hat das Tool auf *Freigabe nötig* gestellt.
|
|
- Der Workspace hat es für sich verschärft, auch nur für eine bestimmte Quelle (z. B. Abfragen auf der Produktionsdatenbank).
|
|
- Der Workspace nutzt **Modus B**: Jede Schreibaktion in ein Fremdsystem braucht eine Freigabe.
|
|
|
|
Lesende und interne Aktionen wie Dateien lesen, Commits auf den Chat-Branch oder der Plan laufen in der Regel ohne Antrag.
|
|
|
|
## Benachrichtigung
|
|
|
|
- **E-Mail** an alle, die entscheiden dürfen (mit E-Mail-Adresse im Profil).
|
|
- **Webhook** in Teams oder Slack, falls der Workspace einen eingetragen hat.
|
|
- **Zähler** in der Seitenleiste bei *Freigaben*.
|
|
|
|
Unter *Freigaben* steht oben *Zu entscheiden*, darunter die zuletzt entschiedenen Anträge.
|
|
|
|
## Einen Antrag prüfen
|
|
|
|
Die Seite eines Antrags zeigt:
|
|
|
|
- **Workspace, Quelle, Tool und Risikoklasse**, dazu den Grund, warum eine Freigabe nötig ist.
|
|
- **Wer entscheidet**, ob Vier Augen gelten und wann der Antrag abläuft.
|
|
- **Aufruf:** die geprüften Argumente. Genau so wird der Aufruf nach der Freigabe ausgeführt. Das ist maßgeblich.
|
|
- **Beschreibung der KI:** Erklärt, was die KI vorhat. Sie ist nicht geprüft; verlass dich auf die Argumente.
|
|
- **Snapshot:** eine Prüfsumme des Antrags. Ändert sich daran etwas, gilt die Freigabe nicht.
|
|
|
|
**Checkliste:**
|
|
|
|
1. Passt die Aktion zur Frage im Chat? Der Link *Zum Chat* zeigt den Zusammenhang.
|
|
2. Sind die Argumente genau das, was passieren soll? Bei SQL-Abfragen z. B. Tabelle, Bedingungen und Umfang.
|
|
3. Werden Daten sichtbar oder verändert, die nicht in diesen Workspace gehören?
|
|
4. Ist das Zielsystem das richtige (Quelle, Dienst)?
|
|
|
|
**Entscheiden:** *Freigeben* oder *Ablehnen*, optional mit Kommentar. Bei Ablehnung ist der Kommentar Pflicht. Die KI erhält ihn und kann ihre Antwort anpassen.
|
|
|
|
## Nach der Entscheidung
|
|
|
|
- **Freigegeben:** Die Plattform prüft die Rechte der entscheidenden Person erneut und führt den Aufruf genau so aus. Das Ergebnis geht an die KI, und die Antwort läuft weiter.
|
|
- **Abgelehnt:** Die KI erfährt die Ablehnung mit Kommentar.
|
|
- **Die auslösende Person** wird über die Entscheidung benachrichtigt.
|
|
|
|
## Ablauf und erneut beantragen
|
|
|
|
Ein Antrag läuft nach 24 Stunden ohne Entscheidung ab (einstellbar). Die Antwort im Chat endet dann. Wer den Antrag ausgelöst hat oder entscheiden darf, kann ihn mit *Erneut beantragen* neu stellen; er wird dabei gegen den aktuellen Stand neu gebaut.
|
|
|
|
## Abgleich nach unklarem Ergebnis
|
|
|
|
Bricht die Verbindung zum Zielsystem während der Ausführung ab, ist unklar, ob die Aktion angekommen ist. Die Antwort zeigt dann **Abgleich nötig**. Workspace-Admins haben zwei Möglichkeiten:
|
|
|
|
- **Abgleichen und fortsetzen:** Die Plattform prüft zuerst, ob die Aktion schon angekommen ist, und führt nichts doppelt aus.
|
|
- **Beenden:** beendet die Antwort; das Zielsystem muss dann von Hand geprüft werden.
|
|
|
|
## Code-Änderungen reviewen
|
|
|
|
Code-Änderungen der KI kommen als Pull Request in den Git-Server (Bitbucket). Erstellt wird er von einem Mitglied per Klick, standardmäßig als Entwurf.
|
|
|
|
**Was der Pull Request mitbringt:**
|
|
|
|
- Branch `ai/c<Chat>-<Titel>` mit den Commits der KI,
|
|
- Beschreibung mit dem Text des Erstellers, dem Plan, der Liste der Commits und dem Namen des Erstellers,
|
|
- einen Link zum Chat, in dem die Änderung entstanden ist (wenn die Plattform-Adresse eingerichtet ist).
|
|
|
|
**Hinweise für das Review:**
|
|
|
|
- Prüfe den Code wie den einer Kollegin oder eines Kollegen. Die KI hat ihn nicht ausgeführt, Tests liefen höchstens in eurer CI.
|
|
- Warnungen der Syntaxprüfung sieht der Ersteller in der Ansicht *Änderungen*; sie stehen nicht im Pull Request.
|
|
- **Kommentare** schreibst du wie gewohnt im Pull Request. Im Chat startet *Kommentare einarbeiten* eine Antwort, in der die KI sie liest und neue Commits anlegt. Ein Mitglied überträgt diese danach mit *Änderungen übertragen*. Antworten im Pull Request kann die KI nicht.
|
|
- **Merge oder Ablehnung** erkennt die Plattform automatisch, benachrichtigt Chat- und PR-Ersteller und schließt den Branch.
|