CoreSec: γιατί ένα αξιόπιστο AI σύστημα πρέπει να ξέρει πότε να μη δώσει απάντηση

Το CoreSec δείχνει γιατί η αποχή, οι σαφείς ρόλοι evidence και το audit trail κάνουν ένα AI σύστημα ασφαλέστερο όταν τα δεδομένα λείπουν ή διαφωνούν.

Απάντηση πρώτα: ένα αξιόπιστο AI σύστημα δεν πρέπει να μετατρέπει κάθε ατελές σύνολο δεδομένων σε βέβαιη απάντηση. Χρειάζεται ρητό δικαίωμα αποχής, συγκεκριμένους κανόνες για το ποιο evidence είναι υποχρεωτικό ή αποφασιστικό και ασφαλή διαδρομή προς άνθρωπο όταν τα signals λείπουν ή διαφωνούν.

Το CoreSec, ένα production σύστημα root cause analysis για δίκτυα Clos της Azure, δείχνει πώς αυτή η αρχή λειτουργεί σε μεγάλη κλίμακα. Αντικαθιστά το weighted scoring με PAM-style σύνθεση, πέντε topology-aware διαμορφώσεις και ελέγξιμο audit trail. Το AI abstention εδώ δεν είναι αδυναμία του συστήματος· είναι ο μηχανισμός που εμποδίζει μια αβέβαιη διάγνωση να γίνει λανθασμένη αυτοματοποιημένη ενέργεια.

Περιεχόμενα

Το πρόβλημα είναι ο θόρυβος, όχι απλώς η έλλειψη δεδομένων

Τι είναι πιο επικίνδυνο για ένα αυτοματοποιημένο σύστημα: να καθυστερήσει μια απάντηση ή να δώσει με βεβαιότητα τη λάθος; Στο root cause analysis μιας μεγάλης cloud υποδομής, η δεύτερη επιλογή μπορεί να ενεργοποιήσει λάθος mitigation, να παρατείνει ένα incident και να στείλει την ομάδα σε πολύτιμα λεπτά άσκοπης έρευνας. Το CoreSec σχεδιάστηκε γύρω από μια διαφορετική αρχή: όταν τα στοιχεία είναι ελλιπή, παλιά ή αντιφατικά, το σύστημα πρέπει να μπορεί να μην κατονομάσει αιτία.

Ένα μεγάλο data center fabric δεν βρίσκεται ποτέ σε κατάσταση απόλυτης «υγείας». Καλώδια εμφανίζουν CRC errors, links κάνουν flapping, οπτικά modules υποβαθμίζονται και switches επανεκκινούν ή αναβαθμίζονται τμηματικά. Η αρχιτεκτονική Clos διαθέτει πολλές ισοδύναμες διαδρομές, ώστε η κίνηση να παρακάμπτει μεγάλο μέρος αυτών των βλαβών χωρίς άμεσο, ορατό πρόβλημα για τον πελάτη.

Η εργασία αναφέρει ότι σε μια δεδομένη στιγμή είναι φυσιολογικό το 0,3% έως 1% των links να εμφανίζει loss, flaps ή degraded optics. Όταν ένα workload παρουσιάσει υψηλό latency ή απώλειες, το σύστημα βλέπει ταυτόχρονα πολλές ύποπτες οντότητες. Κάποιες συνδέονται με το συγκεκριμένο incident, ενώ άλλες ανήκουν στο σταθερό υπόβαθρο βλαβών. Η αφθονία telemetry, επομένως, δεν ισοδυναμεί με καθαρό evidence.

Τα gray failures δυσκολεύουν ακόμη περισσότερο την εικόνα. Δεν είναι πλήρεις διακοπές, αλλά μερικές, διαλείπουσες ή πιθανοτικές αστοχίες: ένα optical module μπορεί να ρίχνει μικρό ποσοστό πακέτων μόνο προς μία κατεύθυνση, ένα linecard να επηρεάζει flows που περνούν από συγκεκριμένο ECMP path ή ένα firmware bug να προκαλεί σύντομες επανεκκινήσεις που ξεφεύγουν από τα health monitors.

