Canonical: https://uhl.cloud/resources/agentic-engineering-standards/
Language: de-CH
Format: public page content, generated from HTML

# Standards für agentisches Engineering

Ein nachvollziehbarer Auslieferungsstandard für KI-gestütztes Engineering mit Änderungsprotokoll, Nachweisprüfungen und wiederverwendbarem Freigabeentscheid.

Geprüft vom UHL-Team · 28. Oktober 2026

ChecklisteAktualisiert am 28. Oktober 2026

[PDF herunterladen](https://uhl.cloud/assets/resources/agentic-engineering-standards-de.pdf?v=5b6ba6aa60ca)

## Auslieferungskontrollen für KI-gestützte Änderungen

Ein KI-Agent kann Änderungen schneller vorschlagen, als ein Team deren Folgen beurteilt. Ein sinnvoller Ablauf trennt den vorgeschlagenen Diff, erfolgreiche Prüfungen, die Freigabe zur Auslieferung und den tatsächlich laufenden Stand. Dieser Leitfaden beschreibt diesen Ablauf. Er ist eine empfohlene Kontrollbasis und keine Zusicherung identischer Schutzregeln für jedes Repository.

## Empfohlene Engineering-Kontrollen

- Agenten arbeiten nur auf Feature-Branches - direkte Commits auf main sind per Branch-Protection verhindert, nicht per Konvention

- Jede Agenten-Änderung kommt als Merge Request mit einer Beschreibung, die ein Mensch geschrieben oder geprüft hat - das 'Warum' wird nie still generiert

- CI muss vor dem Merge grün sein und der Merge-Button braucht einen Menschen - eine grüne Pipeline ist ein Beleg, keine Erlaubnis

- Diffs werden wie bei jedem Contributor geprüft: Secrets, Lizenzheader, neue Abhängigkeiten und generierte Dateien bekommen explizite Aufmerksamkeit

- Secrets gelangen nie in den Agentenkontext - Zugangsdaten leben im Secret Store; erreicht ein Wert ein Transkript, wird er als Incident rotiert

- Agenten verifizieren am echten System, nicht an Annahmen - eine Behauptung wie 'deployed' oder 'merged' wird durch Lesen des tatsächlichen Zustands bestätigt

- Lockfile- und Dependency-Updates gehören dem Dependency-Bot (Renovate) - Agenten konkurrieren nicht auf demselben Branch damit

- Destruktive Operationen brauchen eine explizite menschliche Anweisung - Force-Push, Deletes und History-Umschreibungen sind nie aus dem Kontext ableitbar

- Generierte Artefakte sind reproduzierbar - ein Skript im Repository baut sie neu, sodass der Diff geprüft statt geglaubt werden kann

- Der Zustand nach dem Merge wird verifiziert - die angewandte Revision im Deployment entspricht dem gemergten Commit, nicht nur einer grünen Pipeline

Prüfen Sie, welche Kontrollen Repository und Bereitstellungsplattform tatsächlich erzwingen. Eine schriftliche Regel belegt weder Branch-Schutz noch Freigaberegeln oder beschränkten Produktionszugriff.

## Was Sie messen sollten

Eine kleine, prüfbare Änderung lässt sich leichter ablehnen, testen und zurücknehmen als eine breite autonome Neufassung. Messen Sie Durchlaufzeit zusammen mit Review-Aufwand, übersehenen Fehlern und Wiederherstellungsdauer. Mehr Output allein belegt keine bessere Auslieferung.

## Betriebskontext: diese beiden Websites

UHL Cloud und UHL-Services veröffentlichen zweisprachige statische Websites aus versionierten Inhalten und Build-Skripten. Die öffentlichen Ressourcen haben eine HTML-Seite und einen PDF-Download. Das ist ein nachvollziehbares Beispiel für generierte Artefakte: Vergleichen Sie freigegebene Quelle, erzeugte Seite und ausgelieferten Download. Daraus folgt keine identische Freigaberegel für jedes UHL-Projekt. Siehe [UHL-Entwicklungspraxis](https://uhl.cloud/development/).

## Wiederverwendbares Änderungsprotokoll

- **Ziel und Grenze**
  Erfassen Sie Ziel, Repository, Branch, betroffene Daten und ausdrückliche Ausschlüsse. Benennen Sie die Person mit Freigaberecht.

- **Nachweispaket**
  Halten Sie geprüften Diff, exakten Commit, relevante Testergebnisse und Testumgebung fest. Nennen Sie nicht ausgeführte Prüfungen mit Grund.

- **Freigabeentscheid**
  Dokumentieren Sie die Freigabe getrennt vom CI-Erfolg. Lesen Sie nach der Auslieferung die aktive Revision zurück und prüfen Sie den geänderten Nutzerablauf. Halten Sie Rücknahmekriterien fest.

## Abnahme und weiterführende Quellen

- Die Änderung hat eine verantwortliche Prüfstelle und einen benannten Rücknahmeweg.

- Tests prüfen geändertes Verhalten statt nur Implementierungsdetails nachzubilden.

- Das Freigabeprotokoll trennt Quelle, CI, Bereitstellung und Nutzerabnahme.

- [GitLab Protected Branches](https://docs.gitlab.com/user/project/repository/branches/protected/) beschreibt Repository-Kontrollen.

- [NIST Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) bietet einen übergeordneten Referenzrahmen.

## Mit UHL chatten

Starten Sie einen geführten Chat. Der Assistent stellt ein paar Fragen und speichert Ihre Anfrage zur Prüfung durch unser Team.

## Weiter entdecken

- [KI & Automatisierung](https://uhl.cloud/ai-automation/)

- [Softwareentwicklung](https://uhl.cloud/development/)

- [Sicherheit & verantwortungsvolle KI](https://uhl.cloud/security/)

## Sprechen wir über Ihr Projekt.

[UHL kontaktieren](https://uhl.cloud/contact/)