Mit über 20 Jahren Erfahrung verwandeln wir Ihre digitale Präsenz. Wir sind spezialisiert auf Website- und E-Shop-Entwicklung, SEO und digitales Marketing, ERP-Software und intelligente Automatisierung, die Ihr Unternehmen auf die nächste Stufe heben.
Adresse:
Egnatia 154, Thessaloniki 546 36
Telefon:
+30 231 231 4095
E-Mail:
[email protected]
Sind Sie bereit für den nächsten Schritt?;
CoreSec zeigt auf, warum Datenausschluss, klar definierte Rollen bei der Evidenz und ein Prüfpfad ein KI-System sicherer machen, wenn Daten fehlen oder widersprüchlich sind.
Zunächst die Antwort: Ein zuverlässiges KI-System darf nicht jeden unvollständigen Datensatz in eine sichere Antwort umwandeln. Es bedarf eines ausdrücklichen Rechts auf Zurückhaltung, konkreter Regeln darüber, welche Beweise zwingend oder entscheidend sind, sowie eines sicheren Weges zur menschlichen Entscheidung, wenn Signale fehlen oder widersprüchlich sind.
CoreSec, ein produktionsreifes System zur Ursachenanalyse für Azure-Clos-Netzwerke, veranschaulicht, wie dieses Prinzip in großem Maßstab funktioniert. Es ersetzt die gewichtete Bewertung durch eine PAM-ähnliche Zusammensetzung, fünf topologiebewusste Konfigurationen und einen nachvollziehbaren Prüfpfad. Das AI-Enthaltung Das ist hier keine Schwäche des Systems; es ist der Mechanismus, der verhindert, dass aus einer unsicheren Diagnose eine falsche automatisierte Maßnahme wird.
Was ist für ein automatisiertes System gefährlicher: eine Antwort zu verzögern oder mit Sicherheit eine falsche Antwort zu geben? Bei der Ursachenanalyse einer großen Cloud-Infrastruktur kann die zweite Option zu falschen Abhilfemaßnahmen führen, einen Vorfall verlängern und das Team wertvolle Minuten mit sinnlosen Recherchen verschwenden lassen. CoreSec wurde nach einem anderen Prinzip konzipiert: Wenn die Daten unvollständig, veraltet oder widersprüchlich sind, muss das System in der Lage sein, keine Ursache zu benennen.
Ein großes Rechenzentrumsnetzwerk befindet sich niemals in einem Zustand absoluter «Gesundheit». Kabel weisen CRC-Fehler auf, Verbindungen schwanken, optische Module verlieren an Leistung und Switches werden teilweise neu gestartet oder aktualisiert. Die Clos-Architektur verfügt über zahlreiche gleichwertige Pfade, sodass der Datenverkehr einen Großteil dieser Störungen umgehen kann, ohne dass für den Kunden ein unmittelbares, sichtbares Problem entsteht.
In der Arbeit wird darauf hingewiesen, dass es normal ist, dass zu einem bestimmten Zeitpunkt 0,3 % bis 1 % der Verbindungen Verluste, Flaps oder eine verschlechterte optische Qualität aufweisen. Wenn eine Arbeitslast hohe Latenzzeiten oder Verluste aufweist, erkennt das System gleichzeitig mehrere verdächtige Entitäten. Einige stehen im Zusammenhang mit dem konkreten Vorfall, während andere zum stabilen Hintergrund der Störungen gehören. Die Fülle an Telemetriedaten ist daher nicht gleichbedeutend mit eindeutigen Beweisen.
„Gray Failures“ verkomplizieren das Bild noch weiter. Es handelt sich dabei nicht um vollständige Ausfälle, sondern um teilweise, zeitweise oder zufällige Ausfälle: Ein optisches Modul kann einen geringen Prozentsatz der Pakete nur in eine Richtung verlieren, eine Linecard kann Datenströme beeinträchtigen, die über einen bestimmten ECMP-Pfad laufen, oder ein Firmware-Fehler kann kurze Neustarts verursachen, die von den Zustandsüberwachungssystemen nicht erfasst werden.
Die Idee geht über Netzwerke hinaus. Jedes ein betrieblicher Workflow, der KI nutzt, um Aufgaben zu automatisieren Es stellt eine Art Abwägung zwischen unvollständigen Daten und einer mit Kosten verbundenen Maßnahme dar. Der Unterschied besteht darin, dass sich in einem seriösen System die Unsicherheit nicht hinter einem Konfidenzwert verbirgt.
Der bisherige Ansatz in Azure sammelte Signale von verschiedenen Telemetrie-Agenten, wichtete jedes einzelne Signal und ermittelte schließlich die Entität mit der höchsten Gesamtsumme. Die Logik klingt einleuchtend: Das zuverlässigste Signal erhält eine höhere Gewichtung. In der Praxis war die Zuverlässigkeit jedoch keine konstante Eigenschaft eines Agenten; sie änderte sich je nach Ausfallmodus.
Aktive Sonden erkennen Verbindungsprobleme schnell, können jedoch Lücken in der Abdeckung aufweisen. Geräteszähler liefern direkte Hardware-Indikatoren, weisen jedoch Rauschen und unterschiedliche Aktualisierungsraten auf. Verkehrsbasierte Signale spiegeln die tatsächlichen Auswirkungen auf die Kunden wider, erfordern jedoch ausreichendes Datenaufkommen. Infrastrukturübersichten decken allgemeine Zustände ab, liegen jedoch erst später vor. Die Zusammenfassung all dieser Informationen in einer einzigen Zahl beseitigt den Unterschied zwischen «Ich habe keine Daten», «Die Daten widersprechen sich» und «Ein entscheidendes Signal reicht aus».
Dem Artikel zufolge wies der gewichtete Ansatz eine Falsch-Positiv-Rate von 18 % bis 22 % auf. Die Anpassung der Gewichte zur Verbesserung eines Fehlertyps verschlimmerte einen anderen, während das System stets einen Schuldigen vorschlagen musste, selbst wenn das Netzwerk nicht die Ursache war. Dies ist auch für die Business-KI eine entscheidende Erkenntnis: Die höchste Punktzahl unter schwachen Optionen führt nicht automatisch zu einer sicheren Entscheidung.
Gewichtete Punktzahl
Alle Signale werden zu einer Zahl. Der Mangel, die Uneinigkeit und das eindeutige Zeichen verlieren ihre unterschiedliche Bedeutung.
Rollenbasierte Zusammensetzung
Jeder Agent wird für die jeweilige Fehlerfläche als „requisite“, „required“, „sufficient“ oder „optional“ gekennzeichnet.
Enthaltung mit Trace
Wenn entscheidende Beweise fehlen oder die Signale widersprüchlich sind, wird die Risikominderung unterbrochen und der Bediener prüft, warum.
CoreSec betrachtet RCA als ein Kompositionsproblem und greift dabei auf die Logik der Pluggable Authentication Modules zurück. Anstatt nur zu fragen: «Wie vertrauenswürdig ist dieser Agent?», legt es fest, welche Rolle genau er bei der Entscheidung über eine bestimmte Angriffsfläche spielen darf.
Bei einer Server-zu-TOR-Verbindung kann das Loss-of-Carrier-Signal der Netzwerkkarte als „requisite“ dienen, ein RDMA-Timeout als „sufficient“, der Stand der CRC-Zähler als „required“ und ein kürzlich aufgetretenes Control-Plane-Ereignis als „optional“. Diese Einteilung kodiert betriebliches Wissen. Sie behauptet nicht, dass ein Zähler oder ein Ereignis generell gut oder schlecht ist; sie gibt an, in welchem Ausfallmodus und unter welchen Bedingungen es entscheidend ist.
Das Muster ist für KI-Agenten nützlich, sofern es als Grundsatz und nicht als fertiges Rezept übernommen wird. In einem Rückerstattungs-Workflow kann beispielsweise die bestätigte Zahlung eine Voraussetzung sein, eine eindeutige Stornierung durch den Kunden erforderlich und ein Stimmungssignal optional. Die gleiche Logik der Umwandlung von Anweisungen in überprüfbare KI-Fähigkeiten erfordert versionierte Regeln, klare Berechtigungen und eine manuelle Genehmigung für sensible Aktionen.
Jeder Agent bewertet ein Signal als „healthy“, „unhealthy“ oder „abstain“. Bei schwankenden Metriken werden zwei Schwellenwerte verwendet: Unterhalb des unteren Schwellenwerts wird der Wert als „healthy“ eingestuft, oberhalb des oberen Schwellenwerts als „problematisch“ und dazwischen liegt die „Abstain“-Zone. Ein vorübergehender Ausschlag führt nicht automatisch zu einer Diagnose.
Auf der Merge-Ebene verwendet CoreSec drei Zustände: H für „healthy“, U für „unhealthy“ und I für „indeterminate“. Ein zuverlässiges U hat Vorrang, H erfordert Übereinstimmung und ein Konflikt führt zu I. Die Arbeit stellt einen assoziativen Merge-Operator bereit, sodass dieselbe Menge gültiger Evidenz unabhängig von der Reihenfolge ihres Eintreffens zum gleichen Ergebnis führt.
Diese Unterscheidung geht über ein niedriges Konfidenzniveau hinaus. «Es liegen nicht genügend Daten vor», «die beiden Systeme sind sich nicht einig» und «eine entscheidende Voraussetzung wurde nicht erfüllt» können zwar alle zu einer Unterbrechung führen, erfordern jedoch unterschiedliche Folgemaßnahmen. Der Entscheidungsverlauf muss die Ursache für die Unterbrechung erfassen, nicht nur das endgültige Ergebnis.
Das gleiche Erfordernis tritt bei KI-Workflows auf, die Speicher und Zustand verwalten. Ein Semantisches Rollback für KI-Agenten Es ist nicht vollständig, wenn lediglich die Datenbank wiederhergestellt wird, die fehlerhafte Schlussfolgerung, die zu der Maßnahme geführt hat, jedoch weiterhin aktiv bleibt. Der Entscheidungszustand und der Grund für die Enthaltung müssen Teil des Prüfpfads sein.
CoreSec versucht nicht, alle Fälle mit einer universellen Formel zu lösen. Es führt parallel fünf Konfigurationen aus, die unterschiedlichen Angriffsflächen entsprechen: Server–TOR-Kabel, TOR-Switch, Switch–Switch-Kabel, T1-Switch und T2-Switch. Jede Konfiguration verfügt über eigene maßgebliche Agenten, Flags und eine feste Bewertungsreihenfolge.
Die Unterscheidung schützt das System vor einer vorzeitigen Konvergenz. Ein Kabeldefekt weist ein anderes Muster auf als ein T1-Ausfall. Im ersten Fall kann ein anhaltender bidirektionaler Verlust bei aktiven Probes ausschlaggebend sein. Im zweiten Fall ist eine Korrelation von Problemen über mehrere TORs hinweg sowie eine Vielzahl von Probe-Pfaden erforderlich. Verfügt eine Konfiguration nicht über die erforderliche Abdeckung, wird sie ausgeschlossen, anstatt sich auf ein irrelevantes Signal zu stützen.
Die Autoren berichten, dass dieselben fünf Konfigurationen in verschiedenen Azure-Umgebungen ohne Neukalibrierung bei jeder Bereitstellung funktionierten. Das bedeutet nicht, dass jedes Unternehmen diese Flags einfach kopieren kann. Es bedeutet vielmehr, dass die Isolierung von Fehlerquellen und die explizite Zuweisung von Rollen stabiler sein können als ein einheitlicher Score, der versucht, alle Fälle abzudecken.
Die PAM-artige Zusammensetzung funktioniert in jeder Konfiguration. Anschließend lösen topologiebewusste Heuristiken Konflikte zwischen den Ebenen auf. Für einen TOR-Kandidaten verwendet CoreSec den Wert P2.15, d. h. das 97,85. Perzentil der Verteilung der betroffenen Server, zusammen mit einer Mindestbedingung: Mindestens 20 % der TOR-Server müssen betroffen sein.
Bei einem T1 gilt als Regel die Korrelation bei zwei Dritteln des Fan-outs. Wenn mindestens zwei Drittel der damit verbundenen TORs einen fehlerhaften Zustand aufweisen, wird das T1 als Grundursache identifiziert und die einzelnen TOR-Kandidaten werden unterdrückt. Die Sensitivitätsanalyse der Arbeit zeigt, dass 50 % zu großzügig waren, 75 % die Anzahl der falsch-negativen Ergebnisse erhöhten und der Bereich um 66 % den geringsten Gesamtfehler aufwies.
Auf Cluster-Ebene löst ein „Aggregate Probe Drop“ von über 4 % die Zuordnung auf Cluster-Ebene aus. Werte unter 3 % reagierten auf vorübergehende Pfadinstabilität, während Werte über 5 % keine für den Kunden sichtbaren Auswirkungen hatten. Diese Schwellenwerte beziehen sich auf Azure Clos-Fabrics und stellen keine allgemeinen Benchmarks für E-Commerce, Marketing oder Kundensupport dar.
Bei der betrieblichen Übersetzung geht es um das Konzept der Hierarchie. Ein lokales Symptom darf kein stärkeres Muster auf Systemebene überlagern, aber auch eine allgemeine Warnmeldung darf unabhängige Fehler nicht ausblenden. Bei einer KI für den Kundensupport reicht beispielsweise das Wort «Stornierung» in einer Nachricht nicht für eine Rückerstattung aus, wenn Bestellung, Zahlung und Status der Richtlinien nicht übereinstimmen. Die Chatbots, die echte Kleinunternehmen unterstützen Eine Eskalation ist erforderlich, wenn die Antwort finanzielle Aspekte, Zugriffsrechte oder rechtliche Bedingungen betrifft.
CoreSec wird nach der Erkennung eines Vorfalls aktiviert und wertet ein Telemetriefenster von 16 Minuten aus. Die RCA wird alle fünf Minuten erneut ausgeführt. Der langsamste Agent benötigt etwa dreizehn Minuten, sodass das Zeitfenster nur wenig Spielraum lässt, um verzögerte Daten zu stabilisieren.
Die Konvergenz verläuft monoton: Eine Attribution niedrigerer Ebene kann durch eine stärkere Attribution höherer Ebene ersetzt werden, aber nicht umgekehrt. Wenn die Suffizienzbedingung einer Schicht erfüllt ist, bleibt die Entscheidung stabil. Die Arbeit berichtet, dass sich das Ergebnis in etwa 99 % der Fälle innerhalb der ersten beiden Durchläufe stabilisiert und dass die Schwankungen des vorherigen Ansatzes nicht beobachtet wurden.
Wenn am Ende des Fensters keine Ebene über ausreichende Daten verfügt, lautet die endgültige Antwort „Abstention“. Die automatisierte Mitigation wird gestoppt, und die Bereitschaftstechniker erhalten einen strukturierten Trace: welche Agenten keine aktuellen Daten hatten, welche Konfigurationen fehlten, welche Entitäten Teil-Signale aufwiesen und wann jede Quelle zuletzt aktualisiert wurde.
Das Warten ist nicht kostenlos. Bei einem Vorfall kann jede Minute kostspielig sein. CoreSec entscheidet sich bewusst für eine begrenzte Verzögerung, um die Kosten einer falschen Maßnahme zu senken. Das richtige Gleichgewicht hängt vom Workflow ab: Eine Empfehlung kann mehr Zeit vertragen, während eine Sicherheitsisolierung möglicherweise einen anderen sicheren Standardwert und strengere Echtzeit-Signale erfordert.
Der Vergleich für den Zeitraum 2022–2025 umfasst 712.345 Vorfälle. CoreSec klassifiziert automatisch etwa 98,5 % davon, stuft 1,5 % als „Abstentions“ ein und gibt die Falsch-Positiv-Rate mit unter 1 % an. Der vorherige gewichtete Ansatz weist eine Falsch-Positiv-Rate von 18 % bis 22 % auf. Die „Abstentions“ werden ausdrücklich als Falsch-Negative gezählt, da das System keinen Grund angegeben hat, obwohl einer vorlag.
Die Ausfallquote sank von 10 % im ersten Quartal auf 1,5 % im letzten Halbjahr, was vor allem auf die Einbindung von Agenten zurückzuführen ist, die Datenlücken geschlossen haben. Die Verteilung der Grundursachen ergab 70 % Kabelstörungen, 28 % TOR-Ausfälle und 2 % T1-, T2- oder Cluster-Ausfälle. Falschzuordnungen treten etwa viermal pro Jahr auf, falsche Abhilfemaßnahmen etwa 700 Mal, was 0,1 % der Gesamtzahl entspricht.
Vier Kennzahlen aus der Produktionsbewertung
Die Werte beziehen sich auf CoreSec in Azure Clos-Fabrics und stellen keinen allgemeinen Benchmark für jeden KI-Workflow dar.
Auch die nachgelagerten Kennzahlen sind von Bedeutung: Der Artikel berichtet von einem Rückgang um mehr als 80 % bei fälschlicherweise ausgelösten Schutzmaßnahmen und um 40 % bei Kundenbeschwerden, die mit Fehlzuordnungen in Zusammenhang standen. Der manuelle RCA-Arbeitsaufwand, der drei Vollzeit-Ingenieuren entsprach, wurde Berichten zufolge für Vorfälle, die nun direkt zugeordnet werden, vollständig beseitigt.
Etwa 60 % der Abstinenzfälle sind auf Telemetrielücken zurückzuführen, 39 % auf widersprüchliche Daten und 1 % auf Multi-Cluster- oder datenzentrumsweite Ereignisse. In den ersten beiden Kategorien verhindert die Enthaltung eine unbegründete Zuordnung. In der dritten Kategorie besteht das Problem nicht mehr nur in der Auswahl der fehlerhaften Entität, sondern in der Koordination mehrerer Teams, weshalb menschliches Urteilsvermögen weiterhin unerlässlich ist.
Ein selbstbewusstes, aber falsches RCA zwingt den Bereitschaftsingenieur zunächst dazu, es zu widerlegen. Eine Enthaltung mit Kontext weist ihn auf die Lücken in der Untersuchung hin. Der nützliche Ergebnisausgang ist nicht einfach nur die Bezeichnung «Ich weiß es nicht», sondern der Entscheidungsprozess: Welches Signal war veraltet, welche Konfiguration wurde gewählt, welche enthielt sich und welche Topologie-Regel hat einen schwächeren Kandidaten ausgeschlossen?
Bei KI-Systemen im betrieblichen Einsatz ist dies die praktische Form der Erklärbarkeit. Ein Konfidenzprozentsatz oder eine Begründung in natürlicher Sprache nach der Entscheidung reicht nicht aus. Die Erklärung muss sich aus der Struktur der Entscheidung selbst ergeben und sowohl für Menschen als auch für nachgelagerte Automatisierungsprozesse verständlich sein.
CoreSec setzt bei der endgültigen Zusammensetzung kein maschinelles Lernen ein. ML kann zwar im Vorfeld zur Erkennung von Anomalien, zur Analyse von Probes oder zur Zusammenfassung von Protokollen eingesetzt werden, doch die endgültige Entscheidung erfolgt deterministisch. Dies beweist nicht, dass deterministische Regeln immer besser sind als ML; es zeigt vielmehr, dass die Autoren bei diesem konkreten, mit hohen Kosten verbundenen Aktionspfad Vorhersehbarkeit, Zurückhaltung und Überprüfbarkeit den Vorzug gegeben haben.
Produktionsgate für eine sichere AI-Enthaltung
Lassen Sie keine irreversiblen Aktionen zu, ohne dass ein vollständiger Nachweisweg vorliegt.
Bevor ein KI-Workflow eine Rückerstattung ausstellt, ein Konto sperrt, das Budget ändert oder eine Abhilfemaßnahme auslöst, legen Sie fest, welches Signal erforderlich ist, welches ausreichend ist, welche Diskrepanz zu einer Enthaltung führt, welcher Mitarbeiter die Verantwortung übernimmt und welcher Nachweis die Entscheidung belegt.
Die Übertragung über die Netzwerke hinweg muss sorgfältig erfolgen. Die Schwellenwerte P2.15, zwei Drittel und 4 % sind kein fertiges Rezept für E-Commerce, Marketing, Betrugsbekämpfung oder Support. Der verallgemeinerbare Aspekt ist die architektonische Herangehensweise: Verschiedene Evidenzquellen weisen unterschiedliche Abdeckung, Verzögerung und Aussagekraft auf, daher sollten sie nicht einfach gemittelt werden.
Sieben Schritte vom Anwendungsfall zum kontrollierten KI-Workflow
Beschreiben Sie die genaue Maßnahme, wen sie betrifft und welche Kosten ein „False Positive“, ein „False Negative“ oder eine Verzögerung verursacht. Die Abstention-Policy geht von den Ausfallkosten aus.
Unterscheiden Sie verschiedene Fälle wie Rückerstattung, Betrugsverdacht, Lead-Weiterleitung oder Vorfallbewältigung. Erwarten Sie nicht, dass eine allgemeine Bewertung alle Arten von Risiken widerspiegelt.
Geben Sie für jeden Fall an, welche Nachweise erforderlich, vorgeschrieben, ausreichend oder optional sind. Halten Sie den Verantwortlichen, das Quellsystem, das Aktualitätsfenster und bekannte Lücken in der Abdeckung fest.
Unterscheiden Sie zwischen fehlenden, veralteten und widersprüchlichen Beweisen. Für jede Art der Enthaltung muss es einen konkreten Ausweichwert geben, nicht nur ein allgemeines «Die KI ist gescheitert».
Legen Sie fest, wer die Verantwortung übernimmt, welche Daten eingesehen werden dürfen und welche Aktionen gesperrt werden. Bei hohem Risiko sollte die Standardeinstellung „Pause“ oder „reversibler Entwurf“ lauten.
Testen Sie nicht nur „Happy Paths“. Nutzen Sie Simulationen und gestaffelte Tests für verspätete API-Antworten, fehlende Bestellungen, widersprüchliche Datensätze und veraltete Richtlinien; das Simulationsbasierte Tests in MCP- und RAG-Workflows zeigt, warum die Kontrolle vor der Produktion von entscheidender Bedeutung ist.
Beobachten Sie False Positives, False Negatives, die Abstimmungsenthaltungsrate, die Zeit bis zur Lösung, die Kosten für falsche Maßnahmen und den Anteil der Abstimmungsenthaltungen. Nutzen Sie die Abstimmungsenthaltungs-Cluster, um bestimmte Konnektoren und Agenten zu verbessern.
Bei der Marketing-Attribution sollten eine CRM-Konversion, ein zustimmungsbasiertes Analyseereignis und ein modellierter Touchpoint nicht als gleichwertige Faktoren behandelt werden. Bei der Betrugsprüfung ist das Fehlen einer obligatorischen Verifizierung nicht gleichbedeutend mit einem niedrigen Risikowert. Im Kundensupport darf die KI keine Rückerstattung oder Sperrung vornehmen, wenn Bestell- und Zahlungssysteme voneinander abweichen. Weitere Beispiele für Grenzwerte finden Sie unter KI-Workflows im Marketing unter menschlicher Kontrolle zeigen, dass die endgültige Genehmigung nach wie vor von Menschen getroffen wird.
Der KPI besteht nicht nur darin, «wie viele Fälle die KI automatisch abgeschlossen hat». Es sind die Präzision pro Aktion, die Kosten falscher Maßnahmen, die Eskalationszeit, die Qualität des Trace sowie die Fähigkeit der Abstimmungen erforderlich, Datenlücken systematisch aufzudecken. Wenn das Team die Nichtklassifizierungen durch eine Lockerung der Schwellenwerte reduziert, könnte es das Problem der erzwungenen Klassifizierung einfach erneut hervorrufen.
CoreSec hat jedoch auch klare Grenzen. Neue Firmware-Abstürze oder unbekannte Formen der optischen Verschlechterung können neue Agenten erforderlich machen. Pipeline-Ausfälle führen weiterhin zu Datenlücken, während groß angelegte Ereignisse bewusst zu massiven Ausfällen führen. Der Basisvergleich erfolgt mit dem vorherigen Produktionssystem und nicht mit allen akademischen Alternativen.
Die nützlichste Schlussfolgerung ist nicht, dass jedes Unternehmen vier Flags und drei Thresholds kopieren sollte. Sie lautet vielmehr, dass die Zuverlässigkeit eines Entscheidungssystems nicht daran gemessen wird, wie oft es eine Antwort liefert, sondern daran, ob es erkennt, welche Beweise entscheidend sind, ob es die Unsicherheit sichtbar hält und ob es verhindert, dass ein schwacher Hinweis zu einer präzisen oder unumkehrbaren Handlung führt.
TWO DOTS wendet diese praktische Logik auf die Betriebsautomatisierung und KI: Kartierung des tatsächlichen Prozesses, klare Eingaben, Bedingungen, Genehmigungen, Fehlerbehandlung, Protokolle und manuelle Kontrollpunkte, bevor ein Workflow ein höheres Maß an Autonomie erhält.
Von der KI-Demo in den abgesicherten Modus
Entwerfen Sie einen Workflow, der weiß, wann er anhalten muss
TWO DOTS erfasst Datenquellen, Entscheidungsrollen, Ausnahmeregeln, Genehmigungen und den Prüfpfad, damit KI und Geschäftsautomatisierungen Zeit sparen, ohne dabei Unsicherheiten zu verschleiern oder falsche Aktionen auszuführen.
Häufig gestellte Fragen
Es handelt sich um ein Produktionssystem zur Ursachenanalyse für große CLOS-Netzwerke. Es fasst mehrere Telemetriequellen mithilfe von PAM-inspirierten Kontrollflags zusammen und ermöglicht eine explizite Zurückhaltung, wenn die Beweislage nicht ausreichend ist.
Das bedeutet, dass das System keine endgültige Antwort liefert oder keine Aktion ausführt, wenn wichtige Daten fehlen, veraltet sind oder miteinander in Konflikt stehen. Die Unterlassung muss mit einer Begründung und einer sicheren Eskalation einhergehen.
Denn ein Score kann unterschiedliche Situationen zusammenfassen, wie beispielsweise das Fehlen von Beweisen, widersprüchliche Quellen und einen entscheidenden Hinweis. CoreSec berücksichtigt diese Unterschiede innerhalb der Entscheidungsstruktur.
„Requisite“ für entscheidende Voraussetzungen, „required“ für Elemente, die übereinstimmen müssen, „sufficient“ für ausschlaggebende Signale und „optional“ für unterstützende Anzeichen.
Die Studie gibt mit CoreSec einen Wert von unter 1 % an, gegenüber einem historischen Referenzwert von 18 bis 22 Prozent beim vorherigen gewichteten Ansatz, wobei der Vergleich 712.345 Vorfälle umfasst. Es handelte sich nicht um einen parallelen A/B-Test am selben Datensatz.
Maschinelles Lernen kann im vorgelagerten Bereich zur Extraktion von Signalen eingesetzt werden, doch die endgültige Synthese ist deterministisch. Dies ermöglicht eine vorhersehbare Abstimmung und einen überprüfbaren Entscheidungsablauf.
Ja, grundsätzlich gelten rollenbasierte Nachweise, explizite Verzichtserklärungen und Eskalation. Die konkreten Schwellenwerte von CoreSec stammen aus Azure Clos-Fabrics und sollten nicht unverändert in einen anderen Workflow übernommen werden.
Eine Entscheidung mit bekannten Fehlerkosten auswählen, die Evidenzquellen erfassen und festlegen, welches Fehlen oder welche Meinungsverschiedenheit die Maßnahme blockiert und welche Person die Verantwortung übernimmt.
Quellen
