Wenn ich über KI lese, geht es um Code oder um Text für Marketing und Sales. Beides funktioniert gut. Beides ist auch der Grund, warum ein Anwendungsfall kaum vorkommt, der in jedem zertifizierten Betrieb sofort Geld wert ist: der Abgleich zwischen dem, was dein ISMS behauptet, und dem, was deine Infrastruktur tatsächlich durchsetzt.

Du bist nach ISO 27001 zertifiziert. Deine Infrastruktur läuft in Azure, deine Endgeräte hängen an Intune. Dein ISMS beschreibt, welche Regel gilt und welche Policy sie erzwingt. Am Tag der Zertifizierung stimmt das.

Danach driftet es.

Zwei Dokumente, zwei Anlässe, selten dieselbe Person

Das ISMS fasst jemand an, wenn ein Kunde in der Lieferantenprüfung etwas wissen will. Die Policy fasst jemand an, wenn am Montagmorgen etwas nicht funktioniert. Zwei Auslöser, zwei Wochen, oft zwei Personen.

Du sagst einem Kunden eine Verschärfung zu und ziehst sie in Intune nach. Das ISMS bleibt stehen. Oder umgekehrt: die Regel steht sauber im Dokument, und die Policy, die sie durchsetzen soll, bekommt ein halbes Jahr später eine Ausnahme, weil ein Team sonst nicht arbeiten kann. Keiner der beiden Vorgänge ist ein Fehler. Zusammen ergeben sie eine Dokumentation, die etwas anderes behauptet als deine Maschinen tun.

Das findest du nicht durch Hinsehen. Nicht weil es versteckt wäre, sondern weil du den Blick verlierst. Wer ein ISMS über Jahre pflegt, liest die eigenen Sätze irgendwann nicht mehr, sondern erinnert sich an sie. Erinnerung ist grosszügig. «So war das gemeint» steht dann eben nicht da.

Die Policy, die es gibt und die nichts tut

Der unangenehmste Fall ist ein dritter. Die Policy existiert, sie ist sauber benannt, sie ist zugewiesen, und sie wirkt trotzdem nicht.

Intune ist über die Jahre gewachsen. Dieselbe Einstellung lässt sich heute an vier verschiedenen Orten setzen: im aktuellen Settings Catalog, in den älteren Konfigurationsprofilen, in den administrativen Vorlagen und in den alten Security Baselines. Jeder dieser vier Orte ist eine eigene Liste. Intune zeigt sie dir nirgends zusammengeführt, und wer sie auswertet, muss jede einzeln abfragen.

Am Gerät landen sie trotzdem alle an derselben Stelle. Setzen zwei zugewiesene Policies denselben Wert unterschiedlich, greift keine von beiden verlässlich.

Dein ISMS sagt dann: Defender wird über Policy X erzwungen. Policy X gibt es. Der Satz im Dokument ist wahr. Das Gerät ist trotzdem ungeschützt.

Solche Konstellationen entstehen in bester Absicht. Eine Baseline von vor vier Jahren pflegt Defender, BitLocker und Firewall mit, jemand legt später dedizierte Endpoint-Security-Policies an, niemand räumt die Baseline ab. Beide sind zugewiesen, beide sehen im Portal grün aus.

Wo die KI wirklich stark ist

Aus einem unspektakulären Grund: sie langweilt sich nicht. Dreihundert Einstellungen gegen einen Kontrolltext zu halten, Zuweisungen zu vergleichen, jede Behauptung im Dokument gegen den tatsächlich gesetzten Wert zu prüfen, ist genau die Arbeit, bei der ein Mensch nach zwanzig Minuten anfängt zu überfliegen. Verbindest du ein Modell mit dem ISMS und mit der Durchsetzungsebene, bekommst du in Stunden eine Gegenüberstellung, für die du sonst Wochen einplanst.

Sie findet dabei auch, wonach niemand ausdrücklich gefragt hat, solange es in den Daten steht. Ein Gerät, das sich in Entra anmeldet und in Intune gar nicht geführt wird, fällt beim Abgleich zweier Quellen sofort auf, weil die beiden Listen nicht zusammenpassen. Dasselbe gilt für Geräte, die als nicht konform zurückgemeldet werden, und für solche, die seit Wochen nicht mehr synchronisiert haben.

Und dann produziert dasselbe Modell mit voller Überzeugung den Befund, der dich teuer zu stehen kommt.