Η ιδέα ξεπερνά τα δίκτυα. Κάθε επιχειρησιακό workflow που χρησιμοποιεί AI για να αυτοματοποιήσει εργασίες τοποθετεί κάποια μορφή κρίσης ανάμεσα σε ατελή δεδομένα και μια ενέργεια με κόστος. Η διαφορά είναι ότι σε ένα σοβαρό σύστημα η αβεβαιότητα δεν κρύβεται πίσω από ένα confidence score.

Γιατί το weighted scoring έδινε πειστικές αλλά ασταθείς απαντήσεις

Η προηγούμενη προσέγγιση στην Azure συγκέντρωνε signals από διαφορετικούς telemetry agents, έδινε βάρος στο καθένα και κατέληγε στην οντότητα με το υψηλότερο άθροισμα. Η λογική ακούγεται εύλογη: το πιο αξιόπιστο signal παίρνει μεγαλύτερο βάρος. Στην πράξη, όμως, η αξιοπιστία δεν ήταν μόνιμη ιδιότητα ενός agent· άλλαζε ανάλογα με το failure mode.

Τα active probes εντοπίζουν γρήγορα προβλήματα συνδέσεων, αλλά μπορεί να έχουν κενά κάλυψης. Τα device counters δίνουν άμεσες ενδείξεις hardware, όμως έχουν θόρυβο και διαφορετικούς ρυθμούς ενημέρωσης. Τα traffic-derived signals αποτυπώνουν πραγματικό customer impact, αλλά χρειάζονται επαρκή κίνηση. Τα infrastructure summaries καλύπτουν ευρείες καταστάσεις, αλλά φτάνουν αργότερα. Η συμπίεση όλων αυτών σε έναν αριθμό εξαφανίζει τη διαφορά ανάμεσα στο «δεν έχω στοιχεία», «τα στοιχεία διαφωνούν» και «ένα αποφασιστικό signal αρκεί».

Σύμφωνα με το paper, η weighted προσέγγιση εμφάνιζε false positive rate 18% έως 22%. Η αλλαγή βαρών για τη βελτίωση ενός τύπου βλάβης χειροτέρευε άλλον, ενώ το σύστημα έπρεπε πάντοτε να προτείνει ένοχο ακόμη και όταν το δίκτυο δεν ήταν η αιτία. Αυτό είναι κρίσιμο μάθημα και για business AI: η υψηλότερη βαθμολογία ανάμεσα σε αδύναμες επιλογές δεν μετατρέπεται αυτομάτως σε ασφαλή απόφαση.

Weighted score

Όλα τα signals γίνονται ένας αριθμός. Η έλλειψη, η διαφωνία και η αποφασιστική ένδειξη χάνουν τη διαφορετική σημασία τους.

Forced rankingUnstable tuning

Role-based σύνθεση

Κάθε agent δηλώνεται ως requisite, required, sufficient ή optional για το συγκεκριμένο failure surface.

Explicit roleFreshness gate

Abstention με trace

Όταν λείπει κρίσιμο evidence ή τα signals συγκρούονται, η mitigation σταματά και ο operator βλέπει γιατί.

IndeterminateHuman escalation

Τέσσερις ρόλοι για κάθε signal

