AI மின்னஞ்சல் முகவர்களுக்கான GDPR இணக்கம்: Retention மற்றும் Erasure அமைத்தல்

AI மின்னஞ்சல் முகவர்களுக்கான GDPR இணக்கம்: Retention மற்றும் Erasure அமைத்தல்

உங்கள் AI உண்மையான வாடிக்கையாளர் மின்னஞ்சலைப் படிக்கும்போது தானியங்கி நீக்கம் ஏன் அவசியமாகிறது

மின்னஞ்சல்களைப் படித்துப் பதிலளிக்க AI முகவரை நீங்கள் பயன்படுத்தும்போது, அது பயன்படுத்தும் அஞ்சல் பெட்டியில் தனிப்பட்ட தரவுகள் குவிகின்றன: வாடிக்கையாளர் பெயர்கள், முகவரிகள், ஆர்டர் வரலாறுகள், ஆதரவு புகார்கள். இது ஒரு டெமோவில் பிரச்சனையில்லை, ஆனால் உண்மையான நபரின் தகவல் அந்த இன்பாக்ஸில் வந்தவுடன், நீங்கள் GDPR போன்ற விதிமுறைகளின் கீழ் சட்டப்பூர்வ கடமைகளை ஏற்கிறீர்கள்.

இது இப்போது ஏன் முக்கியமானது (ஜூலை 2026)

தரவுப் பாதுகாப்பு இனி விருப்பத்திற்குரியதல்ல. வாடிக்கையாளர் மின்னஞ்சலைக் கையாளும் நிறுவனங்கள், தங்களிடம் பாதுகாப்பான retention கொள்கைகள் இருப்பதையும், கேட்கப்படும் போது ஒருவரின் தரவை உண்மையில் நீக்க முடியும் என்பதையும் நிரூபிக்க வேண்டிய அழுத்தம் அதிகரித்து வருகிறது. பெரும்பாலான AI மின்னஞ்சல் டெமோக்கள் இதை முழுவதுமாகத் தவிர்க்கின்றன — முகவர் படிக்கிறது, கோப்புகளைச் சேமிக்கிறது, மற்றும் இன்பாக்ஸ் வளர்கிறது. ஒரு இணக்க அதிகாரி அல்லது வாடிக்கையாளரின் வழக்கறிஞர்: "எனது தரவை எப்படி நீக்குவீர்கள்?" என்று கேட்கும் வரை அது நன்றாக வேலை செய்யும். உங்கள் பதில் "நாங்கள் எல்லாவற்றையும் நிரந்தரமாக வைத்திருக்கிறோம்" என்று இருந்தால், நீங்கள் சிக்கலில் உள்ளீர்கள்.

ஒரு முகவர் அஞ்சல் பெட்டியை எது வித்தியாசமாக்குகிறது

ஒரு முகவர் கணக்கு என்பது AI மாடல் வைத்திருக்கும் அஞ்சல் பெட்டியாகும் — இது [email protected] ஒரு மனிதனுக்குப் பதிலாக ஒரு மாடலுக்குப் பதிலளிக்கிறது. ஒவ்வொரு உள்வரும் செய்தியும் அதில் வந்து சேர்கிறது, மேலும் அது உண்மையான நபர்களின் தனிப்பட்ட தரவை வைத்திருப்பதால், GDPR இன் கீழ் அந்தத் தரவுக்கு இரண்டு விஷயங்கள் தேவை: ஆவணப்படுத்தப்பட்ட retention காலம், அதனால் அது நிரந்தரமாக இருக்காது, மற்றும் ஒரு நபர் கோரும்போது அவரது செய்திகளை நீக்கக்கூடிய நிரூபிக்கப்பட்ட erasure வழி.

