Διαγραφή και εξαγωγή ιστορικού chatbot: Ασφαλής έλεγχος για τους χρήστες

Το ιστορικό ενός chatbot είναι βολικό για τους χρήστες: μπορούν να διαβάσουν ξανά απαντήσεις, να συνεχίσουν μια συνομιλία αργότερα ή να μεταβιβάσουν πληροφορίες στην υποστήριξη. Το ίδιο ιστορικό όμως μπορεί να περιέχει αριθμούς παραγγελιών, περιγραφές προβλημάτων, στοιχεία επικοινωνίας ή άλλα ευαίσθητα δεδομένα. Όποιος αποθηκεύει συνομιλίες, χρειάζεται γι' αυτό κάτι περισσότερο από έναν διακριτικό διακόπτη «Ιστορικό». Οι χρήστες θα πρέπει να κατανοούν ποια δεδομένα υπάρχουν, πώς μπορούν να τα πάρουν μαζί τους, να τα διαγράψουν ή να ανακαλέσουν την περαιτέρω πρόσβαση.

Αυτός ο οδηγός παρουσιάζει ένα εφαρμόσιμο προϊόντικο και τεχνικό μοντέλο για chatbots ιστότοπων. Συνδυάζει τη φιλικότητα προς τον χρήστη, την ελαχιστοποίηση δεδομένων, τον ασφαλή έλεγχο ταυτότητας και τις κατανοητές καταστάσεις συστήματος. Οι υποδείξεις δεν αποτελούν εξατομικευμένη νομική συμβουλή· οι συγκεκριμένες υποχρεώσεις εξαρτώνται, μεταξύ άλλων, από τον σκοπό, τη νομική βάση, την αρχιτεκτονική του συστήματος και τα εμπλεκόμενα δεδομένα.

Τέσσερις λειτουργίες αντί για έναν μόνο διακόπτη ιστορικού

Η «Διαχείριση ιστορικού» είναι πολύ αόριστη. Στο περιβάλλον χρήστη και στο backend θα πρέπει να διαχωρίζονται τέσσερις διαφορετικές προθέσεις:

• Προβολή: Οι χρήστες διαβάζουν αποθηκευμένες συνομιλίες, συνημμένα και αναγνωρίσιμα μεταδεδομένα σε μια κατανοητή χρονολογική σειρά.
• Εξαγωγή: Λαμβάνουν ένα αντίγραφο σε αναγνώσιμη μορφή και, εάν είναι χρήσιμο για την περίπτωση χρήσης ή απαιτείται νομικά, επιπλέον σε μια δομημένη μηχαναγνώσιμη μορφή.
• Διαγραφή: Αφαιρούν μεμονωμένες συνομιλίες ή ολόκληρο το συσχετισμένο ιστορικό. Το περιβάλλον χρήστη εξηγεί την έκταση, τις προθεσμίες και τις πιθανές εξαιρέσεις.
• Ανάκληση πρόσβασης: Ακυρώνουν συνδέσμους κοινοποίησης, γνωστές συσκευές ή διακριτικά (tokens) επανέναρξης, χωρίς απαραίτητα να διαγράφουν αμέσως όλα τα δεδομένα περιεχομένου.

Αυτός ο διαχωρισμός αποτρέπει επικίνδυνες παρερμηνείες. Η «Αποσύνδεση» δεν διαγράφει δεδομένα συνομιλίας. Η «Απόκρυψη ιστορικού» δεν είναι διαγραφή. Και ένας ληγμένος σύνδεσμος δεν σημαίνει αυτόματα ότι οι υποκείμενες εγγραφές δεδομένων έχουν εξαφανιστεί. Συμπληρωματικά, αξίζει να διαβάσετε τον οδηγό μας για την ασφαλή συνέχιση των συνομιλιών chatbot.

Ξεκινήστε με ένα ξεκάθαρο μοντέλο δεδομένων

Πριν οι ομάδες σχεδιάσουν κουμπιά, θα πρέπει να καταγράψουν τα αποθηκευμένα αντικείμενα. Μια συνομιλία συχνά δεν αποτελείται μόνο από μηνύματα. Προστίθενται αναγνωριστικά συνεδρίας, χρονοσημάνσεις, αναφορές αρχείων, συμβάντα ασφαλείας, εισιτήρια υποστήριξης, σχόλια (feedback) και τεχνικά αρχεία καταγραφής (logs). Για κάθε αντικείμενο χρειάζεται ένας τεκμηριωμένος σκοπός, ένας υπεύθυνος, ένας κανόνας διατήρησης και μια διαδρομή διαγραφής.

