# 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.