Δρομολόγηση API AI-Retention-Aware: Επιβολή πολιτικών ZDR, κατοικίας και καταγραφής στο Gateway

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

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

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

Το πρόβλημα του αναγνώστη: οι όροι απορρήτου του παρόχου δεν είναι στοιχεία ελέγχου χρόνου εκτέλεσης

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

Οι εφαρμογές κάνουν επιλογές χρόνου εκτέλεσης:

• Ποιο αναγνωριστικό μοντέλου θα πρέπει να χειριστεί αυτό το αίτημα;
• Θα πρέπει το αίτημα να χρησιμοποιεί γείωση αναζήτησης, μεταφόρτωση αρχείων, εκτέλεση κώδικα, μαζική επεξεργασία, προσωρινή αποθήκευση προτροπής ή αποθηκευμένες συνομιλίες;
• Ποια περιοχή ή τελικό σημείο πρέπει να επεξεργαστεί το αίτημα;
• Μπορεί το σύστημα να καταγράψει το μη επεξεργασμένο μήνυμα για εντοπισμό σφαλμάτων;
• Μπορεί η εναλλακτική δρομολόγηση να στείλει το ίδιο αίτημα σε άλλο πάροχο;

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

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

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

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

Πολλά τρέχοντα έγγραφα δημόσιου παρόχου δείχνουν γιατί είναι απαραίτητο:

• OpenAI: Η κατοικία δεδομένων API τεκμηριώνεται ως διαμορφωμένη βάσει έργου, με τοπικά αιτήματα που απαιτούν προθέματα τομέα για συγκεκριμένη περιοχή. Το OpenAI διακρίνει επίσης την υποστήριξη αποθήκευσης από την υποστήριξη επεξεργασίας ανά περιοχή και σημειώνει πρόσθετες απαιτήσεις για περιοχές εκτός των ΗΠΑ. Το OpenAI δηλώνει ότι η παραμονή δεδομένων API εκτός ΗΠΑ απαιτεί έγκριση για ελέγχους παρακολούθησης κατάχρησης και τροποποίηση Τροποποιημένης διατήρησης.
• Anthropic: Το Anthropic τεκμηριώνει μηδενική διατήρηση δεδομένων για περιπτώσεις εμπορικής χρήσης που σχετίζονται με API, σημειώνοντας παράλληλα ότι ορισμένα σχετικά προϊόντα ή ροές συμμόρφωσης έχουν ξεχωριστά μοντέλα διατήρησης, συμπεριλαμβανομένης της μεγαλύτερης διατήρησης για τη ροή δραστηριότητας και τις μεταγραφές απομακρυσμένων περιόδων σύνδεσης.
• Google Gemini: Οι όροι του API Gemini διακρίνουν τις υπηρεσίες χωρίς πληρωμή και υπηρεσίες επί πληρωμή. Για υπηρεσίες χωρίς πληρωμή, η Google μπορεί να χρησιμοποιήσει το περιεχόμενο που έχει υποβληθεί και τις δημιουργημένες απαντήσεις για τη βελτίωση των προϊόντων. για υπηρεσίες επί πληρωμή, η Google λέει ότι τα μηνύματα προτροπής και οι απαντήσεις δεν χρησιμοποιούνται για τη βελτίωση των προϊόντων. Η τεκμηρίωση του Gemini Developer API ZDR λέει ότι τα αρχεία καταγραφής κατάχρησης-παρακολούθησης υπηρεσιών επί πληρωμή διατηρούν κανονικά μηνύματα προτροπής και απαντήσεις για περιορισμένο χρονικό διάστημα, ενώ το εγκεκριμένο ZDR προβάλλει σαφές περιεχόμενο χρήστη και αναγνωρίσιμα μεταδεδομένα πριν από την καταγραφή.
• Αποθηκευτικός χώρος ειδικά για λειτουργίες: Η τεκμηρίωση Gemini αναφέρει ότι η γείωση με την Αναζήτηση Google και η γείωση με τους Χάρτες Google αποθηκεύουν μηνύματα προτροπής, πληροφορίες με βάση τα συμφραζόμενα και παραγόμενα αποτελέσματα για 30 ημέρες, χωρίς τρόπο να απενεργοποιήσετε αυτόν τον χώρο αποθήκευσης όταν χρησιμοποιούνται αυτές οι λειτουργίες.
• Αρχεία καταγραφής που ανήκουν σε προγραμματιστές: Η τεκμηρίωση καταγραφής API Gemini αναφέρει ότι τα αρχεία καταγραφής API που ανήκουν σε προγραμματιστές μπορούν να διατηρηθούν έως και 55 ημέρες από προεπιλογή για έργα με δυνατότητα χρέωσης και ότι οι προγραμματιστές μπορούν να επιλέξουν μικρότερα παράθυρα όπως 7, 14 ή 28 ημερών.
• Διαχείριση κινδύνου: Το Generative AI Profile του NIST συνιστά την παρακολούθηση του περιεχομένου που δημιουργείται από AI για κινδύνους απορρήτου και τη σύνδεση πολιτικών παραγωγής τεχνητής νοημοσύνης με υπάρχοντα δεδομένα, λογισμικό, νομικές διαδικασίες, διαδικασίες συμμόρφωσης και διαχείρισης κινδύνου.

