KAPITEL 01Ausgangslage
In immer mehr Entwicklungs- und Test-Engineering-Projekten entstehen Ergebnisse heute mit Unterstützung generativer KI: Spezifikationen, Testkonzepte, Auswertungen, Berichte, Code, Prüfpläne. Das funktioniert erstaunlich gut — bis jemand eine der folgenden Fragen stellt.
„Woher kommt dieser Wert?"
Ein Grenzwert, eine Auslegung, eine Empfehlung steht im Dokument. Wer sie erzeugt hat, auf welcher Grundlage und wer sie freigegeben hat, lässt sich nicht mehr rekonstruieren.
„Können Sie das nochmal machen?"
Dieselbe Aufgabe, drei Wochen später, anderes Modell — anderes Ergebnis. Ohne festgehaltene Vorgabe lässt sich weder ein Fehler eingrenzen noch eine Verbesserung belegen.
„Kann das jemand anderes übernehmen?"
Das Wissen, warum ein Ergebnis so aussieht, steckt im Gesprächsverlauf einer einzelnen Person. Fällt sie aus, ist das Vorhaben nicht ohne erheblichen Verlust fortsetzbar.
„Haben wir das eigentlich geprüft?"
Erzeugen ist um Größenordnungen billiger geworden, Prüfen nicht. Reviews werden zum Nadelöhr und dann stillschweigend übersprungen. Qualitätssicherung verschwindet nicht laut, sondern leise.
„Warum steht das schon wieder drin?"
Design Rules, Quality Rules und Lessons Learned existieren als Dokumente, die im Moment der Arbeit niemand liest. Bekannte Fehler wiederholen sich — KI beschleunigt auch das.
„Was, wenn das Werkzeug wegfällt?"
Die Arbeitsweise hängt an einem Anbieter. Ändern sich Modell, Lizenzpolitik oder Verfügbarkeit, ist die Investition in Verfahren und geschulte Mitarbeiter entwertet.
Keine dieser Fragen ist neu. Neu ist, dass klassisches und agiles Projektmanagement für sie kein Instrument bereithalten, weil beide von Voraussetzungen ausgehen, die nicht mehr gelten: dass Umsetzung teuer und Planung billig ist, beziehungsweise dass ein Mensch das Ergebnis in vertretbarer Zeit begutachten kann.
Der Engpass in KI-gestützten Projekten ist nicht mehr die Erzeugung. Er ist die Prüf- und Urteilszeit von Menschen — und die Fähigkeit, später zu belegen, was auf welcher Grundlage entschieden wurde. Genau dort setzt KEEL an.
KAPITEL 02Der Ansatz in einem Satz
Die Absicht wird zum versionierten Artefakt, aus dem Menschen und Maschinen gleichermaßen arbeiten — und kein Ergebnis wird Teil des Projekts, ohne dass eine benannte Person es an einem definierten Punkt angenommen und dabei einen Nachweis hinterlassen hat.
Dahinter steht eine einfache Beobachtung über die Geschichte des Projektmanagements. In jeder Generation ist etwas anderes maßgeblich — das, worauf man sich beruft, wenn zwei Beteiligte unterschiedlicher Meinung sind. Im klassischen Vorgehen war das der Plan, im agilen das lauffähige Inkrement. In KI-gestützten Projekten kann beides diese Rolle nicht mehr ausfüllen: Der Plan ist zu grob für Ergebnisse, die in Stunden entstehen, und ein lauffähiges Ergebnis belegt nicht, dass es das gewollte ist. An ihre Stelle tritt die festgehaltene Absicht.
Die vier Elemente
Der Name benennt zugleich den Ablauf: Kernel — Execution — Evidence — Learning. Ein Zyklus dauert Stunden bis wenige Tage und läuft innerhalb Ihrer bestehenden Projektphasen.
Was daraus praktisch folgt
- Die Absichtsbeschreibung ist maschinenlesbar und wird benutzt. Sie ist nicht die Vorstufe der Arbeit, sondern ihr Auslöser. Änderungen daran erzeugen neue Ergebnisse, nicht neue Änderungsanträge.
- Ergebnisse sind grundsätzlich ersetzbar, die Absicht nicht. Repariert wird bevorzugt an der Absicht und neu erzeugt. Das hält Ergebnisse konsistent, statt sie über die Laufzeit auseinanderdriften zu lassen.
- Jede Annahme erzeugt einen Nachweis — als Nebenprodukt der Arbeit, nicht als Zusatzaufwand danach. Damit ist das Projekt rekonstruierbar, prüffähig und übergabefähig.
KI ist Wind: reichlich vorhanden, gratis, macht schnell. Ein Boot ohne Kiel treibt mit dem Wind — schnell, aber nur in eine Richtung und selten dorthin, wo man hinwill. Der Kiel bremst nicht. Er ist der Grund, warum ein Segelboot gegen den Wind kreuzen kann. Genauso verhält sich Methodik zu KI-Leistung.
KAPITEL 03Die Prinzipien
Acht Sätze, bewusst knapp gehalten. Sie sind domänenfrei formuliert und gelten für Software-, Hardware-, Test- und gemischte Projekte gleichermaßen.
- Was nicht im Kernel steht, ist nicht vereinbart. Der Kernel ist die einzige verbindliche Quelle für Ziel, Grenzen, Begriffe, geltende Regeln, Entscheidungen und Abnahmekriterien. Absprachen aus Chats, Mails und Fluren gelten erst, wenn sie dort angekommen sind.
- Ergebnisse sind ersetzbar, die Absicht ist es nicht. Passt ein Ergebnis nicht, wird zuerst geprüft, ob die Absicht unpräzise war.
- Geprüft wird die Änderung, nicht jedes Mal das Ganze. Jedes neu erzeugte Artefakt trägt einen Änderungsvermerk: was sich geändert hat, wodurch, welche Abnahmekriterien betroffen sind und welche Prüfungen deshalb zu wiederholen sind.
- Kein Ergebnis ohne Annahme, keine Annahme ohne Namen. Jede Übernahme in das Projekt erfolgt an einem definierten Punkt durch eine benannte Person. KI kann vorbereiten, vorschlagen und prüfen — annehmen kann sie nicht.
- Jede Annahme hinterlässt einen Nachweis. Festgehalten wird, worauf sich das Ergebnis bezieht, womit es erzeugt wurde, welche Prüfungen es bestanden hat und wer angenommen hat.
- Kontext ist ein gepflegtes Gut, kein Gesprächsverlauf. Projektkontext wird wie Quelltext behandelt: versioniert, überprüfbar, gemeinsam genutzt. Ein Chatverlauf ist ein Arbeitsmittel, niemals ein Projektartefakt.
- Übernehmbarkeit ist ein Abnahmekriterium. Ein Projekt gilt nur dann als geführt, wenn eine fachkundige Person es mit einem anderen Werkzeug, einem anderen Modell oder ganz ohne KI fortsetzen kann. Diese Fähigkeit wird regelmäßig geprüft.
- Die Datenfrage steht vor dem ersten Prompt. Datenklassen, zugelassene Verarbeitungspfade und erlaubte Ausleitungen werden festgelegt, bevor gearbeitet wird.
Drei Rollen
Intent Owner
Verantwortet den Inhalt: Was ist das Ziel, was sind die Grenzen, wann ist etwas gut genug. Entscheidet bei Zielkonflikten. Eine Person aus Ihrem Haus, kein Gremium.
Keel Lead
Verantwortet die Form: Struktur des Kernels, Zuschnitt und Tiefe der Prüfpunkte, Aufbau der Abläufe, Nachweisführung, Werkzeug- und Modellwahl. Diese Rolle wird zu Beginn typischerweise extern besetzt und schrittweise ins Haus übergeben.
Maker
Erzeugt Ergebnisse — mit Agenten, mit Werkzeugen, von Hand. Führt die fachliche Prüfung durch und verantwortet die Ergebnisse der eingesetzten Werkzeuge persönlich. Das sind Ihre Fachexperten, Entwickler und Testingenieure.
Agenten haben keine Rollen, sondern Aufträge. Sie werden wie Werkzeuge beschrieben — mit Zweck, Grenzen, zugelassenen Datenquellen und einem menschlichen Eigentümer. Ein Agent kann nie Intent Owner sein und nie eine Annahme aussprechen. Diese Regel ist die Voraussetzung dafür, dass die Methode in regulierten Umgebungen überhaupt einsetzbar ist.
Drei Artefakte
Artefakt bezeichnet hier ein bewusst erzeugtes, benanntes und versioniertes Arbeitsergebnis mit einer festen Rolle im Projekt. Der Begriff ist in der Projektmanagement-Fachsprache etabliert — der PMBOK Guide führt „Artifacts“ als eigene Kategorie. Gemeint ist ausdrücklich nicht die messtechnische Bedeutung (Bild- oder Messartefakt als Störung). Die drei Artefakte heißen durchgängig Kernel, Runbook und Evidence Log; sinngemäß stehen sie für Vorgabe, Arbeitsweise und Nachweis. Die deutschen Wörter sind Erläuterung, nicht Zweitname — benannt wird nach den englischen Begriffen, weil die Anfangsbuchstaben den Namen KEEL tragen.
| Artefakt (sinngemäß) | Inhalt | Beantwortet die Frage |
|---|---|---|
| Kernel Vorgabe |
Ziel und Nicht-Ziele, Randbedingungen, Begriffe, geltende Regeln, Abnahmekriterien, Datenklassen, Entscheidungshistorie | Was wollen wir, in welchen Grenzen, und warum haben wir uns so entschieden? |
| Runbook Arbeitsweise |
Wiederholbare Abläufe: Arbeitsaufträge, Werkzeug- und Modellwahl, Prüfschritte, Definition der Prüfpunkte | Wie erzeugen und prüfen wir ein Ergebnis — reproduzierbar, durch verschiedene Personen? |
| Evidence Log Nachweis |
Je angenommenem Ergebnis: Bezug, Erzeuger, Änderungsvermerk, bestandene Prüfungen, annehmende Person, Datum | Woher kommt das, wer steht dafür gerade, und was hat sich seit wann geändert? |
Mehr braucht es nicht. Statusberichte, Pläne, Risikolisten, Spezifikationen und Gate-Unterlagen sind abgeleitete Ergebnisse aus Kernel und Evidence Log — sie werden erzeugt, nicht separat gepflegt. Das ist eine der praktischen Pointen: Der wöchentliche Statusbericht wird nicht mehr geschrieben, sondern erzeugt und abgenommen.
KAPITEL 04Prüfen, ohne im Prüfen zu ertrinken
Der häufigste Einwand gegen absichtsgetriebenes Arbeiten ist berechtigt: Wenn die Absicht laufend besser wird und Ergebnisse deshalb neu erzeugt werden, muss dann jedes Mal alles neu geprüft werden? Wäre das so, wäre die Methode teurer als das, was sie ersetzt.
Die Rechnung ist unerbittlich. Ein Testkonzept einmal vollständig zu prüfen kostet vielleicht einen Tag. Fünf Neuerzeugungen kosten fünf Tage — für eine Verbesserung, die drei Absätze betrifft. Kein Team macht das zweimal mit; beim dritten Mal wird durchgewinkt, und damit ist die Nachweisführung wertlos.
Die Antwort: zwei Arten von Prüfpunkten
Jedes neu erzeugte Artefakt trägt einen strukturierten Änderungsvermerk, der vier Fragen beantwortet: Was hat sich geändert (abschnittsgenau)? Wodurch wurde es ausgelöst? Welche Abnahmekriterien sind betroffen? Welche Prüfungen sind deshalb zu wiederholen — und welche ausdrücklich nicht?
| Prüfpunkt | Umfang | Wann | Aufwand |
|---|---|---|---|
| Vollprüfung | Gegen alle Abnahmekriterien | Erstannahme und bei definierten Auslösern | Hoch — bewusst. Sie ist der Bezugspunkt für alle folgenden Änderungen |
| Delta-Prüfung | Nur die im Änderungsvermerk benannten Abschnitte und die davon berührten Prüfungen | Regelfall bei jeder Neuerzeugung | Ein Bruchteil — hier liegt der wirtschaftliche Hebel der Methode |
Wann eine Vollprüfung zwingend ist
Ohne feste Auslöser entsteht ein bekanntes Risiko: viele kleine, jeweils harmlose Änderungen, die in Summe etwas anderes ergeben, ohne dass jemand das Ganze noch einmal gesehen hat. Die Auslöser werden zu Projektbeginn festgelegt. Bewährter Startsatz:
Nach einer festen Zahl von Delta-Prüfungen
Rein mechanisch, keine Ermessensfrage — und genau deshalb wirksam.
Bei Modell- oder Werkzeugwechsel
Ein anderes Modell kann ein Artefakt an Stellen verändern, die kein Änderungsvermerk erfasst.
Bei kritischen Vorgaben
Änderung an einem als sicherheits-, norm- oder freigaberelevant markierten Kernel-Element.
An externen Zäsuren
Formaler Meilenstein, Kundenabnahme, Auditvorbereitung, Übergabe an ein anderes Team oder einen Lieferanten.
Delta-Prüfungen sind nur so belastbar wie die Verknüpfung zwischen Vorgabe, Abschnitt im Ergebnis und Prüfung. Fehlt diese Rückverfolgbarkeit, ist der Änderungsvermerk eine Behauptung. Ihren Aufbau leistet die Methode nicht von selbst — sie ist der eigentliche Inhalt der Einführungsphase.
KAPITEL 05Hardware, lange Zyklen und Lieferanten
In reinen Softwareprojekten ist „neu erzeugen statt reparieren" billig. In Projekten mit Hardware-Anteil ist es das nicht: Tape-out, Musterbau, Werkzeug oder Lieferantenbeauftragung sind teuer, langsam und irreversibel. Deshalb unterscheidet KEEL zwei Artefaktklassen.
| Klasse | Beispiele | Behandlung |
|---|---|---|
| Intent-Artefakte billig neu erzeugbar |
Lastenheft, Spezifikation, Architekturentwurf, Simulationsmodell, Testkonzept, Prüfplan, Abnahmekriterien, FMEA-Entwurf, Lieferantenbriefing, Testprogramm | Voller Zyklus mit hoher Frequenz: erzeugen, delta-prüfen, verbessern |
| Commitment-Artefakte teuer, physisch, irreversibel |
Layout-Freigabe, Tape-out, Maskensatz, Werkzeugbau, Musterbau, Bestellung, Qualifizierung | Keine Delta-Prüfung, sondern ein bewusst schwerer Prüfpunkt mit vollständiger Prüfung und mehreren Verantwortlichen |
Je mehr Denk- und Prüfarbeit vor den teuren Commitment-Punkt wandert, desto weniger Iterationen. Ein vermiedener Hardware-Spin trägt in der Regel die Kosten eines ganzen Einführungsvorhabens. Diese Rechnung funktioniert unabhängig davon, wie man zu KI steht.
Regeln, die tatsächlich wirken
In vielen Entwicklungsorganisationen existieren gute Design Rules, Quality Rules und Lessons Learned — als Dokumente, die im Moment der Arbeit niemand liest. Bekannte Fehler wiederholen sich deshalb, besonders bei jüngeren Entwicklern und bei eng verzahnten Hardware-Software-Aufgaben, wie sie im ATE-Umfeld typisch sind.
KEEL setzt an einer einzigen Stelle an: Regeln liegen im Kernel — und der Kernel ist der Eingang jeder Erzeugung und jeder Prüfung. Damit wirkt eine Regel dreifach:
- Bei der Erzeugung ist sie Teil des Kontexts, mit dem jeder Mensch und jedes Werkzeug arbeitet. Ein Entwurf, der sie verletzt, entsteht seltener.
- Bei der Prüfung ist sie ein Abnahmekriterium auf der Liste — keine Erinnerung, sondern ein Punkt, der abgehakt wird.
- Bei der Rückschau zeigt das Evidence Log, an welchem Prüfpunkt sie durchgerutscht ist. Daraus entsteht die nächste Regel.
Externe Entwicklung und Lieferanten
Entwickelt ein Lieferant, ändert sich methodisch wenig. Er ist ein besonders langsamer und besonders teurer Maker:
- Das Briefing wird abgeleitet, nicht separat geschrieben — damit automatisch konsistent zu Zielen, Grenzen und Regeln.
- Abnahmekriterien werden zu Lieferantenkriterien, ohne Übersetzungsverlust.
- Rückmeldungen werden Nachweise: Messprotokoll, Freigabe, Abweichungsmeldung — jeweils mit Bezug und verantwortlicher Person.
- Die Vertraulichkeitsgrenze verläuft an der Ableitung. Der Lieferant erhält einen Auszug, nie den Kernel. Ein sauber definierter Schnitt, der sich einem Einkauf erklären lässt.
KAPITEL 06Einbettung in bestehende Prozesse
KEEL ist kein Prozess, der einen Prozess ersetzt. Es ist ein Aufsatz, der einen bestehenden Prozess beliefert. Ihr Meilenstein- und Freigabeverfahren bleibt unverändert. Was sich ändert, ist ausschließlich, wie die Unterlagen entstehen, die es ohnehin verlangt.
Das ist keine Beruhigungsformel, sondern eine Konstruktionsentscheidung. In gewachsenen Organisationen sind Entwicklungs- und Freigabeprozesse verbindlich, auditiert und oft konzernweit vorgegeben. Eine Methode, die eine Prozessänderung voraussetzt, ist dort faktisch nicht einführbar — jedenfalls nicht in einem Zeitraum, in dem sie noch nützt.
Praktisch bedeutet das: Ein einzelnes Projektteam kann KEEL einsetzen, weil seine Gate-Unterlage dadurch schneller fertig und besser belegt ist. Ob und wann daraus ein organisationsweiter Standard wird, ist eine spätere und eigenständige Entscheidung.
KAPITEL 07Daten, Vertraulichkeit und Betriebsmodell
In den meisten Erstgesprächen ist dies die erste ernsthafte Frage — noch vor jeder Methodik. Sie lautet selten „welches Modell", sondern fast immer: Was darf überhaupt raus?
Marktstand Mitte 2026, nüchtern zusammengefasst: Auf Enterprise- und API-Ebene trainieren die großen Anbieter nach ihren eigenen Bedingungen standardmäßig nicht auf Geschäftskundendaten und bieten Auftragsverarbeitungsverträge an; Zero-Data-Retention ist meist gesondert zu vereinbaren. Verarbeitung innerhalb der EU ist je nach Anbieter über europäische Regionen erreichbar, bei US-Anbietern bleibt ein Restrisiko aus dem CLOUD Act bestehen. Offene Modelle lassen sich vollständig im eigenen Rechenzentrum betreiben, allerdings mit spürbarem Leistungsabstand, schlechterer Skalierbarkeit und erheblichem Investitionsbedarf. Eine Multi-Modell-Strategie ist inzwischen der Normalfall.
Die Entscheidung lautet deshalb nicht „Cloud oder On-Premise", sondern: welche Daten auf welchem Pfad. KEEL hält das in einer kleinen Matrix im Kernel fest — vor der ersten Nutzung, nicht danach:
| Datenklasse | Beispiele | Zugelassener Pfad | Nachweis |
|---|---|---|---|
| öffentlich | Datenblätter, Normen, Veröffentlichungen | frei, jedes freigegebene Werkzeug | keiner erforderlich |
| intern | Prozessbeschreibungen, interne Berichte ohne Kundenbezug | Enterprise-Tarif mit Auftragsverarbeitungsvertrag | Werkzeug und Modellversion |
| vertraulich | Kundendaten, Testergebnisse, Yield-Daten, Konditionen | EU-Datenresidenz oder eigener Betrieb | Pfad, Region, Rechtsgrundlage |
| kritisch | Kern-IP, Layouts, Rezepturen, besonders geschützte Daten | eigener Betrieb — oder die Aufgabe wird ohne KI gelöst | vollständig, mit Begründung |
Die eigentliche Leistung liegt nicht in der Tabelle. Die meisten Organisationen haben eine solche Klassifizierung bereits — aus dem Informationssicherheits- oder Exportkontrollkontext. KEEL erfindet sie nicht neu, sondern verknüpft die vorhandene Einstufung mit dem zugelassenen Verarbeitungspfad und macht diese Verknüpfung im Nachweis prüfbar. Das ist ein Tagesordnungspunkt, den ein Datenschutzbeauftragter versteht, ohne dass ihm jemand KI erklären muss.
Modelle können nicht nur technisch oder vertraglich ausfallen. Im Juni 2026 wurde der Zugang zu zwei Modellen eines großen Anbieters für rund drei Wochen ausgesetzt, um US-Exportkontrollen zu entsprechen, und nach deren Aufhebung Anfang Juli wiederhergestellt. Unabhängig von der Bewertung des Einzelfalls zeigt der Vorgang ein Betriebsrisiko, das in Architekturentscheidungen bisher kaum vorkam. In KEEL ist Modellunabhängigkeit deshalb kein Bekenntnis, sondern Betriebsvorsorge — und ein Modellwechsel ein definierter Auslöser für eine Vollprüfung.
KAPITEL 08Reifegrade und Einstieg
Vor jeder Einführung steht eine Standortbestimmung: die nüchterne Feststellung, wo eine Organisation im Umgang mit KI in Projekten tatsächlich steht — unabhängig davon, wie viele Werkzeuge bereits im Einsatz sind. Vier Stufen beschreiben das.
L1: Drei Kollegen lassen sich Testkonzepte von einem Assistenzsystem entwerfen. Jeder formuliert seine Anweisung anders, jeder prüft nach eigenem Gefühl, dokumentiert wird nichts. Fällt einer aus, beginnt der Nächste von vorn.
L2: Für Testkonzepte existiert ein festgehaltener Arbeitsauftrag mit den geltenden Randbedingungen, eine kurze Prüfliste, die vor der Annahme abgearbeitet wird, und ein Vermerk, wer wann was angenommen hat. Das Ergebnis ist nicht besser, weil das Werkzeug besser wäre, sondern weil es wiederholbar und übergabefähig geworden ist.
Woran sich der Nutzen messen lässt
| Kennzahl | Messung | Aussage |
|---|---|---|
| Erstannahmequote | Anteil der Ergebnisse, die ohne Nacharbeit angenommen werden | Qualität der Vorgabe — steigt sie, lag es am Kernel, nicht am Modell |
| Prüflast je Ergebnis | Menschliche Minuten je angenommenem Artefakt | Der Wert, der über die Wirtschaftlichkeit entscheidet |
| Nachweisabdeckung | Anteil der Ergebnisse mit eindeutigem Bezug zur Vorgabe | Prüf- und Auditfähigkeit |
| Übernahmezeit | Zeit, bis eine neue Person eigenständig weiterarbeitet | Härtester Test für Übergabefähigkeit; relevant bei Verlagerungen |
| Regelverstöße nach Annahme | Später entdeckte Verletzungen dokumentierter Regeln | Misst, ob Design und Quality Rules tatsächlich wirken |
Drei Einstiegsformen
Standortbestimmung
Einordnung in die Reifegrade anhand eines realen Projekts, Lückenliste, Datenklassen-Matrix, priorisierter Fahrplan zum nächsten Reifegrad. Der Aufwand wird vorab abgegrenzt.
Der risikoärmste Einstieg — er verpflichtet zu nichts weiter.
Pilot
Ein laufendes Projekt wird über einige Wochen nach KEEL aufgesetzt und begleitet: Kernel aufbauen, Prüfpunkte und Delta-Regeln definieren, Abläufe dokumentieren, Team einarbeiten, Kennzahlen erheben.
Die Rolle des Keel Lead wird zeitlich befristet extern besetzt.
Enablement
Workshop für Projektleitungen und Fachteams: Prinzipien, Rollen, Zuschnitt von Prüfpunkten, Arbeit am eigenen Kernel. Der Umfang richtet sich nach Teamgröße und Vorhaben — auf Wunsch mit anschließender Begleitung.
KAPITEL 09Grenzen der Methode
Was eine Methode nicht leistet, gehört genauso zur Beschreibung wie ihr Nutzen. Die folgenden Punkte sind Erfahrungswerte, keine rhetorische Bescheidenheit.
Ersetzt keine Fachkompetenz
KEEL macht Entscheidungen nachvollziehbar. Ob sie fachlich richtig sind, entscheidet weiterhin, wer sie trifft. Eine schlecht begründete Vorgabe wird durch saubere Nachweisführung nicht besser — nur besser dokumentiert.
Rechnet sich nicht überall
Bei einmaligen, kurzen oder folgenlosen Aufgaben übersteigt der Aufwand den Nutzen. Der Einsatz lohnt sich dort, wo Ergebnisse überdauern, geprüft werden müssen oder jemand für sie geradesteht.
Braucht eine Entscheidungsperson
Ohne einen benannten Intent Owner mit Entscheidungsbefugnis läuft der Zyklus leer. Wo Ziele dauerhaft strittig sind, ist das ein Führungs- und kein Methodenproblem.
Kostet zu Beginn Zeit
Der Aufbau von Kernel und Rückverfolgbarkeit ist reale Anfangsinvestition. Sie amortisiert sich über die Prüfzyklen — aber sie fällt zuerst an. Wer in einer akuten Terminkrise steckt, sollte damit nicht starten.
Ist keine Software
KEEL ist ein Verfahren, kein Produkt. Es funktioniert in einem Git-Repository ebenso wie in einem Dokumentenverzeichnis. Das ist beabsichtigt: Es soll keine zusätzliche Abhängigkeit entstehen.
Macht Regulierung nicht überflüssig
Die entstehenden Nachweise unterstützen Anforderungen aus dem EU AI Act und aus Managementsystem-Normen erheblich, ersetzen aber weder eine Konformitätsbewertung noch Rechtsberatung.
KEEL steht nicht in Konkurrenz zu etablierten Standards. Es ist anschlussfähig an Stage-Gate-Prozesse, ergänzt die KI-Behandlung des PMBOK Guide um eine konkrete Arbeitsweise und liefert Material für Anforderungen aus dem EU AI Act und ISO/IEC 42001. In der Softwareentwicklung verhält es sich komplementär zu Spec-Driven-Ansätzen: Diese erzeugen Code aus Spezifikationen, KEEL steuert, entscheidet und belegt — auch dort, wo kein Code entsteht.