ஒரு நல்ல செய்தி: நீங்கள் எப்படியும் பயன்படுத்தும் API முதன்மைகள் — அஞ்சலைப் பட்டியலிடுதல், படித்தல் மற்றும் நீக்குதல் — வழக்கமான Nylas ஒருங்கிணைப்புகளுக்குச் செயல்படும் அதே வழியில் செயல்படுகின்றன. இதில் புதிதாக இருப்பது control-plane retention policy இது அஞ்சல் தானாகவே எவ்வளவு காலம் இருக்கும் என்பதை அமைக்கிறது, மற்றும் data-plane erasure operation இது கோரிக்கையின் பேரில் ஒரு நபரின் தரவை நீக்குகிறது.

இந்த இரண்டு அடுக்குகள் வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. Retention "நாங்கள் எதையும் எவ்வளவு காலம் வைத்திருக்கிறோம்?" என்று பதிலளிக்கிறது — ஒரு பொதுவான நேர வரம்பு. Erasure "இந்த நபரின் தரவை, இப்போதே நீக்கு" என்று பதிலளிக்கிறது — ஒரு இலக்கு கோரிக்கை. இணக்கமான முகவர் அஞ்சல் பெட்டிக்கு இரண்டும் தேவை; ஒன்று மற்றொன்றுக்கு மாற்றாகாது.

இரண்டு அடுக்குகளைப் புரிந்துகொள்வது

Retention என்பது control-plane அமைப்பாகும், இது ஒரு கொள்கையில் உள்ளது — வரம்புகள் மற்றும் ஸ்பேம் அமைப்புகளைத் தொகுக்கும் application-scoped resource — உங்கள் முகவர் கணக்கு சார்ந்திருக்கும் workspace உடன் இணைக்கப்பட்டுள்ளது. இரண்டு புலங்கள் அஞ்சல் எவ்வளவு காலம் இருக்கும் என்பதைக் கட்டுப்படுத்துகின்றன:

  • limit_inbox_retention_period — தளம் தானாகவே நீக்குவதற்கு முன்பு ஒரு செய்தி இன்பாக்ஸில் இருக்கும் நாட்கள்.
  • limit_spam_retention_period — நீக்குவதற்கு முன்பு ஒரு செய்தி ஸ்பேமில் இருக்கும் நாட்கள்.

இவற்றை ஒருமுறை அமைக்கவும், தளம் உங்களுக்காக எந்தவொரு cron job-ம் இல்லாமல் அவற்றைச் செயல்படுத்துகிறது. அந்த workspace-ல் உள்ள ஒவ்வொரு கணக்கும் இந்தக் காலங்களைப் பெறுகின்றன.

Erasure என்பது data-plane செயல்பாடாகும். ஒரு நபருக்கான right-to-erasure கோரிக்கையை நிறைவேற்ற, அனுப்புநரால் வடிகட்டப்பட்ட அவர்களின் செய்திகளை நீங்கள் கண்டறிகிறீர்கள், பின்னர் ஒவ்வொன்றையும் hard-delete செய்கிறீர்கள். சாதாரண delete செய்தியை குப்பைக்கு மட்டுமே மாற்றுகிறது (மீட்கக்கூடியது); ஒரு hard delete உண்மையான erasure ஆகும்.

ஒரு முக்கியமான எச்சரிக்கை: API அஞ்சல் பெட்டியிலிருந்து செய்தியை நீக்க முடியும். நீங்கள் உருவாக்கிய எந்தவொரு derived copy-யும் — உங்கள் தரவுத்தளத்தில் உள்ள வரிசைகள், உங்கள் பயன்பாட்டு பதிவுகளில் உள்ள வரிகள், vector store-ல் உள்ள embeddings — ஆகியவற்றை நீங்கள் தனியாகவே நீக்க வேண்டும். Nylas நீக்கம் உங்கள் Postgres-க்குள் நுழையாது.

ஒரு கொள்கையில் Retention காலங்களை அமைத்தல்

