
KI-Governance, die liefert: den EU AI Act als Deployment-Gate statt als Gremium umsetzen
Der EU AI Act wird jene Unternehmen nicht bremsen, die Governance als Code behandeln. Er wird jene begraben, die Governance als Lenkungsausschuss verstehen, der tagt, nachdem das Modell längst live ist.
Die meiste KI-Governance in Unternehmen besteht heute aus einem Dokument und einem Meeting. Ein Policy-PDF, das niemand liest, und ein Gremium, das KI-Initiativen quartalsweise prüft – meist nachdem sie ausgeliefert wurden. Das stellt einen Auditor genau einen Zyklus lang zufrieden und verhindert keines der eigentlichen Risiken, denn die Risiken entstehen zum Zeitpunkt des Deployments, und das Gremium tagt nach Kalender.
Die Unternehmen, die den EU AI Act aufnehmen, ohne zum Stillstand zu kommen, sind jene, die Governance als Gate in der Deployment-Pipeline neu aufbauen: automatisiert, belegt und durchgesetzt in dem Moment, in dem ein Modell in Produktion geht – statt Monate später darüber zu debattieren. Wir haben das für regulierte Kunden gebaut, und es ist weniger Aufwand als das Gremium – und weit besser zu verteidigen.
Das eigentliche Problem: Governance ist vom Deployment entkoppelt
Wenn Governance in einem Quartalsmeeting lebt und das Deployment in einer CI/CD-Pipeline, laufen die beiden nach unterschiedlichen Uhren. Modelle werden kontinuierlich ausgeliefert; Aufsicht findet periodisch statt. In der Lücke dazwischen erreichen ungeprüfte Systeme die Kundschaft. Schlimmer noch: Die Freigabe des Gremiums ist eine Momentaufnahme – sie sagt nichts über das Modell aus, das drei Wochen später neu trainiert und erneut deployt wurde.
Der EU AI Act macht diese Lücke zur Haftungsfrage. Seine Pflichten für Hochrisikosysteme – Risikomanagement, Data Governance, Logging, menschliche Aufsicht, technische Dokumentation – sind keine einmaligen Abnahmen. Sie sind fortlaufende Eigenschaften eines Systems in Produktion. Eine fortlaufende Pflicht lässt sich nicht mit einem kalendergesteuerten Meeting erfüllen.
Ein Rahmen: Governance als Deployment-Gate
Behandeln Sie Compliance so, wie Sie Security und Tests behandeln – als Prüfungen, die bestanden sein müssen, bevor ein Modell in Produktion befördert werden kann, und die als Nebenprodukt automatisch Nachweise erzeugen. Konkret durchläuft jedes Modell-Deployment ein Gate, das Folgendes prüft und festhält:
- Risikoklassifizierung. Das System wird mit seiner Risikostufe nach AI Act markiert (verboten / hoch / begrenzt / minimal). Hochrisikosysteme lösen das volle Prüfset aus; Systeme mit minimalem Risiko erhalten einen schlanken Pfad. Kein Deployment ohne hinterlegte Klassifizierung.
- Data Lineage. Welche Daten dieses System trainiert haben oder ihm als Grundlage dienen, woher sie stammen, auf welcher Rechtsgrundlage und wo sie verarbeitet werden. Erfasst als Metadaten, nicht als Word-Dokument.
- Evaluationsnachweise. Das Modell hat seine Eval-Suite für Qualität, Bias und Sicherheit bestanden, und die Ergebnisse sind gespeichert und gegen genau diesen Build versioniert.
- Design der menschlichen Aufsicht. Für alles, was eine folgenreiche Entscheidung berührt, bestätigt das Gate, dass ein definierter Human-in-the-Loop- oder Human-on-the-Loop-Mechanismus existiert und eingebunden ist.
- Logging und Nachvollziehbarkeit. Das System gibt die Inputs, Outputs und Entscheidungen aus, die nötig sind, um jeden Einzelfall später zu rekonstruieren. Das Gate prüft, dass das Logging tatsächlich aktiv ist.
- Transparenzpflichten. Kundenseitige KI gibt sich als solche zu erkennen; generierte Inhalte werden gekennzeichnet. Geprüft, nicht angenommen.
Die Verschiebung ist subtil und umfassend: Governance ist nicht länger etwas, das ein Gremium behauptet, sondern etwas, das die Pipeline bei jedem Deployment beweist – mit einem Audit Trail, den Sie nicht von Hand zusammenstellen mussten.
Praxisbeispiel: die Model Registry als Kontrollpunkt
Eine Krankenversicherung hatte elf KI-/ML-Systeme in Produktion und einen Governance-Prozess, der aus einer jährlichen Überprüfung und einer Tabelle bestand. Die Tabelle war bereits falsch – drei Systeme waren seit der letzten Überprüfung neu trainiert worden, und eines hatte sich still und leise von einem internen Tool zu einem versichertenseitigen entwickelt, womit sich seine Risikostufe änderte, ohne dass es jemand neu beurteilt hatte.
Wir haben eine Model Registry zum verpflichtenden Kontrollpunkt gemacht. Nichts gelangt ausser über sie in Produktion, und die Registrierung erfordert die Metadaten des Gates. Die Zahlen, die für den Verwaltungsrat zählten:
- Zeit bis zur Antwort auf «Zeigen Sie mir jedes Hochrisiko-KI-System, seine Datenquellen und seine letzte Evaluation»: von rund 3 Wochen manueller Nachforschung auf eine einzige Abfrage.
- Vorbereitung von Audit-Nachweisen für eine Anfrage der Aufsichtsbehörde: von geschätzt rund 120 Personenstunden auf weniger als einen Tag, weil die Nachweise beim Deployment erzeugt und nicht nachträglich rekonstruiert werden.
- Ungeprüfte Produktionsmodelle: von 3, die im Nachhinein entdeckt wurden, auf 0 mögliche – das Gate befördert kein unklassifiziertes System.
Der Punkt, der das Gespräch mit der Geschäftsleitung verändert hat: Mit dem Gate kam man schneller durch die Compliance als mit dem alten Gremium, denn eine automatisierte Prüfung, die in Minuten besteht, schlägt ein Meeting, auf das man sechs Wochen wartet. Governance war nicht mehr das, was KI bremst, sondern das, was ein Deployment mit Zuversicht ermöglicht.
Der Einwand: «Bremst ein Gate nicht unsere Teams aus?»
Das ist die erste Frage, die jede Engineering-Leitung stellt, und sie beruht auf einem falschen Vergleich. Die Alternative zu einem Deployment-Gate ist nicht «keine Governance, volle Geschwindigkeit» – sie ist das Gremium, die Tabelle und das hektische Nachbessern, wenn etwas schiefgeht. Daran gemessen ist ein automatisiertes Gate dramatisch schneller. Eine Prüfung, die in Minuten läuft und besteht, wenn die Metadaten vorhanden sind, schlägt das wochenlange Warten auf einen Meeting-Termin – und sie beseitigt die viel grösseren Kosten, ein ungeprüftes System in Produktion zu entdecken und unter regulatorischem Druck nachbessern zu müssen.
Der Trick, der das Gate schnell hält, ist die Abstufung. Die meisten Deployments haben minimales Risiko und sollten einen schlanken Pfad problemlos passieren – eine Klassifizierung und grundlegendes Logging, automatisch geprüft, ohne Menschen im Loop. Nur die Hochrisikostufe löst das volle Prüfset aus, und selbst das sind überwiegend automatisierte Prüfungen, ob Artefakte vorhanden sind und Evals bestanden wurden – keine subjektiven Reviews. Eine menschliche Prüfperson kommt nur bei wirklich neuartigen Hochrisikosystemen ins Spiel, und die sind selten. So umgesetzt, erleben 90 % der Deployments das Gate als ein paar Sekunden CI, und die 10 %, die genaues Hinsehen verdienen, bekommen es konsequent – statt davon abzuhängen, ob jemand daran gedacht hat, ein Meeting einzuberufen.
Dazu kommt eine kulturelle Dividende. Wenn Governance ein vorhersehbares, automatisiertes Gate ist, sehen Engineers Compliance nicht mehr als Gegner, sondern behandeln die geforderten Metadaten als weiteren Teil der «Definition of Done», wie Tests. Das Risikoteam muss den Teams nicht mehr wegen Dokumentation nachlaufen, weil die Pipeline sie erzeugt. Beide Seiten bekommen, was sie wollen: Die Engineers können ausliefern, ohne auf ein Gremium zu warten, und das Risikomanagement erhält vollständige, aktuelle Nachweise ohne manuelles Nachfassen. Die Reibung zwischen den beiden Funktionen – meist der eigentliche Engpass bei regulierter KI – nimmt ab, weil das Gate Verhandlung durch einen gemeinsamen, automatisierten Standard ersetzt.
Stolpersteine
- Policy ohne Durchsetzung. Ein Governance-Dokument ohne Pipeline-Gate ist Theater. Wenn ein nicht konformes Modell trotzdem in Produktion gelangen kann, ist Ihre Policy ein Wunsch.
- Freigabe als dauerhaft betrachten. Ein Modell wird bei jedem Retraining und bei jeder Änderung des Verwendungszwecks neu beurteilt. Eine Abnahme zu einem Zeitpunkt deckt kein System ab, das sich weiterentwickelt.
- Das Modell regeln, die Daten ignorieren. Der grösste Teil der Exposition gegenüber dem AI Act liegt in Herkunft und Verwendung der Daten, nicht in den Modellgewichten. Lineage ist das Herzstück des Nachweispakets.
- Systeme mit minimalem Risiko überregulieren. Wenn jedes interne Produktivitätstool den vollen Hochrisikoprozess durchlaufen muss, umgehen die Teams die Governance komplett. Stufen Sie die Strenge nach dem Risiko ab.
- Es als Papierkram aufbauen. Werden die Nachweise von Hand zusammengestellt, sind sie beim Audit veraltet. Erzeugen Sie sie aus der Pipeline.
Entscheidungs-Checkliste
- Gibt es eine einzige Registry, die jedes Produktionsmodell durchlaufen muss?
- Erfordert ein Deployment eine hinterlegte Risikoklassifizierung?
- Wird die Data Lineage zum Zeitpunkt des Deployments als Metadaten erfasst?
- Werden Evaluationsergebnisse pro Build gespeichert und versioniert?
- Ist für folgenreiche Entscheidungen geprüft, dass menschliche Aufsicht eingebunden ist?
- Können Sie das «Zeigen Sie mir alles» einer Aufsichtsbehörde mit einer Abfrage beantworten statt mit einem Projekt?
- Ist die Strenge abgestuft, sodass Systeme mit minimalem Risiko nicht überreguliert werden?
Die gridz-Sicht
Governance, die Sie in einem Meeting behaupten, ist eine Belastung; Governance, die die Pipeline bei jedem Deployment beweist, ist ein Vermögenswert – und entgegen der Intuition der schnellere Weg in die Produktion. Nicht der EU AI Act ist zu fürchten, sondern ein unverwalteter Bestand von elf Modellen, die niemand aufzählen kann. Wir bauen Governance als Deployment-Gate und als Model Registry, die ihre eigenen Nachweise erzeugt, sodass Compliance zu einer Eigenschaft Ihrer Auslieferung wird statt zu einem Gremium, auf das Sie warten. Richtig umgesetzt, bekommen Ihre Auditoren eine Abfrage und Ihre Engineers können am Dienstag deployen.
Der pragmatische erste Schritt kostet fast nichts: Richten Sie eine einzige Registry ein und machen Sie die Registrierung für die Produktion verpflichtend – auch wenn das einzige Feld, das Sie am ersten Tag durchsetzen, eine Risikoklassifizierung und eine verantwortliche Person ist. Das allein bringt die Systeme ans Licht, die niemand verfolgt, und beendet das Rätselraten «Wie viele KI-Systeme betreiben wir eigentlich?», das jedem Governance-Feuerwehreinsatz vorausgeht. Ergänzen Sie die Prüfungen zu Data Lineage, Evaluation und Aufsicht schrittweise und nach Risiko abgestuft, sodass das Gate strenger wird, ohne je zum Engpass zu werden. Die Unternehmen, die mit der Registry beginnen, erleben den AI Act als Frist, die sie gelassen einhalten – nicht als Notfall, den sie plötzlich entdecken. Wenn Sie diesen ersten Schritt angehen wollen, sprechen Sie uns an.

Kommentare