Périmé : lorsque l'autorisation valide de l'IA expire avant son exécution

Το verdict staleness είναι η απώλεια εγκυρότητας μιας έγκρισης ανάμεσα στον έλεγχο και την εκτέλεση. Μια απόφαση AI μπορεί να είναι σωστή όταν εκδίδεται και λανθασμένη λίγα βήματα αργότερα, επειδή στο μεταξύ άλλαξαν το απόθεμα, η τιμή, τα δικαιώματα, η κατάσταση μιας παραγγελίας ή οι συνθήκες λειτουργίας.

Η μελέτη «Approved Too Late: Verdict Staleness in LLM-Guarded Self-Adaptive Systems», η οποία έγινε δεκτή στο ACSOS 2026, δείχνει γιατί οι παραγωγικοί AI agents χρειάζονται όχι μόνο σωστό έλεγχο, αλλά και σαφή διάρκεια ισχύος, επανεπικύρωση και ασφαλές fallback. Το πρακτικό ερώτημα δεν είναι απλώς «ήταν σωστή η έγκριση;», αλλά «παρέμεινε σωστή μέχρι τη στιγμή της πράξης;».

Τι είναι το verdict staleness

Στα αυτοπροσαρμοζόμενα συστήματα, ένας controller παρατηρεί την τρέχουσα κατάσταση, προτείνει μια ενέργεια και ζητά από ένα LLM guardrail να την εγκρίνει ή να την απορρίψει. Η υπολογιστική διαδικασία, η μεταφορά δεδομένων, η ουρά εκτέλεσης και η παράδοση της απόφασης όμως χρειάζονται χρόνο. Το σύστημα συνεχίζει να μεταβάλλεται όσο η έγκριση ταξιδεύει προς την πράξη.

Οι ερευνητές περιγράφουν το κενό ως κίνδυνο time-of-check to time-of-use, ή TOCTOU, στο στάδιο Execute. Η έγκριση μπορεί να ήταν ορθή για το context και την ενέργεια που είδε ο κριτής, αλλά να μην είναι πλέον αποδεκτή για το context που υπάρχει όταν η πράξη ενεργοποιείται. Δεν απαιτείται κακόβουλη παρέμβαση. Αρκεί η φυσιολογική εξέλιξη ενός κλειστού βρόχου λειτουργίας.

Η αναλογία με έναν επιχειρηματικό AI agent είναι άμεση. Ένα σύστημα μπορεί να εγκρίνει επιστροφή χρημάτων επειδή το υπόλοιπο και η κατάσταση παραγγελίας είναι σωστά, αλλά μέχρι την εκτέλεση να έχει ολοκληρωθεί άλλη επιστροφή. Μπορεί να εγκρίνει αλλαγή τιμής με βάση snapshot αποθέματος που έχει ήδη ξεπεραστεί ή να ακυρώσει παραγγελία αφού ξεκίνησε η αποστολή.

Γιατί η φρεσκάδα δεν είναι το ίδιο με την ακρίβεια

Η εργασία ονομάζει verdict freshness την εγκυρότητα μιας απόφασης τη στιγμή της χρήσης και verdict staleness την απώλειά της. Η διάκριση μετατρέπει τον χρόνο από απλό performance metric σε μέρος της σημασίας της απόφασης. Η καθυστέρηση δεν επηρεάζει μόνο την εμπειρία χρήστη· μπορεί να αλλάξει το αν η ενέργεια εξακολουθεί να επιτρέπεται.

Οι συγγραφείς μετρούν την ηλικία της έγκρισης από τη λήψη της παρατήρησης και όχι από τη στιγμή που το μοντέλο επιστρέφει το verdict. Έτσι περιλαμβάνεται όλο το διάστημα από το αρχικό snapshot έως την εκτέλεση. Σε ζωντανό σύστημα, η καθυστέρηση μετατρέπεται συντηρητικά σε βήματα ελέγχου ως K_live = ceil(Δ/T_ctrl). Καθυστέρηση δύο δευτερολέπτων σε control period 0,25 δευτερολέπτων αντιστοιχεί σε οκτώ βήματα.

Οκτώ βήματα σε δύο συστήματα δεν σημαίνουν τον ίδιο φυσικό χρόνο. Γι’ αυτό η μελέτη συγκρίνει κοινή μετατόπιση simulator steps και όχι κοινή διάρκεια σε δευτερόλεπτα. Μια πραγματική εγκατάσταση χρειάζεται τη δική της end-to-end latency distribution, ιδιαίτερα τις αργές ουρές της, όχι μόνο έναν μέσο ή διάμεσο χρόνο.

