نشر الذكاء الاصطناعي في بيئة مؤهلة لـ HIPAA باستخدام Amazon Quick

تريد منظمات الرعاية الصحية من الذكاء الاصطناعي الشيء ذاته الذي تريده كل الأعمال الأخرى: إجابات أسرع، وعمل يدوي أقل، ورؤى تصل إلى صانعي القرار في الوقت الكافي للتصرف بناءً عليها. ولكن ما يميز قطاع الرعاية الصحية هو أن بياناته فريدة التعقيد، وعميقة السياق، وتخضع لتنظيم صارم. لذا يبدأ هذا المنشور ببعض التعريفات لوضع الأساس لكل ما يليه.

المعلومات الصحية المحمية (PHI) هي أي معلومات تحدد هوية شخص وتتعلق بصحته أو رعايته أو الدفع مقابل الرعاية، مثل مذكرة طبية أو مطالبة أو معرّف عضو. عندما تتعامل البرمجيات مع بيانات PHI، فإنها تقع تحت قانون قابلية نقل التأمين الصحي والمساءلة (HIPAA)، وهو القانون الفيدرالي الذي ينظم كيفية الوصول إلى بيانات PHI وتأمينها وتدقيقها.

يغيّر الذكاء الاصطناعي الوكيل (Agentic AI) معنى أن تتطرق البرمجيات إلى بيانات PHI. فأداة التحليلات التقليدية تقرأ البيانات وتعيد استجابة. أما مساحة العمل الوكيلة مثل Amazon Quick فقد تذهب أبعد من ذلك. على سبيل المثال، يعمل وكلاء الدردشة لديها عبر المحتوى غير المنظم، مثل الملاحظات الإكلينيكية ورسائل التظلم، والبيانات المنظمة، مثل المطالبات وسجلات الأعضاء. قد يسترجع الوكلاء البيانات من مصادر منظمة وغير منظمة على حد سواء، ويستدعون أنظمة أخرى عبر الموصلات، ويكملون مهام متعددة الخطوات نيابة عن المستخدم. الموصلات (Connectors) هي تكاملات مبنية مسبقًا تتيح لـ Amazon Quick القراءة بأمان من أنظمتك الخارجية واتخاذ إجراءات فيها، مثل Slack، وMicrosoft Outlook, ، وSalesforce, ، وAtlassian Jira، و Microsoft SharePoint. كما يمكنك إضافة أدواتك المخصصة عبر Model Context Protocol (MCP). الموصلات المرئية هي فقط تلك المصرّح بها داخل مؤسستك. عندما يستطيع وكيل الدردشة قراءة بيانات PHI والتصرف بناءً عليها معًا، تحتاج إلى حوكمة كافية: ضمانات حتمية، وسجل تدقيق سلوكي لما قام به الوكيل، ومساءلة واضحة عن الإجراءات المتخذة دون وجود شخص في الحلقة. لدعم تلك الحوكمة، توفر Amazon Quick استرجاعًا واعيًا بقوائم ACL، وتسجيلًا للدردشة والتعليقات، وضوابط على ما يُسمح لكل وكيل دردشة بفعله.

Amazon Quick هي خدمة مؤهلة لـ HIPAAوهذه الأهلية تنطبق على عملاء Amazon Quick للويب وسطح المكتب والجوال، شاملةً الأهلية عبر عملاء الويب وسطح المكتب والجوال، وذلك وفقًا لنموذج المسؤولية المشتركة وإعداداتك. ومع ذلك، يركز هذا المنشور على إمكانات نسخة الويب من Amazon Quick، التي تصل إليها عبر متصفحك.

في هذا المنشور، نبدأ بالأسس: مَن تنطبق عليه HIPAA والفرق بين الأهلية لـ HIPAA والامتثال لـ HIPAA. ثم نقدم Amazon Quick كمنصة وتدفقَي البيانات لـ PHI (غير المنظم والمنظم). من هناك، نغطي ما توفره Amazon Quick للبيئات الخاضعة للتنظيم وما لا توفره، ونتناول نشر خطة صحية خيالية (AnyCompany)، ونستخلص أفضل الممارسات والقرارات غير القابلة للتراجع التي يجب اتخاذها مسبقًا. ونختم بدليل تنفيذ خطوة بخطوة، وخاتمة، وموارد لقراءة أعمق.

على مَن تنطبق HIPAA؟

تمتد HIPAA إلى أبعد من المستشفيات والعيادات. فبموجب القانون، تحمل فئتان من المنظمات التزامات، ومعظم مشاريع الذكاء الاصطناعي تمس كليهما.

الكيانات المشمولة (CEs)

• خطط الرعاية الصحية – شركات التأمين الصحي، ومنظمات الصيانة الصحية (HMOs)، والخطط التي يرعاها أصحاب العمل، وMedicare، وMedicaid.
• غرف مقاصة الرعاية الصحية – المنظمات التي تعالج المعلومات الصحية غير القياسية إلى صيغ إلكترونية قياسية.
• مقدمو الرعاية الصحية – الأطباء والعيادات والمستشفيات والصيدليات ودور التمريض وأي مقدم ينقل المعلومات الصحية إلكترونيًا.

الشركاء التجاريون (BAs)

• «الشريك التجاري» هو أي شخص أو كيان، من خارج القوى العاملة للكيان المشمول، ينشئ أو يستلم أو يحتفظ أو ينقل المعلومات الصحية المحمية (PHI) بالنيابة عن الكيان المشمول.
• تشمل الأمثلة الشائعة مزودي الخدمات السحابية، وموردي تقنية المعلومات، وشركات إعداد الفواتير، وشركات تحليل البيانات، ومعالجي المطالبات، ومكاتب المحاماة، وشركات الاستشارات.
• المتعهدون من الباطن الذين يتعاملون مع معلومات الصحة المحمية (PHI) نيابة عن طرف_associate آخر يُعدّون أنفسهم أطرافًا مشاركة.

يجب على كل من الكيانات المشمولة وشركاء الأعمال التوقيع على ملحق شريك الأعمال (BAA) قبل تبادل أي معلومات صحية محمية (PHI). بعد قبولك لاتفاقية AWS BAA عبر AWS Artifact، تعمل AWS كشريك أعمالك بالنسبة لحساب AWS المحدد ذاك، وفقط عندما تستخدم خدمات مؤهلة لمتطلبات HIPAA مثل Amazon Quick لمعالجة PHI داخل الحساب. لا يمتد الملحق إلى حساباتك الأخرى، ولا إلى PHI الموضوعة في خدمات غير مؤهلة لمتطلبات HIPAA، ولا إلى الطريقة التي تهيئ بها الخدمة. وتبقى هذه الأمور مسؤوليتك أنت. راجع دائمًا وأكّد شروط AWS BAA الحالية والتزاماتك مع فرقك القانونية وفرق الامتثال الخاصة بك.

