Was ServiceNow auf der Knowledge 2026 angekündigt hat
Auf der Knowledge 2026 hat ServiceNow eine Erweiterung von ServiceNow AI Control Tower™ angekündigt. Laut der offiziellen ServiceNow-Newsroom-Mitteilung erlaubt ACT Unternehmen jetzt, "KI über jedes System im Unternehmen hinweg zu entdecken, zu beobachten, zu steuern, abzusichern und zu messen" — fünf Fähigkeiten, die zusammen die Plattform als zentrale Befehlsfläche für das KI-Inventar einer Organisation positionieren.
Die Erweiterung ist substanziell. Discovery wurde auf 30 neue Enterprise-Integrationen ausgedehnt, einschließlich der großen Hyperscaler (AWS, Google Cloud, Azure) und der operativen Systeme, in denen Enterprise-KI tatsächlich läuft (SAP, Oracle, Workday). Risikoklassifikation ist an fünf Frameworks ausgerichtet, darunter NIST AI RMF und die KI-Verordnung. Beobachtbarkeit für Agenten-Runtime-Verhalten kommt aus der kürzlich angekündigten Traceloop-Akquisition. Die Secure-Fähigkeit ergänzt identitäts- und zugriffsbewusste Governance über die Veza-Integration, plus einen Notfall-Kill-Switch für entgleisende Agenten. Allgemeine Verfügbarkeit der erweiterten Fläche ist für August 2026 geplant.
Ein paar Zeilen aus der Pressemitteilung rahmen die Produkt-Positionierung präzise. ACT "entdeckt KI im Unternehmen — einschließlich LLMs, Agenten, Modelle und Anwendungen, die auf AWS, Azure, Google Cloud, Salesforce, SAP, Oracle, Workday und mehr laufen." Die Abdeckung umfasst Risiko-Frameworks, ausgerichtet an NIST AI RMF, der KI-Verordnung, weiteren internationalen KI-Standards und ServiceNows eigenen internen Policies. Die Secure-Fähigkeit "schützt KI durch identitätsbewusste Governance und Runtime-Beobachtbarkeit, mit Ein-Klick-Kontrollen zum Deaktivieren entgleisender Agenten."
Das ist die Ankündigung. Die Substanz ist real, und das Framing ist ehrlich darüber, was das Produkt ist: eine Governance-Plattform.
Warum das wichtig ist — auch jenseits von ServiceNow-Kunden
Ein ernsthafter Governance-Plattform-Anbieter, der eine Produkt-Roadmap explizit an die KI-Verordnung ausrichtet, ist ein starkes Nachfrage-Signal. ServiceNow jagt keinen Moden hinterher, und das Unternehmen setzt keine Flaggschiff-Knowledge-Keynote auf einen regulatorischen Rahmen, wenn ihre Enterprise-Kunden nicht danach fragen. Sie tun es.
Das validiert ein Procurement-Muster, auf dem die gesamte Compliance-Tech-Kategorie aufgebaut ist: CISO und DSB und Chief AI Officer wollen alle dieselbe Evidenz, alle wollen sie an einem Ort, und alle wollen das regulatorische Mapping erledigt haben, bevor der Prüfer klopft. Lesen Sie die Ankündigung als gute Nachricht für alle, die am KI-Verordnung-Stack arbeiten — auch für Teams, die niemals ServiceNow betreiben werden. Ein Schwergewicht-Plattform-Anbieter, der sich in diese Richtung bewegt, bedeutet, dass die regulator-getriebene Kategorie größer wird, die Käufer-Bildungskosten sinken und sich die Frage von "brauchen wir das?" zu "welche Kombination von Produkten brauchen wir?" verschiebt.
Der Grund, warum diese Verschiebung für den Rest der Kategorie wichtig ist, ist, dass kein einzelnes Produkt die KI-Verordnung für ein Unternehmen vollständig beantworten wird. Die Verordnung umfasst technische Dokumentation (Anhang IV), pro-Entscheidung-Logging (Art. 12), menschliche Aufsicht (Art. 14), Risikomanagement (Art. 9), Daten-Governance (Art. 10), Genauigkeit und Robustheit (Art. 15) und einen Konformitäts-Workflow, der all diese Stränge zusammenzieht. Ein Teil davon ist Policy und Prozess. Ein Teil ist Architektur. Ein Teil ist kryptographische Evidenz, die während der Inferenz erzeugt wird. Unterschiedliche Schichten, unterschiedliche Tools.
Zwei Ebenen der KI-Governance
Borgen wir uns ein Bild aus benachbarten Sicherheitskategorien.
In der Netzwerksicherheit gibt es eine Steuerungsebene (das SIEM, das fragt: "was ist im Netzwerk, wer meldet sich an, welche Alerts haben gefeuert?") und eine Datenebene (das EDR, das fragt: "was tut jeder Endpunkt gerade tatsächlich?"). Beide existieren. Keines ersetzt das andere. Ein SOC, das nur ein SIEM betreibt, hat keine Erkennung am Endpunkt; ein SOC, das nur EDR betreibt, kann nicht über das Inventar hinweg korrelieren.
In der Identität gibt es eine Steuerungsebene (das IAM, das fragt: "wer kann auf was zugreifen?") und eine Datenebene (der Secrets Manager, das fragt: "was ist der geheime Wert, wurde er rotiert, wer hat ihn zuletzt abgerufen?"). Wieder existieren beide; wieder ersetzt keines das andere.
KI-Governance hat dieselbe Form. ACT ist eine Steuerungsebene in dieser Taxonomie: die Plattform, die fragt "welche KI läuft, wer hat sie gebaut, in welche Risikoklasse fällt sie, wer darf sie nutzen, welche Policies gelten?" Lucairn ist eine Datenebene: das Gateway, das fragt "welche Daten gingen in diese konkrete Anfrage, was hat das Modell produziert, können wir es kryptographisch belegen?" Unterschiedliche Probleme, beide real.
Das Vokabular Steuerungsebene/Datenebene ist in der Sicherheitsarchitektur nicht neu, aber es ist für KI-Governance ungewöhnlich klärend, weil die beiden Schichten wirklich unterschiedliche Formen haben. Die Steuerungsebene ist policy-förmig — entdecken, klassifizieren, attribuieren, auf Meta-Ebene beobachten. Die Datenebene ist request-förmig — sanitisieren, routen, signieren, pro Aufruf aufzeichnen. Ein Produkt, das auf das eine optimiert ist, ist strukturell ein anderes Produkt als eines, das auf das andere optimiert ist.
Wo die Abdeckung von ACT bewusst aufhört
Wenn man die öffentlichen Materialien sorgfältig liest, ist der angegebene Scope von ACT konsistent und gut definiert.
Die Govern-Fähigkeit verfolgt Pflichten aus Art. 12 und Anhang IV und produziert Compliance-Berichte. Der ServiceNow-Community-Blueprint zu AI Control Tower (Link unten) beschreibt ACT als zentrale Plattform, um die Pflichten sichtbar zu machen und Evidenz aus jedem integrierten System zu aggregieren. Der Blueprint ist explizit, dass die zugrundeliegenden Logs von jedem integrierten System produziert und in ACT eingespeist werden — ACT ist der Governance-Hub, nicht der Inline-Produzent pro-Entscheidung-Artefakte.
Die Secure-Fähigkeit fokussiert auf Identität, Zugriff und Runtime-Beobachtbarkeit von Agenten. Öffentliche Materialien beschreiben Veza-gestützte identitätsbewusste Governance und Traceloop-gestützte Beobachtbarkeit von Agentenverhalten — Berechtigungen, Scope, Verhaltensmuster. Es gibt keine öffentliche Aussage, dass ACT Request-Inhalte inline inspiziert oder PII vor einem Modell-Aufruf schwärzt.
Das sind bewusste Scope-Entscheidungen, keine Lücken. Eine Steuerungsebene, die auch Datenebene zu sein versucht, würde ihren Wert als Single Pane of Glass verlieren. Die Stärke der Plattform liegt genau darin, dass sie über dem Request-Flow sitzt und Evidenz von darunter aggregiert; sie in den Request-Pfad zu drücken, würde die architektonische Form des Produkts ändern.
Was das für einen KI-Verordnung-Käufer bedeutet, ist, dass ACT die Governance- und Inventar-Fragen nativ beantwortet und für die pro-Entscheidung-Evidenz auf die Datenebene zeigt. Das ist gute Architektur. Es ist auch der Grund, warum die meisten regulierten Käufer beide Ebenen brauchen werden.
Wo Lucairn ACT ergänzt
Drei konkrete Muster.
Muster A: ACT entdeckt, Lucairn evidentiert. ACT inventarisiert einen regulierten Workload — sagen wir ein Kreditentscheidungs-LLM unter Anhang III — als hochriskant nach der KI-Verordnung. Das Compliance-Team markiert ihn für Art.-12-Logging. ACT produziert das Policy-Mapping und den Konformitäts-Workflow. Inline gibt Lucairn pro LLM-Aufruf in diesem Workload einen signierten Beleg aus. Jeder Beleg trägt eine Ed25519-Signatur über die kanonischen Request-Bytes, ein RFC-3161-TSA-Token und einen Sigstore-Rekor-Inklusionsbeweis. Die Belege fließen in ACT als Evidenz-Zeilen zurück, getaggt am entdeckten KI-Asset. ACT wird zur Lese-Schnittstelle für den Prüfer; Lucairn produziert die Artefakte, die die Lese-Schnittstelle anzeigt. Siehe die Implementierungs-Aufschlüsselung unter audit-trail-for-ai.
Muster B: Identität bleibt aus dem Modell heraus. ACT setzt durch, wer die KI über Veza-gestützte identitätsbewusste Governance aufrufen darf — die Zugriffskontroll-Frage. Lucairn setzt durch, was die KI tatsächlich sieht über On-Gateway-Pseudonymisierung — die Daten-Exposure-Frage. Ein Nutzer ruft einen Hochrisiko-LLM-Workflow auf; ACT bestätigt, dass der Nutzer den richtigen Scope hat; Lucairn fängt die Anfrage ab, schwärzt PII, bevor das LLM den Prompt sieht, und re-linkt die Platzhalter erst auf der Antwort. Zwei Durchsetzungspunkte, beide real, keiner redundant. Das Ergebnis ist, dass eine Modellausgabe, die unter ACTs Zugriffslogs auf einen konkreten Nutzer zurückführbar ist, im Moment der Modellproduktion die Roh-Identität des Nutzers nie tatsächlich enthielt. Siehe private-ai-inference für die Architektur.
Muster C: Kryptographische Integrität. Das Audit-Modul von ACT zeichnet die Entscheidungs-Kette auf der Plattform-Ebene auf. Die pro-Antwort-Ed25519-Signatur von Lucairn plus der öffentliche Zeitstempel plus der Sigstore-Rekor-Anker bedeuten, dass die Kette unabhängig verifizierbar ist, ohne dass ACT und Lucairn kooperieren. Ein Prüfer mit dem öffentlichen Witness-Schlüssel kann jeden einzelnen Beleg offline verifizieren. Ein Regulator kann die Existenz eines Belegs zu einem Zeitpunkt über das öffentliche Rekor-Log bestätigen, ohne einen der Anbieter zu kontaktieren. Diese Art unabhängiger Verifizierbarkeit ist eine Eigenschaft des Belegs, nicht eine Eigenschaft der Plattform, die ihn anzeigt — was der ganze Sinn kryptographischer Evidenz ist.
Keines dieser Muster erfordert tiefe Integration. Das Beleg-Format ist offen, die Verifikations-Schlüssel sind öffentlich, und die Verdrahtung zwischen den beiden Ebenen ist REST plus signiertes JSON.
Ein praktisches Beispiel: der regulierte EU-Workload
Konkretes Szenario. Eine Bank setzt ACT für Governance ein und Lucairn als Inline-Gateway vor einem Anthropic-LLM-Aufruf in einem Hochrisiko-Kreditentscheidungs-Workflow.
Ein Kreditbearbeiter entwirft eine Empfehlung und schickt sie durch das LLM-gestützte Zusammenfassungs-Tool. ACT loggt den Workflow-Aufruf gegen das entdeckte KI-Asset und den Zugriffs-Scope des Nutzers. Inline fängt Lucairn die Anfrage ab. Name, Geburtsdatum und Adresse des Antragstellers werden vom Sanitizer erkannt und durch stabile Platzhalter ersetzt. Der geschwärzte Prompt geht an Anthropic. Die Antwort kommt zurück. Lucairn re-linkt die Platzhalter, signiert die Antwort und das zugehörige Sanitisierungs-Manifest, RFC-3161-zeitstempelt es, verankert den Beleg im öffentlichen Sigstore-Rekor-Log und leitet sowohl die Antwort als auch die Beleg-URL an die Bank-Anwendung weiter.
Sechs Monate später bestreitet der Antragsteller die Entscheidung und der Regulator eröffnet eine Art.-12-Untersuchung. Der CISO öffnet ACT, sieht den Inventar-Eintrag und findet die Audit-Zeile des Workflows. Aus dieser Zeile verlinkt ACT auf den Lucairn-Beleg für die konkrete Anfrage. Der Prüfer lädt den Beleg herunter, holt den öffentlichen Witness-Schlüssel vom Well-known-Endpunkt, verifiziert die Ed25519-Signatur offline, verifiziert den RFC-3161-Zeitstempel via FreeTSA und prüft den Sigstore-Rekor-Inklusionsbeweis gegen das öffentliche Rekor-Log. Unabhängige Bestätigung: Der Beleg existierte zum gestempelten Zeitpunkt, der Eingabe-Hash stimmt mit der vom Regulator eingereichten Reproduktion überein, und weder die Bank noch Lucairn noch ServiceNow haben die kryptographische Fähigkeit, den Datensatz nachträglich zu verändern.
Keiner der Anbieter hat die Kunden-Identitätsdaten der Bank gespeichert. Beide haben Evidenz produziert. Der Prüfer schließt die Untersuchung mit einem Urteil ab, das die Bank verteidigen kann.
Was sich für Lucairn ändert
Strukturell nichts. Zwei Notizen für das Team und die Vertriebs-Bewegung.
Wenn ein Käufer "wir haben bereits ACT" sagt, ist das eine Öffnung, kein Einwand. Sie haben die Steuerungsebene; sie brauchen die Datenebene. Die richtige Antwort ist: bestätigen Sie mit dem Käufer, dass ACT PII vor dem LLM nicht schwärzt und dass ACT keine pro-Antwort-kryptographischen Belege produziert (laut öffentlicher Doku tut es das nicht). Bilden Sie die Lücke auf Lucairn ab, mit der Schichten-Mapping-Seite als procurement-tauglicher Antwort.
Hören Sie auf, KI-Verordnung-Gespräche allein mit "Compliance" zu eröffnen. ServiceNow kann jedes Startup auf genau dieser Phrase überbieten, und sie sollten es — sie haben ein glaubwürdiges Governance-Produkt für den CISO des Käufers. Führen Sie stattdessen mit der Runtime-Garantie. Auf den Developer- und Pro-Hosted-Stufen schwärzt On-Gateway-Pseudonymisierung PII, bevor Ihr LLM die Anfrage sieht, und jede Antwort trägt einen signierten Beleg, den ein Prüfer unabhängig gegen einen öffentlichen Witness-Schlüssel verifizieren kann. Das sind Aussagen, die eine Steuerungsebene strukturell nicht treffen kann.
Enterprise-Self-hosted hat eine andere Form. Dort läuft die gesamte Architektur innerhalb des Kunden-Perimeters, und keine Roh-Identitätsdaten verlassen Ihre Umgebung — Sandbox A und die ID Bridge laufen auf Kunden-Infrastruktur; nur pseudonymisierte Payloads überqueren die Grenze zum Inferenz-Anbieter. Auf der Enterprise-Stufe sitzt auch der optionale, auf das Domänen-Korpus des Kunden custom-trainierte PII-Shield — nach Scope bepreist.
Abschluss — ein gesunder Stack
Ein gesunder Enterprise-KI-Stack wird wie ACT (oder ein glaubwürdiger Peer) auf der Governance-Ebene aussehen, plus Best-of-Breed-Datenebene-Gateways wie Lucairn im Request-Pfad, plus den vom Kunden gewählten LLM-Anbieter. Wir haben dieses Muster in jeder benachbarten Kategorie konvergieren sehen — SIEM und EDR, IAM und Secrets Manager, CIEM und Runtime-Schutz. Wir erwarten, dass es hier konvergiert. Lucairn ist für die Datenebene gebaut.
Wenn Sie in einer Organisation sind, die ACT betreibt und den KI-Verordnung-Aufbau scopt, geht die Schichten-Mapping-Seite die procurement-tauglichen Fragen Zeile für Zeile durch. Wenn Sie die Request-Pfad-Artefakte im Detail sehen wollen, sind audit-trail-for-ai und evidence-layer die tiefsten Lektüren. Wenn Sie einen Pilot scopen wollen, ist das 15-Minuten-Compliance-Assessment der schnellste Weg hinein.
Quellen
- ServiceNow Newsroom: ServiceNow expands AI Control Tower to discover, observe, govern, secure and measure AI deployed across any system in the enterprise
- ServiceNow Community: AI Control Tower als Blueprint für KI-Governance und KI-Verordnung-Compliance
- The Register zu ACT-Agent-Kill-Switches auf der Knowledge 2026: theregister.com/software/2026/05/05/servicenow-adds-agent-kill-switches-to-ai-control-tower
- SiliconANGLE zur Enterprise-Positionierung von ACT: siliconangle.com/2026/05/05/servicenow-bids-become-control-tower-enterprise-ai