Ein falscher Treffer ist peinlich, ein falscher Freispruch ist gefährlich

Der Bericht, den du zurückbekommst, listet die Abweichungen auf, jede mit Fundstelle. Du arbeitest sie der Reihe nach ab. Und ganz unten steht, dass der Rest in Ordnung ist.

An diesen letzten Satz geht danach niemand mehr ran. Einen falschen Treffer prüfst du nach, er löst sich auf, du hast eine Stunde verloren und bist hinterher schlauer. Ein Freispruch kostet dich gar nichts, bis er im Audit als Nachweis auf dem Tisch liegt.

Was in den Daten steht, findet das Modell also. Die Lücke, die in den Daten kein Signal hinterlässt, ist die in deinem eigenen Export. Ziehst du eine der vier Listen von weiter oben und übergibst nur diese, lautet die Antwort «keine Konflikte», und sie stimmt sogar, für diese eine Liste. Über deine Geräte sagt sie nichts, und nirgends in der Antwort steht, dass es drei weitere Listen gibt. Ein Modell, das die Plattform gut kennt, fragt an dieser Stelle vielleicht nach. Verlassen kannst du dich darauf nicht, und wenn es nicht nachfragt, bekommst du keine Fehlermeldung, sondern ein sauberes Ergebnis. Ein sauberes Ergebnis liest sich wie ein sauberes System.

Dieselbe Falle wartet überall dort, wo ein System lange genug gewachsen ist, dass der alte Weg neben dem neuen weiterlebt, und das ist in einer zehn Jahre alten Umgebung eher die Regel als die Ausnahme.

Nach einem sauberen Ergebnis musst du deshalb wissen, was auf dem Tisch lag, als das Modell geprüft hat.

Die Arbeit steckt nicht im Prompt

Sie steckt in der Frage, was vollständig heisst, und die musst du beantworten, bevor die Auswertung läuft.

  • Zähl vorher auf, an welchen Stellen die Einstellung überhaupt stehen kann, und frag jede davon ab. Jedes System mit Geschichte hat neben dem heutigen Weg noch zwei oder drei alte, die weiterhin aktiv sind.
  • Behandle ein leeres Feld nicht als Beweis für Abwesenheit. Mach die Gegenprobe an einem zweiten Weg oder direkt im Portal, und zwar an einem Objekt, von dem du weisst, wie es gesetzt ist.
  • Frag bei allem, was falsch aussieht, zuerst nach dem Zweck. Eine Abweichung von der Norm ist noch kein Befund, sondern eine Frage nach der Absicht, die noch niemand gestellt hat.

Und nimm einen Status im Portal nicht für bare Münze. Ein Gerät, das seit drei Wochen nicht synchronisiert hat, zeigt dir den Zustand von vor drei Wochen. Halte den Zeitpunkt der letzten Synchronisierung gegen den Zeitpunkt deiner Änderung, sonst jagst du Konflikte, die längst behoben sind.

Dasselbe Vorgehen, bevor das ISMS überhaupt existiert

Baust du ein ISMS neu auf, bekommst du einen Satz Kontrolltexte aus einer Vorlage, formulierst sie auf dein Unternehmen um und beschreibst, wie es laufen soll. Danach beginnt die Arbeit, das Beschriebene und das tatsächlich Laufende in Deckung zu bringen. Der Drift aus diesem Artikel ist dann am ersten Tag schon angelegt.

Die Reihenfolge lässt sich umdrehen. Lies zuerst aus, was in Azure und Intune wirklich erzwungen wird, und lass die KI die Kontrolltexte aus diesem Befund heraus generieren. Für alles, was bereits sauber durchgesetzt ist, formuliert dir das Modell die Beschreibung samt der Policy. Für alles ohne Entsprechung bekommst du eine Liste dessen, was du umsetzen oder als akzeptiertes Restrisiko begründen musst. Es ist dieselbe Auswertung wie oben, nur früher, und sie ist an derselben Stelle angreifbar: ein unvollständiges Inventar produziert hier kein falsches Auditergebnis, sondern ein ISMS, das von Anfang an etwas anderes behauptet als deine Maschinen tun.

Der Auditor fragt dich nicht, womit du deine Abweichungen gefunden hast. Er fragt, ob dein Dokument stimmt. Zwischen «die KI hat nichts gefunden» und «da ist nichts» liegt dein Inventar. Das baust immer noch du.