مؤهل لقانون HIPAA لا يعني نفسه متوافق مع قانون HIPAA

بينما أن "HIPAA eligible" تصنيف من AWS، فإن "HIPAA compliant" خاصية تخص بيئتك بأكملها. مصطلح "HIPAA eligible" يعني أن AWS قيّمت الخدمة وتسمح لك باستخدامها لمعالجة وتخزين ونقل المعلومات الصحية المحمية (PHI) بموجب اتفاقية عمل موقعة مع AWS (BAA). خدمة Amazon Quick هي خدمة مؤهلة لـ HIPAA، ويقوم مدققون من أطراف ثالثة بتقييمها ضمن برامج الامتثال الخاصة بـ AWS بما في ذلك HIPAA وFedRAMP وPCI DSS وSOC وISO. لا توجد شهادة رسمية لـ HIPAA لـ AWS كخدمة سحابية، وكذلك AWS نفسها ليست "مؤهلة لـ HIPAA".

أهلية Amazon Quick لا تخدم سوى ككتلة بناء أساسية. هذا وحده لا يجعل تطبيقك وبيئتك متوافقين مع HIPAA. لا يزال يتعين عليك توقيع اتفاقية BAA، وتصنيف بياناتك، وضبط الضوابط بشكل صحيح، وتحمّل الضمانات الإدارية والمادية التي يتطلبها HIPAA، بما في ذلك تدريب القوى العاملة وتحليل المخاطر وإجراءات الاختراق التي لا تنفذها AWS نيابةً عنك. الخدمة المؤهلة مثل Amazon Quick، واتفاقية BAA موقعة، وضبط صحيح، وحوكمة، وضماناتك الخاصة هي ما ينتج نشراً متوافقاً مع HIPAA. كون Amazon Quick مؤهلاً يعني أنه يمكنك بناء سير عمل متوافق عليه. لكنه لا يعني أن تشغيله يجعلك متوافقاً تلقائياً.

ما هو Amazon Quick

غالبًا ما يتم التعرف على Amazon Quick من خلال وكلاء الدردشة الخاصين به، لكن أهلية HIPAA تنطبق على مساحة العمل بأكملها، وليس على ميزة واحدة، لذا فإن النظر على مستوى المنصة مهم للامتثال. جميع القدرات في Amazon Quick مُجمّعة من الوحدات الأساسية التالية:

• دردشة هي الواجهة الأساسية. يمكن للمستخدم طرح سؤال أو تقديم تعليمة بلغة طبيعية، وتقرر Amazon Quick كيفية الاستجابة.
• وكلاء الدردشة معالجة كل طلب. هذا ما تراه في وحدة التحكم، ضمن قائمة Chat agents. يمكن تهيئة كل وكيل دردشة بتعليمات، وتأسيسه على مصادر معرفية، ومنحه أدوات لاتخاذ إجراءات. يأتي Amazon Quick مع وكيل دردشة افتراضي (My Assistant)، ويمكنك إنشاء وكلاء دردشة مخصصين لنطاقات محددة.
• المساحات تنظيم الموارد التي يحتاجها وكيل الدردشة، مثل المستندات ولوحات المعلومات ومجموعات البيانات وقواعد المعرفة وموصلات الإجراءات. يمكن مشاركة المساحة مع فريق.
• عمليات التكامل قم بربط Amazon Quick ببيئتك: قواعد المعرفة للمحتوى غير المهيكل مثل خدمة التخزين البسيط من أمازون (Amazon S3), مايكروسوفت شيربوينت، و أتلاسيان كونفلوينس؛ وصلات البيانات المهيكلة التي تربط Amazon Quick Sight بقواعد البيانات المهيكلة ومستودعات البيانات وبحيرات البيانات لديك؛ وموصلات الإجراءات (المبنية من مواصفات OpenAPI أو خوادم Model Context Protocol)؛ والإضافات (Chrome وSlack وMicrosoft Teams وMicrosoft 365).

  وفوق تلك اللبنات الأساسية توجد الميزات. إن ما يستند إليه هذا العمود مهم للامتثال، لأنه يوضح كتل البناء التي يعتمد عليها كل ميزة، وبالتالي مسارات البيانات التي تستند إليها.

ملاحظة: SPICE هو محرك الاستعلام داخل الذاكرة الخاص بـ Amazon Quick Sight. تستخدم مجموعة بيانات SPICE مفتاح إدارة العميل الافتراضي للحساب عند الإنشاء، وللاستيراد لمجموعة بيانات موجودة على مفتاح افتراضي جديد يجب عليك إجراء تحديث كامل. إذا كانت بياناتك تتضمن معلومات صحية محمية (PHI)، فأدرج SPICE في استراتيجية التشفير لديك (احمِه بمفتاح AWS Key Management Service (KMS) المُدار من العميل إذا كنت تستخدم واحداً) وفي قرارات تقليل البيانات المتعلقة بما تستورده، مثل الاستعلام المباشر أو تحميل نسخة مجهولة الهوية بدلاً من ذلك.

تمتد نفس مؤهلات الأهلية واتفاقية BAA والتشفير وضبط الوصول وموقف التدقيق عبر كل ميزة. لكن كما ذُكر في البداية، تصل معلومات PHI إلى Amazon Quick عبر مسارين، وكل منهما مؤمَّن بشكل مختلف. المسار غير المهيكل يمر عبر قواعد المعرفة، حيث تتحكم قوائم ACL على مستوى المستند في الوثائق وتُقيَّم وقت الاستعلام. أما المسار المهيكل فيمر عبر Amazon Quick Sight الذي يقرأ قواعد البيانات وبحيرات البيانات لديك، حيث يُضبط الوصول إلى الصفوف والأعمدة من خلال الأمان على مستوى الصف والأمان على مستوى العمود. تدفق البيانات هذان يحملان PHI بشكل مختلف، وكما يوضح القسم التالي، تُطبَّق الضوابط بشكل مختلف في كل مسار.

ما يوفره Amazon Quick للبيئات الخاضعة للتنظيم

Amazon Quick مؤهل لمعيار HIPAA، ونوضح فيما يلي ما يعني ذلك عملياً.