Αυτά είναι γεγονότα που πρέπει να επαληθεύσετε σε σχέση με την τρέχουσα τεκμηρίωση προμηθευτή πριν από την κυκλοφορία. Το αρχιτεκτονικό μάθημα είναι σταθερό: η διατήρηση δεν είναι Boolean ενός επιπέδου παρόχου.

Αρχιτεκτονική: μηχανισμός πολιτικής πύλης στη διαδρομή αιτήματος

Μια πύλη με επίγνωση διατήρησης έχει πέντε βασικά στοιχεία:

1. Αίτημα ταξινομητή ευαισθησίας: επισημαίνει το φόρτο εργασίας πριν από τη δρομολόγηση.
2. Πίνακας δυνατοτήτων παρόχου: περιγράφει τον πάροχο, το μοντέλο, το τελικό σημείο, την περιοχή, τη διατήρηση, την καταγραφή και τη συμπεριφορά χαρακτηριστικών.
3. Κανόνες πολιτικής ως κώδικα: μετατρέπουν τις απαιτήσεις ασφαλείας σε χρόνο εκτέλεσης, επιτρέπονται, απορρίπτονται ή εξετάζονται αποφάσεις.
4. Επίπεδο πύλης λειτουργιών: αποκλείει λειτουργίες που αλλάζουν τη διατήρηση εκτός εάν επιτρέπεται ρητά.
5. Επίπεδο ελέγχου και αναλυτικών στοιχείων: καταγράφει χρήσιμα μεταδεδομένα χωρίς να αποθηκεύει μη επεξεργασμένα μηνύματα από προεπιλογή.

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

Βήμα 1: ταξινομήστε την ευαισθησία αιτημάτων πριν επιλέξετε ένα μοντέλο

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

Παραδείγματα ετικετών ευαισθησίας:

• δημόσιο: δημόσια τεκμηρίωση, αντίγραφο μάρκετινγκ, περιεχόμενο δημόσιου ιστότοπου.
• εσωτερικές: μη δημόσιες πληροφορίες εταιρείας με χαμηλή ευαισθησία.
• εμπιστευτικό: στρατηγική, συμβόλαια, πλαίσιο πελατών, λεπτομέρειες προϊόντων που δεν έχουν κυκλοφορήσει.
• customer_pii: ονόματα, μηνύματα ηλεκτρονικού ταχυδρομείου, διευθύνσεις, αναγνωριστικά λογαριασμού, μεταγραφές υποστήριξης.
• ρυθμίζεται: προστατευμένα δεδομένα υγειονομικής περίθαλψης, οικονομικά, νομικά, εκπαίδευσης ή δικαιοδοσίας.
• source_code: αποκλειστικός κώδικας, διαμόρφωση, αρχεία αρχιτεκτονικής.
• διαπιστευτήρια: μυστικά, διακριτικά, κωδικοί πρόσβασης, ιδιωτικά κλειδιά. Στα περισσότερα συστήματα αυτό θα πρέπει να αποκλειστεί και όχι να δρομολογηθεί.