Ο Γενικός Κανονισμός για την Προστασία Δεδομένων αναφέρει στο Άρθρο 5, μεταξύ άλλων, την ελαχιστοποίηση των δεδομένων και τον περιορισμό της περιόδου αποθήκευσης. Το Άρθρο 15 αφορά το δικαίωμα πρόσβασης, το Άρθρο 17 το δικαίωμα διαγραφής με προϋποθέσεις και εξαιρέσεις, και το Άρθρο 20 τη φορητότητα των δεδομένων στο εκάστοτε πεδίο εφαρμογής τους. Από αυτό δεν προκύπτει ότι κάθε περιβάλλον chatbot πρέπει να προσφέρει ταυτόσημες λειτουργίες. Οι ομάδες προϊόντος θα πρέπει όμως να κατασκευάζουν τις ροές δεδομένων έτσι ώστε τα αιτήματα που δικαιούνται απάντησης να μπορούν να διεκπεραιώνονται αξιόπιστα.

Ελέγξτε την ταυτότητα κατάλληλα πριν από την εξαγωγή και τη διαγραφή

Όποιος καθιστά ένα ιστορικό προσβάσιμο μόνο μέσω ενός συνδέσμου που μπορεί να προβλεφθεί ή ενός επαναχρησιμοποιούμενου αναγνωριστικού συνεδρίας, διακινδυνεύει διαρροή δεδομένων. Ταυτόχρονα, ο έλεγχος ταυτότητας δεν επιτρέπεται να απαιτεί γενικά περισσότερα προσωπικά δεδομένα από όσα είναι απαραίτητα για τη συγκεκριμένη ενέργεια. Οι τελικές Κατευθυντήριες Γραμμές EDPB 01/2022 για το δικαίωμα πρόσβασης πραγματεύονται, μεταξύ άλλων, την ταυτοποίηση, την έκταση και την ασφαλή παροχή αντιγράφων. Το Άρθρο 12 Παράγραφος 6 του GDPR επιτρέπει πρόσθετες πληροφορίες για την επιβεβαίωση της ταυτότητας, εάν υπάρχουν δικαιολογημένες αμφιβολίες για την ταυτότητα.

Στην πράξη, έχει αποδειχθεί αποτελεσματική μια διαβάθμιση βάσει κινδύνου. Η προβολή ενός ψευδώνυμου σύντομου ιστορικού στην ίδια συσκευή μπορεί να απαιτεί μια έγκυρη, βραχύβια συνεδρία. Μια συνολική εξαγωγή, μια μη αναστρέψιμη διαγραφή ή η ανάκληση όλων των συσκευών δικαιολογεί μάλλον έναν νέο έλεγχο ταυτότητας. Η τρέχουσα κατευθυντήρια γραμμή του NIST για τη διαχείριση συνεδριών περιγράφει τον επανέλεγχο ταυτότητας (re-authentication), τα χρονικά όρια και τον τερματισμό συνεδρίας ως ανεξάρτητους ελέγχους. Η συγκεκριμένη ισχύς πρέπει να ταιριάζει με τον κίνδυνο· οι προδιαγραφές του NIST για τις ομοσπονδιακές αρχές των ΗΠΑ δεν αποτελούν γενική νομική απαίτηση για κάθε επιχείρηση.

Για τα δημόσια widgets και τις περιοχές συνδεδεμένων πελατών, το όριο θα πρέπει να παραμένει ορατό. Το άρθρο μας σχετικά με την ταυτότητα και την πρόσβαση σε δεδομένα στην πύλη πελατών δείχνει γιατί μια δημόσια συνομιλία δεν πρέπει να μετατρέπεται σιωπηρά σε κανάλι δεδομένων λογαριασμού.

Μια εξαγωγή πρέπει να είναι κατανοητή και πλήρως εξηγήσιμη