البنية التحتية المُدارة

Amazon Quick خدمة مُدارة بالكامل. تشغّل AWS البنية التحتية الأساسية وتتحمل مسؤولية أمان السحابة، ويتم التحقق من ذلك من قبل مدققين خارجيين كما هو موضح في AWS Shared Responsibility Model.

التشفير

يشفّر Amazon Quick البيانات في حالة السكون افتراضياً ويدعم التشفير للبيانات أثناء النقل.

• التشفير في حالة السكون مفعّل افتراضياً باستخدام مفاتيح مملوكة لـ AWS أو مُدارة من AWS. تسجيل مفتاح مُدار من العميل اختياري وليس متطلباً من متطلبات HIPAA. إذا كنت تتطلب تحكماً مباشراً في مفاتيح التشفير، فيمكنك تسجيل مفتاح AWS KMS مُدار من العميل (يتطلب اشتراك Enterprise) لأنواع الموارد المشاركة، بما في ذلك مجموعات بيانات SPICE وبيانات اعتماد مصادر البيانات ورموز OAuth ومخرجات التقارير. وفي الأماكن التي لا ينطبق فيها مفتاح مُدار من العميل، تُشفّر AWS البيانات بمفتاح مملوك لـ AWS أو مُدار من AWS.
• تفصيل واحد يجب ملاحظته: ملاحظات المستخدمين على ردود المحادثة، بما في ذلك التعليقات النصية الحرة الاختيارية، لا تُشفَّر بمفتاحك المُدار من العميل أو بالمفتاح الذي يحمي بيانات Amazon Quick المفهرسة بالذكاء الاصطناعي. يجب التعامل مع ملاحظات المستخدمين كسطح محتمل لمعلومات PHI وحوكمتها وفقاً لذلك.
• بالنسبة للبيانات أثناء النقل، يؤمّن Amazon Quick عمليات النقل المشفرة باستخدام Transport Layer Security (TLS). بالنسبة لبعض اتصالات قواعد البيانات، يمكنك اختيار ما إذا كان النقل مشفراً، لذا يجب عليك تمكين TLS/SSL صراحةً على تلك اتصالات مصادر البيانات بدلاً من افتراض أنه مفعّل دائماً.

بياناتك لا تُدرِّب النماذج

لا يستخدم Amazon Quick بيانات عملائك لتدريب أو تحسين النماذج اللغوية الكبيرة (LLMs) الأساسية.

ضبط الوصول والاتحاد الهوياتي

يدعم Amazon Quick ضبط الوصول القائم على الأدوار (RBAC) وتسجيل الدخول الأحادي (SSO) عبر AWS IAM Identity Center ومزودي هويات Microsoft Active Directory وSAML 2.0. بالنسبة لأحمال ذكاء الأعمال (BI)، يمكنك تعزيز ذلك بالأمان على مستوى الصف والأمان على مستوى العمود وأدوار التنفيذ نيابةً لتحديد الوصول إلى البيانات وقت الاستعلام. بهذه القدرات، يمكنك فرض التعريف الفريد للمستخدم ومبدأ الامتياز الأدنى.

إشارات التدقيق والمراقبة

يُصدر Amazon Quick عدة إشارات مميزة. فهي ليست قابلة للتبادل، والخلط بينها يمثل ثغرة تدقيق شائعة.

• يسجّل AWS CloudTrail عمليات واجهة برمجة التطبيقات المدعومة ومجموعة موثقة من الأحداث غير المتعلقة بواجهة برمجة التطبيقات، مثل مشاهدات لوحات المعلومات وإجراءات إدارة المستخدمين. فهو يلتقط من فعل ماذا ومتى، ولكن ليس نصوص رسائل المحادثة أو محتوى الردود.
• تُسلّم سجلات Amazon CloudWatch السجلات الخاصة بالذكاء الاصطناعي إلى وجهة تتحكم فيها (CloudWatch Logs أو Amazon S3 أو Firehose). هناك خمسة أنواع من السجلات: محادثات الدردشة (CHAT_LOGS)، وملاحظات المستخدمين (FEEDBACK_LOGS)، وساعات الوكلاء والبحث (AGENT_HOURS_LOGS)، واستخدام تخزين الفهرس (INDEX_USAGE_LOGS)، ومزامنة ملفات قاعدة المعرفة (KB_FILE_SYNC_LOGS). هذا هو المكان الذي توجد فيه "ما سأله المستخدم وما أجاب عنه Amazon Quick"، وليس في CloudTrail.
• توفر مقاييس CloudWatch والتنبيهات مراقبة تشغيلية شبه لحظية أيضاً.
• توفر لوحة تحليلات الاستخدام والتبني للمسؤولين. يُرجى ملاحظة أنها قد تكشف نصوص الاستعلامات التفصيلية والسياق الكامل للمحادثات ضمن نطاق مراجعة الملاحظات السلبية، لذا امنح الوصول إلى المسؤولين المصرح لهم فقط.

بما أن سجلات المحادثات والملاحظات قد تحتوي على معلومات صحية خاصة (PHI)، طبّق تقنية إخفاء البيانات في CloudWatch Logs، وتأكد من أن الإشارة المعنية يغطي فعلًا الحدث الذي تنوي تتبعه قبل الاعتماد عليها لأغراض الامتثال.

ترجمة الميزات إلى ضوابط HIPAA

كون Amazon Quick خدمة مؤهلة أمر مفيد لأنه يربط كل ميزة بضمانة محددة من HIPAA، كما هو موضح في الجدول التالي:

ما لا تقدمه Amazon Quick

في حين تقدم Amazon Quick الضوابط السابقة، يتناول هذا القسم ما لا تقدمه Amazon Quick وكيفية سد هذه الفجوة. تحكم Amazon Quick في الوصول والاسترجاع والتفاعل. إنها ليست منصة لهندسة البيانات أو حوكمة بحيرة البيانات. في سياق HIPAA، تقع عدة احتياجات خارج نطاق Amazon Quick وتلبيها خدمات AWS الأخرى المنبعثة منها.

