Wie ich meine KI-Architektur ohne technischen Hintergrund entworfen habe und was 42001 mich darüber gelehrt hat
Ich programmiere nicht. Dennoch habe ich eine funktionierende KI-Architektur entworfen und betreibe diese. Diese beiden Tatsachen sind weniger widersprüchlich, als sie klingen, und der Grund dafür erwies sich als die nützlichste Lektion über 42001, die ich außerhalb eines Kundenauftrags gelernt habe.
Dies ist keine Anleitung. Es ist eine Reflexion über Designentscheidungen und die dahinter stehende Governance-Logik, geschrieben von jemandem, der beruflich KI-Managementsysteme auditiert und beschlossen hat, denselben Blick auf sein eigenes Setup zu richten. Eine KI-Architektur ist in diesem Zusammenhang der zusammenhängende Aufbau von Tools, Wissensströmen und Kontrollpunkten, mit denen eine Person KI verantwortungsvoll arbeiten lässt.
Was die Architektur eigentlich ist
Das Setup ist ein verbundenes Set von Tools, kein Stapel loser Apps. Claude als Reasoning-Ebene. Confluence als persistente Wissensebene, in der Strategie, Seitendokumentation und Entscheidungshistorie leben und über Sitzungen hinweg verfügbar bleiben. Jira für strukturierte Aufgaben. Ahrefs für Daten, von denen die Arbeit abhängt. Diese sind über das Model Context Protocol verbunden, sodass die Reasoning-Ebene direkt aus der Wissensebene lesen und in diese schreiben kann, anstatt dass ich Text zwischen Fenstern kopiere.
Der Punkt sind nicht die spezifischen Tools. Es geht darum, dass die Architektur eine Form hat. Wissen bleibt an einem Ort bestehen. Arbeit verläuft über definierte Pfade. Die Reasoning-Ebene beginnt nicht jedes Mal bei Null, weil die Wissensebene sich erinnert.
Die Designprinzipien und woher sie kamen
Ich habe nicht mit einer Tool-Liste begonnen. Ich begann mit Prinzipien und bemerkte erst danach, dass sie fast exakt mit einer Norm übereinstimmten, die ich für andere implementiere.
Das erste Prinzip war persistentes Wissen. Alles, was das System benötigt, um gut zu schlussfolgern, sollte irgendwo dauerhaft verankert sein, nicht im flüchtigen Kontext eines einzelnen Gesprächs. Deshalb steht Confluence im Mittelpunkt. Das zweite waren reproduzierbare Workflows. Dieselbe Aufgabe sollte auf dieselbe Weise ablaufen, was bedeutet, dass die Schritte in der Dokumentation leben, nicht in meinem Gedächtnis. Das dritte war die menschliche Kontrolle an definierten Kontrollpunkten. Das System entwirft und schlägt vor. Ich beurteile und entscheide. Die Grenze zwischen diesen beiden ist explizit, nicht improvisiert. Das vierte waren Qualitätstore. Die Arbeit wird anhand einer Rubrik bewertet, bevor sie als fertig gilt, und der Schwellenwert ist schriftlich fixiert.
Diese vier Prinzipien sind ein Governance-Design. Ich habe das erst im Nachhinein erkannt, was die ehrliche Version der Geschichte ist.
Was 42001 über die von mir getroffenen Entscheidungen sagt
42001:2023 beginnt mit dem Kontext, Kap. 4.1. Verstehen Sie vor allem anderen die Umgebung, in der die KI operiert, und was sie erreichen soll. Das hatte ich getan, ohne es so zu benennen: Die Architektur wurde um das herum gebaut, was meine Praxis wirklich braucht, nicht um das, was die Tools konnten.
Kap. 6.1 erfordert eine Risikobeurteilung der KI-Nutzung. Der Entwurf meines eigenen Setups zwang mich zu fragen, wo etwas schiefgehen könnte, was passiert, wenn die Reasoning-Ebene mit Überzeugung falsch liegt, und welche Schritte einen Menschen im Prozess benötigen, eben weil die Kosten eines ungeprüften Fehlers hoch sind. Das ist eine Risikobeurteilung meiner eigenen KI-Nutzung, durchgeführt, weil der Aufbau des Systems die Risiken konkret gemacht hat.
Kap. 8.4 befasst sich mit der menschlichen Aufsicht. Die definierten Kontrollpunkte, an denen das System Vorschläge macht und ich entscheide, sind genau das. Keine Aufsicht als bloße Grundsatzerklärung, sondern eine in den Workflow integrierte Aufsicht als Schritt, der nicht übersprungen werden kann.
Was ein begrenzter technischer Hintergrund tatsächlich bewirkt hat
Ich hatte erwartet, dass mein Mangel an Programmierkenntnissen eine Einschränkung sein würde. Er wirkte eher wie ein Designfilter. Da ich nicht auf eine clevere technische Lösung zurückgreifen konnte, musste jede Entscheidung in einfachen Worten erklärbar und im Nachhinein prüfbar sein. Wenn ich nicht beschreiben konnte, warum ein Schritt funktionierte und wie ich erkennen würde, dass er fehlschlug, konnte ich ihn nicht bauen. Diese Disziplin machte die Architektur robuster, nicht weniger. Es gibt nichts darin, was ich nicht verantworten kann – genau die Eigenschaft, nach der ich suche, wenn ich die KI-Governance anderer auditiere.
Die nächste Ebene ist schwieriger. Mehrere Agenten, die zusammenarbeiten, Supervisor-Muster, die sie koordinieren, und die Fragen, die mit der Übertragung von mehr Autonomie an das System einhergehen. Das sind die Fragen, auf die ich jetzt hinarbeite, und es sind Governance-Fragen, bevor es technische Fragen sind. Wer ist verantwortlich, wenn ein Agent auf der Grundlage der Ausgabe eines anderen handelt? Wo befindet sich der menschliche Kontrollpunkt, wenn der Workflow mehr bewegliche Teile hat? Die Norm wird auch dazu etwas zu sagen haben.
Der Grund, dies aufzuschreiben, ist nicht das Setup selbst. Es ist die Tatsache, dass die Fragen, die ich beantworten musste, um es verantwortungsvoll aufzubauen, dieselben Fragen sind, die jede Organisation, die KI einsetzt, beantworten muss, ob es nun jemand so formuliert hat oder nicht. Wo lebt das Wissen? Wie werden Workflows reproduziert? Wo befindet sich der menschliche Kontrollpunkt? Was ist das Qualitätstor? Wie würden Sie erkennen, dass das System versagt hat? Dies sind genau die Fragen, die KI-Governance lösen sollte, und es ist derselbe Blickwinkel, den iQomply bei der Beurteilung anwendet, wie eine Organisation ihre eigene KI aufgebaut hat. Wenn Ihnen dadurch klar wurde, dass Sie diese Fragen für Ihr eigenes KI-Setup nicht vollständig beantworten können, dann ist diese Erkenntnis der nützliche Teil. Ein KI-Architektur-Review legt denselben Governance-Blick auf die KI Ihrer Organisation, und das ist eine Arbeit, um die iQomply immer häufiger gebeten wird. Der einfachste erste Schritt ist ein Gespräch.
Häufig gestellte Fragen
Nein. Eine funktionierende Architektur erfordert Design Thinking, Klarheit darüber, wie Wissen fließt, und ein Governance-Mindset mehr als Programmierkenntnisse. Ein begrenzter technischer Hintergrund kann sogar als nützlicher Filter dienen, da er jede Entscheidung dazu zwingt, erklärbar und prüfbar zu sein, anstatt von einer cleveren technischen Lösung abhängig zu sein.
Auf die gleiche Weise wie für die eines Kunden. Kap. 4.1 verlangt von Ihnen, den Kontext zu verstehen, in dem Ihre KI operiert. Kap. 6.1 erfordert eine Risikobeurteilung Ihrer KI-Nutzung. Kap. 8.4 erfordert menschliche Aufsicht. Der Aufbau einer Architektur um persistentes Wissen, reproduzierbare Workflows und definierte menschliche Kontrollpunkte erfüllt diese Klauseln in der Praxis, nicht nur auf dem Papier.
Das System entwirft und schlägt vor. Der Mensch beurteilt und entscheide. Die Grenze zwischen diesen beiden ist als Kontrollpunkt in den Workflow integriert, der nicht übersprungen werden kann – genau das, was Kap. 8.4 mit menschlicher Aufsicht meint. Es ist ein geplanter Schritt, keine bloße Grundsatzerklärung.
Es wirft einen Governance-Blick darauf, wie eine Organisation ihre KI aufgebaut hat: wo Wissen lebt, wie Workflows reproduziert werden, wo menschliche Kontrollpunkte liegen und wie Fehler erkannt würden. Dieselben Fragen, die in den Aufbau einer verantwortungsvollen Architektur einfließen, sind die Fragen, die zur Beurteilung einer bestehenden Architektur verwendet werden.