Το CoreSec αντιμετωπίζει το RCA ως πρόβλημα σύνθεσης και δανείζεται τη λογική των Pluggable Authentication Modules. Αντί να ρωτά μόνο «πόσο αξιόπιστος είναι αυτός ο agent;», ορίζει ποιον ακριβώς ρόλο επιτρέπεται να παίξει στην απόφαση για μια συγκεκριμένη επιφάνεια βλάβης.

  • Requisite: αν το κρίσιμο signal λείπει, είναι stale ή αποτύχει το όριό του, η συγκεκριμένη διαμόρφωση απέχει αμέσως.
  • Required: όλοι οι required agents πρέπει να περάσουν για να παραχθεί ψήφος· αν κάποιος δεν περάσει, η διαμόρφωση απέχει στο τέλος.
  • Sufficient: ένα θετικό και ισχυρό signal αρκεί για άμεση ψήφο χωρίς αναμονή των υπολοίπων.
  • Optional: προσθέτει υποστηρικτικό context, αλλά δεν μπορεί μόνο του να καθορίσει το αποτέλεσμα.

Για ένα server-to-TOR cable, το loss-of-carrier signal από το NIC μπορεί να λειτουργεί ως requisite, ένα RDMA timeout ως sufficient, η τάση των CRC counters ως required και ένα πρόσφατο control-plane event ως optional. Η κατανομή αυτή κωδικοποιεί operational γνώση. Δεν ισχυρίζεται ότι ένα counter ή ένα event είναι γενικά καλό ή κακό· δηλώνει σε ποιο failure mode και υπό ποιες προϋποθέσεις είναι αποφασιστικό.

Το μοτίβο είναι χρήσιμο για AI agents, εφόσον μεταφερθεί ως αρχή και όχι ως έτοιμη συνταγή. Σε ένα refund workflow, για παράδειγμα, η επιβεβαιωμένη πληρωμή μπορεί να είναι requisite, μια σαφής ακύρωση από τον πελάτη required και ένα sentiment signal optional. Η ίδια λογική της μετατροπής οδηγιών σε ελέγξιμες δεξιότητες AI απαιτεί versioned κανόνες, σαφή permissions και ανθρώπινη έγκριση για τις ευαίσθητες ενέργειες.

Η τρίτη κατάσταση: healthy, unhealthy ή indeterminate

Κάθε agent αξιολογεί ένα signal ως healthy, unhealthy ή abstain. Για θορυβώδη metrics χρησιμοποιούνται δύο thresholds: κάτω από το χαμηλό όριο η ένδειξη φαίνεται υγιής, πάνω από το υψηλό φαίνεται προβληματική και ανάμεσα στα δύο βρίσκεται η ζώνη αποχής. Ένα transient spike δεν μετατρέπεται αυτόματα σε διάγνωση.

Στο επίπεδο συγχώνευσης, το CoreSec χρησιμοποιεί τρεις καταστάσεις: H για healthy, U για unhealthy και I για indeterminate. Ένα αξιόπιστο U υπερισχύει, το H απαιτεί συμφωνία και η σύγκρουση οδηγεί σε I. Η εργασία δίνει έναν associative merge operator, ώστε το ίδιο σύνολο έγκυρων evidence να οδηγεί στο ίδιο αποτέλεσμα ανεξάρτητα από τη σειρά άφιξης.

Αυτή η διάκριση είναι βαθύτερη από ένα χαμηλό confidence. Το «δεν υπάρχουν αρκετά δεδομένα», το «τα δύο συστήματα διαφωνούν» και το «ένα κρίσιμο prerequisite απέτυχε» μπορεί να οδηγούν όλα σε παύση, αλλά απαιτούν διαφορετική επόμενη ενέργεια. Το decision trace πρέπει να καταγράφει την αιτία της αποχής, όχι μόνο την τελική ετικέτα.

Η ίδια ανάγκη εμφανίζεται σε AI workflows που διατηρούν μνήμη και state. Ένα semantic rollback για AI agents δεν είναι ολοκληρωμένο αν επαναφέρει μόνο τη βάση δεδομένων αλλά αφήνει ενεργό το λανθασμένο συμπέρασμα που οδήγησε στην ενέργεια. Η κατάσταση απόφασης και ο λόγος αποχής πρέπει να είναι μέρος του audit trail.