• إزالة التعريف والتحويل. لا تقوم Amazon Quick بإزالة تعريف PHI أو إعادة تشكيل بيانات المصدر. عندما تتطلب حالة الاستخدام الخاصة بك مجموعة بيانات محدودة أو مستخرجًا خاليًا من التعريف، جهّزه قبل أن يصل إلى Amazon Quick باستخدام خدمات AWS المناسبة، على سبيل المثال باستخدام AWS Glue DataBrew، وهي إمكانية من AWS Glue، لإعداد البيانات وحجبها بصريًا، أو AWS Glue لمسارات الاستخراج والتحويل والتحميل (ETL).
• حوكمة بحيرة البيانات وأذونات الجداول الدقيقة. بالنسبة للبيانات المهيكلة التي تستعلم عنها Amazon Quick Sight عبر بحيرة بيانات، فإن الحوكمة على مستوى الأعمدة والصفوف للبحيرة نفسها هي دور AWS Lake Formation، وليس Amazon Quick. تفرض Amazon Quick Sight أمانها الخاص على مستوى الصفوف والأعمدة في طبقة التحليلات، لكن المنح الموثوقة على مستوى البحيرة توجد في Lake Formation وAWS Glue Data Catalog.
• الضمانات الإدارية والمادية. يبقى تدريب القوى العاملة وتحليل المخاطر وإجراءات الاختراق مسؤوليتك بغض النظر عن الأدوات المستخدمة.

من الممارسات الجيدة العامة تحديد المسؤوليات والسماح للخدمات المنبعثة بتحديد البيانات الموجودة ومن يمكنه الاستعلام عنها من المصدر. ودع Amazon Quick تقرر من يمكنه طرح الأسئلة عليها وما يجوز للوكيل فعله بالبيانات.

AnyCompany Health Plan: حالة استخدام نموذجية

توضح AnyCompany Health Plan، وهي خطة صحية افتراضية، حالة استخدام ونمطًا. AnyCompany Health Plan هي كيان مشمول يريد أمرين: السماح لفريق إدارة الرعاية لديه بطرح أسئلة على وثائق السياسات واستئنافات الأعضاء بلغة طبيعية، ومنح قادة العمليات لوحات معلومات ذاتية الخدمة فوق بيانات المطالبات. كلاهما يتضمن PHI، لذا تحتاج AnyCompany إلى التأكد من أن الحل متوافق مع HIPAA. تتضمن بيئة AnyCompany مسارين للبيانات، وكل منهما مُعمَّق ومحكوم بحلول متميزة قبل أن تتمكن Amazon Quick من الوصول إلى البيانات.

المسار غير المهيكل (وثائق السياسات والسجلات الطبية)

→ حاوية Amazon S3 (مصدر قاعدة معرفية مدرك لقوائم ACL)

→ قاعدة معرفة Amazon Quick Knowledge Base (قوائم ACL على مستوى المستندات، مع الفشل الآمن fail-closed عند وقت الاستعلام)

المسار المهيكل (المطالبات)

توجد جميع بيانات المطالبات حالياً في بحيرة بيانات (Amazon S3).

→ Glue ETL (تهيئة) → Glue DataBrew (إزالة التمييز)

→ Lake Formation (منح على مستوى الصفوف والأعمدة و AWS Glue Data Catalog)

→ مجموعة بيانات Amazon Quick Sight (Amazon Athena) (أمن على مستوى الصفوف والأعمدة، ودور تنفيذ run-as)

يتقارب مسارا البيانات السابقان للبيانات المهيكلة وغير المهيكلة في وكيل محادثة Amazon Quick مع تسجيل دخول موحد فيدرالي SSO، ومساحة بأقل الامتيازات، وضوابط حماية، وسجلات موزعة عبر CloudWatch.

إليك كيف ينفذ مسؤول AnyCompany الحل:

1. وقّع اتفاقية BAA ووفّر الخدمة عبر AWS Management Console. يقبل المسؤول اتفاقية AWS BAA في AWS Artifact مقابل حساب AWS، ثم يوفّر Amazon Quick من AWS Management Console مع IAM Identity Center. تسجّل AnyCompany معرّف الاتفاقية والطابع الزمني والحساب في سجل الامتثال الخاص بها. فقط نسخة الويب من Amazon Quick، الموفّرة عبر AWS Management Console، يمكن إدخالها تحت اتفاقية BAA موقّعة من خلال AWS Artifact، وهو مكوّن ضروري للعملاء الذين يبنون سير عمل متوافقاً مع HIPAA يمس بيانات PHI، وذلك مرهون بالتهيئة الصحيحة ومسؤوليات الامتثال الخاصة بالعميل.
2. اضبط الضوابط غير القابلة للتراجع في اليوم صفر. لأن سياسة أمن AnyCompany تتطلب التحكم بمفاتيح التشفير الخاصة بها، يختار المسؤول تسجيل مفتاح يديره العميل (customer managed key) كافتراضي للحساب قبل إنشاء أي بيانات Amazon Quick AI. يُضبط مفتاح البيانات مرة واحدة ولا يمكن تغييره لاحقاً. (التشفير الافتراضي المُدار من AWS مؤهل أيضاً بموجب HIPAA، واستخدام المفاتيح التي يديرها العميل ليس شرطاً مسبقاً لتأهيل الخدمة بموجب HIPAA.) يحسم المسؤول أيضاً نموذج الهوية على IAM Identity Center بحيث ينطبق اكتشاف المستخدمين غير النشطين. مفتاح بيانات Amazon Quick هو يُضبط مرة واحدة عند أول إنشاء للبيانات ولا يمكن تغييره أبداً. إذا حُذف المفتاح، فالاسترداد الوحيد هو إلغاء الاشتراك وإعادة الاشتراك، وهو ما يزيل جميع بيانات Amazon Quick نهائياً.
3. جهّز المسار المنظَّم خارج Amazon Quick. قبل أن يلمس Amazon Quick Sight المطالبات، تستخدم فرق بيانات AnyCompany خدمة AWS Glue لبناء جداول المطالبات المنسّقة، وGlue DataBrew لإنتاج مستخرَج مجهّل الهوية للوحات معلومات العمليات. تمنح AWS Lake Formation صلاحيات على مستوى الصفوف والأعمدة لتلك الجداول من خلال AWS Glue Data Catalog. ونتيجة لذلك، لا يرى Amazon Quick أبداً أي بيانات PHI خام لا يحتاجها.
4. أنشئ قاعدة معرفية تدعم قوائم التحكم بالوصول (ACL) للمستندات. يربط المسؤول حاوية S3 الخاصة بالسياسات والاستئنافات كقاعدة معرفية مع تفعيل قوائم ACL على مستوى المستند عند الإنشاء. ولأن قوائم ACL لا يمكن تفعيلها لاحقاً، يجب تهيئة ذلك عند إنشاء حاوية S3. يقيّم Amazon Quick هوية كل مستخدم عند وقت الاستعلام ولا يُرجع أي مستندات عندما يعجز عن تأكيد حق الوصول.
5. ابنِ مساحة مخصصة ووكيلاً محادثة مخصصاً. تنشئ AnyCompany مساحة PHI بعضوية مقيّدة، منفصلة عن مساحات الإنتاجية العامة. يقتصر وكيل المحادثة لإدارة الرعاية على قاعدة المعرفة المدعومة بقوائم ACL فقط، مع تعطيل البحث المفتوح في الويب وتهيئة دروع الحماية (guardrails). وتُنفَّذ موصّلات للقراءة فقط لكل ما يتاخم بيانات PHI.
6. اربط لوحات المعلومات بأمن على مستوى الاستعلام. تقرأ لوحات معلومات العمليات مجموعة بيانات Amazon Quick Sight المجهّلة الهوية عبر Athena، مع أمن Amazon Quick Sight على مستوى الصفوف والأعمدة ودور تشغيل-بصفتي (run-as) يُضاف فوق منح Lake Formation.
7. شغّل إشارات التدقيق قبل ضم المستخدمين. ينشئ المسؤول مسار CloudTrail ويهيّئ تسليم سجلات CloudWatch المُدارة (CHAT_LOGS وFEEDBACK_LOGS وKB_FILE_SYNC_LOGS وغيرها) إلى وجهة محفوظة ومُقنَّعة. تُعامل الملاحظات (Feedback) كسطح لبيانات PHI.
8. تحقّق، ثم توسّع من غير PHI إلى PHI. تبدأ AnyCompany بسير عمل غير تابع لـ PHI، مثل أسئلة وأجوبة السياسات والبحث في المستندات، لتأكيد الحوكمة، وتختبر بطلبات مواجهة للتحقق من سلوك الإغلاق الآمن لقوائم ACL، ويراجع السجلات للتأكد من التقاط الأحداث، وفقط حينها توسّع فريق إدارة الرعاية إلى عمل متاخم لبيانات PHI.

   يفرض Amazon Quick الهوية والاسترجاع ودروع الحماية ومسار التدقيق. لكن إخفاء الهوية وعمليات ETL ومنح مستوى البحيرة تحدث في المنبع في Glue وGlue DataBrew وLake Formation. هذا التقسيم هو النمط الموصى به، وهو الجواب العملي على تعزيز Amazon Quick في بيئة موزّعة.

