Darf ein KI Agent selbst entscheiden, ob ein ERP-Test bestanden ist? KI Agenten können heute große Teile des Softwaretestens autonom übernehmen. Aber wie weit darf diese Autonomie gehen und das insbesondere bei geschäftskritischen ERP-Prozessen?
Diese Frage stellt sich gerade sehr konkret bei unserer Arbeit mit Infor LN. Unsere Agenten analysieren Anforderungen, erstellen Testfälle und Testdaten, automatisieren und führen Tests aus und analysieren anschließend die Ergebnisse.
Natürlich wollen wir diese Autonomie nutzen. Denn wenn ein KI Agent einen Test vollständig automatisiert ausführt und ein Mensch anschließend jeden einzelnen Schritt noch einmal manuell überprüfen muss, haben wir einen erheblichen Teil des Produktivitätsgewinns wieder verloren.
Gerade bei geschäftskritischen ERP Prozessen können wir einen Agenten aber auch nicht einfach alles selbst entscheiden lassen.
Die interessantere Frage lautet deshalb: Welche Entscheidungen darf ein Agent autonom treffen, und an welchen Stellen muss die autonome Ausführung bewusst unterbrochen werden?
Hier wird aus AI Automation für uns Agentic Engineering.
Nicht jeder Test hat die gleiche Kritikalität
Ein ERP-System besteht aus Prozessen mit sehr unterschiedlichen Risiken.
Ein Fehler in einem wenig kritischen UI-Verhalten hat andere Konsequenzen als ein Fehler in einem Prozess, der beispielsweise Buchungen, Bestände oder finanzielle Transaktionen betrifft. Deshalb kann auch die Art und Tiefe der Prüfung nicht überall identisch sein.
Im Hingepoint Framework unterscheiden wir dabei bewusst zwischen Verification und Validation.
Verification: Was it built right?
Verification prüft, ob die Implementierung den freigegebenen funktionalen, architektonischen und taktischen Specifications entspricht.
Sie erfolgt in drei Stufen:
- Self-Test durch die AI: Der Agent erstellt und führt Tests gegen die Implementierung aus.
- Independent AI Review: Eine zweite, unabhängige AI untersucht die Implementierung auf Defekte, Ineffizienzen, Security-Schwachstellen und fehlende Tests.
- Architect Review: Ein Mensch prüft die Implementierung gegen die vorher vereinbarte Architektur und Tactical Specification und gibt sie explizit frei.
Das ist ein wichtiger Punkt im Hingepoint Framework: AI generating and AI reviewing alone is not sufficient.
Der Mensch muss nicht zwangsläufig jede einzelne Codezeile lesen. Aber er muss genügend Kontext besitzen, um beurteilen zu können, ob der vereinbarte Lösungsansatz tatsächlich umgesetzt wurde und dafür Verantwortung übernehmen zu können.
Validation: Was the right solution built?
Danach folgt eine andere Frage und zwar nicht: Haben wir die Lösung richtig gebaut?, sondern: Haben wir die richtige Lösung gebaut?
Validation prüft, ob das Ergebnis weiterhin dem Intent, den funktionalen Erwartungen sowie den vereinbarten Governance- und Security-Anforderungen entspricht.
Auch hier kann und soll AI einen zunehmenden Teil der Arbeit übernehmen. Der Hingepoint Guide sieht ausdrücklich vor, dass Validation mit zunehmender Reife einer Organisation immer stärker automatisiert werden kann.
Aber die Organisation definiert die Kriterien, nach denen Verification und Validation bestanden oder nicht bestanden sind. Validation kann dabei drei Ergebnisse haben:
- Passed.
- Gaps.
- Skipped, mit expliziter menschlicher Bestätigung.
Und bei Gaps wird es besonders interessant: Was passiert, wenn der Agent während des Tests etwas Unerwartetes entdeckt?
Nehmen wir ein vereinfachtes Beispiel aus einem ERP-System. Während der Planung gehen Mensch und AI davon aus, dass eine bestimmte Schnittstelle ein definiertes Verhalten zeigt.Diese Annahme fließt in die Specification und den Plan ein. Der Agent beginnt mit seiner Arbeit.
Während der Ausführung stellt er jedoch fest, dass die Schnittstelle verhält sich anders als angenommen. Jetzt könnte der autonome Agent versuchen, das Problem selbst zu lösen.
- Vielleicht interpretiert er das Verhalten neu.
- Vielleicht passt er den Test an.
- Vielleicht verändert er seine Annahme und arbeitet einfach weiter.
Das darf im Hingepoint Framework nicht still passieren. Denn aus einer kleinen falschen Annahme können sehr schnell viele technisch plausible Folgeentscheidungen entstehen.
Das ist ein Technical Hingepoint
Ein Hingepoint ist im Framework ein geplanter, ereignisgesteuerter Synchronisationspunkt, an dem automatisierte Ausführung pausiert, sobald eine notwendige Entscheidung, Abhängigkeit, Freigabe oder externe Bedingung noch nicht geklärt ist.
Hingepoints sind damit der Runtime-Control-Mechanismus des Frameworks. Sie trennen autonome Ausführung von bewusster Entscheidungsfindung.
In unserem Beispiel stellt der Agent fest, dass eine technische Annahme nicht stimmt. Damit entsteht ein Technical Hingepoint.
Wichtig ist dabei eine Feinheit: Das bedeutet nicht automatisch, dass der Agent sofort jede Arbeit stoppen muss.
Der Hingepoint wird an der Stelle im Plan relevant, an der die ungeklärte Annahme für den weiteren Fortschritt benötigt wird. Bis dahin kann unabhängige Arbeit weiterlaufen.
Ist die Frage aber nicht geklärt, wenn dieser Punkt erreicht wird, wird der betroffene Teil der Arbeit blockiert. Der Agent darf die Lücke nicht einfach selbst mit einer plausiblen Annahme schließen. Das ist eine der zentralen Regeln des Frameworks:
A Hingepoint prevents AI from filling a relevant gap with an implicit assumption.
Viele Hingepoints kennen wir schon vor der Ausführung
Hingepoints entstehen allerdings nicht erst, wenn etwas schiefgeht. Bereits während des Planning leitet AI aus den freigegebenen Specifications einen Implementierungsplan ab.
Dieser enthält unter anderem:
- Implementierungsreihenfolge,
- Tests und Testdaten,
- Mocks und Probes,
- Deployment-Aktivitäten,
- Dependencies,
- Milestones
- und die bereits bekannten Hingepoints.
Unsichere Annahmen sollen dabei bewusst als Validierungsschritte eingeplant werden.
Wenn beispielsweise das Verhalten einer externen Schnittstelle unsicher ist, kann bereits vor der davon abhängigen Implementierung ein Probe, Spike oder Test vorgesehen werden.
Der Grund ist einfach: Eine unsichere Annahme früh zu überprüfen ist günstiger, als eine darauf aufgebaute Implementierung später korrigieren zu müssen.
Und manchmal entsteht ein Compliance Hingepoint
Nicht jede Grenze der Autonomie ist technisch. Nehmen wir an, ein Agent stellt während seiner Arbeit fest, dass er für einen Test auf zusätzliche sensible Daten zugreifen müsste.
Oder eine geplante Aktion berührt eine Security Anforderung, die in dieser konkreten Situation noch nicht eindeutig geklärt ist.
Dann darf er auch diese Lücke nicht eigenständig interpretieren. Es kann ein Compliance Hingepoint entstehen.
Im Hingepoint Framework gibt es insgesamt fünf Typen:
- Decision,
- Dependency,
- Compliance,
- Resource und
- Technical.
Sie unterscheiden sich in ihrer Ursache, folgen aber demselben Prinzip: Wenn eine relevante Voraussetzung für die weitere Arbeit nicht erfüllt ist, wird diese Unsicherheit explizit statt durch eine stille Annahme ersetzt.
Wenn die Konsequenzen größer werden, muss auch die menschliche Prüfung tiefer werden
Nicht jede Software ist gleich kritisch. Bei einem wenig kritischen Prozess kann es vollkommen angemessen sein, einen großen Teil der Verification und Validation durch AI durchführen zu lassen.
Bei geschäftskritischen Funktionen würden wir dagegen eine deutlich intensivere menschliche Prüfung empfehlen.
Das Hingepoint Framework definiert dafür bewusst keine allgemeingültige Grenze. Ob eine Funktion mission-critical ist und welche zusätzliche Prüfung daraus folgt, hängt vom jeweiligen System, seinem Einsatzgebiet und den Vorgaben der Organisation ab.
Aber der Prozess kann diese Entscheidung explizit abbilden.
Wenn bereits während Shaping und Planning bekannt ist, dass eine bestimmte Funktion eine besonders intensive menschliche Prüfung benötigt, wird diese Prüfung nicht erst am Ende spontan eingefordert, sondern sie wird Teil des Plans.
Und dort, wo vor der weiteren Ausführung oder Freigabe eine menschliche Entscheidung notwendig ist, kann ein entsprechender Decision Hingepoint vorgesehen werden.
Der Agent arbeitet bis zu diesem Punkt autonom. Dann wird die vereinbarte Evidenz vorgelegt, die notwendige menschliche Prüfung durchgeführt und die Entscheidung getroffen. Erst wenn die Bedingung des Hingepoints erfüllt ist, geht die betroffene Arbeit weiter.
Autonomie und menschliche Kontrolle sind damit kein Widerspruch
Das ist für uns ein wichtiger Punkt. Wir müssen uns nicht zwischen zwei Extremen entscheiden:
Entweder der Agent arbeitet autonom. Oder der Mensch kontrolliert alles.
Hingepoint verfolgt einen anderen Ansatz. Wir überlegen bereits bei der Planung:
- Wo kann AI autonom arbeiten?
- Welche Risiken müssen vorher überprüft werden?
- Welche Entscheidungen können innerhalb des vereinbarten Lösungsansatzes getroffen werden?
- Und an welchen Stellen brauchen wir bewusst menschliches Judgment?
Diese Punkte werden sichtbar gemacht und dort in den Plan eingebaut, wo sie tatsächlich relevant werden. Damit kann ein Agent große Teile seiner Arbeit autonom erledigen, ohne dass wir auf menschliche Kontrolle an den entscheidenden Stellen verzichten müssen.
Der Agent soll nicht ständig fragen. Er soll wissen, wann er stoppen muss. Darin liegt für uns eine der wichtigsten Voraussetzungen für produktives Agentic Engineering.