الالتزامات الأمنية التي تنطبق عليك بالفعل كمطوّر مستقل

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

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

بموجب GDPR، يُعدّ المستقل الذي يعالج بيانات العملاء "معالِجاً" — وله التزامات مباشرة

إذا سلّمك عميل في الاتحاد الأوروبي (أو عميل يقع مستخدموه في الاتحاد الأوروبي) بيانات شخصية — قاعدة بيانات مستخدمين لترحيلها، أو نظام إنتاج لتصحيح أخطائه، أو تصديراً لتحليله — فأنت تعمل في الغالب الأعم بصفة معالِج بيانات (data processor) بموجب GDPR، وفي بعض المهام (عندما تقرر أنت ما الذي يُجمع ولماذا) بصفة متحكّم (controller). لا تشترط أي من الصفتين وجود شركة. فتعريفات GDPR في المادة 4 تنطبق على "شخص طبيعي أو اعتباري" — والشخص الذي يملك حاسوباً محمولاً يستوفي هذا الشرط.

وتترتّب على هذه الصفة التزامات مباشرة وشخصية:

• المادة 28 تشترط أن تُنظَّم معالجتك لبيانات العميل بموجب عقد — واتفاقية معالجة البيانات التي يواصل عملاؤك من المؤسسات الكبرى إرسالها إليك ليست عرضاً بيروقراطياً؛ إنها متطلب قانوني على كليكما، وتُلزمك بالتزامات أمنية محددة.
• المادة 32 تشترط أن تنفّذ "تدابير تقنية وتنظيمية مناسبة" لتأمين البيانات الشخصية التي تعالجها — بما يتناسب مع المخاطر، وهذا يشمل التحكم في من وما الذي يمكنه الوصول إليها.
• المادة 33 تشترط على المعالِج إخطار المتحكّم "دون تأخير لا مبرر له" فور علمه بحدوث خرق للبيانات الشخصية — وهذا يفترض أنك في موقع يمكّنك من العلم بحدوث مثل هذا الخرق.
• المادة 82 تمنح أصحاب البيانات الحق في التعويض من المعالِجين عن الأضرار الناجمة عن معالجة تنتهك اللائحة، وتدعم المادة 83 هذا الإطار بأكمله بغرامات إدارية قد تصل، في أشد الانتهاكات جسامة، إلى عشرين مليون يورو أو أربعة بالمئة من إجمالي حجم الأعمال العالمي السنوي، أيهما أعلى.

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

قانون الذكاء الاصطناعي الأوروبي يضيف التزامات على مستخدمي أنظمة الذكاء الاصطناعي

إذا أصبح عملك مع العملاء يشمل الآن دمج الذكاء الاصطناعي في المنتجات — مساعد داخل تطبيق أحد العملاء، أو وكيل ذكاء اصطناعي يؤتمت مهمة عمل، أو نموذج يتخذ قرارات تؤثر على الأشخاص — فإن قانون الذكاء الاصطناعي الأوروبي (EU AI Act) يخصّك. فالقانون لا ينظّم فقط الشركات التي تدرّب النماذج؛ بل يفرض التزامات على المستخدِمين (deployers) — أي الجهات التي تستخدم أنظمة الذكاء الاصطناعي تحت سلطتها الخاصة في سياق مهني.

تحدد المادة 26 التزامات المستخدِمين بالنسبة لأنظمة الذكاء الاصطناعي عالية المخاطر، بما في ذلك استخدام الأنظمة وفقاً لتعليماتها، وضمان رقابة بشرية مناسبة، ومراقبة تشغيلها. وتشترط المادة 4 على مقدّمي الأنظمة والمستخدِمين على حد سواء ضمان مستوى كافٍ من المعرفة بالذكاء الاصطناعي لدى الأشخاص الذين يشغّلون هذه الأنظمة نيابة عنهم. وتدعم المادة 99 هذا الإطار بغرامات إدارية عند عدم الامتثال. وتتوقف الالتزامات المطبَّقة على مهمة معينة على ما يفعله النظام وفئة المخاطر التي يندرج تحتها — لكن عبارة "أنا فقط دمجته، لم أبنِه" هي بالضبط الدور الذي كُتبت من أجله فئة المستخدِم.

هناك مفارقة عملية نراها باستمرار في حوكمة وكلاء الذكاء الاصطناعي: المطوّرون المستقلون هم الأكثر تبنياً لوكلاء البرمجة بالذكاء الاصطناعي وروبوتات الأتمتة — والأقل احتمالاً لامتلاك جرد بما يمكن لهذه الوكلاء الوصول إليه. فإذا كان بإمكان وكيل ذكاء اصطناعي أن يدفع (push) إلى كل مستودع تملكه، فهذه حقيقة عن وضعك الأمني سواء سألت عنها جهة رقابية يوماً أم لا.

عملاؤك من المؤسسات الكبرى منظَّمون بالفعل — والتزاماتهم تنسحب عليك

حتى لو لم تلمس بيانات شخصية أوروبية أبداً ولم تنشر نظام ذكاء اصطناعي قط، هناك مصدر ثالث لالتزامات أمنية ينطبق على شبه كل مستقل يعمل مع شركات من أي حجم: العقود. فعملاؤك من المؤسسات الكبرى يعملون بموجب تقارير SOC 2، وشهادات ISO 27001، ومتطلبات المادة 28 من GDPR الخاصة بالمعالِجين، وبرامج إدارة موردين يتحقق منها مدققوهم فعلياً. ولا تفرّق هذه البرامج بين مورّد من 500 شخص ومورّد من شخص واحد. المورّد مورّد.