كيف تجعلها متوافقة: أفضل الممارسات

الأهلية تمنحك منصة قادرة على معالجة بيانات PHI. لكن عليك أن تهيّئها بحيث تفعل ذلك فعلاً.

يساعدك هذا القسم على فهم قرارات المسؤولية المشتركة المعنية. ولأن بعض هذه القرارات غير قابل للتراجع، اتخذها قبل إنشاء الموارد أو ضم المستخدمين.

ابدأ بنموذج الأمن للذكاء الاصطناعي الوكيل

لا ينتظر وكلاء Amazon Quick تعليمات عند كل خطوة. فهم يستدعي الأدوات ويعدّلون البيانات ويتفاعلون مع الأنظمة الخارجية من تلقاء أنفسهم. وهذا يغيّر طريقة تعاملك مع تأمين بيئتك. نشرت AWS أصدرت أربعة مبادئ أمنية للذكاء الاصطناعي الوكيل في أبريل 2026، وتنطبق مباشرةً هنا.

المبدأ 1 — أضف ضمانات الوكيل فوق إطار الأمن الحالي لديك. لا تنشئ وضعاً أمنياً موازياً لـ Amazon Quick. أضف تدابير خاصة بالوكلاء (دروع الحماية، وحجب المواضيع، وحجب بيانات التعريف الشخصية PII) فوق سياسات IAM والشبكة والتشفير التي تفرضها بالفعل.

المبدأ 2 — ثق بالضوابط الحتمية على القائمة على التوجيهات (prompts). يمكن للمدخلات العدائية المصاغة بعناية أن تتجاوز تعليمات التوجيه (prompt). أما سياسات إدارة الهوية والوصول في AWS (IAM)، وقوائم التحكم في الوصول على مستوى المستندات، وحدود الشبكة، وضوابط الحماية التي يضبطها المسؤول، فلا يمكن تجاوزها بالكلام. استخدمها كوسيلة الإنفاذ الأساسية لديك. تعليمات الوكيل هي طبقتك الثانية، وليست طبقتك الوحيدة.

المبدأ 3 — طبّق الدفاع في العمق عبر الإدراك والاستدلال والتنفيذ. اطلب كل قدرة من قدرات الوكيل إلى إحدى الطبقات الثلاث:

• الإدراك: قواعد المعرفة، والملفات المرفوعة، والبحث على الويب، ومدخلات الموصلات، ومخرجات أدوات MCP.
• السبب: سياق معالجة النموذج اللغوي الكبير (LLM)، الذي تتحكم فيه الحواجز الوقائية وضوابط المواضيع.
• الفعل: الموصلات (Connectors)، والتدفقات السريعة (Quick Flows)، والأتمتة السريعة (Quick Automate)، والمهام المجدولة، واستدعاءات أدوات MCP.

طبّق الضوابط في كل طبقة على حدة. لا ينبغي أن تنتشر فجوة في طبقة ما إلى الطبقات الأخرى.

لاحظ أن التزامات HIPAA BAA تمتد إلى الخدمات والحلول الداعمة مثل أدوات MCP.

المبدأ 4 — وسّع الاستقلالية تدريجيًا. ابدأ الوكلاء (agents) في وضع القراءة فقط على بيانات غير تابعة لـ PHI. أضف القدرات واحدًا تلو الآخر. اختبر تسرّب البيانات، ومقاومة حقن الأوامر (prompt-injection)، والالتزام بحدود الأذونات في كل خطوة قبل الانتقال إلى الخطوة التالية.

قرّر قبل النشر

لأن هذه الخيارات الثلاثة دائمة، اتخذ هذه القرارات قبل التنفيذ.

سجّل مفتاح KMS الخاص بك أولًا. إذا كانت مؤسستك تتطلب التحكم في مفاتيح التشفير الخاصة بها، فسجّل مفتاحًا يديره العميل (customer managed key) كافتراضي للحساب قبل إنشاء أي موارد من Amazon Quick AI. يُضبط مفتاح البيانات في المرة الأولى التي تُنشأ فيها بيانات Quick AI في الحساب. بعد ذلك، لا يمكن تغييره. يتطلب دعم المفتاح المُدار من العميل اشتراكًا من فئة Enterprise. لاحظ أن المفتاح المُدار من العميل يعطّل ذاكرة المحادثة. الحسابات التي تمت تهيئتها بمفتاح مُدار من العميل لا تدعم هذه الميزة.

