Wenn Governance zum Laufzeitproblem wird
Die Policy, die den Antrag verpasste
Das Governance-Meeting war gründlich. Die Risiken wurden aufgelistet. Der Anwendungsfall wurde klassifiziert. Die Datenquellen wurden freigegeben. Die Rechtsgrundlage wurde festgehalten. Für Fälle mit hoher Auswirkung war menschliche Aufsicht erforderlich. Das Protokoll war sauber genug, um einen Compliance-Beauftragten kurz an die Zivilisation glauben zu lassen. Dann ging das System live, und der erste unangenehme Antrag traf um 09:14 Uhr an einem Dienstag ein.
Der Antrag kümmerte sich nicht darum, dass der Ausschuss monatlich tagte. Er brachte eine Benutzerrolle, eine Kundendatei, eine Policy-Version, eine Modellroute, eine Tool-Berechtigung, eine Frage zur Datenresidenz, ein Budgetlimit und eine mögliche externe Auswirkung mit. Der Workflow musste in Sekunden entscheiden, ob er abrufen, generieren, eskalieren, ablehnen, protokollieren, benachrichtigen oder handeln sollte. Governance war kein Dokument mehr hinter dem System. Sie war zu einem Laufzeitproblem im System geworden.
An diesem Punkt spüren viele KI-Programme, wie der Boden unter ihnen wegrutscht. Das Governance-Design war nicht unbedingt falsch. Der Vorstand war nicht töricht. Die Policy-Sprache war vielleicht sogar gut. Das Problem ist, dass KI-Systeme in Bewegung handeln. Sie ziehen frische Kontexte, rufen Tools auf, überschreiten Servicegrenzen, nutzen Daten wieder, erzeugen neue Artefakte und laden Menschen ein, sich auf die Ergebnisse zu verlassen. Eine Policy, die nicht in diese Bewegung eintreten kann, wird zu einem Nachschlagewerk. Nützlich vielleicht. Nicht ausreichend.
Laufzeit-Governance bedeutet, dass das System Governance-Bedingungen bewerten kann, während die Arbeit stattfindet. Wer fragt. Zu welchem Zweck. Welche Daten verwendet werden dürfen. Welches Modell erlaubt ist. Welches Tool handeln darf. Welche Rechtsordnung gilt. Welches Budget akzeptabel ist. Welche Fälle eine menschliche Prüfung benötigen. Welcher Datensatz geschrieben werden muss. Welcher Weg für Einspruch besteht. Das sind nicht nur Beschaffungsfragen oder Fragen der Jahresprüfung. Es sind Fragen des Antragspfads.
Dokumente zählen weiterhin
Es gibt eine modische Versuchung, Governance-Dokumente zu verspotten. Policies, Register, Folgenabschätzungen, Risikorahmen, Lieferantenbewertungen, Modellkarten, DPIAs, Beschaffungsnotizen, Aufbewahrungspläne. Sie können durchaus dekorativ werden. Manche Dokumente sind mit der gequälten Eleganz von Menschen geschrieben, die wissen, dass niemand über Seite fünf hinausliest. Aber die Antwort ist nicht, Dokumente zu verachten. Die Antwort ist, aufzuhören, so zu tun, als wären sie die endgültige Form von Governance.
Dokumente beschreiben Absicht, Verantwortung, Umfang, Risiko und Auslegung. Sie schaffen ein institutionelles Gedächtnis. Sie ermöglichen es Menschen, vor der Bereitstellung zu argumentieren, statt nach einem Schaden. Sie geben Prüfern, Käufern, Ingenieuren, Juristen und Managern eine gemeinsame Grundlage. Das ist wertvoll. Runtime-Governance hängt davon ab. Ein System kann keine Richtlinie bewerten, die niemand geschrieben hat. Es kann keinen Zweck durchsetzen, den niemand definiert hat. Es kann keine Nachweise gemäß einem Zeitplan aufbewahren, der nicht existiert.
Das Problem beginnt, wenn ein Dokument so behandelt wird, als würde es ausgeführt. Eine Richtlinie besagt, dass risikoreiche Ausgaben eine Überprüfung erfordern, aber der Workflow hat keinen Status für erforderliche Überprüfung. Eine Risikobewertung besagt, dass ein Modell keine sensible Quelle verwenden darf, aber die Abfrage hat keinen Schutz für den Quellenumfang. Eine Beschaffungsnotiz besagt, dass der Anbieter die Prüfung unterstützen muss, aber die Integration speichert nur aggregierte Protokolle. Ein Aufbewahrungsplan besagt, dass Datensätze ablaufen, aber generierte Artefakte wandern ohne Herkunftsnachweis in nachgelagerte Systeme. Das Dokument hat seinen Teil erfüllt. Die Runtime hat die Mitteilung nicht erhalten, was keine Metapher ist, wenn die Mitteilung buchstäblich per E-Mail gesendet wurde.
Gute Governance hat daher einen Übersetzungsschritt. Die geschriebene Richtlinie wird zu Runtime-Bedingungen: Gates, Rollen, Schwellenwerte, Schemata, Protokolle, Warnungen, Beschwerdewege, Aufbewahrungsregeln und Freigabeprüfungen. Nicht jeder Satz wird zu Code. Einiges Urteilsvermögen bleibt menschlich. Aber das System muss wissen, welche Teile operativ sind. Sonst wird Governance zu einem zeremoniellen Dach über einem Gebäude ohne Wände.
Der Anforderungspfad ist der Ort, an dem Zusagen auf die Probe gestellt werden
KI-Governance wird oft auf Systemebene diskutiert. Ist dieses System genehmigt. Ist dieses Modell vertrauenswürdig. Ist dieser Anwendungsfall akzeptabel. Diese Fragen sind wichtig, aber das tatsächliche Risiko zeigt sich auf der Ebene der Anforderungen. Dasselbe System kann für einen Benutzer ein geringes Risiko und für einen anderen ein hohes Risiko darstellen. Dasselbe Modell kann für das Entwerfen akzeptabel und für autonomes Handeln inakzeptabel sein. Dieselben Daten können für den Support erlaubt und für Marketing verboten sein. Dieselbe Antwort kann intern harmlos und extern folgenreich sein, wenn sie nach außen gesendet wird.
Runtime-Governance erkennt diese Unterschiede, weil sie den Kontext bewertet. Eine Anforderung von einem geschulten Mitarbeiter mit einem engen Zweck ist nicht dasselbe wie eine Anforderung von einem externen Benutzer mit breitem Tool-Zugriff. Eine Abfrage über öffentliche Dokumentation ist nicht dasselbe wie eine Abfrage aus einer sensiblen Fallakte. Ein Entwurf einer Nachricht ist nicht dasselbe wie eine gesendete Nachricht. Eine Empfehlung, die ein Mensch ignorieren darf, ist nicht dasselbe wie eine Entscheidung, die einen Datensatz aktualisiert. Der Anforderungspfad ist der Ort, an dem diese Unterscheidungen real werden.
Das bedeutet nicht, dass jede Anforderung ein juristisches Seminar benötigt. Es bedeutet, dass das System genügend Kontext tragen sollte, um korrekt zu routen. Identität, Zweck, Datenklasse, Auswirkungsklasse, Modellfreigabe, Tool-Umfang, Zuständigkeit, Umkehrbarkeit, menschliche Rolle und Nachweisanforderung. Viele Prüfungen sind einfach, sobald sie benannt sind. Der schwierige Teil ist nicht immer die Berechnung. Der schwierige Teil ist zuzugeben, dass der Kontext wichtig ist, und sich zu weigern, ihn aus Bequemlichkeit zu glätten.
Bequemlichkeit ist der Ort, an dem Runtime-Governance normalerweise verloren geht. Ein Entwickler fügt eine Abkürzung hinzu, weil die Überprüfungswarteschlange langsam ist. Ein Produktteam verwendet eine Datenquelle erneut, weil die Feldnamen übereinstimmen. Ein Manager genehmigt eine vorübergehende Ausnahme, weil der Start bevorsteht. Ein Prompt erhält eine neue Anweisung, weil das Richtlinien-Gate nicht bereit ist. Jeder Schritt mag verständlich sein. Zusammen bauen sie ein System, in dem Governance im Geiste existiert und im Pfad versagt. Geist ist eine schlechte Runtime-Abhängigkeit.
Richtlinien-Gates sind keine Richtlinien-Eigentümer
Eine Runtime-Gate kann eine Bedingung durchsetzen, aber sie besitzt nicht die Bedeutung der Bedingung. Dieser Unterschied ist wichtig. Eine Policy-Eigentümerin entscheidet, welche Fälle eine Prüfung erfordern, welche Quellen zulässig sind, welche Aufbewahrungsfrist gilt und welche Schäden von Bedeutung sind. Eine Gate wendet diese Entscheidungen schnell an. Wenn die Organisation die beiden verwechselt, wird Engineering stillschweigend zu Policy, oder Policy tut so, als sei das Implementierungsdetail das Wetter von jemand anderem.
Das gesunde Muster ist ein Vertrag zwischen Policy und Runtime. Policy-Eigentümer definieren Regeln, Schwellenwerte, Ausnahmen und Prüfungspflichten. Ingenieure implementieren Gates, Tests, Aufzeichnungen und Fehlermodi. Betreiber überwachen, ob die Gates wie erwartet auslösen. Prüfer geben Rückmeldung, wo Regeln absurde Ergebnisse erzeugen. Governance-Gremien prüfen die Belege und ändern die Policy, wenn die Realität unhöflich war. Das ist Governance als Kreislauf, nicht als gerahmtes PDF.
Policy-Gates benötigen auch Versionierung. Eine Anfrage, die nach der Regel von letztem Monat bearbeitet wurde, sollte später nicht so beurteilt werden, als hätte die heutige Regel existiert. Ein laufender Fall kann eine Policy-Version überschreiten. Ein Modell kann Entwürfe unter einer Schwelle und Aktionen unter einer anderen erzeugen. Wenn das System nur den aktuellen Policy-Zustand aufzeichnet, werden Audits zu Zeitreisen mit schlechter Beschilderung. Die Aufzeichnung muss sagen, welche Regelversion auf welchen Übergang angewendet wurde.
Hier gibt es eine bescheidene Disziplin, die viel Drama erspart. Behandle Policy wie eine lebende Abhängigkeit. Gib ihr Kennungen. Gib ihr Eigentümer. Teste sie. Stufe sie ein. Rolle sie zurück. Beobachte sie. Zeichne ihre Entscheidungen auf. Das macht Policy nicht mechanisch. Es macht den mechanischen Teil ehrlich genug, damit Menschen den Rest regieren können.
Lokalität macht Governance zu Routing
Datenlokalität wurde früher als Speicherproblem diskutiert. Wo ist die Datenbank. Welche Region. Welcher Anbieter. Welches Backup. In KI-Systemen wird Lokalität aktiver. Der Abruf kann Daten aus einer Region ziehen, ein Modell kann in einer anderen laufen, ein Tool kann einen Drittanbieterdienst aufrufen, und eine menschliche Prüferin kann unter einem anderen Rechtsregime sitzen. Die Frage ist nicht mehr nur, wo Daten ruhen. Es ist, wo Arbeit Grenzen überschreitet.
Runtime-Governance muss daher nach Lokalität routen. Einige Daten können ein Gerät nur als Aggregat verlassen. Einige Aufzeichnungen können in einer Rechtsordnung verarbeitet werden, aber nicht in einer anderen. Einige Anbieter können für geringe Sensibilität zugelassen und für höhere Klassen gesperrt sein. Einige Modellrouten können für öffentlichen Text erlaubt sein, aber nicht für persönliche Dateien. Einige Protokolle können lokal bleiben, auch wenn der Modellaufruf remote ist. Diese Entscheidungen können nicht nur zur Beschaffungszeit gelöst werden. Die Live-Anfrage trägt die Antwort.
Lokalität ist nicht nur Recht. Sie ist Leistung, Resilienz, Sicherheit, Kosten und institutionelle Kontrolle. Ein lokales Modell kann langsamer, aber für sensible Arbeit akzeptabler sein. Ein Remote-Dienst kann billiger, aber für bestimmte Aufzeichnungen ungeeignet sein. Ein regionaler Index kann Latenz reduzieren, aber Versionsdivergenz erzeugen. Ein Anbieter kann Verschlüsselung unterstützen, aber nicht das für Audits benötigte Exportformat. Runtime-Governance löst diese Abwägungen nicht magisch. Sie macht sie explizit, bevor das System Arbeit über eine Grenze sendet.
Die Alternative ist verstecktes Routing. Der Workflow ruft jeden Endpunkt auf, der bequem ist. Der Endpunkt ruft einen anderen Dienst auf. Protokolle bewegen sich woanders hin. Abgeleitete Daten erscheinen in Analysen. Sechs Monate später fragt jemand, wohin ein Fall gegangen ist. Die Antwort erfordert ein Diagramm, zwei Ingenieure und ein überraschendes Maß an Optimismus. Das ist keine Governance. Es ist Kartografie nach der Expedition.
Budgets sind Governance, keine Finanzspielerei
KI-Budgets werden oft besprochen, nachdem die Rechnungen eingetroffen sind, was ein wenig zu spät ist, so wie es zu spät ist, den Stall zu schließen, nachdem das Pferd einen Premium-Token-Plan abonniert hat. Kosten sind ein Laufzeit-Governance-Problem, weil unkontrollierte Kosten das Verhalten verändern. Teams deaktivieren Traces. Sie verkürzen die Auswertung. Sie vermeiden menschliche Überprüfung. Sie senken die Quellenqualität. Sie bündeln zu aggressiv. Sie lassen Agentenschleifen umherschweifen. Ein Kostenproblem wird zu einem Kontrollproblem mit Buchhaltung.
Ein Laufzeitsystem sollte das Budget als Teil der Route kennen. Wie viele Modellaufrufe darf diese Anfrage machen. Welche Tools sind erlaubt. Wie viel Kontext ist gerechtfertigt. Wie viele Wiederholungen. Wann sollte ein Agent aufhören. Wann ist eine günstigere Route akzeptabel. Wann verdient ein Fall mit hoher Auswirkung teurere Nachweise. Kosten sind nicht nur eine Obergrenze. Sie sind eine Möglichkeit, Prioritäten auszudrücken und außer Kontrolle geratenes Verhalten zu verhindern.
Budgetwächter verringern auch Sicherheitsrisiken. Eine Schleife, die Geld verbrennt, kann auch Aktionen wiederholen, Nachrichten duplizieren, Datensätze sperren oder einen Anbieter belasten. Ein Abrufprozess, der zu viele Daten zieht, kann die Datenschutzexposition erhöhen. Ein Zusammenfassungsauftrag, der jedes Dokument verarbeitet, kann abgeleitete Datensätze mit neuen Pflichten erzeugen. Schrittlimits, Kontingente, Stornierung und Metriken zu Kosten pro nützlichem Ergebnis sind Governance-Kontrollen. Sie sind weniger edel als Werteerklärungen und stoppen die Maschine eher im richtigen Moment.
Das bedeutet nicht, dass die günstigste Route die verantwortungsvolle Route ist. Manchmal kosten stärkere Nachweise mehr. Manchmal kostet lokale Verarbeitung mehr und ist trotzdem richtig. Manchmal ist menschliche Überprüfung teuer, weil sie der Punkt ist. Laufzeit-Governance sollte diese Entscheidungen sichtbar machen. Das Ziel ist nicht billige KI. Das Ziel ist KI, deren Kosten, Nachweise und Risiken verstanden werden, während die Arbeit läuft.
Die Fehlermodi riechen vertraut
Fehler in der Laufzeit-Governance kommen selten mit einem Schild. Sie riechen vertraut. Richtliniendrift. Schatten-Tools. Überschreitung. Fehlende Berufung. Budgetschleifen. Veraltete Einwilligung. Das sind keine exotischen KI-Monster. Es sind gewöhnliche organisatorische Fehler, die durch Software beschleunigt werden. Das ist fast schlimmer, denn gewöhnliche Fehler sind leicht zu entschuldigen, bis sie zur Infrastruktur werden.
Policy-Drift entsteht, wenn sich die geschriebene Regel ändert, der Laufzeitpfad jedoch nicht, oder wenn sich der Laufzeitpfad ändert, die geschriebene Regel jedoch nicht. Schattenwerkzeuge entstehen, wenn Teams langsame Kontrollen mit inoffiziellen Integrationen umgehen. Übergriffigkeit entsteht, wenn ein System, das für Unterstützung freigegeben wurde, stillschweigend Einfluss auf Durchsetzung, Preise oder Zugriff nimmt. Fehlende Beschwerdemöglichkeit entsteht, wenn Nutzer ein KI-geprägtes Ergebnis erhalten, es aber nicht auf eine Weise anfechten können, die im Protokoll landet. Budgetschleifen entstehen, wenn Agenten oder Stapeljobs weiterhin Geld ausgeben, nachdem die nützliche Arbeit beendet ist. Veraltete Einwilligung entsteht, wenn alte Berechtigungen als frisch behandelt werden, weil niemand die Einwilligung in den Anfragepfad aufgenommen hat.
Die sinnvolle Reaktion ist nicht Panik. Sie ist Instrumentierung. Benennen Sie die Fehlerart. Fügen Sie eine Absicherung hinzu, wo sie verhindert werden kann. Fügen Sie eine Warnung hinzu, wo sie erkannt werden kann. Fügen Sie eine verantwortliche Stelle hinzu, wo sie behoben werden kann. Fügen Sie einen Datensatz hinzu, wo er geprüft werden muss. Manche Fehler erfordern eine Richtlinienänderung. Manche erfordern eine Schnittstellenänderung. Manche erfordern Datenverträge. Manche erfordern Disziplin bei der Beschaffung. Laufzeit-Governance hilft, weil sie der Organisation einen Ort bietet, an dem sie die Korrektur anbringen kann.
Sie offenbart auch unbequeme Wahrheiten. Ein Gate kann zeigen, dass einem beliebten Anwendungsfall die rechtliche Grundlage fehlt. Eine Einwilligungsprüfung kann zeigen, dass die Datenpipeline nicht so sauber ist wie die Folienpräsentation. Ein Budgetlimit kann zeigen, dass sich das Geschäftsmodell nur trägt, wenn die Evaluierung unterfinanziert ist. Ein Beschwerdeprotokoll kann zeigen, dass eine Richtlinie und nicht ein Modell unfaire Ergebnisse erzeugt. Gute Governance-Belege sind unhöflich. Das ist eine ihrer besten Eigenschaften.
Menschliche Governance muss im Kreislauf bleiben
Laufzeit-Governance ist kein Plan, um Menschen aus der Governance zu entfernen. Ganz im Gegenteil. Sie gibt Menschen bessere Orte zum Eingreifen. Ein Vorstand kann nicht jede Anfrage bewerten. Ein Richtlinienverantwortlicher kann nicht jeden Tool-Aufruf genehmigen. Ein Jurist kann nicht in jeder Abrufentscheidung sitzen. Ein Prüfer kann nicht jeden Entwurf mit geringem Risiko inspizieren. Das System muss gewöhnliche Prüfungen übernehmen. Menschen müssen die Regeln, Ausnahmen, strittigen Fälle, die Auslegung und die Behebung verantworten.
Der Schlüssel ist das Eskalationsdesign. Wann sollte das System anhalten und fragen. Wann sollte es ohne Nachfrage ablehnen. Wann sollte es erlauben und aufzeichnen. Wann sollte es für eine spätere Überprüfung Stichproben ziehen. Wann sollten wiederholte Signale mit geringem Risiko zu einem Muster mit hohem Risiko werden. Wann sollte eine Nutzerbeschwerde einen abgeschlossenen Zustand wieder öffnen. Dies sind Governance-Entscheidungen. Sie sollten nicht in Prompts, Warteschlangenstandards oder dem heldenhaften Urteil der Person versteckt sein, die gerade Bereitschaft hat.
Runtime evidence improves human governance because it gives committees something better than anecdotes. The governance group can see how often gates blocked, where exceptions clustered, which appeals succeeded, which suppliers caused friction, which policies slowed work, and which model routes created incidents. Then the meeting becomes about evidence. It may still be long. We should not promise miracles. But at least it has a chance of being useful.
People also remain necessary because policy sometimes conflicts with reality. A rule may be legally correct and operationally cruel. A data source may be permitted and still socially risky. A model may perform well in aggregate and fail a vulnerable edge case. A budget limit may save money and create unfair delay. Runtime systems can surface those conflicts. People must decide what they mean.
Runtime governance changes procurement
Buying AI without runtime governance support is buying future uncertainty. A supplier may have excellent models, pleasant demos, certifications, and confident slides. The practical questions are less glamorous. Can the system expose policy decisions per request. Can model and prompt versions be pinned. Can data locality be enforced dynamically. Can tool calls be scoped and recorded. Can logs be separated by purpose. Can evidence be exported in a usable format. Can an institution leave with its records. Can a case be replayed when the supplier has changed its platform.
These questions are not hostile to suppliers. They are adult. A supplier that supports runtime governance helps the buyer operate responsibly. A supplier that cannot support it may still be useful for low-risk tasks, but the buyer should know the boundary. The worst outcome is pretending that a general capability is suitable for consequential work merely because the demo did not include a governance problem. Demos rarely do. That is why they fit in rooms with snacks.
Procurement should also ask about failure. What happens when a policy gate is unavailable. Does the system fail closed, fail open, or route to review. What happens when a model is deprecated. What happens when a region becomes unavailable. What happens when an audit export is requested. What happens when a user asks for deletion. What happens when logs contain sensitive data. The answer to governance is often hidden in the failure mode.
Runtime governance does not require every supplier to reveal every internal method. It requires the service boundary to be accountable. The buyer needs enough control and evidence to meet its own duties. If a black-box component can sit safely behind a governed boundary, fine. If the boundary itself is black box, the buyer has outsourced not only capability but also part of its ability to answer for the work.
Governance as an operating loop
The mature pattern is an operating loop. Sense what is happening. Evaluate context. Gate the action. Act within limits. Review outcomes. Update rules, data, models, and interfaces. This loop runs at different speeds. Some checks happen per request. Some daily. Some after release. Some quarterly. Some after incidents. The important part is that the loops connect. A complaint should reach evaluation. An appeal should reach policy. A policy change should reach gates. A model upgrade should reach tests. A supplier incident should reach routing.
This is how governance becomes less theatrical. It stops being a set of ceremonies around a system and becomes a property of the system's operation. The organisation can still have committees, registers, policies, and reports. It should. But those artefacts now connect to live evidence. The governance meeting can ask what the system did, not only what the system claims to be.
Ein Betriebszyklus macht Governance außerdem anpassungsfähiger. KI-Systeme ändern sich. Gesetze ändern sich. Daten ändern sich. Das Nutzerverhalten ändert sich. Modelle ändern sich. Lieferantenbedingungen ändern sich. Eine statische Genehmigung kann das alles nicht abdecken. Runtime-Governance löst Unsicherheit nicht, indem sie die Welt einfriert. Sie gibt der Organisation eine Möglichkeit, zu erkennen, zu entscheiden und zu aktualisieren, ohne die Verantwortung für frühere Entscheidungen zu verlieren.
Der Zyklus muss ein Gedächtnis haben. Sonst wird Anpassung zu stillem Umschreiben. Wenn sich eine Regel ändert, brauchen alte Fälle weiterhin ihren alten Kontext. Wenn eine Modellroute ausgemustert wird, brauchen vergangene Entscheidungen weiterhin eine Erklärung. Wenn eine Quelle entfernt wird, brauchen abgeleitete Ausgaben weiterhin ihre Herkunft. Runtime-Governance sollte Veränderung unterstützen, ohne die Gründe auszulöschen, die zuvor bestanden. Das ist ein unscheinbarer Satz mit großer Tragweite.
Die Lektion
Governance wird zu einem Runtime-Problem, wenn KI-Systeme schneller, breiter und kontextbezogener agieren, als Vorstandsartefakte allein verwalten können. Die Antwort ist nicht, Governance-Dokumente aufzugeben oder menschliches Urteilsvermögen durch Code zu ersetzen. Die Antwort ist, Dokumente, Rollen, Richtlinien, Gates, Aufzeichnungen und Review-Schleifen so zu verbinden, dass Governance arbeiten kann, während die Arbeit geschieht.
Runtime-Governance prüft Identität, Zweck, Daten, Lokalität, Modellroute, Tool-Berechtigung, Budget, menschliche Überprüfung, Evidenz, Einspruch und Aufbewahrung im Live-Pfad. Sie behandelt Richtlinien als Live-Abhängigkeiten. Sie leitet bewusst über rechtliche und betriebliche Grenzen. Sie protokolliert, welche Regel angewendet wurde. Sie benennt Fehlermodi, bevor sie zur Gewohnheit werden. Sie gibt Menschen Evidenz statt Anekdoten.
Das ist eine weniger romantische Sicht auf Governance und eine nützlichere. Die ernste Frage ist nicht, ob die Organisation einen KI-Governance-Rahmen hat. Die ernste Frage ist, was um 09:14 Uhr an einem Dienstag passiert, wenn eine echte Anfrage das System bittet, sich zu bewegen. Wenn die Antwort geprüft, begrenzt, protokolliert und überprüfbar ist, läuft Governance. Wenn die Antwort ist, dass die Richtlinie in einem Ordner liegt, wartet Governance immer noch auf die Bürozeiten.