Τρεις μετρήσεις που δεν πρέπει να συγχέονται

Η πρώτη ποσότητα είναι η αλλαγή verdict σε όλους τους υποψήφιους χειρισμούς. Η ανάλυση κρατά την ίδια ενέργεια και ελέγχει αν η deterministic reference κρίση αλλάζει σε μεταγενέστερο context. Περιλαμβάνει τόσο expiry, από επιτρεπτό σε μη επιτρεπτό, όσο και recovery, από μη επιτρεπτό σε επιτρεπτό.

Η δεύτερη είναι το oracle-labeled approval expiry. Εξετάζει ενέργειες που πέρασαν από μια μέθοδο και ήταν επιτρεπτές κατά τον αρχικό έλεγχο, και ρωτά πόσες έγιναν μη επιτρεπτές στη μεταγενέστερη στιγμή. Αυτή είναι η βασική μέτρηση για τη σύγκριση του reference-open μηχανισμού με το Freshness-Bounded Shield.

Η τρίτη είναι η judge-conditioned use-time invalidity μέσα στο approval stream κάθε LLM judge. Επειδή δεν προϋποθέτει ότι η ενέργεια ήταν σωστή στο check time σύμφωνα με τον reference checker, μπορεί να συνδυάζει αρχικό λάθος του judge και πραγματική χρονική λήξη μιας αρχικά σωστής έγκρισης.

Οι τρεις οικογένειες έχουν διαφορετικό παρονομαστή. Η αριθμητική απόσταση ανάμεσά τους δεν είναι effect size και δεν επιτρέπεται να χρησιμοποιηθεί για ranking μοντέλων. Η ίδια προσοχή χρειάζεται γενικότερα όταν ένας οργανισμός αξιολογεί LLM judges σε AI agents: το metric πρέπει να απαντά ακριβώς στο ερώτημα που ενδιαφέρει.

Πέντε περιβάλλοντα με διαφορετική δυναμική

Το πείραμα εφαρμόζει fixed-action replay σε πέντε αναπαραγώγιμα περιβάλλοντα. Το DeltaIoT προσαρμόζει ρυθμίσεις επικοινωνίας σε πολυ-hop δίκτυο IoT και χρησιμοποιεί ως gate feature το packet loss. Το SimTune ρυθμίζει παραμέτρους simulator για workloads edge-cloud. Το mRUBiS είναι παράδειγμα αρχιτεκτονικής αυτοΐασης, το Switch αλλάζει παραλλαγές μοντέλου object detection καθώς μεταβάλλεται το φορτίο και το SimDex κατανέμει εργασίες σε backend workers.

Οι operational predicates είναι συγκεκριμένα κατώφλια, όχι πλήρεις ορισμοί ασφάλειας. Στο DeltaIoT, για παράδειγμα, το packet loss πρέπει να είναι έως 0,10. Στο SimTune το rt_err πρέπει να είναι έως 2,0, στο mRUBiS η per-step utility τουλάχιστον 27,0 και στο SimDex η μέση καθυστέρηση έως 5,0. Το Switch χρησιμοποιεί βαθμονομημένο threshold ανά instance.

Η ποικιλία δείχνει γιατί ένα ενιαίο χρονικό όριο δεν μπορεί να θεωρείται αυτονόητα σωστό. Η λήξη εξαρτάται από τη δυναμική του συστήματος, τη δομή του predicate και την κατανομή των ενεργειών που παράγει ο controller. Ένα TTL που είναι υπερβολικά μεγάλο αφήνει stale approvals να περάσουν· ένα υπερβολικά μικρό TTL μπορεί να μετατρέψει το σύστημα σε μηχανισμό διαρκούς άρνησης.

Τι έδειξε το replay στα οκτώ βήματα

Στην κοινή μετατόπιση K=8, η αλλαγή verdict για όλους τους υποψήφιους χειρισμούς κυμάνθηκε από 5,3% στο SimDex έως 48,4% στο DeltaIoT. Η περίπου εννιαπλάσια διαφορά, παρότι το K ήταν ίδιο, δείχνει ότι η ηλικία μιας απόφασης δεν αρκεί από μόνη της για να προβλέψει τη σταθερότητά της.