اختر نموذج الهوية الخاص بك بعناية. لديك أربعة خيارات: IAM Identity Center، وActive Directory، والاتحاد عبر IAM، ومستخدمي Quick المحليين. وهي تختلف في سلوك التزويد (provisioning)، وإلغاء التزويد (offboarding)، والحوكمة. فاكتشاف المستخدمين غير النشطين، على سبيل المثال، يعمل فقط مع IAM Identity Center أو Active Directory. تغيير مزوّد الهوية بعد النشر يعني إعادة تزويد أذونات كل مستخدم وعضوياته في المساحات. اختر مرة واحدة.

اجعل قواعد معرفة PHI مدركة لقوائم التحكم بالوصول (ACL-aware) عند الإنشاء. بالنسبة للمصادر المدعومة (Amazon S3، وGoogle Drive، وSharePoint، وConfluence Cloud، وOneDrive)، تقرر عند الإنشاء ما إذا كانت قاعدة المعرفة ستفرض قوائم ACL على مستوى المستند. هذا الإعداد دائم. لا يمكنك تمكين قوائم ACL في قاعدة معرفة أُنشئت بدونها. بالنسبة لأي محتوى قريب من PHI، أنشئه مدركًا لقوائم ACL من البداية.

تحذير: يمكن لخرائط مخزن المستخدمين (user-store mappings) التي تمت تهيئتها بشكل خاطئ أن تكشف المستندات المقيدة للمستخدمين الخاطئين بصمت، دون أخطاء أو تنبيهات. من الضروري التحقق من صحة مطابقة الهوية مع قوائم ACL لديك قبل استيعاب محتوى PHI.

حدود منطقة AWS والشبكة والحساب

خطط لمنطقة النشر (Region) الخاصة بك بناءً على العوامل التالية:

• موقع البيانات: يعالج Amazon Quick البيانات ويخزنها في المنطقة التي توفرها فيها، وتحتاج إلى التأكد من أن تلك المنطقة تلبي متطلبات توطين البيانات في مؤسستك. لاحظ أن Amazon Quick خدمة أحادية المنطقة: فهي تستفيد من مرونة تعدد مناطق التوافر (multi-AZ) داخل منطقة واحدة، لكنه لا ينتقل تلقائيًا بين المناطق. إذا كنت تدعم سير عمل حرجًا للأعمال يتطلب مرونة عبر المناطق، فوفر نشرًا منفصلاً لـ Amazon Quick في منطقة ثانية، مع بياناته الداعمة، على سبيل المثال، تكرار مصادر قواعد المعرفة المستندة إلى S3 عبر المناطق.
• توفر الخدمة. تُطلق الميزات أحيانًا في مناطق مختلفة في أوقات مختلفة. تحقق من أن كل ما يحتاجه وكلاؤك، مثل قواعد المعرفة والموصلات وقدرات Amazon Quick Sight، متاح في المكان الذي تخطط للنشر فيه.
• استراتيجية تعدد الحسابات. ضع Amazon Quick في حساب أحمال عمل مخصص في AWS Organizations. استخدم سياسات التحكم بالخدمة (SCPs) لفرض قيود المنطقة ومنع التوفير العرضي في مناطق خارج النطاق.

بالنسبة لحدود الشبكة: Amazon Quick خدمة مُدارة يُصل إليها عبر HTTPS. لا تنشره في سحابة خاصة افتراضية (VPC). لكن مصادر بياناتك (دلاء S3، وقواعد البيانات، والأنظمة المحلية) قد تكون خلف حدود VPC. استخدم نقاط نهاية VPC وAWS PrivateLink حيثما تتوفر. تأكد من أن ترجمة DNS وقواعد جدار الحماية تسمح لموصلات Amazon Quick بالوصول إلى مصادر بياناتك المصرح بها دون فتح الشبكة أكثر من اللازم.

قلّل مساحة هجوم الوكيل

تصوّر وثائق Amazon Quick نفسها مخاطر الهجمات التضليلية (الخصومية) كمسألة ذات شرطين: توجد المخاطرة عندما يستطيع (1) الوكيل قراءة محتوى من خارج حدود الثقة الخاصة بك، و (2) اتخاذ إجراء ذي عواقب. وقلّص أيًا من الشرطين فتقلّ تعرّضك للخطر.

قيّد ما يمكن للوكلاء قراءته (طبقة الإدراك Perceive). اعرف كل مصدر يغذي سياق الوكيل: قواعد المعرفة، والملفات المرفوعة، والبحث على الويب، ومزودو الأبحاث الخارجيون، واستجابات الموصلات (connectors)، ومخرجات أدوات MCP، وذاكرة المحادثة المحفوظة. بالنسبة لسير عمل PHI:

• احصر الوكلاء في قواعد معرفة موثوقة تدعم قوائم التحكم بالوصول (ACL).
• أوقف ميزة البحث المفتوح على الويب حيث لا تكون هناك حاجة إليها.
• أوقف رفع الملفات إذا لم يتطلب الوكيل ذلك.
• احصر الاحتفاظ بسجل المحادثات في الحد الأدنى المفيد.

قيّد ما يمكن للوكلاء فعله (طبقة التنفيذ Act). أعد جرد كل مسار صادر: الموصلات، وأدوات MCP، واستعلامات الويب، وسير Quick Flows، وسير عمل Quick Automate، وتشغيلات الوكلاء المجدولة. بالنسبة للوكلاء المرتبطين بـ PHI:

• فضّل وصول الموصلات للقراءة فقط.
• كن حذرًا مع سير العمل الآلي والمجدول، لأنها تعمل دون رقابة من أحد.
• احجب إجراءات الكتابة ما لم تكن مبررة صراحة ومعتمدة من فريق الأمان لديك.
• استخدم تحديد نطاق الصلاحيات على مستوى الموصل لتقييد العمليات التي يمكن للوكيل استدعاؤها.

اعرف الهوية التي يعمل بموجبها الإجراء. تُصادَق الإجراءات الفورية بهوية المستخدم المستدعي، ضمن حدود صلاحيات ذلك المستخدم في الموصلات. أما سير العمل الآلي فيعمل دون جلسة تفاعلية. طابق مستوى الاستقلالية مع حساسية الإجراء، ووثّق الوكلاء الذين يعملون في كل نمط هوية.