இலவசத் திட்டத்தில், retention இயல்பாக இன்பாக்ஸில் 30 நாட்களுக்கும் ஸ்பேமில் 7 நாட்களுக்கும் அமைக்கப்பட்டுள்ளது, அந்த இயல்புநிலை அமைப்புகளை மாற்ற முடியாது. கட்டணத் திட்டங்கள் உங்கள் சொந்த காலங்களை அமைக்க அனுமதிக்கின்றன. எந்த வகையிலும், ஆவணப்படுத்தப்பட்ட உங்கள் retention அட்டவணையுடன் பொருந்தக்கூடிய காலங்களைத் தேர்ந்தெடுக்கவும் — ஒரு தணிக்கையாளருக்கு நீங்கள் எழுதும் எண்ணாக இருக்க வேண்டுமே தவிர, நீங்கள் யூகித்த எண்ணாக இருக்கக்கூடாது.

படி 1: ஒரு retention கொள்கையை உருவாக்கவும்

curl ஐப் பயன்படுத்தி:

curl --request POST \
  --url "https://api.us.nylas.com/v3/policies" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Support Agent Retention Policy",
    "limits": {
      "limit_inbox_retention_period": 365,
      "limit_spam_retention_period": 30
    }
  }'

அல்லது Nylas CLI ஐப் பயன்படுத்தி:

nylas agent policy create --data '{
  "name": "Support Agent Retention Policy",
  "limits": {
    "limit_inbox_retention_period": 365,
    "limit_spam_retention_period": 30
  }
}'

இரண்டும் ஒன்றை வழங்குகின்றன policy_id. அதைப் பாதுகாப்பாக வைத்திருக்கவும் — ஒரு workspace அதைக் குறிக்கும் வரை ஒரு கொள்கை தானாகவே எதையும் செய்யாது.

படி 2: உங்கள் workspace-ல் கொள்கையை இணைக்கவும்

உங்கள் முகவர் கணக்கு வழங்கப்படும்போது அது தானாகவே ஒரு இயல்புநிலை workspace-ஐ உருவாக்குகிறது. அந்த workspace-ல் கொள்கையை இணைக்கவும், இதன் மூலம் அதிலுள்ள ஒவ்வொரு கணக்கும் retention காலங்களைப் பெறும்.

curl ஐப் பயன்படுத்தி:

curl --request PATCH \
  --url "https://api.us.nylas.com/v3/workspaces/REPLACE_WITH_WORKSPACE_ID" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "policy_id": "REPLACE_WITH_POLICY_ID"
  }'

அல்லது CLI ஐப் பயன்படுத்தி:

nylas workspace update REPLACE_WITH_WORKSPACE_ID --policy-id REPLACE_WITH_POLICY_ID

இது தளத்தின் பக்கத்தில் உள்ள முழுமையான retention கதையாகும். இங்கிருந்து, Nylas தானே காலங்களைச் செயல்படுத்துகிறது — நீங்கள் எழுத, கண்காணிக்க அல்லது சரிசெய்ய எந்தத் திட்டமிடப்பட்ட வேலையும் இல்லை.

Erasure வழியை உருவாக்குதல்

Retention செயலற்ற நிகழ்வைக் கையாளுகிறது: அஞ்சல் ஒரு அட்டவணையில் காலாவதியாகிறது. Erasure செயலில் உள்ள நிகழ்வைக் கையாளுகிறது: யாராவது தங்கள் தரவை நீக்குமாறு உங்களிடம் கேட்டால், நீங்கள் அதை நீக்குகிறீர்கள்.

ஒரு குறிப்பிட்ட நபரின் செய்திகளை நீக்க, அனுப்புநரின் முகவரியின் மூலம் அவர்களின் அஞ்சலைக் கண்டறிந்து, பின்னர் ஒவ்வொன்றையும் hard-delete செய்யவும்:

curl --request DELETE \
  --url "https://api.us.nylas.com/v3/grants/REPLACE_WITH_GRANT_ID/messages/REPLACE_WITH_MESSAGE_ID?hard_delete=true" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY"

முழுமையான அடையாளத்தை அழிக்க — grant-ஐயே நீக்க — இதைப் பயன்படுத்தவும்:

curl --request DELETE \
  --url "https://api.us.nylas.com/v3/grants/REPLACE_WITH_GRANT_ID" \
  --header "Authorization: Bearer REPLACE_WITH_NYLAS_API_KEY"

இந்த hard_delete=true அளவுரு முக்கியமானது. அது இல்லாமல், நீங்கள் செய்தியை குப்பைக்கு மட்டுமே நகர்த்துகிறீர்கள் — அதை உண்மையிலேயே அழிக்கவில்லை.

பிரிப்பு ஏன் முக்கியமானது

retention (control-plane)-ஐ erasure (data-plane)-லிருந்து பிரிப்பது இரண்டு வேறுபட்ட பிரச்சனைகளைப் பற்றி சிந்திக்க உங்களை கட்டாயப்படுத்துகிறது. Retention என்பது நீங்கள் ஒருமுறை அமைத்துவிட்டு மறந்துவிடும் ஒரு பொதுவான நேர வரம்பு. Erasure என்பது தனிப்பட்ட கோரிக்கைகளுக்குப் பதிலளிக்க நீங்கள் உருவாக்கும் workflow ஆகும். இரண்டும் அவசியமானவை. retention காலத்தைக் கொண்டு, erasure வழியைக் கொண்டிராத ஒரு அஞ்சல் பெட்டி, யாராவது கேட்கும்போது அவர்களின் தரவை நீக்க மறுக்கலாம். erasure-ஐக் கொண்டு, retention காலத்தைக் கொண்டிராத ஒரு அஞ்சல் பெட்டி, யாரும் நீக்குமாறு கேட்கவில்லை என்றால் செய்திகளை நிரந்தரமாக வைத்திருக்கலாம்.

முடிவுரை

இணக்கமான முகவர் அஞ்சல் பெட்டியை உருவாக்குவது என்பது தரவுப் பாதுகாப்பை ஒரு பின்னாலோசனையாக இல்லாமல் உள்கட்டமைப்பாகக் கருதுவதாகும். நீங்கள் ஒரு கொள்கையை அமைத்தவுடன் Nylas retention-ஐத் தானாகவே கையாளுகிறது; யாராவது கேட்கும்போது அவர்களின் செய்திகளைக் கண்டறிந்து நீக்குவதற்கான ஆவணப்படுத்தப்பட்ட செயல்முறை உங்களிடம் இருக்க erasure தேவைப்படுகிறது. உங்களிடம் ஒரு நேர வரம்பு மற்றும் நீக்குதல் வழி இரண்டுமே இருப்பதை ஒரு ஒழுங்குமுறை அதிகாரிக்கு — அல்லது ஒரு வழக்கறிஞருக்கு — நிரூபிக்க இந்த இரண்டும் சேர்ந்து உங்களை அனுமதிக்கின்றன. 2026 இல், உண்மையான மின்னஞ்சலைத் தொடும் எந்தவொரு AI முகவருக்கும் இது அவசியமான ஒன்றாகும்.

நன்மைகள்

  • Retention தளத்தால் செயல்படுத்தப்படுகிறது, உங்களின் திட்டமிடப்பட்ட வேலைகளால் அல்ல — cron அமைதியாகத் தோல்வியடையும் அபாயம் இல்லை.
  • இரண்டு தனித்தனி அடுக்குகள் (retention மற்றும் erasure) "பொதுவான நேர வரம்புகளை" "இந்த நபரின் தரவை நீக்கு" என்பதிலிருந்து தெளிவாகப் பிரிக்கின்றன.
  • இந்த API வழக்கமான Nylas ஒருங்கிணைப்புகளைப் போலவே உள்ளது — கற்றுக்கொள்ள புதிய கருத்துகள் எதுவும் இல்லை.
  • இலவசத் திட்டத்தில் 30 நாள் இன்பாக்ஸ் இயல்புநிலை உள்ளமைக்கப்பட்டுள்ளது, எனவே டெமோக்களுக்குக் கூட சில பாதுகாப்புகள் உள்ளன.
  • கட்டணத் திட்டங்கள் முழுமையாக உள்ளமைக்கக்கூடியவை, இது உங்கள் சட்டக் குழுவின் retention அட்டவணையுடன் பொருந்துமாறு செய்ய உங்களை அனுமதிக்கிறது.
  • ஒரு கொள்கையை இணைப்பது ஒரு முறைச் செயலாகும்; retention காலத்தைப் புதுப்பிப்பது workspace-ல் உள்ள அனைத்து கணக்குகளுக்கும் தானாகவே பொருந்தும்.