Οι καμπύλες είχαν διαφορετικά μοτίβα. DeltaIoT και SimTune βρέθηκαν ήδη κοντά στο 48% από K=1 και παρουσίασαν πρώιμο κορεσμό. Το mRUBiS ήταν πιο ευαίσθητο στην ηλικία: ανέβηκε συνολικά από 16,5% στο K=1 σε 32,7% στο K=8, με τοπικές μη μονοτονίες. Το Switch παρέμεινε περίπου επίπεδο και το SimDex είχε χαμηλότερη βάση με μικρές μεταβολές.

Αυτά είναι περιγραφικά σχήματα, όχι απόδειξη για τον μηχανισμό που τα προκαλεί. Καθώς αυξάνεται το K, λιγότερα σημεία παραμένουν μέσα στο ίδιο επεισόδιο, οπότε μπορεί να αλλάζει και το cohort που μετριέται.

Πώς λειτουργεί το Freshness-Bounded Shield

Το Freshness-Bounded Shield, ή FBS, τοποθετεί ένα ελαφρύ gate μετά την αρχική έγκριση. Υπολογίζει πρώτα το signed safe-side margin: πόσο μακριά βρίσκεται το τρέχον scalar feature από το όριο, προς την ασφαλή πλευρά. Στη συνέχεια εκτιμά την πρόσφατη μεταβλητότητα με εκθετικό κινητό μέσο της απόλυτης αλλαγής του feature. Στη μελέτη, ο συντελεστής α είναι 0,1 και παραμένει σταθερός στα πέντε περιβάλλοντα.

Η εκτιμώμενη διάρκεια ισχύος προκύπτει από τον λόγο margin προς volatility, με floor ώστε μια στιγμιαία σταθερότητα να μη δημιουργεί άπειρο horizon και με ανώτατο όριο δ_max. Η ενέργεια περνά μόνο αν υπάρχει upstream approval, το margin είναι θετικό και η ηλικία δεν υπερβαίνει τον εκτιμώμενο ορίζοντα. Διαφορετικά εφαρμόζεται το fallback του περιβάλλοντος.

Μεγάλη απόσταση από το όριο και μικρή πρόσφατη κίνηση υποδεικνύουν μεγαλύτερη πιθανή διάρκεια ζωής. Μικρό margin ή μεγάλη volatility ζητούν γρηγορότερη λήξη. Αφού είναι διαθέσιμα feature, threshold και age, το FBS προσθέτει σταθερό scalar υπολογιστικό έργο O(1) και δεν απαιτεί δεύτερο model call.

Η μείωση του expiry δεν αρκεί χωρίς utility

Στο K=8, το reference-open παρουσίασε oracle-labeled expiry από 3,4% έως 24,7% στα πέντε περιβάλλοντα. Με FBS, το εύρος μειώθηκε σε 0% έως 1,8%. Οι αναλογίες FBS προς reference-open ήταν από 0 έως 0,18, δηλαδή σχετικές μειώσεις 82%–100%, και οι paired συγκρίσεις ανά seed είχαν raw p<0,001 με τις ρυθμίσεις Wilcoxon της εργασίας.

Η σωστή ανάγνωση είναι στενή. Κάθε rate υπολογίζεται μέσα στο pass set της αντίστοιχης μεθόδου. Ένας μηχανισμός θα μπορούσε να εμφανίσει μηδενικό expiry απορρίπτοντας σχεδόν όλες τις ενέργειες. Συνεπώς, χαμηλότερο ποσοστό δεν αποδεικνύει μόνο του καλύτερη ισορροπία ασφάλειας και χρησιμότητας.

Η ειδική safety-utility ανάλυση στο DeltaIoT δείχνει τη διαφορά. Στο K=8, το reference-open είχε 24,0% expiry και μέση ανταμοιβή -960. Το πλήρες FBS πέτυχε 0,0% expiry με την ίδια αναφερόμενη μέση ανταμοιβή -960. Η παραλλαγή margin_only πέτυχε επίσης 0,0%, αλλά η ανταμοιβή έπεσε σε -1050, ενώ ένα σταθερό deadline έφτασε το -1200. Η vol_only παρέμεινε κοντά στο baseline, με 23,9% expiry και ανταμοιβή -965.

Το αποτέλεσμα αφορά μόνο αυτό το περιβάλλον και το K=8. Σε παραγωγή πρέπει να μετρώνται μαζί pass rate, fallback rate, task utility, κόστος καθυστέρησης και πραγματικά incidents. Το ίδιο μάθημα ισχύει σε agentic υποδομές όπου τα retries δεν επαρκούν: ένα προστατευτικό μέτρο δεν είναι επιτυχημένο αν μηδενίζει την αξία της ροής.

Τι έδειξαν οι τέσσερις ροές LLM judges