افرض مبدأ الحد الأدنى من الصلاحيات وفصل البيانات

• افصل قواعد المعرفة والمساحات التي تحتوي على PHI عن تلك المخصصة للإنتاجية العامة. وقيّد العضوية.
• امنح المساحات (spaces) والوكلاء صلاحيات الوصول على أساس الحاجة إلى المعرفة فقط. راجع كلاً من أذونات المشاركة (من يمكنه استخدام قاعدة معرفة) وقوائم التحكم في الوصول (ACLs) للمستندات المصدرية (أي المستندات المفهرسة يستطيع المستخدم المصرّح له استرجاعها فعلياً).
• دورة التحديث الافتراضية لقاعدة المعرفة هي 24 ساعة. قصّرها عندما تتطلب متطلبات تغيير الوصول لديك انتشاراً أسرع. حدّث قوائم ACL قبل إعادة تعيين عناوين البريد الإلكتروني أو إعادة تدويرها.
• يجب ألا يشارك وكيل PHI مساحةً مع أدوات إنتاجية للأغراض العامة. هذا يعني أنك بحاجة إلى عزل حالات الاستخدام على مستوى المساحة.
• راجع أذونات الموصلات (connectors) بانتظام. بدّل بيانات الاعتماد المخزنة في AWS Secrets Manager وفق جدول زمني يطابق سياسة إدارة بيانات الاعتماد لديك.

طبّق مبدأ تقليل البيانات

توصي AWS بعدم إدخال بيانات سرية في أسماء الموارد أو الوسوم (tags)، لتجنب ذكرها عرضاً في سجلات الفوترة أو التشخيص.

• فضّل البيانات المجهّلة الهوية أينما سمحت حالة الاستخدام بذلك.
• عند استيعاب بيانات منظمة من قواعد بيانات أو واجهات برمجة التطبيقات، رشّح الأعمدة والصفوف عند المصدر قبل الفهرسة.
• كوّن ضوابط حماية للوكيل (guardrails) لتحجب البيانات الشخصية المميزة (PII) في الردود، بإخفاء أرقام الضمان الاجتماعي (SSNs) وأرقام السجلات الطبية (MRNs) وتواريخ الميلاد، باستخدام فلاتر كشف PII المدمجة.

كوّن سجلات التدقيق والاحتفاظ بالبيانات

يوفر Amazon Quick عدة إشارات تدقيق متميزة. ولا يتدفق أي منها افتراضياً، وقد تحتاج إلى تفعيلها.

إليك كيفية إعدادها:

1. أنشئ مسار CloudTrail للحسابات والمناطق المشمولة في النطاق.
2. قم بتكوين تسليم سجلات CloudWatch المُدار (CHAT_LOGS، FEEDBACK_LOGS، KB_FILE_SYNC_LOGS) بعد فترة قصيرة من تشغيل ميزات الذكاء الاصطناعي في Amazon Quick.
3. طبّق إخفاء البيانات الحساسة في سجلات CloudWatch Logs على سجلات المحادثات حتى لا تُخزَّن بيانات PHI بنص صريح.
4. حدد فترة احتفاظ لا تقل عن ست سنوات. فكّر في استخدام S3 Object Lock لأرشيف السجلات.
5. أضف تنبيهات CloudWatch للأنشطة الشاذة.
6. فعّل AWS Security Hub لإجراء فحوصات الامتثال المستمرة.
7. وجّه التنبيهات الحرجة إلى منصة إدارة معلومات وأحداث الأمان (SIEM) أو منصة الاستجابة للحوادث لديك.

تحقّق من الصحة قبل التوسع

قبل توسيع النطاق، تحقق مما يلي:

• تم توثيق قبول BAA في سجل الامتثال لديك.
• تم توثيق تصنيف البيانات: أي قواعد المعرفة والمساحات تحتوي على بيانات PHI، وأي وكلاء يمكنهم الوصول إليها.
• تم اختبار الاستعلامات العدائية وسيناريوهات حقن الأوامر التوجيهية.
• يتم التقاط السجلات والإخفاء يعمل بشكل صحيح.
• اكتمل تمرين محاكاة اختراق على الطاولة.
• حصلت على موافقة قسم أمن المعلومات (InfoSec).

القيود المعروفة

إليك بعض القيود المعروفة في Amazon Quick.

• لا يوجد BAA على مسار Free أو Plus. يجب استخدام المسار الموفَّر عبر AWS Management Console للحصول على تغطية BAA.
• لا توجد نسخ متماثل بين المناطق. التعافي من الكوارث (DR) مقيد بمنطقة واحدة.
• آليات الحماية احتمالية، لا حتمية. إنها تقلل المخاطر لكنها لا تلغيها. عززها بعناصر التحكم على مستوى البنية التحتية الموصوفة سابقًا.
• الموصلات الخارجية توسّع التزاماتك بموجب BAA. عندما يرسل موصل بيانات إلى نظام خارجي، تتبع مسؤولية الامتثال البيانات.
• قد تحتوي ذاكرة المحادثة على بيانات PHI منعكسة. اضبط سياسات الاحتفاظ وطبّق الإخفاء.

دليل التنفيذ

أظهر مثال AnyCompany Health Plan كيفية طرح Amazon Quick. يحوّل هذا القسم ذلك النمط إلى خطة مشروع خطوة بخطوة يمكنك تسليمها لفريق المنصات لديك.

الخطوة 1: تنفيذ BAA (اليوم 1)

• سجّل الدخول بصلاحيات AWS Artifact واقبل BAA.
• سجّل معرّف الاتفاقية والطابع الزمني وـ principal ARN ومعرّف الحساب.
• أبلغ فريقك القانوني وفريق الامتثال.

الخطوة 2: ضع ضوابط أساسية غير قابلة للتراجع (الأيام 1–2)

• سجّل مفتاحًا يُدار من العميل كمفتاح افتراضي للحساب.
• تحقق من أن سياسة المفتاح تمنح الأذونات المطلوبة: Encrypt وDecrypt وGenerateDataKey وDescribeKey.
• قم بتكوين نموذج الهوية الخاص بك (يُوصى باستخدام IAM Identity Center).
• تأكد من أن الحساب موجود في وحدة تنظيمية مخصصة لأحمال العمل (OU) مع سياقات SCP مقيّدة للمنطقة.

الخطوة 3: إنشاء قواعد معرفة مدركة لقوائم ACL (الأيام 3–7)