குறைபாடுகள்

  • API அஞ்சல் பெட்டியில் உள்ள செய்திகளை மட்டுமே நீக்குகிறது, உங்கள் சொந்த தரவுத்தளம், பதிவுகள் அல்லது vector store-களில் உள்ள நகல்களை அல்ல — அவற்றை நீங்கள் தனித்தனியாகக் கண்காணித்து நீக்க வேண்டும்.
  • இலவசத் திட்ட retention இன்பாக்ஸில் 30 நாட்கள் மற்றும் ஸ்பேமில் 7 நாட்கள் என நிர்ணயிக்கப்பட்டுள்ளது, எனவே இது உங்கள் இணக்கத் தேவைகளுக்குப் பொருந்தாமல் போகலாம்.
  • Erasure என்பது ஒரு மேனுவலான data-plane செயல்பாடாகும், தானியங்கி அல்ல — நீக்குதல் கோரிக்கைகளைப் பெற்று நிறைவேற்ற நீங்கள் workflow-ஐ உருவாக்க வேண்டும்.
  • எந்தக் கொள்கையும் இணைக்கப்படாத ஒரு workspace உங்கள் திட்டத்தின் இயல்புநிலை வரம்புகளில் கணக்குகளை இயக்குகிறது, இது ஒரு கட்டணத் திட்டத்தில் எந்தவொரு retention வரம்பும் இல்லை என்பதைக் குறிக்கலாம்.
  • தளம் retention காலங்களைச் செயல்படுத்துகிறது, ஆனால் தணிக்கை செய்யப்பட்டால் இணக்கத்தை நிரூபிக்க நீங்களே பொறுப்பாவீர்கள்.

எச்சரிக்கை

இந்தக் கட்டுரை கல்வி நோக்கங்களுக்கானது மற்றும் ஆவணப்படுத்தப்பட்டுள்ளபடி Nylas API ஐ விளக்குகிறது. இது சட்ட ஆலோசனை அல்ல. தயாரிப்பில் retention மற்றும் erasure-ஐச் செயல்படுத்துவதற்கு முன்பு, நீங்கள் தேர்ந்தெடுக்கும் retention காலங்கள் (உதாரணமாக, 365 நாட்கள்) ஆவணப்படுத்தப்பட்ட உங்களின் இணக்கக் கொள்கை மற்றும் உங்கள் சட்டக் குழுவின் தேவைகளுடன் பொருந்துகிறதா என்பதைச் சரிபார்க்கவும். எந்தவொரு கட்டளைகளையும் இயக்குவதற்கு முன்பு அனைத்து placeholder மதிப்புகளையும் (REPLACE_WITH_NYLAS_API_KEY, REPLACE_WITH_WORKSPACE_ID, REPLACE_WITH_POLICY_ID, REPLACE_WITH_GRANT_ID, REPLACE_WITH_MESSAGE_ID) உங்கள் உண்மையான மதிப்புகளுடன் மாற்றவும். இந்த வழிகாட்டுதலை நம்புவதற்கு முன்பு அதிகாரப்பூர்வ Nylas ஆவணங்கள் மற்றும் உங்கள் நிறுவனத்தின் சட்ட அல்லது இணக்கக் குழுவைக் கலந்தாலோசிக்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