Μια καλή εξαγωγή δεν είναι μια ακατέργαστη απόρριψη (dump) από τη βάση δεδομένων. Ξεκινά με μια επισκόπηση: χρονική περίοδος δημιουργίας, περιλαμβανόμενες συνομιλίες, συνημμένα, χρησιμοποιούμενη ζώνη ώρας και έκδοση μορφής. Στη συνέχεια ακολουθεί το περιεχόμενο σε σαφή σειρά. Το JSON μπορεί να είναι χρήσιμο για δομημένη περαιτέρω επεξεργασία· το HTML ή το PDF είναι πιο εύκολα αναγνώσιμο για τους περισσότερους ανθρώπους. Το κατά πόσον και σε ποιο βαθμό απαιτείται νομικά μια φορητή μορφή θα πρέπει να εξετάζεται για τη συγκεκριμένη περίπτωση.

Εάν το σύστημα δημιουργεί την εξαγωγή ασύγχρονα, το περιβάλλον χρήστη χρειάζεται μια σαφή κατάσταση: «προετοιμάζεται», «έτοιμο έως...», «έληξε» ή «απέτυχε». Ο σύνδεσμος λήψης θα πρέπει να είναι βραχύβιος, να μην μπορεί να προβλεφθεί και να μπορεί να ανακληθεί μετά τη χρήση. Μυστικά όπως εσωτερικά prompts, κλειδιά πρόσβασης ή δεδομένα άλλων προσώπων δεν ανήκουν στο πακέτο. Πριν από την παροχή, ένα φίλτρο στην πλευρά του διακομιστή (server-side) θα πρέπει να ελέγχει εάν οι συσχετίσεις με υποθέσεις υποστήριξης, κοινόχρηστες συνομιλίες ή περιεχόμενο τρίτων απαιτούν ειδικό χειρισμό.

Η διαγραφή ως μηχανή κατάστασης αντί για υπόσχεση άμεσης ενέργειας

Ένα κουμπί με το μήνυμα «Όλα διαγράφηκαν» είναι προβληματικό όταν το ευρετήριο αναζήτησης, το αρχείο αναλύσεων, το σύστημα υποστήριξης ή τα αντιγράφα ασφαλείας (backups) εξακολουθούν να περιέχουν αντίγραφα. Καλύτερη είναι μια μικρή μηχανή κατάστασης (state machine) που απεικονίζει την πραγματική διαδικασία.

Ουσιαστικές καταστάσεις διαγραφής

1. Υποβλήθηκε αίτημα: Η ταυτότητα και το επιθυμητό εύρος έχουν επιβεβαιωθεί.
2. Κλειδωμένο: Το ιστορικό δεν είναι πλέον προσβάσιμο για κανονική χρήση· τα διακριτικά επανέναρξης και κοινοποίησης είναι άκυρα.
3. Σε επεξεργασία: Η πρωτεύουσα μνήμη, το ευρετήριο αναζήτησης, η αποθήκευση αρχείων, οι προορισμοί ανάλυσης και ενοποίησης επεξεργάζονται.
4. Ολοκληρώθηκε: Τα προβλεπόμενα ενεργά συστήματα έχουν καθαριστεί· τα εναπομείναντα αντίγραφα ασφαλείας υπόκεινται στη δεδομένη εναλλαγή backup ή σε μια αιτιολογημένη εξαίρεση.
5. Μερικώς μπλοκαρισμένο: Ένα σύστημα δεν μπόρεσε να καθαριστεί ή τα δεδομένα πρέπει να διατηρηθούν προς το παρόν. Η περίπτωση κλιμακώνεται με διαφανή τρόπο.

Μην ξεχνάτε τα εξαρτώμενα δεδομένα

Τα μηνύματα μπορούν να αναφέρονται σε αρχεία, embeddings, ευρετήρια αναζήτησης, αξιολογήσεις ποιότητας, εγγραφές CRM ή εισιτήρια υποστήριξης. Το αίτημα διαγραφής χρειάζεται επομένως ένα σταθερό ID αιτήματος και ιδιοδύναμα (idempotent) βήματα εργασίας: μια νέα εκτέλεση δεν επιτρέπεται να δημιουργεί νέα αντίγραφα ή να αναιρεί βήματα που έχουν ήδη ολοκληρωθεί. Για τα δεδομένα μετρήσεων, θα πρέπει ήδη από τον σχεδιασμό να αποφασιστεί εάν μπορούν να διατηρηθούν συγκεντρωτικοί δείκτες που δεν μπορούν πλέον να συσχετιστούν. Περισσότερα γι' αυτό υπάρχουν στο άρθρο σχετικά με τα analytics chatbot με ελαχιστοποίηση δεδομένων.