Πέντε παράλληλες διαμορφώσεις αντί για μία γενική μηχανή

Το CoreSec δεν προσπαθεί να λύσει όλες τις περιπτώσεις με μία καθολική φόρμουλα. Εκτελεί παράλληλα πέντε configurations που αντιστοιχούν σε διαφορετικές επιφάνειες βλάβης: server–TOR cable, TOR switch, switch–switch cable, T1 switch και T2 switch. Κάθε configuration έχει τους δικούς του authoritative agents, flags και σταθερή σειρά αξιολόγησης.

Η διάκριση προστατεύει το σύστημα από πρόωρη σύγκλιση. Ένα cable fault έχει διαφορετική υπογραφή από ένα T1 failure. Στο πρώτο, επίμονο bidirectional loss από active probes μπορεί να είναι αποφασιστικό. Στο δεύτερο, χρειάζεται συσχέτιση προβλημάτων σε πολλούς TORs και ποικιλία probe paths. Αν μια διαμόρφωση δεν έχει την κατάλληλη κάλυψη, απέχει αντί να δανειστεί βεβαιότητα από άσχετο signal.

Οι συγγραφείς αναφέρουν ότι οι ίδιες πέντε διαμορφώσεις λειτούργησαν σε διαφορετικά Azure environments χωρίς recalibration ανά deployment. Αυτό δεν σημαίνει ότι κάθε επιχείρηση μπορεί να αντιγράψει τα flags. Σημαίνει ότι η απομόνωση των failure surfaces και η ρητή ανάθεση ρόλων μπορεί να είναι σταθερότερη από ένα ενιαίο score που προσπαθεί να καλύψει όλες τις περιπτώσεις.

Πώς η τοπολογία επιλέγει το υπεύθυνο επίπεδο

Η PAM-style σύνθεση λειτουργεί μέσα σε κάθε configuration. Στη συνέχεια, topology-aware heuristics επιλύουν τις συγκρούσεις μεταξύ επιπέδων. Για έναν TOR candidate, το CoreSec χρησιμοποιεί το P2.15, δηλαδή το 97,85ο εκατοστημόριο της κατανομής των επηρεασμένων servers, μαζί με έναν ελάχιστο όρο: πρέπει να έχει επηρεαστεί τουλάχιστον το 20% των servers του TOR.

Για ένα T1, ο κανόνας είναι η συσχέτιση στα δύο τρίτα του fan-out. Αν τουλάχιστον τα δύο τρίτα των TORs που συνδέονται σε αυτό δείχνουν unhealthy state, το T1 αναγνωρίζεται ως root cause και οι επιμέρους TOR candidates καταστέλλονται. Η sensitivity analysis της εργασίας αναφέρει ότι το 50% ήταν πολύ επιτρεπτικό, το 75% αύξανε τα false negatives και η περιοχή γύρω στο 66% βρισκόταν στο χαμηλότερο συνολικό error.

Σε επίπεδο cluster, aggregate probe drop πάνω από 4% ενεργοποιεί cluster-level attribution. Τιμές κάτω από 3% αντιδρούσαν σε transient path instability, ενώ πάνω από 5% έχαναν customer-visible impact. Τα συγκεκριμένα thresholds συνδέονται με Azure Clos fabrics και δεν αποτελούν γενικά benchmarks για e-commerce, marketing ή customer support.

Η επιχειρησιακή μετάφραση είναι η έννοια της ιεραρχίας. Ένα τοπικό symptom δεν πρέπει να υπερισχύει ενός ισχυρότερου system-level pattern, αλλά και ένα γενικό alert δεν πρέπει να σβήνει ανεξάρτητες βλάβες. Σε ένα customer-support AI, για παράδειγμα, η λέξη «ακύρωση» σε ένα μήνυμα δεν αρκεί για refund αν order, payment και policy state δεν συμφωνούν. Τα chatbots που υποστηρίζουν πραγματικές μικρές επιχειρήσεις χρειάζονται escalation όταν η απάντηση επηρεάζει χρήματα, πρόσβαση ή νομικούς όρους.