சாதாரண delete மற்றும் hard delete-க்கு இடையே உள்ள வித்தியாசம் என்ன? — சாதாரண delete செய்தியை குப்பைக்கு நகர்த்துகிறது, அங்கிருந்து அதை மீட்க முடியும். ஒரு hard delete (?hard_delete=true) உண்மையான erasure மற்றும் அதை மீட்க முடியாது.

நான் இலவசத் திட்டத்தில் இருந்தாலும் ஒரு retention கொள்கையை அமைக்க வேண்டுமா? — இல்லை, இலவசத் திட்டத்தில் இயல்பாக 30 நாள் இன்பாக்ஸ் retention மற்றும் 7 நாள் ஸ்பேம் retention உள்ளது. அந்த காலங்கள் உங்கள் தேவைகளுக்குப் பொருந்தினால், நீங்கள் ஒரு கொள்கையை அமைக்க வேண்டியதில்லை. கட்டணத் திட்டங்கள் நீங்கள் retention-ஐ வெளிப்படையாக உள்ளமைக்க வேண்டும்.

எனது தரவுத்தளத்தில் நான் ஏற்கனவே நகலெடுத்துள்ள தரவை Nylas நீக்க முடியுமா? — இல்லை. Nylas API அஞ்சல் பெட்டியில் உள்ள செய்திகளை மட்டுமே நீக்குகிறது. ஏதேனும் derived copies — தரவுத்தள வரிசைகள், பதிவுகள் அல்லது embeddings — அவற்றை நீக்குவது உங்கள் பொறுப்பாகும்.

ஸ்பேம் காலத்தை விடக் குறுகிய retention காலத்தைக் கொண்ட கொள்கையை நான் இணைத்தால் என்ன நடக்கும்? — API அதை நிராகரிக்கும். உண்மையான அஞ்சலுக்கு முன்னதாக ஸ்பேம் அழிக்கப்பட வேண்டும் என்பதற்காக, ஸ்பேம் retention காலம் இன்பாக்ஸ் retention காலத்தை விடக் குறைவாக இருக்க வேண்டும்.

ஒரு workspace-ல் உள்ள அனைத்து கணக்குகளும் ஒரே retention கொள்கையைப் பெறுகின்றனவா? — ஆம். ஒரு workspace-ல் உள்ள ஒவ்வொரு முகவர் கணக்கும் அந்த workspace-உடன் இணைக்கப்பட்ட கொள்கையிலிருந்து retention காலங்களைப் பெறுகிறது.

நான் பின்னர் retention காலத்தை மாற்ற வேண்டும் என்றால் என்ன செய்வது? — காலங்களை மாற்ற கொள்கையை PATCH செய்யவும். அந்த workspace-ல் உள்ள அனைத்து கணக்குகளும் உடனடியாக புதிய அட்டவணையைப் பின்பற்றும்.

ஒரு குறிப்பிட்ட செய்தியை hard-delete செய்யாமல் என்னால் நீக்க முடியுமா? — முடியும், ஆனால் சாதாரண delete அதை குப்பைக்கு மட்டுமே நகர்த்துகிறது. அதை உண்மையிலேயே அழிக்க (அதை மீட்க முடியாதபடி செய்ய), இதைப் பயன்படுத்தவும் ?hard_delete=true அளவுரு.

erasure செயல்முறையை தானியக்கமாக்க ஒரு வழி இருக்கிறதா? — API தானியங்கி நீக்கத்தை ஆதரிக்கிறது, ஆனால் தளத்தின்படி, நீக்குதல் கோரிக்கைகளைப் பெற உங்கள் சொந்த workflow-ஐ நீங்கள் உருவாக்குவீர்கள் மற்றும் ஒவ்வொரு செய்திக்கும் hard-delete endpoint-ஐ அழைப்பீர்கள்.

குறிச்சொற்கள்

#gdpr #email #dataprotection #compliance #retention #api #erasure #agentmail

Free field guide

Incident Response: First Hour

A calm, evidence-preserving checklist for establishing control, bounding impact, communicating clearly, and containing an incident safely.