Η ανάκληση προστατεύει ιδιαίτερα σε κοινόχρηστες συσκευές

Σε ξενοδοχεία, χώρους πωλήσεων, εργαστήρια ή οικογενειακά νοικοκυριά, τα άτομα αλλάζουν συχνότερα στην ίδια συσκευή. Γι' αυτό η «Ανάκληση πρόσβασης» θα πρέπει να μπορεί να κάνει περισσότερα από τη διαγραφή ενός cookie τοπικά. Στην πλευρά του διακομιστή, τα γνωστά διακριτικά συνεδρίας, οι σύνδεσμοι κοινοποίησης και ενδεχομένως οι συνδέσεις συσκευών πρέπει να ακυρώνονται. Το περιβάλλον χρήστη θα πρέπει να διακρίνει μεταξύ «αυτής της συσκευής», «όλων των συσκευών» και «όλων των κοινόχρηστων συνδέσμων».

Μετά την ανάκληση, το κουμπί επιστροφής δεν επιτρέπεται να εμφανίζει ευαίσθητο ιστορικό από τη λανθάνουσα μνήμη (cache). Οι προεπισκοπήσεις στις ειδοποιήσεις, η αυτόματη συμπλήρωση προγράμματος περιήγησης και τα τοπικά δεδομένα εκτός σύνδεσης (offline) ανήκουν στον έλεγχο. Ταυτόχρονα, ο χρήστης θα πρέπει να λαμβάνει μια σαφή επιβεβαίωση σχετικά με το ποιες προσβάσεις τερματίστηκαν και εάν τα δεδομένα συνομιλίας εξακολουθούν να είναι αποθηκευμένα. Έτσι, η ανάκληση δεν συγχέεται με τη διαγραφή.

Σχεδιάστε την επιβεβαίωση διαγραφής προσβάσιμη και με ανοχή σε σφάλματα

Μια μη αναστρέψιμη ενέργεια χρειάζεται μια ήρεμη, κατανοητή επιβεβαίωση. Η επεξήγηση του WCAG 2.2 για το Κριτήριο Επιτυχίας 3.3.4 αναφέρεται ρητά και στην τροποποίηση ή διαγραφή δεδομένων που ελέγχονται από τον χρήστη. Προβλέπεται τουλάχιστον μία δυνατότητα αναστροφής, ελέγχου ή επιβεβαίωσης. Ποια παραλλαγή ταιριάζει εξαρτάται από το προϊόν.

Οι καλοί διάλογοι αναφέρουν συγκεκριμένα «3 συνομιλίες και 2 συνημμένα» αντί για απλά «δεδομένα». Η πρωτεύουσα και η καταστροφική ενέργεια ορίζονται με σαφήνεια οπτικά, είναι προσβάσιμες μέσω πληκτρολογίου και δεν εξηγούνται μόνο μέσω του χρώματος. Μετά την υποβολή, μια προσβάσιμη περιοχή κατάστασης αναφέρει ότι το αίτημα έγινε δεκτό. Ένας κάδος ανακύκλωσης με περιορισμένη προθεσμία επαναφοράς μπορεί να καλύψει λάθη χειρισμού, αλλά δεν επιτρέπεται να έρχεται κρυφά σε αντίθεση με μια υποσχόμενη άμεση διαγραφή.

Μεταβίβαση στην υποστήριξη χωρίς σκιώδη αντίγραφα

Εάν μια συνομιλία μεταβιβαστεί σε ανθρώπους, συχνά δημιουργείται ένα ξεχωριστό εισιτήριο υποστήριξης. Αυτό το αντικείμενο ενδέχεται να έχει διαφορετικό σκοπό, διαφορετικούς ρόλους πρόσβασης και διαφορετικό κανόνα διατήρησης. Η ρύθμιση ιστορικού στο chatbot δεν επιτρέπεται ούτε να διαγράφει αόρατα ένα τέτοιο εισιτήριο ούτε να το αγνοεί σιωπηρά. Πριν από τη μεταβίβαση, το περιβάλλον χρήστη θα πρέπει να εξηγεί ποια περιεχόμενα μεταφέρονται. Σε μεταγενέστερο αίτημα, το σύστημα πρέπει να βρει τη σύνδεση και να χειριστεί την υπόθεση σύμφωνα με τους ισχύοντες κανόνες.