Δεκαέξι λεπτά για σύγκλιση χωρίς ταλαντώσεις

Το CoreSec ενεργοποιείται μετά τον εντοπισμό incident και αξιολογεί ένα παράθυρο telemetry δεκαέξι λεπτών. Επανεκτελεί το RCA κάθε πέντε λεπτά. Ο πιο αργός agent χρειάζεται περίπου δεκατρία λεπτά, οπότε το παράθυρο αφήνει μικρό περιθώριο για να σταθεροποιηθούν τα καθυστερημένα στοιχεία.

Η σύγκλιση είναι μονότονη: attribution χαμηλότερου επιπέδου μπορεί να αντικατασταθεί από ισχυρότερη υψηλότερου επιπέδου, αλλά όχι το αντίστροφο. Όταν ικανοποιηθεί η sufficiency condition ενός layer, η απόφαση παραμένει σταθερή. Η εργασία αναφέρει ότι περίπου στο 99% των περιπτώσεων το αποτέλεσμα σταθεροποιείται μέσα στα δύο πρώτα reruns και ότι οι ταλαντώσεις της προηγούμενης προσέγγισης δεν παρατηρήθηκαν.

Αν στο τέλος του παραθύρου κανένα επίπεδο δεν διαθέτει επαρκή στοιχεία, η τελική απάντηση είναι abstention. Η αυτοματοποιημένη mitigation σταματά και οι on-call engineers λαμβάνουν structured trace: ποιοι agents δεν είχαν fresh data, ποια configurations απείχαν, ποιες οντότητες είχαν partial signals και πότε ενημερώθηκε τελευταία φορά κάθε πηγή.

Η αναμονή δεν είναι δωρεάν. Σε ένα incident, κάθε λεπτό μπορεί να κοστίζει. Το CoreSec επιλέγει συνειδητά bounded delay για να μειώσει το κόστος μιας λανθασμένης ενέργειας. Η σωστή ισορροπία εξαρτάται από το workflow: ένα recommendation μπορεί να αντέχει περισσότερο χρόνο, ενώ ένα security containment ίσως χρειάζεται διαφορετικό safe default και αυστηρότερα realtime signals.

Τι δείχνουν τα production αποτελέσματα

Η σύγκριση της περιόδου 2022–2025 περιλαμβάνει 712.345 incidents. Το CoreSec αποδίδει αυτόματα περίπου το 98,5%, κρατά 1,5% ως abstentions και αναφέρει false positives κάτω από 1%. Η προηγούμενη weighted προσέγγιση αποδίδεται με false positive rate 18% έως 22%. Οι abstentions μετρώνται ρητά ως false negatives, επειδή το σύστημα δεν έδωσε αιτία παρότι υπήρχε.

Η αποχή μειώθηκε από 10% στο πρώτο τρίμηνο σε 1,5% στο πιο πρόσφατο εξάμηνο, κυρίως με την προσθήκη agents που κάλυψαν data gaps. Η κατανομή των root causes ήταν 70% cable faults, 28% TOR failures και 2% T1, T2 ή cluster-level failures. Οι misattributions αναφέρονται περίπου σε τέσσερις τον χρόνο και οι wrong mitigations περίπου σε 700, ή 0,1% του συνόλου.

Τέσσερα μεγέθη από την παραγωγική αξιολόγηση

Οι τιμές αφορούν το CoreSec σε Azure Clos fabrics και δεν αποτελούν γενικό benchmark για κάθε AI workflow.

712.345incidents στη σύγκριση 2022–2025
<1%false positives με CoreSec
1,5%abstentions στο πιο πρόσφατο εξάμηνο
≈99%σταθεροποίηση στα δύο πρώτα reruns

