پاسخ کوتاه این است: بستگی دارد چه اطلاعاتی، به کدام سرویس، با چه تنظیماتی و تحت چه قراردادی ارسال شود. عبارت «API امن است» یا «API ناامن است» به‌تنهایی معنی زیادی ندارد؛ برای ارزیابی واقعی باید چند موضوع را از هم جدا کنیم.

آیا اطلاعات API برای آموزش مدل استفاده می‌شود؟

در مورد OpenAI API، این شرکت اعلام می‌کند داده‌های ورودی و خروجی API به‌صورت پیش‌فرض برای آموزش یا بهبود مدل‌هایش استفاده نمی‌شوند؛ مگر اینکه مشتری به‌صورت صریح Opt-in کند. اما استفاده نشدن برای Training مساوی با ذخیره نشدن نیست.

طبق مستندات فعلی OpenAI، بسیاری از endpointهای API به‌صورت پیش‌فرض می‌توانند Abuse Monitoring Log را تا ۳۰ روز نگهداری کنند و شرایط نگهداری Application State نیز بر اساس endpoint متفاوت است. برخی مشتریان واجد شرایط می‌توانند از Zero Data Retention استفاده کنند. بنابراین باید Training و Retention را دو موضوع جدا بدانیم.

Gemini چطور؟

Google نیز برای Gemini میان سرویس‌های رایگان، Paid Services و سرویس‌های سازمانی تفاوت قائل است. طبق مستندات فعلی Gemini Developer API، در Paid Services محتوای Prompt و Response برای بهبود محصولات Google استفاده نمی‌شود؛ با این حال برخی قابلیت‌ها ممکن است باعث نگهداری اطلاعات شوند.

برای مثال Google اعلام کرده استفاده از Grounding with Google Search می‌تواند Prompt، Context و خروجی تولیدشده را برای ۳۰ روز ذخیره کند. برای نیازهای جدی Zero Data Retention و قراردادهای سازمانی، خود Google استفاده از Vertex AI را مطرح می‌کند.

این نکته مهمی است: نام مدل به‌تنهایی سیاست امنیتی را مشخص نمی‌کند؛ نوع سرویس نیز مهم است.

رمزنگاری کافی است؟

رمزنگاری اطلاعات هنگام انتقال ضروری است، اما امنیت سازمانی فقط TLS نیست. OpenAI برای سرویس‌های Business و API خود رمزنگاری در حالت انتقال و ذخیره را مستند کرده است؛ با این حال هنوز باید موارد دیگری را بررسی کرد:

  • چه کسی داخل سازمان به API Key دسترسی دارد؟
  • Promptها داخل Log نرم‌افزار خودتان ذخیره می‌شوند؟
  • آیا اطلاعات قبل از ارسال Mask می‌شوند؟
  • چه Data Processing Agreementای وجود دارد؟
  • Backupها کجا هستند؟
  • چه سرویس‌های واسطه‌ای در مسیر وجود دارند؟

API واسطه یک ریسک جداگانه است

فرض کنید به‌جای OpenAI مستقیماً از یک Gateway شخص ثالث استفاده می‌کنید. در این حالت اطلاعات ابتدا به Gateway و سپس احتمالاً به Provider اصلی ارسال می‌شوند؛ بنابراین سیاست حریم خصوصی هر دو مجموعه اهمیت دارد. این مسئله دربارهٔ Logging Platformها، Monitoring Toolها و Proxyهای AI نیز صدق می‌کند.

چه اطلاعاتی را بهتر است مستقیم ارسال نکنیم؟

برای داده‌های بسیار حساس بهتر است اصل Data Minimization رعایت شود؛ یعنی اگر مدل فقط به بخشی از یک سند نیاز دارد، کل سند ارسال نشود. اطلاعاتی مانند Password، API Secret، Private Key و Credentialها اصولاً نباید داخل Prompt قرار بگیرند. برای اطلاعات شخصی، مالی، پزشکی، حقوقی یا اسناد محرمانه نیز الزامات قانونی و قراردادی سازمان باید جداگانه بررسی شود.

معماری Hybrid

یک راه‌حل رایج این است که اطلاعات اصلی داخل زیرساخت شرکت باقی بماند، RAG به‌صورت داخلی اجرا شود و فقط بخش‌هایی که برای پاسخ لازم هستند به مدل ابری ارسال شوند. حتی قبل از ارسال می‌توان اطلاعات حساس مانند نام، ایمیل، شمارهٔ تماس یا شناسهٔ مشتری را Mask کرد و در سطح بالاتر مدل را نیز Self-Hosted کرد. تفاوت این معماری‌ها در Cloud AI یا Self-Hosted یا Hybrid بررسی شده است.

نتیجه

استفاده از API یک Provider معتبر لزوماً به معنی عمومی شدن یا آموزش مدل با اطلاعات سازمان نیست؛ اما این هم درست نیست که تصور کنیم «چون API است، هیچ داده‌ای ذخیره نمی‌شود». قبل از استفادهٔ سازمانی باید حداقل Training Policy، Retention Policy، Endpoint مورد استفاده، قابلیت‌های جانبی، محل پردازش داده و قرارداد سرویس بررسی شود.

و مهم‌تر از همه: این سیاست‌ها ممکن است تغییر کنند، بنابراین برای پروژه‌های حساس باید همیشه مستندات رسمی همان زمان بررسی شوند.