Η ξεχωριστή audit εξέτασε approvals από qwen2.5:0.5b, llama3.2:1b, Claude Haiku και gpt-4o-mini. Στο DeltaIoT και στο K=8, κάθε stream είχε μη μηδενική use-time invalidity, από 11,5% έως 36,8% μέσα στο δικό του approval set.

Τα νούμερα δεν αποτελούν ranking ποιότητας. Κάθε judge εγκρίνει διαφορετικό σύνολο ενεργειών, ενώ η μέτρηση μπορεί να περιέχει τόσο check-time error όσο και μεταγενέστερο expiry. Η εργασία δεν αξιολογεί το ίδιο judge-generated stream με και χωρίς FBS, επομένως δεν επιτρέπεται να συμπεράνουμε πόσο θα βελτίωνε το FBS καθένα από τα τέσσερα μοντέλα.

Το ασφαλές συμπέρασμα είναι θεμελιώδες: σε κάθε εξεταζόμενη ροή υπήρχαν approvals που δεν ήταν έγκυρα στη στιγμή χρήσης. Η επιλογή καλύτερου μοντέλου ή το υψηλό accuracy στο check time δεν λύνουν από μόνα τους το χρονικό πρόβλημα. Όπως και στο tool calling όπου ένα πρώτο λάθος επηρεάζει όλη την αλυσίδα, η αξιοπιστία χρειάζεται runtime controls πέρα από το μοντέλο.

Το freshness contract για παραγωγικά συστήματα

Οι συγγραφείς προτείνουν ένα freshness contract: κάθε έγκριση πρέπει να καταγράφει το context και την ενέργεια που ελέγχθηκαν, τον χρόνο grounding, έναν κανόνα λήξης ή επανελέγχου και ένα αιτιολογημένο fallback. Η ορθότητα στο check time είναι μόνο το πρώτο μισό της υποχρέωσης· το δεύτερο είναι η εγκυρότητα στο use time.

Η παρακολούθηση πρέπει να περιλαμβάνει την κατανομή της πραγματικής ηλικίας K_live, το signed margin, τη volatility, τη συχνότητα fallback και την επιχειρηματική utility. Τα offline replay audits μπορούν να μετρούν χωριστά το oracle-labeled expiry, ενώ τα logs χρειάζονται ακριβή timestamps, versioned predicates και σαφή αναφορά στο policy που παρήγαγε το approval.

Το contract χρειάζεται ιδιοκτησία. Η ομάδα μοντέλου μπορεί να παρακολουθεί την ποιότητα του judge, αλλά η ομάδα προϊόντος ή συστήματος πρέπει να ορίσει τι σημαίνει ληγμένη απόφαση και ποια ενέργεια ακολουθεί. Αν το predicate ή το fallback αλλάξει, η αλλαγή πρέπει να εκδοθεί ως νέα έκδοση και να συνδεθεί με τα approvals που παρήχθησαν κάτω από εκείνη.

Η λογική συμπληρώνει την προσέγγιση της ρητής κατάστασης στους AI agents. Το operational state λέει ποια είναι η τρέχουσα αλήθεια, ενώ το freshness contract λέει για πόσο μπορεί να χρησιμοποιηθεί μια κρίση που βασίστηκε σε προηγούμενη αλήθεια. Τα δύο χρειάζονται ξεχωριστό audit trail.

Εφαρμογή σε e-commerce, marketing και operations

Στο e-commerce, ένα freshness contract μπορεί να συνοδεύει approvals για επιστροφές, εκπτώσεις, αλλαγές τιμής, ακύρωση παραγγελιών και διαχείριση αποθέματος. Το checked snapshot πρέπει να περιλαμβάνει τα πεδία που δικαιολογούν την πράξη, ενώ η λήξη μπορεί να ενεργοποιείται όταν αλλάζει η κατάσταση πληρωμής, το διαθέσιμο απόθεμα, η αξία του καλαθιού ή το fulfillment status.

Στο marketing automation, ένας agent μπορεί να εγκρίνει audience, budget ή creative βάσει δεδομένων που μεταβάλλονται γρήγορα. Η σωστή προσαρμογή δεν είναι να αντιγραφούν τα thresholds της μελέτης, αλλά να οριστεί ποιο metric αποτελεί ουσιαστικό margin, πώς μετριέται η volatility και ποιο fallback είναι αποδεκτό. Ένα no-op δεν είναι αυτομάτως ασφαλές: η καθυστέρηση καμπάνιας ή η μη εκτέλεση υποχρεωτικής ενέργειας μπορεί να έχει πραγματικό κόστος.