Οι downstream ενδείξεις είναι επίσης σημαντικές: το paper αναφέρει πτώση πάνω από 80% στις mis-triggered mitigations και 40% στα customer complaints που συνδέονταν με misattribution. Το manual RCA workload που αντιστοιχούσε σε τρεις full-time engineers αναφέρεται ότι εξαλείφθηκε για τα incidents που πλέον αποδίδονται απευθείας.

Πότε η αποχή είναι λειτουργία ασφαλείας

Περίπου το 60% των abstentions αποδίδεται σε telemetry gaps, το 39% σε αντιφατικά στοιχεία και το 1% σε multi-cluster ή datacenter-wide events. Στις δύο πρώτες κατηγορίες, η αποχή αποτρέπει μια ατεκμηρίωτη attribution. Στην τρίτη, το πρόβλημα δεν είναι πλέον μόνο η επιλογή failing entity αλλά ο συντονισμός πολλών ομάδων, άρα η ανθρώπινη κρίση παραμένει απαραίτητη.

Ένα confident αλλά λάθος RCA αναγκάζει τον on-call engineer πρώτα να το διαψεύσει. Ένα abstention με context τον κατευθύνει στα κενά της έρευνας. Η χρήσιμη έξοδος δεν είναι απλώς η ετικέτα «δεν ξέρω», αλλά η διαδρομή απόφασης: ποιο signal ήταν stale, ποιο configuration ψήφισε, ποιο απείχε και ποιος topology rule κατέστειλε έναν χαμηλότερο candidate.

Για επιχειρησιακά AI συστήματα, αυτή είναι η πρακτική μορφή explainability. Δεν αρκεί ένα confidence percentage ή μια φυσική γλωσσική αιτιολόγηση μετά την απόφαση. Η εξήγηση πρέπει να προκύπτει από την ίδια τη δομή της απόφασης και να μπορεί να καταναλωθεί τόσο από άνθρωπο όσο και από downstream automation.

Το CoreSec δεν χρησιμοποιεί machine learning στην τελική σύνθεση. ML μπορεί να λειτουργεί upstream για anomaly extraction, probe analysis ή log summarization, αλλά το final decision είναι deterministic. Αυτό δεν αποδεικνύει ότι deterministic rules είναι πάντα καλύτεροι από ML· δείχνει ότι στο συγκεκριμένο high-cost action path οι συγγραφείς προτίμησαν προβλεψιμότητα, abstention και auditability.

Production gate για ασφαλές AI abstention

Μην επιτρέπετε irreversible action χωρίς complete evidence path

Πριν ένα AI workflow εκδώσει refund, περιορίσει λογαριασμό, αλλάξει budget ή ενεργοποιήσει mitigation, ορίστε ποιο signal είναι requisite, ποιο sufficient, ποια διαφωνία οδηγεί σε abstention, ποιος άνθρωπος αναλαμβάνει και ποιο trace θα αποδείξει την απόφαση.

Επτά βήματα για ασφαλέστερη επιχειρησιακή AI

Η μεταφορά πέρα από τα δίκτυα πρέπει να γίνει προσεκτικά. Τα thresholds P2.15, δύο τρίτα και 4% δεν είναι έτοιμη συνταγή για e-commerce, marketing, fraud ή support. Το γενικεύσιμο μέρος είναι η αρχιτεκτονική στάση: διαφορετικές πηγές evidence έχουν διαφορετική κάλυψη, καθυστέρηση και εξουσία, άρα δεν πρέπει να γίνονται απλώς ένας μέσος όρος.