لهذا السبب يستمر استبيان الأمان في الوصول قبل العقد. فعميلك ملزَم — بحكم إطاره التنظيمي، أو مدققه، أو عملائه هو نفسه — بجمع أدلة أمنية من الجهات التي يسلّمها بياناته. بما فيك أنت. والمستقلون القادرون على الإجابة بمصداقية ("إليك ما لديه حق الوصول إلى بيئة التطوير الخاصة بي، وإليك كيف أتحكم فيه، وإليك الدليل") يُغلقون هذه الصفقات أسرع من غيرهم ممن يرتجلون الإجابات. وقد كتبنا عن النسخة الخاصة بالمؤسسات من هذه الديناميكية في ما يطلبه المدققون لحوكمة الذكاء الاصطناعي في 2026؛ أما نسخة المورّد فتصلك على شكل استبيان.

ما الذي يكلّفه الخرق فعلياً للمطوّر المستقل

هذا هو الإطار الصادق للمخاطر: يمكن أن يعني حادث أمني في مشروع لعميل مسؤولية مالية مباشرة بموجب بند التعويض في عقدك، ويمكن أن يعني مسؤولية المعالِج بموجب المادة 82 من GDPR إذا كانت بيانات شخصية متورطة — والأكثر واقعية بالنسبة لمستقل — يمكن أن يعني نهاية العلاقة مع العميل والمرجع الذي كان يصاحبها. فبالنسبة لاستشاري بمفرده، السمعة هي رأس المال التجاري. لا شيء من هذا خيال بعيد؛ إنه السلسلة الاعتيادية من العواقب حين يتحول بيانات اعتماد مخترقة أو تكامل مُنح صلاحيات مفرطة إلى حادثة تمس بيانات العميل.

إذاً، ما الذي تعرّض بالفعل في حسابك الآن؟

إليك النسخة المحددة وغير المريحة من السؤال. من شبه المؤكد أن عمل عملائك يعيش على حساب GitHub شخصي. وقد تراكم على هذا الحساب، على مدى سنوات من المشاريع:

• تطبيقات GitHub المثبَّتة — روبوتات نشر، وأدوات تكامل مستمر (CI)، ومساعدون بالذكاء الاصطناعي — كل منها يحمل صلاحية وافقت عليها مرة واحدة وربما لم تراجعها منذ ذلك الحين. بعضها يحمل صلاحية كتابة أو إدارة كاملة على كل ما تملكه. وبعضها ينتمي إلى مشاريع انتهت في 2024.
• مفاتيح النشر (Deploy keys) — بيانات اعتماد SSH غير مُراقبة موجودة على خوادم، وبعضها يحمل صلاحية كتابة على مستودع كان من المفترض أن يقتصر وصوله على القراءة فقط. فإذا اختُرق ذلك الخادم، يصبح مفتاح النشر القابل للقراءة والكتابة مساراً لحقن الشيفرة في منتج عميلك.
• المتعاونون (Collaborators) — أشخاص أضفتهم أثناء تعاون انتهى منذ ذلك الحين، ولا يزالون يحملون صلاحية كتابة، بما في ذلك على مستودعات عامة.
• مدى تعرّض المستودعات — أي من مستودعاتك عام، وما الموجود بداخله، هو بحد ذاته سؤال جرد لا يستطيع معظم المطوّرين الإجابة عنه من الذاكرة.

كل واحد من هذه العناصر قابل للقراءة الآلية عبر واجهة برمجة تطبيقات GitHub نفسها، ما يعني أن كل واحد منها قابل للتحقق منه — لا بالاعتماد على ذاكرتك، بل بحصر ما يحمل فعلياً صلاحية الوصول اليوم. وهذا الجرد بالضبط هو ما ينتجه الآن موصّل GitHub الخاص بـ 8200.dev للحسابات الشخصية، وليس فقط للمؤسسات: اربط حساب GitHub الخاص بك، ويقوم الفحص بإدراج التطبيقات المثبَّتة وصلاحياتها الممنوحة، ومفاتيح النشر وما إذا كان كل منها للقراءة فقط، والمتعاونين في كل مستودع، والنتائج التي تنبثق من ذلك الرسم البياني — الروبوت المنسي الذي يحمل صلاحيات إدارية، ومفتاح النشر القادر على الكتابة، والتطبيق القديم الذي لم يلمسه أحد منذ عام.

تُجري الفئة الشخصية المجانية الفحص الكامل وتُظهر لك أشد النتائج خطورة؛ أما الفئة الشخصية المدفوعة — بسعر يشبه اشتراك أداة إكمال شيفرة، وليس برمجية مؤسسية — فتفتح لك القائمة الكاملة مع مراقبة مستمرة وتنبيهات. وإذا نمت لتصبح وكالة لديها حساب مؤسسة (organization)، فإن الفحص نفسه، والقواعد نفسها، ومسار الأدلة نفسه يتوسع معك — وهذا هو جانب المؤسسات من المنتج، وهو الموصّل نفسه.

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

*هذا المقال معلومات عامة حول اللوائح التي تنطبق عادة على المطوّرين المستقلين؛ وهو ليس استشارة قانونية، وكيفية انطباق كل لائحة على وضعك الخاص تتوقف على وقائع لا يمكن لأداة فحص أن تعرفها. لذلك، تحدث إلى محامٍ.*