Η ταξινόμηση μπορεί να προέρχεται από πολλές πηγές:

• Μια κεφαλίδα που παρέχεται από την εφαρμογή, όπως X-Data-Class: customer_pii.
• Πολιτική ενοικιαστών, όπου όλη η κίνηση από έναν εγκεκριμένο πελάτη αντιμετωπίζεται ως ρυθμιζόμενη, εκτός εάν υποβαθμιστεί από έναν εγκεκριμένο κανόνα.
• Πολιτική τελικού σημείου, όπου η σύνοψη εισιτηρίων υποστήριξης είναι από προεπιλογή customer_pii.
• Σάρωση ελαφρού περιεχομένου για διαπιστευτήρια, προφανείς PII ή παραβάσεις πολιτικής.

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

Βήμα 2: δημιουργήστε έναν πίνακα δυνατοτήτων παρόχου

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

Παράδειγμα πεδίων:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "model-large",
  "api_family": "chat_completions",
  "endpoint": "https://eu.example-provider.com/v1",
  "περιοχή": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": αληθές,
  "zdr_contract_required": true,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": false,
  "supported_features": {
    "plain_chat": αλήθεια,
    "streaming": αλήθεια,
    "tool_calls": true,
    "search_grounding": ψευδής,
    "maps_grounding": false,
    "file_upload": ψευδής,
    "παρτίδα": ψευδής,
    "stored_conversations": ψευδής
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Χρησιμοποιήστε προφίλ μοντέλων αντί για ακατέργαστα αναγνωριστικά μοντέλων. Ένα προφίλ συνδυάζει μοντέλο, πάροχο, τελικό σημείο, περιοχή, σύνολο χαρακτηριστικών και στάση διατήρησης. Οι προγραμματιστές ζητούν model_profile: compliant_summarization, όχι μόνο model: fastest-large-model.

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

Βήμα 3: γράψτε κανόνες πολιτικής ως κώδικα

Οι κανόνες πολιτικής πρέπει να είναι σαφείς, να μπορούν να ελεγχθούν και να αναγνωσθούν από τις ομάδες ασφάλειας και πλατφόρμας.

Παράδειγμα κανόνων στον ψευδοκώδικα:

άρνηση εάν data_class == "διαπιστευτήρια"
  λόγος "credentials_must_not_be_sent_to_model"
επιτρέπεται μόνο εάν η κλάση δεδομένων σε ["regulated", "customer_pii"]
  και profile.zdr_eligible == true
  και profile.zdr_contract_required_satisfied == true
  reason_on_failure "model_profile_not_zdr_eligible"
deny if residency_required == "eu"
  και "eu" όχι στο profile.processing_residency
  λόγος "region_processing_not_supported"
deny if data_class in ["confidential", "customer_pii", "regulated"]και request.raw_prompt_logging == true
  λόγος "raw_prompt_logging_not_allowed"
άρνηση εάν request.features.search_grounding == true
  και policy.requires_zdr == true
  και profile.feature_storage.search_grounding_days > 0
  λόγος "grounding_requires_retained_content"
αρνηθείτε εάν fallback_profile.retention_level 

{
  "σφάλμα": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Δεν επιτρέπεται η γείωση αναζήτησης για φόρτους εργασίας που έχουν επισημανθεί ως requires_zdr επειδή αυτή η δυνατότητα παρόχου αποθηκεύει περιεχόμενο προτροπής, περιεχόμενο και εξόδου.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "request_exception"
    ]
  }
}