Επτά βήματα από το use case σε ελεγχόμενο AI workflow

  1. Βήμα 1Ορίστε μία απόφαση και το κόστος λάθους

    Περιγράψτε την ακριβή ενέργεια, ποιον επηρεάζει και τι κοστίζει ένα false positive, ένα false negative ή μια καθυστέρηση. Το abstention policy ξεκινά από το failure cost.

  2. Βήμα 2Χαρτογραφήστε τα failure surfaces

    Χωρίστε διαφορετικές περιπτώσεις, όπως refund, fraud flag, lead routing ή incident mitigation. Μην περιμένετε από μία γενική βαθμολογία να εκφράσει όλα τα είδη κινδύνου.

  3. Βήμα 3Αναθέστε ρόλο σε κάθε πηγή

    Δηλώστε ποιο evidence είναι requisite, required, sufficient ή optional για κάθε περίπτωση. Καταγράψτε owner, source system, freshness window και γνωστά coverage gaps.

  4. Βήμα 4Ορίστε ρητή κατάσταση indeterminate

    Ξεχωρίστε missing, stale και conflicting evidence. Κάθε τύπος abstention πρέπει να έχει συγκεκριμένο fallback, όχι ένα γενικό «απέτυχε το AI».

  5. Βήμα 5Σχεδιάστε escalation και permissions

    Ορίστε ποιος άνθρωπος αναλαμβάνει, ποια δεδομένα βλέπει και ποιες actions μπλοκάρονται. Σε υψηλό ρίσκο, το default πρέπει να είναι pause ή reversible draft.

  6. Βήμα 6Δοκιμάστε καθυστέρηση, σύγκρουση και απουσία

    Μην ελέγχετε μόνο happy paths. Χρησιμοποιήστε simulation και staged tests για late API, missing order, αντικρουόμενα records και stale policy· το simulation-based testing σε MCP και RAG workflows δείχνει γιατί ο έλεγχος πριν από την παραγωγή είναι ουσιώδης.

  7. Βήμα 7Μετρήστε ποιότητα και βελτιώστε τα data gaps

    Παρακολουθήστε false positives, false negatives, abstention rate, time-to-resolution, wrong-action cost και λόγο αποχής. Χρησιμοποιήστε τα clusters abstention για να βελτιώσετε συγκεκριμένα connectors και agents.

Σε marketing attribution, ένα CRM conversion, ένα consented analytics event και ένα modeled touchpoint δεν πρέπει να αντιμετωπίζονται ως ισοδύναμες ψήφοι. Σε fraud review, η απουσία mandatory verification δεν είναι το ίδιο με χαμηλό risk score. Σε customer support, το AI δεν πρέπει να εκτελεί refund ή restriction όταν order και payment systems διαφωνούν. Για περισσότερα παραδείγματα ορίων, τα AI workflows στο marketing με ανθρώπινο έλεγχο δείχνουν πού η τελική έγκριση παραμένει ανθρώπινη.

Το KPI δεν είναι μόνο «πόσες υποθέσεις έκλεισε αυτόματα το AI». Χρειάζονται precision ανά action, κόστος λανθασμένης ενέργειας, χρόνος escalation, ποιότητα του trace και η δυνατότητα των abstentions να αποκαλύπτουν συστηματικά data gaps. Αν η ομάδα μειώνει την αποχή χαλαρώνοντας τα όρια, μπορεί απλώς να ξαναδημιουργήσει το forced-classification πρόβλημα.

Το CoreSec έχει και σαφή όρια. Νέα firmware crashes ή άγνωστες μορφές optical degradation μπορεί να απαιτήσουν νέους agents. Pipeline failures συνεχίζουν να δημιουργούν missing data, ενώ μεγάλης κλίμακας events οδηγούν σκόπιμα σε μαζική αποχή. Η baseline σύγκριση γίνεται με το προηγούμενο production system και όχι με όλες τις ακαδημαϊκές εναλλακτικές.

Το πιο χρήσιμο συμπέρασμα δεν είναι ότι κάθε εταιρεία πρέπει να αντιγράψει τέσσερα flags και τρία thresholds. Είναι ότι η αξιοπιστία ενός decision system δεν μετριέται από το πόσο συχνά απαντά, αλλά από το αν γνωρίζει ποιο evidence είναι αποφασιστικό, αν διατηρεί ορατή την αβεβαιότητα και αν εμποδίζει μια αδύναμη ένδειξη να μετατραπεί σε ακριβή ή μη αναστρέψιμη ενέργεια.

