Generative Entwicklung erzeugt eine überzeugende Oberfläche oft schneller als die zugehörigen Nachweise. Beispieldaten lassen sich speichern, der Hauptweg funktioniert und die Vorführung wirkt abgeschlossen. Genau dann braucht der Product Owner einen strukturierten Abnahmenachweis.

Acht Evidenzpakete decken die wesentlichen Bereiche ab. Jedes enthält Belege, einen Eigentümer, offene Befunde und eine Entscheidung. Bei einem kleinen internen Werkzeug dürfen die Unterlagen schlank sein. Kein materieller Bereich wird jedoch allein durch eine gelungene Demo erfüllt.

1. Geschäftsregeln und Abnahme

Entscheidungen, Berechnungen, Schwellen und Statuswechsel werden aufgelistet. Für wesentliche Regeln existieren Normal-, Grenz- und Negativtests mit unabhängig festgelegtem Ergebnis. Die generierte Logik darf nicht ihre eigene Referenz sein.

Je nach Prozess gehören doppelte Eingaben, widersprüchliche Werte, Zeitzonen, Währungen und gleichzeitige Änderungen in den Test. Eine nicht am Build beteiligte Person führt die wichtigsten Nutzerwege aus.

2. Datenmodell und Records

Führende Systeme, Entitäten, Schlüssel, Beziehungen, Pflichtfelder, Aufbewahrung, Löschung und Migration werden dokumentiert. Die App darf keine unkontrollierte Kopie maßgeblicher Daten erzeugen.

Tests verwenden realistische Datenmengen. Microsoft dokumentiert, dass nicht delegierbare Abfragen in Power Apps nur einen begrenzten Teil lokal auswerten und trotzdem plausibel aussehen können. Delegation und Leistung müssen mit produktionsnahen Daten geprüft werden.

3. Identitäten und Rechte

Jede repräsentative Rolle wird mit ihrem tatsächlichen Zugriff getestet. Connectoren, Service Principals, persönliche Verbindungen, geteilte Anmeldedaten und das Eigentum ausgerollter Objekte werden geprüft. Der erfolgreiche Maker-Test genügt nicht.

Unerlaubte Lese-, Schreib-, Freigabe- und Verwaltungsaktionen werden aktiv versucht. Minimalrechte müssen auch an der Datenquelle gelten.

4. Validierung, Fehler und Wiederherstellung

Ungültige Eingaben, ausgefallene Abhängigkeiten, Netzunterbrechung, doppelte Aktionen, Teilabschluss und Wiederholung werden getestet. Nutzer müssen Erfolg, Fehler und unklaren Zustand unterscheiden können. Kritische Schreibvorgänge benötigen Schutz vor Duplikaten.

Wiederherstellung umfasst Daten, Konfiguration und Anwendungsversion. Ein Code-Rollback ohne Reparatur inkonsistenter Geschäftsdaten ist unvollständig.

5. Barrierefreiheit und Nutzersicherheit

Automatische Prüfungen werden durch repräsentative Tastatur- und Assistenztechnik-Tests ergänzt. Bewertet werden Beschriftungen, Fokus, Kontrast, Fehlermeldungen, mobile Nutzung und alternative Eingabemöglichkeiten. Warnungen gehören an den Punkt der Konsequenz.

6. Leistung und Kapazität

Start, Suche, Speichern und Integrationen werden unter realistischer Datenmenge und Gleichzeitigkeit gemessen. Plattformgrenzen, Drosselung und Verbrauchsannahmen werden sichtbar. Auch degradiertes Verhalten gehört in den Nachweis.

7. Lebenszyklus und Release

Unterstützte Artefakte und Konfiguration liegen in geeigneter Versions- und Solution-Struktur. Entwicklung, Test und Produktion sind getrennt. Dasselbe versionierte Artefakt durchläuft kontrollierte Stufen; Verbindungen und Umgebungswerte werden beim Deployment validiert.

Power-Platform-Pipelines können sequenzielle Stufen, Vorprüfung, Freigaben und Historie liefern. Der Nachweis beschreibt auch Rollback-Bedingungen und nicht automatisch umkehrbare Datenänderungen.

8. Eigentum und Betrieb

Benannt werden Product Owner, technischer Betreuer, Support, Security-Kontakt und Stilllegungsverantwortung. Servicezeiten, Incident-Schwere, Änderungsfreigabe, Abhängigkeitsprüfung und Access Review sind festgelegt. Das System muss ohne den ursprünglichen Prompt-Autor wartbar sein.

Beispielabnahme: Reiseausnahmen

Eine KI-erstellte App ermöglicht Reiseanträge oberhalb einer Richtlinienschwelle. In der Demo wird ein Antrag erzeugt, freigegeben und in eine Liste geschrieben.

Die Abnahme findet drei materielle Lücken: Die Schwelle vergleicht nach der Währungsformatierung Text, ein Nutzer kann einen genehmigten Antrag nachträglich ändern, und der Flow arbeitet mit der persönlichen Verbindung des Makers. Der Tastaturtest entdeckt zusätzlich ein unbeschriftetes Absende-Icon.

Die Methode wird nicht pauschal abgelehnt. Die aktuelle Version erhält jedoch keine Freigabe. Das Team korrigiert den Währungsvergleich, sperrt genehmigte Datensätze, setzt eine genehmigte Identität ein, beschriftet das Steuerelement und ergänzt Regressionstests. Die neue Solution wird kontrolliert durch Test und Produktion transportiert.

Der zweite Review genehmigt die Nutzung mit einem dreißigtägigen Check von Nutzung und Incidents. Geschlossene Evidenz trägt die Entscheidung, nicht Vertrauen in das Generierungswerkzeug.

Drei Entscheidungszustände verwenden

Release bedeutet vollständige Evidenz und akzeptiertes Restrisiko. Conditional Release begrenzt Nutzer, Daten, Zeit oder Funktion und nennt klare Ausstiegskriterien. Reject kennzeichnet eine materielle Lücke und erklärt, was vor erneuter Prüfung geändert werden muss.

Eine reine Ja-Nein-Liste reicht nicht. Belege werden verknüpft und Risikoverantwortliche benannt. Gleichzeitig darf ein reversibles Werkzeug für fünf Personen weniger Dokumenttiefe benötigen als ein regulierter Kundenprozess.

Produktionsreife entsteht, wenn die Organisation das Verhalten versteht und die Anwendung unterstützen, ändern, wiederherstellen und stilllegen kann. Amplified Pi übersetzt diesen Anspruch in einen effizienten Gate, der gute Lösungen in Produktion bringt und schwache Annahmen vorher korrigiert.