Στην εξυπηρέτηση πελατών, μια προέγκριση πρέπει να επαληθεύει ότι η υπόθεση, τα δικαιώματα, η συναλλαγή και οι προηγούμενες ενέργειες παραμένουν αμετάβλητα. Αυτό είναι ιδιαίτερα σημαντικό όταν ένα conversational support σύστημα συνδέεται με e-commerce πράξεις και δεν περιορίζεται σε απαντήσεις κειμένου.

Για υψηλού αντίκτυπου ενέργειες, η επανεπικύρωση ακριβώς πριν από το dispatch μπορεί να είναι καταλληλότερη από έναν heuristic horizon. Η μελέτη προσφέρει σχεδιαστική αρχή, όχι έτοιμο universal policy. Η ανθρώπινη έγκριση επίσης δεν λύνει αυτόματα το πρόβλημα αν η τελική εκτέλεση γίνεται αρκετά αργότερα πάνω σε διαφορετικό state.

Τα όρια της μελέτης και του FBS

Τα πειράματα έγιναν σε πέντε step-driven simulators, με αραιό grid K={1,2,3,5,8,10} και σταθερές ρυθμίσεις FBS. Ίδιο K δεν σημαίνει ίδιο χρόνο. Η ευαισθησία στις παραμέτρους και στις ενδιάμεσες ηλικίες δεν μετρήθηκε, ενώ οι eligible παρατηρήσεις μειώνονται κοντά στα όρια κάθε episode.

Το replay κρατά σταθερή την υποψήφια ενέργεια και τη βαθμολογεί σε μεταγενέστερο recorded context. Δεν ανακατασκευάζει αιτιακά τι θα συνέβαινε αν η ενέργεια καθυστερούσε, απορριπτόταν ή αντικαθιστόταν. Ο deterministic checker καλύπτει συγκεκριμένα operational predicates, όχι κάθε διάσταση ασφάλειας.

Το FBS αντικαθιστά ένα άγνωστο worst-case drift bound με smoothed recent change. Ένα απότομο άλμα μπορεί να ξεπεράσει την εκτίμηση. Το scalar feature μπορεί να μην αποτυπώνει όλες τις εξαρτήσεις, το age measurement πρέπει να είναι αξιόπιστο και το fallback να είναι σχεδιασμένο για το συγκεκριμένο σύστημα.

Οι ίδιοι οι συγγραφείς χαρακτηρίζουν το FBS proof-of-concept heuristic και όχι πιστοποιημένη εγγύηση. Η utility αξιολογήθηκε μόνο στο DeltaIoT για K=8, ενώ η end-to-end σύνθεση Judge+FBS πάνω στο ίδιο judge-generated stream παραμένει μελλοντική εργασία. Για αποφάσεις υψηλού ρίσκου, χρειάζεται ο συνδυασμός freshness, fidelity και ελέγχου που αναλύεται και στο άρθρο για AI agents που είναι πειστικοί αλλά όχι πάντα πιστοί.

Επτά βήματα πριν από την παραγωγή

Η μετάβαση από ένα καλό offline accuracy σε ασφαλή εκτέλεση χρειάζεται μετρήσιμο συμβόλαιο. Το παρακάτω checklist μεταφέρει τη λογική της εργασίας σε e-commerce, CRM, customer support και εσωτερικούς αυτοματισμούς χωρίς να παρουσιάζει το FBS ως έτοιμη συνταγή.

Η επιχειρηματική αρχή: καμία έγκριση χωρίς λήξη

Ένα approval δεν πρέπει να αποθηκεύεται ως γυμνό boolean. Χρειάζεται provenance, χρονικό σημείο αναφοράς, checked context, συνθήκες εγκυρότητας και καθορισμένη συμπεριφορά όταν λήξει. Η αρχή ισχύει για LLM guardrails, ανθρώπινα approvals και κάθε delayed approver που βασίζεται σε μεταβαλλόμενη κατάσταση.

Για τις ομάδες που σχεδιάζουν AI agents, η αξιολόγηση πρέπει να περάσει από το «πόσο συχνά απαντά σωστά το μοντέλο;» στο «πόσο συχνά η εγκεκριμένη πράξη παραμένει σωστή όταν εκτελείται και ποιο είναι το κόστος όταν τη σταματάμε;». Η φρεσκάδα μιας απόφασης είναι μέρος της αξιοπιστίας της, όχι απλώς μέρος της ταχύτητας.