Η TWO DOTS εφαρμόζει αυτή την πρακτική λογική στους αυτοματισμούς επιχειρήσεων και AI: χαρτογράφηση της πραγματικής διαδικασίας, σαφή inputs, conditions, approvals, error handling, logs και ανθρώπινα checkpoints πριν ένα workflow αποκτήσει μεγαλύτερη αυτονομία.

Από το AI demo σε ασφαλή λειτουργία

Σχεδιάστε workflow που ξέρει πότε να σταματά

Η TWO DOTS χαρτογραφεί data sources, decision roles, abstention rules, approvals και audit trail, ώστε AI και business automations να μειώνουν χρόνο χωρίς να κρύβουν την αβεβαιότητα ή να εκτελούν λάθος ενέργειες.

Συχνές ερωτήσεις

Τι είναι το CoreSec;

Είναι production σύστημα root cause analysis για μεγάλα δίκτυα Clos. Συνθέτει πολλαπλές πηγές telemetry με PAM-inspired control flags και επιτρέπει ρητή αποχή όταν το evidence δεν επαρκεί.

Τι σημαίνει AI abstention;

Σημαίνει ότι το σύστημα δεν δίνει οριστική απάντηση ή δεν εκτελεί ενέργεια όταν κρίσιμα δεδομένα λείπουν, είναι stale ή συγκρούονται. Η αποχή πρέπει να συνοδεύεται από αιτία και ασφαλές escalation.

Γιατί δεν αρκεί ένα confidence score;

Επειδή ένα score μπορεί να συμπιέσει διαφορετικές καταστάσεις, όπως απουσία evidence, σύγκρουση πηγών και μία αποφασιστική ένδειξη. Το CoreSec διατηρεί αυτές τις διαφορές μέσα στη δομή της απόφασης.

Ποιοι είναι οι τέσσερις control flags;

Requisite για κρίσιμα προαπαιτούμενα, required για στοιχεία που πρέπει να συμφωνήσουν, sufficient για αποφασιστικά signals και optional για υποστηρικτικές ενδείξεις.

Πόσο βελτιώθηκε το false positive rate;

Το paper αναφέρει κάτω από 1% με CoreSec, έναντι ιστορικού baseline 18 έως 22 τοις εκατό για την προηγούμενη weighted προσέγγιση, σε σύγκριση που καλύπτει 712.345 incidents. Δεν επρόκειτο για παράλληλο A/B στο ίδιο dataset.

Το CoreSec χρησιμοποιεί machine learning;

Machine learning μπορεί να χρησιμοποιείται upstream για εξαγωγή signals, αλλά η τελική σύνθεση είναι deterministic. Αυτό επιτρέπει προβλέψιμο abstention και decision trace που μπορεί να ελεγχθεί.

Μπορεί η ίδια λογική να εφαρμοστεί σε e-commerce ή support;

Ναι ως αρχή role-based evidence, ρητής αποχής και escalation. Τα συγκεκριμένα thresholds του CoreSec προέρχονται από Azure Clos fabrics και δεν πρέπει να μεταφερθούν αυτούσια σε άλλο workflow.

Ποιο είναι το πρώτο πρακτικό βήμα για μια επιχείρηση;

Να επιλέξει μία απόφαση με γνωστό κόστος λάθους, να χαρτογραφήσει τις πηγές evidence και να ορίσει ποια απουσία ή διαφωνία μπλοκάρει την ενέργεια και ποιος άνθρωπος αναλαμβάνει.

Ενημερωτικό Δελτίο

Εισάγετε τη διεύθυνση email σας παρακάτω για να εγγραφείτε στο ενημερωτικό δελτίο μας