• صنّف مصادر بياناتك: PHI، والقريبة من PHI، وغير PHI.
• أنشئ قواعد معرفة مع تشغيل خاصية الوعي بقوائم ACL لمصادر PHI والمصادر القريبة من PHI.
• اربط مخزن الهوية بأذونات المصدر وتحقق من صحتها باستخدام عدة مستخدمين اختباريين.
• تحقق من أن سجلات المزامنة تؤكد نجاح الاستيعاب. حافظ على فصل قواعد معرفة PHI عن المحتوى العام.

الخطوة 4: إنشاء المساحات (الأيام 5–8)

• افصل المساحات القريبة من PHI عن مساحات الإنتاجية العامة.
• أرفق قواعد المعرفة ولوحات المعلومات وموصلات الإجراءات. قيّد العضوية.
• تأكد من حجب المستخدمين غير المصرّح لهم.

الخطوة 5: إنشاء وكلاء مخصصين مع ضمانات (الأيام 7–12)

• حدّد غرض كل وكيل بشكل ضيق. أرفق مصادر المعرفة التي يحتاجها فقط.
• كوّن تنقيح بيانات PII والموضوعات المحجوبة وفلاتر المحتوى وضوابط التأسيس.
• اختبر باستعلامات عادية واستعلامات حدودية وطلبات عدائية.
• وثّق النتائج وخطوات المعالجة.

الخطوة 6: تكوين موصلات الإجراءات (الأيام 10–14)

• ابدأ بوضع القراءة فقط للبيانات القريبة من PHI. حدّد نطاق كل موصل لموارد محددة.
• خزّن بيانات الاعتماد في AWS Secrets Manager مع تشغيل التدوير.
• وثّق المبررات لأي وصول كتابي. احصل على موافقة فريق الأمان قبل تشغيله.
• اختبر حدود النطاق للتأكد من أن الموصلات لا يمكنها الوصول إلى موارد خارج نطاقها المقصود.

الخطوة 7: تكوين التدقيق والاحتفاظ والمراقبة (الأيام 12–16)

• فعّل سجلات CloudTrail وسجلات CloudWatch الموردة.
• طبّق إخفاء حماية البيانات. اضبط مدة الاحتفاظ على ست سنوات على الأقل. فعّل S3 Object Lock.
• كوّن التنبيهات، وفعّل Security Hub، وادمج مع نظام SIEM الخاص بك.

الخطوة 8: التحقق مع InfoSec (الأيام 14–21)

• جمّع حزمة الأدلة: تأكيد BAA، وتكوين KMS، وإعداد الهوية، وتصنيف البيانات، ونتائج الاختبارات، وعينات السجلات.
• نفّذ تمرينًا نظريًا لمحاكاة اختراق.
• اعرض على فريق InfoSec الخاص بك. عالج النتائج. احصل على الموافقة النهائية.

مرحلة التوسع (الأسابيع 4–8)

ابدأ بسير العمل غير المتعلقة بـ PHI: الأسئلة والأجوبة حول السياسات، والبحث في المستندات، والتحضير للاجتماعات، وأتمتة سير العمل. تمكّن هذه الفئات فريقك من بناء الثقة بالمنصة قبل دخول PHI إلى الصورة.

ثم توسّع إلى سير العمل القريبة من PHI: المساعدة في التوثيق الإكلينيكي، ومعالجة المطالبات، والتفويض المسبق، والأسئلة والأجوبة التنظيمية، وصياغة التواصل مع المرضى مع وجود مراجعة بشرية في العملية.

راقب عن كثب: راجع سجلات الدردشة أسبوعياً، وتتبع معدلات تفعيل الضوابط الوقائية، وراقب أنماط الوصول لمدة 30 يوماً بعد إطلاق كل سير عمل جديد.

الخلاصة

يمنح Amazon Quick المؤسسات الصحية الخاضعة للتنظيم، وشركاء الأعمال الذين يخدمونهم، مساحة عمل ذكاء اصطناعي مُدارة ومؤهلة لمعايير HIPAA عبر كامل نطاق قدراتها: الذكاء الاصطناعي الوكيل، واسترجاع المعرفة، وذكاء الأعمال، والأتمتة، والبحث.

يتبع الطريق إلى نشر متوافق مع المعايير تسلسلاً واضحاً:

1. افهم الفرق بين الأهلية والامتثال، وتحمل مسؤوليتك في نموذج المسؤولية المشتركة.
2. نفّذ اتفاقية BAA على حساب مُوفَّر من خلال AWS Management Console.
3. اضبط الضوابط غير القابلة للتراجع أولاً: مفاتيح KMS، ونموذج الهوية، وقواعد المعرفة المدركة لقوائم ACL.
4. قلّص أسطح القراءة والإجراءات الخاصة بالوكيل إلى الحد الأدنى، وطبّق مبدأ الامتيازات الأدنى، وأخفِ بيانات PHI في السجلات.
5. تحقق بمشاركة فريق أمن المعلومات لديك، ثم توسّع من سير عمل غير مرتبط ببيانات PHI إلى سير عمل مجاور لها.

تتغير توقعات الامتثال بسرعة تطور التقنية. نشرت AWS مبادئها الأربعة الأمنية للذكاء الاصطناعي الوكيل في أبريل 2026 وعدسة Well-Architected Agentic AI Lens في يونيو 2026. المؤسسات التي تبني اليوم على ضوابط حتمية على مستوى البنية التحتية من المرجح أن تكون في موقع جيد مع اقتراب التوقعات التنظيمية من ما يستطيع الذكاء الاصطناعي الوكيل تحقيقه.

الخطوات التالية

إذا كنت تقيّم Amazon Quick: اطلب إحاطة تركز على الامتثال من فريق حساب AWS لديك. اسأل عن نطاق اتفاقية BAA، والمسؤولية المشتركة في الذكاء الاصطناعي الوكيل، وأحدث الخدمات المضافة المؤهلة لمعايير HIPAA.

إذا كنت جاهزاً للنشر: استخدم دليل التنفيذ كخطة مشروعك. القرارات غير القابلة للتراجع في الخطوة 2 تستحق مراجعة معمارية مخصصة قبل البدء في إنشاء الموارد.

إذا كنت تشغّل Amazon Quick بالفعل: دقّق نشرتك مقابل أفضل الممارسات الواردة في هذه المقالة، وخاصة مبادئ أمن الوكلاء وقائمة القيود المعروفة.

للحصول على إرشادات معمارية، تواصل مع مهندس حلول AWS لديك أو مع فريق AWS للرعاية الصحية وعلوم الحياة.

عن المؤلفين