Εάν μια αυτόματη διαγραφή αποτύχει ή η ταυτότητα και το εύρος είναι ασαφή, η διαδικασία χρειάζεται ένα ασφαλές ανθρώπινο κανάλι. Το άρθρο σχετικά με το Human Handoff στην υποστήριξη ιστότοπων περιγράφει γι' αυτό πακέτα πλαισίου και κανόνες κλιμάκωσης. Θα πρέπει να μεταβιβάζεται μόνο ό,τι πραγματικά χρειάζεται ο αρμόδιος υπάλληλος.

Λίστα ελέγχου υλοποίησης για ομάδες προϊόντος και υποστήριξης

1. Καταγράψτε όλα τα αντικείμενα δεδομένων και τις τοποθεσίες αποθήκευσης μιας συνομιλίας.
2. Μοντελοποιήστε την προβολή, την εξαγωγή, τη διαγραφή και την ανάκληση ως ξεχωριστά δικαιώματα.
3. Επανελέγξτε την ταυτότητα βάσει κινδύνου για ευαίσθητες ενέργειες.
4. Δομήστε τα πακέτα εξαγωγής με κατανοητό τρόπο και ορίστε ασφαλείς χρόνους λήξης.
5. Κάντε τα βήματα διαγραφής ιδιοδύναμα (idempotent) και παρακολουθήστε τα με ένα ID αιτήματος.
6. Συμπεριλάβετε το ευρετήριο αναζήτησης, αρχεία, analytics, ενοποιήσεις, caches και υποθέσεις υποστήριξης.
7. Δοκιμάστε τους διαλόγους επιβεβαίωσης και τα μηνύματα κατάστασης με πληκτρολόγιο και αναγνώστη οθόνης (screen reader).
8. Προσομοιώστε κοινόχρηστες συσκευές, ληγμένους συνδέσμους και χαμένες συσκευές.
9. Κλιμακώστε τα μερικά σφάλματα ορατά, χωρίς να αντιγράφετε ευαίσθητο περιεχόμενο στα αρχεία καταγραφής.
10. Ελέγχετε τακτικά τους κανόνες διατήρησης και διαγραφής με την προστασία δεδομένων και τα αρμόδια τμήματα.

Οι σημαντικότερες δοκιμές πριν από το λανσάρισμα

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

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

Συμπέρασμα: Ο έλεγχος του χρήστη είναι μια ιδιότητα άκρου εις άκρον (End-to-End)

Ένα αξιόπιστο chatbot δεν κάνει το ιστορικό απλώς προσβάσιμο. Διαχωρίζει την προβολή, την εξαγωγή, τη διαγραφή και την ανάκληση, ελέγχει τις ευαίσθητες ενέργειες ανάλογα και δείχνει την πραγματική κατάσταση επεξεργασίας. Καθοριστική είναι η σύνδεση του σαφούς UX με ένα μοντέλο δεδομένων που γνωρίζει όλα τα εξαρτώμενα συστήματα.

Όποιος ενσωματώνει αυτές τις λειτουργίες νωρίς στην αρχιτεκτονική, στις διαδικασίες υποστήριξης και στις δοκιμές, μειώνει τις χειροκίνητες ειδικές περιπτώσεις και αποφεύγει τις ψευδείς υποσχέσεις. Εξετάστε επίσης κατά τον σχεδιασμό ποιες λειτουργίες του ChatReact ταιριάζουν στον ιστότοπό σας και στη διαδικασία υποστήριξής σας. Ξεκινήστε με μια καταγραφή δεδομένων και μια μεμονωμένη δοκιμή άκρου εις άκρον: εξαγωγή ιστορικού, ανάκληση πρόσβασης, ενεργοποίηση διαγραφής και απόδειξη του αποτελέσματος σε όλα τα εμπλεκόμενα συστήματα.

Πηγές και πρόσθετες υποδείξεις

• EUR-Lex: Κανονισμός (ΕΕ) 2016/679, ειδικότερα τα Άρθρα 5, 12, 15, 17 και 20.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Έκδοση 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.