【مسار الامتثال】مولّد التطبيقات وبيئات التطوير الذكية: باب التطوير انفتح على مصراعيه، لكن بوابات حماية بيانات المستخدم الخمس ما زالت صامدة — تحول هندسة البرمجيات في عصر الذكاء الاصطناعي، تعلّم الذكاء الاصطناعي ببطء 176
انهارت حواجز بناء التطبيقات، لكن حواجز الوصول إلى بيانات المستخدمين لم تنهار
مديرو المنصات الرقمية في قطاع التجارة الإلكترونية يسألونني مؤخرًا السؤال نفسه: فرق الأعمال تستطيع خلال أسبوع واحد بناء ثلاثة أدوات داخلية صغيرة باستخدام الذكاء الاصطناعي، بينما لا يزال جدول تطوير تقنية المعلومات محجوزًا حتى الربع القادم. أين يكمن الاختناق بالضبط؟
إجابتنا تتلخص في حكم واحد: حواجز التطوير انهارت، لكن حواجز الوصول إلى بيانات المستخدمين لم تنهار بعد.
خلف هذه العبارة حقيقتان تتزامنان في الوقت نفسه.
Bolt.new هو منتج من تطوير StackBlitz، أُطلق بصمت عبر تغريدة في أكتوبر 2024، ووصل إلى 40 مليون دولار من الإيرادات السنوية المتكررة (ARR) خلال خمسة أشهر فقط. تتعقبه منصتا Sacra وGrowth Unhinged كأسرع منتج نموًا في التاريخ بعد ChatGPT. عند إغلاق السنة المالية 2026، كشف Eric Simons، الرئيس التنفيذي لـ StackBlitz، على LinkedIn أن Bolt.new أصبح مستخدمًا من قبل ثلاثة أرباع شركات Fortune 500، وارتفعت الإيرادات السنوية المتكررة على مستوى المؤسسات بنسبة 10 أضعاف على أساس سنوي (منشور رسمي لـ Eric Simons، إغلاق السنة المالية 2026). أما Lovable، فهو من فريق في ستوكهولم بالسويد (مؤسسه Anton Osika)، حصل في نوفمبر 2025 على تمويل من الفئة A بقيمة 200 مليون دولار بتقييم 1.8 مليار دولار، ثم في نهاية ديسمبر 2025 حصل على تمويل من الفئة B بتقييم 6.6 مليار دولار، أي أن تقييمه قفز نحو 4 أضعاف في ستة أشهر فقط (مصادر متقاطعة: Forbes/CNBC/Bloomberg/TechCrunch). في يونيو 2026، تجاوزت الإيرادات السنوية المتكررة لـ Lovable حاجز 500 مليون دولار (تقرير Forbes، ونشر TechCrunch في 2026-06-09 بالتزامن)، وفي نفس اليوم نقلت Forbes عن أربعة مصادر مطلعة أن الشركة تجري جولة تمويل جديدة بتقييم 12 مليار دولار (أي ما يقارب الضعف). هذا النوع من الأدوات اختصر بناء تطبيق كامل من أشهر من العمل الجماعي إلى بعد ظهر واحد لشخص واحد.
لكن بينما انهار حاجز التطوير، فإنّ العقبات الحقيقية التي تُكلّف شركتك الكثير من الوقت والمال لم تتحرك قيد أنملة: تقييم نقل البيانات عبر الحدود، واختبار تصنيف أمن المعلومات (MLPS / Dengbao)، وتسجيل الخوارزميات (Algorithm Filing)، وموافقة تغيير البنية (Change Advisory Board)، والتدقيق والمطابقة المالية. هذه العقبات لا علاقة لها تقريبًا بكتابة الكود نفسه، لكن كل واحدة منها تستهلك أسابيع. أدوات توليد التطبيقات كسرت الباب الأول، وأصبح بإمكان الفرق التجارية بناء تطبيقاتها بنفسها؛ لكن الباب الثاني — من يملك صلاحية الوصول إلى بيانات الإنتاج، ومن يستطيع تعديل المعاملات الأساسية — لم يتحرك قيد أنملة.
وهنا تظهر فجوة مخاطر لم ينتبه إليها معظم صناع القرار بعد: من يستطيع بناء التطبيق، ليس بالضرورة من يملك الصلاحية القانونية ليجعل هذا التطبيق يلمس البيانات.
سيناريو حقيقي رافقناه (تجارة إلكترونية، تم إخفاء الهوية): فريق عمليات المؤثرين في إحدى شركات التجارة الإلكترونية المنزلية استخدم Lovable لبناء 7 أدوات داخلية صغيرة خلال شهرين: مطابقة المؤثرين، حساب العمولات، تتبع المنتجات الرائجة، وتحليل أسباب الإرجاع. لم يُبلَّغ مركز التقنية بأي شيء. عند إجراء جرد للأنظمة غير الموثقة (Shadow IT) في منتصف العام، اكتشفوا أن 4 من هذه الأدوات تقرأ جداول طلبات واسعة تحتوي على أرقام هواتف وعناوين توصيل، وأن أداتين تصدّران البيانات وتخزنانها في حسابات تخزين سحابية شخصية. هذا هو المشهد الشائع الذي تواجهه فرق منصات التجارة الإلكترونية عند جرد الأصول منذ النصف الثاني من 2025 — وليس حالة معزولة.
سيناريو حقيقي رافقناه (مشغّل اتصالات، تم إخفاء الهوية): أثناء جلسة تدريب داخلي في أحد الفروع الإقليمية لمشغّل اتصالات، اعترف مدير مشروع في مركز التسويق أنهم استخدموا Bolt لبناء “أداة استعلام سريع عن ملف العميل” تتيح إدخال رقم هاتف لعرض سجل تغييرات الباقة خلال آخر 90 يومًا، وسجل الشكاوى، وجدول العروض الموصى بها — دون علم الإدارة التقنية إطلاقًا. وهذا يصطدم مباشرةً بالخط الأحمر في قانون الأمن السيبراني وقانون حماية المعلومات الشخصية فيما يتعلق بصلاحيات الاستعلام عن البيانات الشخصية.
ألقِ نظرة على هذه الصورة أولاً لفهم حجم الثغرة.
دعونا نفكك الأمر: ما المشكلة التي تحلها هذه الأدوات ولمن، وكيف يتغير دور المهندسين، وما شكل التطبيقات غير الموثقة المتفشية في التجارة الإلكترونية، وما العقبات الحقيقية في القطاعات شديدة التنظيم، وكيف نمنح الجهات التشغيلية مسارًا متوافقًا.
أولاً: لنضع هذه الأدوات الخمسة في سياقها الصحيح
كثيرٌ من الناس يخلطون بين هذه الأدوات ويطلقون عليها جميعًا اسم “البرمجة بالذكاء الاصطناعي”. لكنها في الحقيقة تخدم فئتين مختلفتين تمامًا، وفهم هذا الفرق هو ما يجعل أي حكم لاحق على هذه الأدوات سليمًا.
الفئة الأولى: “من يعرفون كيف يكتبون الكود”. هؤلاء يبحثون عن محرر أكواد أسرع: أداة تفهم سياق قاعدة البيانات البرمجية الخاصة بك، وتعدّل عبر ملفات متعددة، وتشغّل الاختبارات تلقائيًا، وتشرح لك أخطاء التشغيل. من أبرز الأمثلة على هذه الفئة: Cursor، وTrae من ByteDance، وTongyi Lingma من Alibaba، وGitHub Copilot. الفرضية الأساسية هنا أنك مهندس برمجيات أصلًا، والأداة مجرد وسيلة لتوفير الجهد المتكرر. وقد تناولنا هذه الفئة بالتفصيل في المقال الرابع من السلسلة، ولن نكرر ذلك هنا.
الفئة الثانية: “من لا يعرفون البرمجة”. وهذه هي بطلة مقالنا اليوم: مولّدات التطبيقات (App Generators). أنت تكتب جملة واحدة بالعربية تصف فيها ما تريده، فتعطيك مباشرة تطبيقًا قابلًا للتشغيل، يشمل الواجهة الأمامية والخلفية وقاعدة البيانات والنشر — كل ذلك في خطوة واحدة. هذه الأدوات لا تفترض أن لديك أي خلفية برمجية.
اخترنا لهذا المقال أربعة من مولّدات التطبيقات لنتناولها بالتفصيل، مع إفراد Trae باهتمام خاص ضمن فئة بيئات التطوير المتكاملة بالذكاء الاصطناعي (AI IDE)، لأنه يلامس نقطة حساسة للغاية بالنسبة للصناعات الخاضعة لرقابة مشددة.
Bolt.new (من إنتاج StackBlitz). أُطلق بصمت عبر تغريدة في أكتوبر 2024، وتتبّعته Sacra وGrowth Unhinged كأسرع منتج نموًا في التاريخ (في المرتبة الثانية بعد ChatGPT): تجاوز مليون دولار من الإيرادات السنوية المتكررة (ARR) في أسبوعه الأول، و4 ملايين في أربعة أسابيع، و20 مليونًا في شهرين تقريبًا، و40 مليونًا في خمسة أشهر، مع حوالي 5 ملايين مستخدم مسجّل (وفقًا لتصريحات الرئيس التنفيذي لـ StackBlitz). التقنية الأساسية وراءه تُسمى WebContainers، وهي تتيح تشغيل بيئة Node.js كاملة داخل المتصفح، مما يمكّن الذكاء الاصطناعي من التعامل المباشر مع الملفات، وتثبيت الحزم، وتشغيل الخوادم دون الحاجة إلى إعداد بيئة محلية. عند إغلاق السنة المالية 2026، كان Bolt.new قد اعتمده ثلاثة أرباع شركات Fortune 500، وشهدت إيراداته المؤسسية السنوية المتكررة نموًا عشرة أضعاف على أساس سنوي (وفقًا لمنشور رسمي لإريك سيمونز على LinkedIn بمناسبة إغلاق السنة المالية 2026). جمعت StackBlitz جولة تمويل من الفئة B بقيمة 105.5 مليون دولار في يناير 2025، بتقييم يبلغ حوالي 700 مليون دولار (كما ورد في Business Insider وغيره). الاستخدام النموذجي له هو بناء تطبيقات صغيرة أو صفحات هبوط يمكن معاينتها فورًا.
Lovable (مقرها ستوكهولم، السويد، أسسها Anton Osika، وهي امتداد لمشروع المصدر المفتوح GPT Engineer). تتبع هذه الأداة نهج “من جملة واحدة إلى تطبيق كامل قابل للنشر”، وموقعها أقرب إلى تطبيقات الأعمال الشاملة مقارنةً بأداة Bolt. في نوفمبر 2025، جمعت جولة تمويلية من الفئة A بقيمة $200M بتقييم $1.8B، وفي نهاية ديسمبر 2025، جمعت جولة تمويلية من الفئة B بقيمة $330M بتقييم $6.6B، أي أن التقييم تضاعف نحو 4 مرات في غضون ستة أشهر. في يونيو 2026، تجاوزت الإيرادات السنوية المتكررة (ARR) حاجز $500M (بحسب تقرير Forbes بتاريخ 2026-06-05، ونشرته TechCrunch بالتوازي)، وفي اليوم نفسه، نقلت Forbes عن أربعة مصادر مطلعة أن الشركة تجري جولة تمويلية جديدة بتقييم يبلغ نحو $12B (أي ما يقارب الضعف، بحسب Forbes/Rashi Shrivastava). من بين عملاء Lovable من الشركات: Workday وAsana وNVIDIA (وفقًا لتجميع ARR.club لعام 2026).
Vercel v0. تم إطلاقه في أكتوبر 2023، وفي 3 فبراير 2026 تم تغيير اسمه رسميًا من v0.dev إلى v0.app، ليتطور من أداة لبناء مكونات الواجهة إلى مولّد تطبيقات متكامل (بيئة تشغيل معزولة + تكامل مع GitHub + تكامل مع قواعد بيانات Snowflake/AWS). وفقًا للتصريحات الرسمية من Vercel في مارس 2026، تجاوز عدد المستخدمين 6 ملايين مطوّر، مع حوالي 80 ألف فريق نشط شهريًا (تقديرات محللي المنافسين تشير إلى إيرادات سنوية متكررة تبلغ حوالي 42 مليون دولار أمريكي، وفقًا لتجميع Taskade في مارس 2026).
Replit Agent 4. صدر في 13 مارس 2026، ويُعدّ أهم تحديث في تاريخ Replit. تغيّرت ثلاثة أمور في آنٍ واحد: ① ترقية Design Mode إلى Infinite Design Canvas، بحيث يمكنك تعديل الكود أثناء التصميم؛ ② تحوّل التعاون من نمط fork-and-merge إلى “مشروع واحد، مهام متعددة المسارات” — حيث تعمل عدة sub-agents بالتوازي، وفي النهاية يتولى sub-agent مخصص لحل التعارضات الدمج تلقائيًا، وفق البيانات الرسمية: Agent 4 يحل 90% من تعارضات الدمج تلقائيًا (تغطية AlphaSignal 2026، وسجل التغييرات الرسمي لـ Replit في مارس 2026)؛ ③ لم يعد التخطيط والتنفيذ متسلسلين، بل يمكن التخطيط والتنفيذ في الوقت نفسه. في الفترة نفسها، أغلقت Replit جولة تمويل من الفئة D بقيمة تقارب 9 مليارات دولار (تغطية Atal Upadhyay 2026؛ ومصادر متعددة من TechCrunch وBloomberg تؤكد ذلك). انطلقت Replit كبيئة برمجة عبر الإنترنت، وبطبيعتها تحمل التعاون والاستضافة، وAgent 4 ضغط زمن “فريق صغير يبني منتجًا معًا” إلى سرعة تقترب من العمل الفردي.
القاسم المشترك بين هذه الأدوات الأربع: خفض تكلفة “بناء تطبيق” من فريق × شهر، إلى فرد × ساعات.
سنتناول Trae بشكل منفصل، لأنه يمثل مخاطر مورد محددة لمؤسسات الاتصالات والتمويل والتجارة الإلكترونية. Trae في شكله هو IDE (محرر أكواد)، لكنه في جوهره بيئة تطوير مرتبطة بالكامل بخوادم ByteDance — وبالنسبة للمؤسسات، لا يمكن التعامل معه كـ”IDE عادي”، بل يجب تقييمه كـ”أداة نقل بيانات عبر الحدود” ضمن إجراءات التصريح الأمني. أطلقته ByteDance في يناير 2025، مستهدفًا منافسة Cursor، باستراتيجية تقديم نماذج متقدمة مثل Claude وGPT-4o مجانًا. خلال 12 شهرًا، وصل عدد المستخدمين المسجلين إلى 6 ملايين، مع 1.6 مليون مستخدم نشط شهريًا، وإجمالي ما يقارب 100 مليار سطر من الأكواد المُولَّدة (وفقًا لتقرير تجميعي من OpenAI Tools Hub، مايو 2026). لكن في يوليو 2025، نشر باحث الأمن segmentationf4u1t مشروع telemetry_research الذي أثبت أنه حتى عند تعطيل التتبع عن بُعد في الإعدادات، يستمر Trae في نقل البيانات في الخلفية إلى خوادم ByteDance مثل mon-va.byteoversea.com — بما في ذلك معلومات الأجهزة، وإصدار نظام التشغيل، ومعرفات الأجهزة والآلات الدائمة، وبيانات نشاط المشروع؛ ويمكن أن تصل حزمة التتبع الواحدة إلى 53,606 بايت كحد أقصى، مع أكثر من 500 استدعاء وحوالي 26 ميجابايت من البيانات الناتجة عن 7 دقائق من الاستخدام العادي (بيانات مباشرة من GitHub segmentationf4u1t/trae_telemetry_research، كما غطته The Register وCybernews في 28 يوليو 2025).
ردّ ByteDance اللاحق يستحق التوثيق. في تحديث Cybernews بتاريخ 2026-08-01، ورد: أقرّ بيان ByteDance الرسمي بأن مفتاح telemetry الموجود في إعدادات IDE يتحكم فقط في بيانات القياس الخاصة بإطار عمل VS Code، وأن جمع بيانات أدوات Trae الأخرى لا يتأثر بهذا المفتاح — وبعبارة أبسط: ظننت أنك أطفأته، لكنه في الحقيقة ما زال يعمل. بعد تواصل الباحثين مباشرة مع فريق Trae، تأكدوا أن وضع Privacy Mode مستقل من المقرر إطلاقه حوالي أغسطس 2026. في الوقت نفسه، خرق Trae وعد “forever free” عبر “نظام الدفع القائم على الرموز (token-based paywall)” في فبراير 2026، مما دفع العديد من المطورين الذين اعتمدوه في بيئات الإنتاج إلى إعادة تقييم خياراتهم (وفقًا لاستطلاع OpenAI Tools Hub في مايو 2026).
بالنسبة للمطور الفردي، نسخة Claude المجانية خيار ممتاز. أما بالنسبة لك كصانع قرار، فهذه مشكلة امتثال نموذجية تتعلق بنقل البيانات عبر الحدود — مهندسوك يغذّون أداةً تعيد إرسال البيانات إلى خوادم ByteDance بكود شركتك، وربما إعداداتها وواجهاتها البرمجية. في قطاعات مثل الاتصالات والمالية، التي تخضع لقانون أمن البيانات (Data Security Law) وقانون حماية المعلومات الشخصية (Personal Information Protection Law)، هذه الخطوة وحدها كافية لإطلاق حادثة امتثال. سنتناول هذا بالتفصيل في القسم الرابع.
ثانيًا: إعادة كتابة التطوير: من “كتابة الكود” إلى “المراجعة والتنسيق والضبط”
أكثر سوء فهم شائع حول مولّدات التطبيقات هو أنها “ستلغي الحاجة إلى المهندسين”. هذا الطرح في الاتجاه الخاطئ.
الصيغة الأدق هي: ما يتغيّر هو محور عمل المهندس، وليس إلغاء الوظيفة نفسها. عندما يصبح بإمكان الذكاء الاصطناعي وأفراد الأعمال إنتاج الكود والتطبيقات، تنتقل قيمة المهندس من “الكتابة بنفسه” إلى ثلاثة أمور: مراجعة صحة هذه المخرجات، وتنسيقها في أنظمة موثوقة، والتحكم في بوابة الأمان والجودة.
هذه الأمور الثلاثة أكثر ندرة من “كتابة الكود”، وأعلى قيمةً. من يكتب مكوّن React واحدًا في الشارع كثيرون؛ أما من يستطيع الحكم على ما إذا كان تطبيق ترويجي يولّده الذكاء الاصطناعي جاهزًا للتعامل مع بيانات المعاملات، وما إذا كان نظام التحقق من الهوية فيه حقيقيًا أم وهميًا، وما إذا كان يسجّل السجلات إلى خوادم خارجية — فهؤلاء أندر بكثير.
هنا لا بد من تقديم تصنيف واضح ومتدرّج، لأن كثيرًا من الشركات تقع في التطرف في هذه المسألة: إما أن يفوّضوا كل شيء للمولّد، أو يمنعوه منعًا كليًا. كلا الطرفين خاسر.
هذا الشكل يريد إيصال رسالة واحدة فقط: المحور الأفقي يقيس مدى تعقيد منطق التطبيق، والمحور العمودي يقيس ما إذا كان يمسّ المال أو البيانات الشخصية. الخانة السفلية اليمنى (تعقيد عالٍ + حساسية عالية) — مهما كان مولّد التطبيقات ذكيًا، لا يحق له الدخول إلى هذا المجال. تسليم صفحة هبوط ترويجية إلى Lovable أمر مقبول؛ أما بوابة الدفع الخاصة بك — فالمشكلة مسألة وقت فقط.
احفر هذا الخط الأحمر في ذهنك، ثم انظر إلى ما يحدث في التجارة الإلكترونية.
ثالثًا:痛点 الحقيقي للتجارة الإلكترونية: التطبيقات الظلّية تصطدم ببيانات الطلبات
لنوسّع العدسة قليلًا، وننظر أولًا إلى رقم طرحته Gartner في النصف الثاني من 2025: بحلول نهاية 2026، سيكون 40% من تطبيقات المؤسسات مدمجًا بها وكلاء ذكاء اصطناعي (AI agents) مخصصون لمهام محددة، مقارنة بأقل من 5% في 2025 (توقعات Gartner الرسمية، ونشرتها Process Excellence Network في 2025-08-27). ويصاحب ذلك مجموعة أرقام أكثر لفتًا للانتباه: تشير تقارير Gartner إلى أن استفسارات المؤسسات حول أنظمة الوكلاء المتعددين (multi-agent systems) ارتفعت بنسبة 1445% بين الربع الأول من 2024 والربع الثاني من 2025 — وهو الموضوع الأسرع نموًا في أعمال Gartner الاستشارية للذكاء الاصطناعي، بلا منازع (مجمّع من RAPIDCLAW وHendricks.ai وArion Research).
ترجمة هذين الرقمين إلى لغة التجارة الإلكترونية: **40% من تطبيقات المؤسسات ستعمل بتقنية وكلاء الذكاء الاصطناعي (AI agents)**، مع رقم آخر مرافق — ارتفاع الاستشارات المتعلقة بالأنظمة متعددة الوكلاء في المؤسسات بنسبة +1445% (وفقًا لمعيار نمو استشارات Gartner للذكاء الاصطناعي، وليس معيار النشر، لكن الإشارة الاتجاهية واضحة بالفعل): لقد انتقل وكلاء الذكاء الاصطناعي من “مساعدة المطورين على كتابة الكود” إلى “عدة وكلاء يتعاونون معًا لتنفيذ دورة الأعمال بأكملها”. عندما يبدأ وكلاء الذكاء الاصطناعي في العمل داخل تطبيقات المؤسسات، فيتعاملون مع البيانات، وينفذون العمليات، ويكتبون السجلات، تتحول طبيعة مولّد التطبيقات (App Generator) من “أداة” إلى “نظام”.
تقرير صادر عن شركة الأبحاث UpGuard لعام 2025 (بعنوان “State of Shadow AI”، ونقلته Cybersecurity Dive) يتضمن رقمين أكثر لفتًا للانتباه من نسبة Gartner البالغة 40%: أكثر من 80% من الموظفين يستخدمون أدوات ذكاء اصطناعي غير معتمدة في عملهم، وحتى داخل فرق الأمن، ما يقرب من 90% يفعلون ذلك. وهناك رقم آخر: حوالي نصف الموظفين يعترفون بأنهم لصقوا بيانات شركة سرية مباشرة في هذه الأدوات غير المعتمدة. Mimecast تعطي 51% وTeramind تعطي 49% — وهي أرقام متقاربة. أما Gartner فتعطي الجانب الآخر: 69% من المؤسسات تشتبه أو تؤكد أن موظفيها يستخدمون أدوات ذكاء اصطناعي محظورة، بينما 37% فقط لديها سياسات واضحة لاستخدام الذكاء الاصطناعي (بما نقلته The Hacker News).
لنترجم هذه الأرقام إلى لغة التجارة الإلكترونية: فريق التشغيل لديك، فريق التسويق، فريق تخطيط الحملات — كلهم يستخدمون أدوات مثل Bolt وLovable وv0 لبناء تطبيقاتهم الخاصة. مكوّن إعداد قواعد العروض الترويجية، لوحة متابعة اختيار المؤثرين للمنتجات، تطبيق صغير للاستعلام عن المخزون، أداة لتدفق تذاكر الدعم ما بعد البيع. هذه الأدوات سريعة، سهلة الاستخدام، وتحل مشاكل حقيقية. كما أنها — تقريبًا كلها — تتجاوز قسم تكنولوجيا المعلومات وحوكمة البيانات تمامًا.
سيناريو حقيقي عشناه (قطاع التجارة الإلكترونية، تم إخفاء البيانات): منذ النصف الثاني من 2025، أجرينا جردًا للـ IT الظل (Shadow IT) لدى 4 شركات تجارة إلكترونية متوسطة وكبيرة (فرق منصة رقمية بحجم 50-200 شخص)، ولم تكن أي منها خالية. الحالة الأكثر نموذجية كانت شركة تجارة إلكترونية منزلية: فريق إدارة المؤثرين بنى لنفسه 7 أدوات داخلية عبر Lovable في شهرين فقط، 4 منها تتعامل مع جداول طلبات واسعة (تحتوي أرقام هواتف وعناوين توصيل)، و2 منها صدّرت البيانات وحفظتها في خدمات تخزين سحابية شخصية. يوم الجرد، قال مدير الأمن جملة واحدة: “كادنا وقتها ما نكملش الجرد — كنا خايفين من اللي ممكن نطلعه وما يكونش حد في الإدارة قادر يستوعبه.”
هذا النمط يمكن تسميته “الـ IT الظل للبيانات”. خلال العقد الماضي، كان الـ IT الظل الذي يسبب الصداع هو الـ SaaS الذي تشتريه الأقسام التجارية بنفسها (المبيعات تشتري CRM، التسويق يشتري أداة بريد جماعي). أما الآن فالـ IT الظل هو تطبيقات تبنيها الأقسام التجارية بنفسها. إنها تستخدم أداة غير معتمدة — والأخطر من ذلك، أنها تنتج نظامًا جديدًا يتعامل مع بيانات حساسة، وهذا النظام غير مسجل في قائمة أصول تقنية المعلومات.
الفرق في الحجم: شراء SaaS يعني ربط نظام خارجي واحد؛ استخدام مولّد التطبيقات يعني توليد مجموعة أنظمة جديدة من العدم داخل شركتك، كل منها بواجهات بيانات، وكل منها قد يكون قابلًا للوصول من الإنترنت الخارجي. في سنة واحدة، قد تولّد شركة تجارة إلكترونية أكثر من مئة تطبيق من هذا القبيل، ولا يوجد أي منها في قائمة أصول تقنية المعلومات.
هذا الأمر لا يمكن إيقافه. نسبة 80% التي نشرتها UpGuard كافية لإثبات أن “المنع” ليس حلًا. البشر سيجدون دائمًا الأداة الأسهل لإنجاز العمل، هذه هي الطبيعة البشرية، وهذا أيضًا ما تقيسه مؤشرات الأداء. لذا لا تسأل “كيف نمنع الفرق التجارية من استخدام المولّدات؟”، بل اسأل “كيف نجعلهم يستخدمونها بأمان؟”. القسم الرابع يتناول عتبات الامتثال، والقسم الخامس يتناول كيفية تأمين القنوات.
رابعًا: ما هي عتبات الامتثال؟ لا تخلط بينها وبين الاختبارات
هذا هو القسم الأهم في هذه المقالة، وهو أيضًا الأكثر عرضة للخطأ في الكتابة.
كثير ممن جاءوا من خلفيات شركات الإنترنت، عندما تذكر لهم “المراجعة والتحكم”، يتبادر إلى أذهانهم فورًا الاختبارات الآلية في CI/CD: تشغيل اختبارات الوحدة، واختبارات التكامل، واختبارات الانحدار، وإذا كانت النتيجة خضراء، يُسمح بالمرور. الفرق التقنية التي تدير حملات التخفيضات الكبرى في التجارة الإلكترونية تعرف هذه المنظومة جيدًا.
لكن في قطاع الاتصالات، والقطاع المالي، والتصنيع الخاضع للرقابة، والتجارة الإلكترونية المنظَّمة، فإن “التحقق” يتجاوز بكثير مجرد الاختبارات. العوائق الحقيقية هي عدة مراحل لا علاقة لها تقريبًا بكود البرنامج نفسه، لكن كل واحدة منها تستهلك أسابيع. اعتبار هذه المراحل مجرد “اختبارات” هو تحيّز نابع من ثقافة الإنترنت، وسيضلل صناع القرار ويجعلهم يقللون من تقدير مدة التسليم.
دعنا نمر عليها واحدة واحدة.
تقييم نقل البيانات عبر الحدود.[^1] إذا كان تطبيقك يعتمد على خدمات ذكاء اصطناعي خارجية (فالعديد من المولّدات تعمل في الخلفية عبر OpenAI أو Anthropic)، أو إذا كان المهندسون يستخدمون بيئة تطوير متكاملة مثل Trae التي تنقل البيانات إلى الخارج، فبمجرد أن تتضمن البيانات معلومات شخصية أو بيانات حساسة، تصبح ملزماً بمتطلبات نقل البيانات عبر الحدود المنصوص عليها في قانون أمن البيانات وقانون حماية المعلومات الشخصية. إكمال تقييم رسمي لأمن نقل البيانات أو تسجيل اتفاقية معيارية قد يستغرق من شهر أو شهرين في أفضل الحالات، إلى أكثر من ستة أشهر في أسوأها. اكتشاف أن Trae “ينقل البيانات حتى بعد تعطيل القياس عن بُعد” يعني أنه حتى لو اعتقدت أنك لا تنقل شيئًا، فالنقل يحدث فعليًا. مثل هذه الأدوات لا ينبغي أن تجد لها مكانًا في بيئة التطوير في الصناعات شديدة التنظيم.
تقييم الحماية من مستويات التصنيف.[^2] بموجب قانون الأمن السيبراني، ونظام الحماية من التصنيف الإلكتروني (النسخة 2.0)، فإن أي تطبيق موجه للجمهور سيُصنّف على الأرجح في المستوى الثالث من الحماية. التصنيف، والتسجيل، والمعالجة، والتقييم — تستغرق هذه الدورة عادةً من ثلاثة إلى ستة أشهر. هذا مطلب قانوني وليس خيارًا. لن تحصل على إعفاء من هذا التصنيف لمجرد أن تطبيقك المبني على الذكاء الاصطناعي أُنجز بسرعة.
تسجيل الخوارزميات.[^3] إذا كان تطبيقك موجهًا للجمهور ويستخدم الذكاء الاصطناعي التوليدي (مثل التوليد التلقائي لتفاصيل المنتجات، أو الردود التلقائية لخدمة العملاء، أو محتوى مولّد بالذكاء الاصطناعي ضمن التوصيات المخصصة)، فأنت ملزم بتسجيل الخوارزمية وفقًا للوائح إدارة خدمات الذكاء الاصطناعي التوليدي والأحكام ذات الصلة بشأن التوصية الخوارزمية. إطلاق التطبيق دون التسجيل يُعد حادث امتثال.
Change Approval (CAB) and Rollback Plans. [^4] For core systems in finance and telecom, every release requires approval from the Change Advisory Board (CAB): scope of impact assessment, rollback plan, and confirmation of the maintenance window. This step consumes calendar time, not machine time—if you miss the window, you wait until next week.
Reconciliation and Auditing. [^5] For e-commerce peak seasons and financial clearing/settlement, after launch you must reconcile with funding sources and upstream partners, and have audit logs to trace every transaction. AI-generated applications are often completely lacking in this area: they can run, but they have no reconciliation design, so when discrepancies arise, there is no way to trace them.
Putting all this together, a counter-intuitive conclusion emerges: App generators make the leap from “idea” to “working prototype” an order of magnitude faster, but from “working prototype” to “compliant launch,” there is no time saved at all. The hurdles take just as long as they always did.
This is the red line that didn’t move in the first chart. The development barrier collapsed, saving the time engineers spend writing code; but the compliance barrier didn’t move—the evaluations, tests, and approvals still take as long as before. The biggest mistake a decision-maker can make is to assume that speeding up the former automatically speeds up the latter. It doesn’t.
5. Give the business side a compliant path, don’t let it grow wild
Since you can’t block it, provide a path—this is one of the few viable ways to govern shadow IT.
There are four steps to build this path.
الخطوة الأولى: توفير مولّد داخلي مُعتمد أمنيًا. بدلًا من ترك الفرق التشغيلية تستخدم أدوات خارجية عشوائية مثل Lovable، ينبغي على الشركة اقتناء أو بناء نسخة داخلية تتوافق مع معايير الأمن السيبراني المحلية (الاختبار الأمني المُطابق للمعايير الصينية “等保测评” – ما يعادل شهادة ISO 27001 أو NIST) وتضمن عدم خروج البيانات خارج حدود المؤسسة، مع توفير بوابة دخول داخلية موحّدة. عندما يجد الفريق التشغيلي الأداة الداخلية مريحة وفعّالة، لن يلجأ إلى أدوات خارجية — وهذه هي استراتيجية “التوجيه” بدل “المنع” فقط.
لقد قدّمت Microsoft في عامها المالي 2026 نموذجًا مرجعيًا واضحًا: EY نشرت Copilot لـ 150,000 موظف وحققت زيادة إنتاجية بنسبة 15%؛ وAtos نشرت Copilot لـ 56,000 موظف في 54 دولة، وتدير 19,000 وكيل ذكاء اصطناعي تحت إطار تحكم موحّد يغطي الهوية والأمن والامتثال وحوكمة الوكلاء (المصدر: مدونة Microsoft FY26回顾 بتاريخ 2026-07-28، والبيان الرسمي Atos بتاريخ 2026-06-09، وكلاهما تصريح مشترك من البائع والعميل). القاسم المشترك بين الحالتين: دمج أدوات الذكاء الاصطناعي في مستوى التحكم الأمني والامتثالي للمؤسسة — وهذا هو النموذج الحي للقناة المُعتمدة.
على الصعيد المحلي، يمكن الاستناد إلى “المبادئ التوجيهية للامتثال لتطبيقات النماذج الكبيرة في القطاع المالي” الصادرة عن معهد الاتصالات والبنية التحتية المالية الصيني، وكذلك الممارسات الامتثالية ضمن مبادرة وزارة الصناعة وتكنولوجيا المعلومات “الذكاء الاصطناعي لتمكين التصنيع الجديد” — المسارات المحلية قيد التنفيذ بالفعل، وما ينقص هو دمجها في العمليات الإلزامية للمؤسسة.
الخطوة الثانية: التسجيل الإلزامي. من بنى التطبيق، وما البيانات التي يقرؤها، ولمن يخدم — كل ذلك يُقيَّد في سجل موحّد. يجب أن يكون التسجيل خفيفًا: نموذج يُملأ في 5 دقائق، لا أن يتحول إلى إجراء يستغرق شهرين، وإلا فلن يملأه أحد، ونعود إلى العمل في الظل. الغرض من التسجيل ليس الموافقة على كل تطبيق، بل أن تكون لديك قائمة واضحة.
الخطوة الثالثة: التصنيف والتوجيه حسب درجة حساسية البيانات. استخدم المصفوفة من القسم الثاني. التطبيقات التي تتعامل فقط مع بيانات مجهولة المصدر أو بيانات اختبارية تُمرَّر تلقائيًا؛ أما أي طلب يمس بيانات حقيقية مثل الطلبات الفعلية أو المعلومات الشخصية، فيُفعَّل تلقائيًا إجراء التقييم المسبق لنقل البيانات عبر الحدود وتقييم الأمن السيبراني (ما يعادل تقييم تأثير حماية البيانات بموجب GDPR). اجعل المسار يتبع حساسية البيانات، بدلًا من تطبيق معيار موحّد على جميع التطبيقات.
الخطوة الرابعة: الفحص الأمني التلقائي. التطبيقات المولّدة بالذكاء الاصطناعي تُظهر معدلات ثغرات أمنية أعلى بشكل ملحوظ مقارنةً بالكود المكتوب يدويًا. حدّثت CodeRabbit هذا الرقم في تقريرها لعام 2026: عدد المشكلات (بما في ذلك أخطاء المنطق والصحة) في الكود المُنتَج بمساعدة الذكاء الاصطناعي يبلغ 1.7 ضعف ما هو عليه في الكود التقليدي المكتوب يدويًا (وفق منهجية CodeRabbit الخاصة، مع الإشارة إلى موقفها التجاري؛ وبالتوازي مع ندوة DORA عبر الإنترنت في فبراير 2026، ومراجعة Kunal Ganglani المقارنة لعام 2026). تقرير Veracode لعام 2025 حول أمن كود الذكاء الاصطناعي التوليدي كان أكثر مباشرة: في العينات التي اختبرتها، حوالي 45% من الكود المولّد بالذكاء الاصطناعي يحتوي على ثغرات بمستوى OWASP Top 10 (نسبة الفشل في كود Java المولّد تتجاوز 70%، وفق منهجية Veracode الخاصة، مع الإشارة إلى موقفها التجاري). دراسة أكاديمية واسعة النطاق حللت مستودعات عامة على GitHub (arXiv:2510.26103) تدعم نفس الاتجاه. لذا، فإن خطوة الفحص هذه إلزامية للتطبيقات المولّدة بالذكاء الاصطناعي، وليست اختيارية. اربط أدوات SAST وفحص التبعيات وفحص المفاتيح السرية بمسار إصدار المولّد، ولا تسمح بالمرور إلا إذا كانت النتائج خضراء. في يونيو 2026، تم إثبات أن CodeRabbit هي أداة مراجعة الكود بالذكاء الاصطناعي الأكثر تثبيتًا على GitHub/GitLab، مع أكثر من 15,000 عميل مدفوع، وراجعت 6 ملايين مستودع، وحتى الرئيس التنفيذي لـ NVIDIA، Jensen Huang، أيدها علنًا قائلاً “NVIDIA تستخدم CodeRabbit في جميع أنحاء الشركة” — لذا فإن اعتبارها خطًا أساسيًا مرجعيًا لبوابة جودة الكود بالذكاء الاصطناعي على مستوى المؤسسات هو أمر منطقي.
ستة: متى لا يجب استخدام مولّد التطبيقات
ليس حلاً سحرياً. هناك أربعة أنماط نموذجية من سوء الاستخدام، وقد شاهدنا كل واحد منها لدى عملائنا الذين نخدمهم.
استخدامه للمعاملات الأساسية أو إدارة المخاطر. هذا هو الأخطر. البعض يعتقد: “المولّد بهذه القوة، لنجرّب بوابة الدفع أيضاً”. الزاوية اليمنى السفلية من المصفوفة السابقة هي المنطقة الحمراء — منطق معقّد يلامس المال، وتسليمه للمولّد يعني تسليم النظام الأساسي لمتدرب لا يتحمل المسؤولية. عند وقوع حادثة مالية، لا يوجد تسوية، لا يوجد تدقيق، لا توجد خطة تراجع.
هنا يجب توضيح رقم تم تداوله بشكل خاطئ. ورد في المسودة الأصلية عبارة “نسبة تبني الذكاء الاصطناعي الخفي 45%”، وهذا خلط بين أمرين مختلفين. 45% هي نسبة العيوب في الكود المولّد بالذكاء الاصطناعي وفق تقرير Veracode، وليست نسبة تبنّي الأدوات؛ أما نسبة تبنّي الذكاء الاصطناعي الخفي فتُستمد من تقرير UpGuard الذي يتجاوز 80%+. الرقمان يتحدثان عن أمرين مختلفين تماماً، لا تخلط بينهما.
الكود المُولَّد بالذكاء الاصطناعي آمن افتراضيًا. الأرقام تتحدث عن نفسها: CodeRabbit بنسبة 1.7 مرة، وVeracode بنسبة 45%. بين “يبدو أن التطبيق يعمل” و”يعمل بأمان” — فجوة كاملة هي هندسة الأمن. التعامل مع تطبيقات الذكاء الاصطناعي بمعايير أمنية مخففة مقارنةً بالكود البشري، يعني ببساطة: إنتاج ثغرات أسرع.
استخدام مولّدات خارجية لمعالجة البيانات الشخصية دون تقييم نقل البيانات عبر الحدود. هذا يحدث بصمت في قطاع التجارة الإلكترونية: حملة تسويقية لصفحة موجهة للمستهلك، النهاية الخلفية تستدعي OpenAI لتوليد النصوص، ورقم هاتف المستخدم ينتقل معها إلى خادم خارجي. هكذا يُعبَر الخط الأحمر لقانون حماية البيانات الشخصية. عند وقوع حادث، يُصنَّف كحادث أمن بيانات، لا كخلل برمجي.
تثبيت أدوات تطوير مثل Trae (التي تنقل البيانات خارجيًا) افتراضيًا لجميع مهندسي الشركة. الإغراء كبير: نماذج متقدمة مجانية، والمهندسون يثبّتونها بأنفسهم. بمجرد أن تصل شفرتك الأساسية، إعداداتك، وواجهاتك إلى خوادم ByteDance (أو أي كيان خارجي)، يكون الأوان قد فات للتراجع. إدخال مثل هذه الأدوات إلى بيئة التطوير يتطلب تقييمًا مشتركًا مع فرق الأمن والشؤون القانونية — ليس قرارًا تتخذه الفرق التقنية وحدها.
سابعًا: عدسة القطاعات الأربعة — ما يمكن تسليمه وما لا يمكن تسليمه أبدًا
يركز هذا الفصل على 4 قطاعات رافقنا فيها عملاء عبر أخطاء حقيقية (التجارة الإلكترونية، الخدمات المالية، الاتصالات، التصنيع). أما القطاعات شديدة التنظيم مثل الحكومة والرعاية الصحية، فسنخصص لها مقالًا منفصلًا لاحقًا.
دعنا ننتقل بالكاميرا إلى القطاعات الأربعة، وسنضع لكل قطاع سيناريو حقيقيًا شهدناه بأنفسنا كتعليق توضيحي.
التجارة الإلكترونية. أكثر ما يسهل أن ينفجر هو “مُكوِّن قواعد العروض الترويجية”، و”لوحة اختيار منتجات المؤثرين”، و”تطبيق الاستعلام عن المخزون” — تبدو كأدوات، لكنها في الواقع تقرأ جداول الطلبات الواسعة التي تحتوي على أرقام هواتف وعناوين. هذا النوع من التطبيقات يجب أن يمر عبر قناة التسجيل الرسمية (sanctioned channel) المذكورة في القسم الثالث، وأي وصول إلى بيانات حقيقية يفعّل تلقائيًا متطلبات حماية البيانات وتقييم نقل البيانات عبر الحدود. لقد رأينا بأعيننا فريق عمليات في شركة تجارة إلكترونية بنى 7 أدوات داخلية في شهرين، 4 منها كانت تقرأ جداول الطلبات الواسعة — وهذه ليست حالة معزولة.
القطاع المالي. الخط الأحمر هو “أنظمة التداول / المدفوعات / التسوية والمقاصة / إدارة المخاطر / مكافحة الاحتيال / التقارير التنظيمية”. ما يناسب المولّد (Generator) هو أدوات مثل منصة عمل مديري العلاقات، ومُكوِّن الحملات التسويقية، وواجهات تسوية الحسابات. ممنوع تمامًا استخدامه في بناء محرك إدارة المخاطر أو قواعد مكافحة الاحتيال — نسبة أخطاء المنطق التي تبلغ 1.7 ضعفًا في CodeRabbit (وفق منهجية CodeRabbit الخاصة، مع الأخذ في الاعتبار موقفها التجاري) تتضخم في السيناريو المالي إلى مخاطر مالية مباشرة. الحالة التالية تم إخفاء هوية الشركة المعنية: بنك مساهمة بدأ في نهاية 2025 باستخدام البرمجة بالذكاء الاصطناعي للمساعدة في توليد التقارير التنظيمية، ونتيجة لذلك احتوت نصوص التقارير المقدمة وفق معايير الهيئة التنظيمية المالية على 3 أخطاء في مطابقة الحقول، مما أدى إلى استدعاء البنك من قبل الجهة الرقابية — وكان أحد الأسباب الجذرية هو أن “الكود الذي يبدو صحيحًا” الذي يولده الذكاء الاصطناعي لم يقم أحد بمراجعته.
الاتصالات/مشغلو الشبكات. في إحدى الشركات الإقليمية التي عملنا معها، قام فريق التسويق في أحد الفروع المحلية ببناء أداة “الاستعلام السريع عن ملف العميل” باستخدام Bolt، حيث تتيح إدخال رقم الهاتف لعرض سجل الباقات والشكاوى والتوصيات خلال آخر 90 يومًا — وهو ما يصطدم مباشرةً بحدود صلاحيات الاستعلام المنصوص عليها في قانون حماية المعلومات الشخصية. في بيئة مشغلي الاتصالات، يمكن للمولّد أن يُستخدم في بناء “منصة عمل لمديري الحسابات” أو “واجهة أمامية لقاعدة المعرفة لخدمة العملاء” أو “إعداد الحملات التسويقية”، لكنه لا يجوز أن يقترب إطلاقًا من أنظمة الفوترة، أو إصدار الفواتير، أو الاستعلام عن تفاصيل المكالمات — فهذه هي شريان الحياة للمشغل، وأي خطأ فيها يتحول إلى خبر يملأ وسائل الإعلام.
التصنيع. أنظمة MES/ERP، والتكامل والربط، وفحص الجودة، وإعداد التقارير هي أنظمة أساسية، ولا يمكن للمولّد أن يعمل إلا على الأطراف — لوحات ورش العمل، والاستعلام عن مسارات التصنيع، وعروض توضيحية لكفاءة المعدات OEE. ممنوع تمامًا الاقتراب من: الخوارزميات الأساسية لجدولة الإنتاج، وقواعد الحكم على الجودة، وواجهات التسوية مع نظام ERP العلوي. تم إخفاء هوية الحالة: مورّد قطع غيار سيارات (توجد عدة حوادث استدعاء مماثلة موثقة في المعلومات العامة، وتفاصيل الحالة مستخلصة من إعلانات الاستدعاء العامة ومن مشاريع شاركت فيها شخصيًا، لتوضيح منطق اتخاذ القرار، ولا تشير إلى شركة محددة) كلّف فريق تقنية المعلومات باستخدام Bolt لبناء “لوحة عرض أمامية لنموذج AI لفحص الجودة” — كان القصد فقط عرض صور العينات ونتائج الحكم، لكن أثناء العرض الأمامي، تم ترميز عتبة الثقة الأصلية لاستدلال نموذج AI بشكل ثابت داخل العميل، وقام موظف الأعمال بتغييرها عن طريق الخطأ من 0.85 إلى 0.6، وخلال 3 أيام، تم تصنيف أكثر من 200 قطعة كان يجب أن تُحكم عليها بأنها “غير مطابقة” على أنها “مطابقة” وتدفقت إلى خط الإنتاج النهائي، وانتهى الأمر باستدعاء 3 دفعات. الخطأ الأكثر شيوعًا لدى شركات التصنيع المتوسطة هو تسليم “الواجهة الأمامية لنموذج AI لفحص الجودة” أيضًا إلى المولّد — فما بعد قواعد فحص الجودة هو استدعاء المنتج، والخطأ مرة واحدة يعني إعلان استدعاء.
ثامنًا: الدروس المستفادة لصناع القرار
الدرس الأول: ارسم خريطة طبقات التطبيقات أولاً، ثم تحدّث عن شراء الأدوات.
استخدم المصفوفة التي عرضناها في القسم الثاني، وضع تطبيقاتك الحالية والمخططة فيها وفق بُعدي التعقيد وحساسية البيانات. ستكتشف فوراً: أيها يقع في المنطقة الخضراء ويمكن تسليمه بأمان لمولّدات الكود لتسريع العمل، وأيها في المنطقة الحمراء لا يجوز الاقتراب منه. هذه الخريطة وحدها كفيلة بصدّ عشرات المقترحات الاندفاعية مثل “إعادة بناء الأنظمة الأساسية باستخدام المولّدات”، وفي الوقت نفسه تمنح الأجزاء التي تستحق التسريع مبرراً واضحاً للانطلاق.
الدرس الثاني: تعامل مع نقل البيانات عبر الحدود والامتثال الأمني كشرط دخول، لا كإجراء لاحق.
قبل شراء أي أداة ذكاء اصطناعي تلامس الكود أو البيانات، مرّرها أولاً على هذين المعيارين. مشكلة أدوات مثل Trae ليست في “هل تعمل؟” بل في “هل يمكن استخدامها في بيئتك التنظيمية؟” هذا القرار يجب أن يُتخذ مسبقاً، وثمن الخطأ فيه هو إصلاحات لاحقة، أو إنذارات رسمية، أو حتى إيقاف الخدمة. عملياً: أدخل شراء أدوات الذكاء الاصطناعي في مسار اعتماد مشترك مع فرق الأمن والشؤون القانونية، وحدد قائمة صريحة بـ”مسموح لدخول بيئة التطوير” وقائمة أخرى بـ”يتطلب موافقة حالة بحالة”.
الدرس الثالث: وفر للجهات التشغيلية مساراً امتثالياً واضحاً، وإلا ستزداد التطبيقات الظلّية.
نسبة 80% التي ذكرناها في القسم الثالث تُثبت أن المنع لا يجدي. بدلاً من انتظار الجرد عند وقوع مشكلة، اعمل الآن على بناء المسار الذي طرحناه في القسم الخامس: مولّدات معتمدة، تسجيل خفيف، توجيه حسب حساسية البيانات، وفحص تلقائي. دع الجهات التشغيلية تتحرك بسرعة، لكن كل أداة على القائمة. بهذه الطريقة تحوّل الـ IT الظلّي من منطقة عمياء غير مراقبة إلى أصول قابلة للتدقيق.
الدرس الرابع: غيّر مقياس النجاح، وإلا ستذهب الميزانية كلها إلى الأدوات وتبقى العقدة كما هي.
هذه الرسالة موجّهة إلى الإدارة العليا. كثير من مجالس الإدارة اليوم تقيس نجاح التحول بالذكاء الاصطناعي عبر “عدد تراخيص الذكاء الاصطناعي المشتراة” أو “نسبة تسريع التطوير”. لهذا النوع من المقاييس نتيجة واحدة: الميزانية تتدفق نحو شراء الأدوات، بينما العقد الحقيقية التي تعطّل التسليم — مثل فريق مراجعة نقل البيانات عبر الحدود، فريق الامتثال للأمن السيبراني، هندسة الأمان، ومطابقة الحسابات والتدقيق — تبقى بلا تمويل ولا كوادر. النتيجة: تراكم الأدوات، وبطء التسليم كما هو. لعلاج مشكلة “نعرف المشكلة لكننا لا نتحرك”، يجب تغيير المقاييس من الأعلى. أضف مقاييس مثل: “كم نسبة التطبيقات التي تغطيها قناة الامتثال”، “كم انخفض عدد التطبيقات غير المصرح بها من N إلى M”، “كم أصبحت المدة من النموذج الأولي إلى الإطلاق المتوافق”. عندما تتغير المقاييس، ستتدفق الميزانية إلى الأماكن التي تعطّل العمل فعلًا.
مراجعة ذاتية (لا تجمّل الإجابة): كم تطبيقًا بنته أقسام العمل بنفسها باستخدام الذكاء الاصطناعي في شركتك الآن؟ هل تستطيع أن تحدد الرقم؟ كم من هذه التطبيقات تتعامل مع طلبات، أرقام هواتف، أو عناوين؟ بيئة التطوير الذكية التي ثبّتها لمهندسيك افتراضيًا، إلى أين تُرسل البيانات؟ هل تحققت؟ الأرقام التي تستخدمها لقياس نجاح الذكاء الاصطناعي — هل تكافئ “شراء الأدوات” أم “تسريع التسليم”؟ إذا شعرت بالتردد في إجابة واحدة من هذه الأسئلة، فالمخاطر التي سيتناولها هذا المقال قد بدأت بالفعل في شركتك.
الخطوة التالية
هذه هي المقالة الخامسة من سلسلة من 18 مقالًا حول “تحول هندسة البرمجيات في عصر الذكاء الاصطناعي”. لقد رأينا كيف تعمل مولّدات التطبيقات وبيئات التطوير المتكاملة بالذكاء الاصطناعي على خفض حاجز “بناء تطبيق” إلى مستويات غير مسبوقة، ولماذا لا ينهار حاجز التعامل مع البيانات بنفس الطريقة.
المقالة التالية (السادسة) تنظر إلى اتجاه معاكس يتحول إلى إجماع في الصناعة: التطوير الموجّه بالمواصفات (Spec-Driven Development). لماذا تتجه GitHub Spec Kit وClaude Code وAWS Kiro وAGENTS.md من OpenAI جميعًا نحو “توثيق المتطلبات كتابيًا أولًا، ثم ترك الذكاء الاصطناعي ينفّذ”. في القسم السابق، أوضحنا أن معدل الثغرات في الكود المولّد بالذكاء الاصطناعي أعلى من الكود البشري، والتطوير الموجّه بالمواصفات هو أحد العلاجات لهذه المشكلة: تحويل المتطلبات الغامضة إلى مواصفات قابلة للفحص، وعندها فقط يصبح من الممكن وضع الذكاء الاصطناعي تحت المجهر.
ملاحظة حول السلسلة: تتابع هذه السلسلة أحدث التطورات في أدوات البرمجة بالذكاء الاصطناعي، والهياكل التنظيمية، ونماذج هندسة البرمجيات. تابع السلسلة للحصول على رؤى محدّثة باستمرار.
تريد تطبيق هذه الرؤى في شركتك؟
عندما تدخل مولّدات التطبيقات إلى المؤسسات، عادةً ما تحتاج إلى حل عدة أسئلة محددة: أي التطبيقات والبيانات يمكن تسليمها للإدارات التجارية لتوليدها ذاتيًا، وأيها يجب أن تبقى تحت سيطرة تقنية المعلومات، وإلى أي مدى تحتاج عمليات التحقق الحالية إلى التعزيز، وما هي المؤشرات التي يجب استخدامها لقبول التجارب الأولية.
حاليًا، نقدم ثلاثة أنواع من التعاون:
- التدريب الداخلي للمؤسسات: بالاعتماد على مشاريعك الفعلية، يتم تنفيذ عملية اختيار أدوات توليد التطبيقات، وتحديد حدود الاستخدام، ومسارات الامتثال، وتصميم آليات الحوكمة.
- الاستشارات المتخصصة: التركيز على قرار محدد وواضح، مثل “هل يجب منح الإدارات التجارية صلاحية استخدام مولّد التطبيقات المعتمد (Sanctioned App Generator)؟”، أو تحديد أولويات المعالجة بعد جرد التطبيقات غير الرسمية (Shadow Apps).
- جلسات للإدارة العليا ومحاضرات عامة: تدور حول أدوات البرمجة بالذكاء الاصطناعي، وحوكمة التطبيقات غير الرسمية، وتحول المؤسسات إلى الذكاء الاصطناعي، وحوكمة المؤسسات.
يقدّم المقال إطارًا عامًا قابلاً للتطبيق، لكن التنفيذ الفعلي يتطلب إعادة تصميم بناءً على حدود البيانات في المؤسسة، والمتطلبات التنظيمية، ودرجة النضج الهندسي، وسير عمل التسليم الحالي. للتعاون، يمكنكم التواصل عبر coach@iaiuse.com.
قراءة موسّعة: “منهجية العلامة المرئية v1.0” (تعلّم الذكاء الاصطناعي ببطء 187)، والتي تستعرض بشكل منهجي إطارًا من 7 خطوات للتحول المؤسسي في مجال الذكاء الاصطناعي.
حول هذه السلسلة
“تحول هندسة البرمجيات في عصر الذكاء الاصطناعي” هي سلسلة بحثية موجهة إلى مدراء المعلومات (CIO)، ومدراء البيانات (CDO)، ومدراء التكنولوجيا (CTO)، ومسؤولي التحول الرقمي في قطاعات الاتصالات، والمالية، والتصنيع، والتجارة الإلكترونية. تتكون السلسلة من 18 مقالًا، وتركز على كيفية تأثير أدوات البرمجة بالذكاء الاصطناعي، ومولّدات التطبيقات، وحوكمة التطبيقات غير الرسمية على عمليات تسليم البرمجيات، والهياكل التنظيمية، وآليات الحوكمة، ومقاييس الإدارة.
سلسلة تتتبع باستمرار الأوراق الأكاديمية ومواد البائعين وتقارير الصناعة، وتضم قاعدة أبحاث تراكمية تتجاوز 200 وثيقة، مع تمييز مستويات الأدلة لكل حكم رئيسي، والتفريق قدر الإمكان بين الحقائق المُتحقق منها، وادعاءات البائعين، وملاحظات الصناعة، واستنتاجات الكاتب.
لديّ خبرة تمتد لنحو 8 سنوات في الاستشارات المؤسسية الكبرى والتحليل التجاري، حيث عملت سابقًا في IBM وشاركت في مشاريع تتعلق بالاتصالات والتمويل والتأمين والتصنيع. بعد ذلك، واصلت العمل في الخطوط الأمامية لتطوير منتجات المشغّلين ومنتجات الإنترنت وتطبيقات الذكاء الاصطناعي، في مجالات تحليل المتطلبات وتصميم المنتجات والتنفيذ عبر الفرق.
الأحكام الواردة في هذه السلسلة حول اختيار الأدوات، وحدود استخدام مولّدات التطبيقات، وتصميم مسارات الامتثال، وهندسة الحوكمة التنظيمية، مستمدة من هذه الممارسات العملية، مع التحقق المتبادل من خلال الأبحاث المنشورة ودراسات الحالة في الصناعة. تم إخفاء هوية أي محتوى يتعلق بمشاريع محددة؛ وبعض سيناريوهات الصناعة هي استنتاجات نموذجية قائمة على مشكلات شائعة، مع الإشارة إلى المراجع في نهاية المقال.
خلف هذا الحساب يوجد في الواقع فريق صغير — أنا وزميل أو زميلان نتعاون معهم منذ فترة طويلة، نتولى كلٌّ منا جانبًا: أبحاث أدوات البرمجة بالذكاء الاصطناعي، ودراسة حالات الحوكمة التنظيمية، وجلسات التدريب الإرشادي. معظم المشاريع التي نذكر فيها أننا “رافقنا المؤسسات في خوضها” هي مشاريع قمنا بتسليمها معًا. ما زلنا لا نذكر أسماء العملاء أو الحدود التنظيمية المتعلقة بهم، مع الإبقاء على إخفاء الهوية لإتاحة المجال لزملاء التعاون المستقبليين.
المراجع (تم التحقق منها جميعًا، مع تمييز مستوى الأدلة + الموقف لكل مرجع)
Eric Simons، الرئيس التنفيذي لشركة StackBlitz (LinkedIn، نهاية السنة المالية 2026). يستخدم ثلاثة أرباع شركات فورتشن 500 أداة Bolt.new، وقد شهدت الإيرادات السنوية المتكررة على مستوى المؤسسات نموًا بمقدار عشرة أضعاف مقارنة بالعام الماضي. تصريح رسمي من الشركة (بمنظور البائع). https://www.linkedin.com/posts/eric-simons-a464a664_a-growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV
Sacra / Growth Unhinged (2025). تتبع نمو الإيرادات السنوية المتكررة لـ Bolt.new (حوالي 5 أشهر للوصول إلى 40 مليون دولار من الإيرادات السنوية المتكررة، وحوالي 5 ملايين مستخدم، وهو ثاني أسرع نمو في التاريخ بعد ChatGPT). بحث/تتبع من الدرجة الأولى. https://sacra.com/c/bolt-new/ و https://www.growthunhinged.com/p/boltnew-growth-journey
Taskade (2026-03) / Business Insider. جولة تمويل من الفئة B لشركة StackBlitz بقيمة 105.5 مليون دولار أمريكي في يناير 2025، بقيمة تقديرية تبلغ حوالي 700 مليون دولار أمريكي؛ إطلاق Bolt V2 على منصة Bolt Cloud. تغطية شاملة من التقارير الصناعية.
Forbes / Rashi Shrivastava (2026-06-05). شركة Lovable تجري جولة تمويل جديدة بتقييم 12 مليار دولار أمريكي؛ تجاوزت الإيرادات السنوية المتكررة (ARR) حاجز 500 مليون دولار أمريكي (تأكيد متزامن من TechCrunch في 2026-06-09). تقرير صناعي من الدرجة الأولى. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation
CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). جولة تمويل من الفئة B لشركة Lovable بقيمة 330 مليون دولار أمريكي بتقييم 6.6 مليار دولار أمريكي؛ جولة تمويل من الفئة A بقيمة 200 مليون دولار أمريكي بتقييم 1.8 مليار دولار أمريكي. تقارير صناعية.
ARR.club (2026-07). منحنى نمو إيرادات Lovable السنوية المتكررة: $17M (2025-02) ← $100M (2025-07) ← $200M (2025-11) ← $400M (2026-02) ← $500M (2026-06)؛ عملاء المؤسسات يشملون Workday وAsana وNVIDIA. تتبّع قطاعي.
Vercel (2026-02-03 المدونة الرسمية “Introducing the new v0”). غيّرت v0 نطاقها من v0.dev إلى v0.app، وتطوّرت من مولّد مكونات واجهة المستخدم إلى مولّد تطبيقات كامل المكدس (بيئة تشغيل معزولة + GitHub + تكامل مع Snowflake/AWS). تصريح رسمي من الشركة. https://vercel.com/blog/introducing-the-new-v0
Taskade (2026-03) / Vercel. مستخدمو v0 تجاوزوا 6 ملايين حتى مارس 2026، مع حوالي 80 ألف فريق نشط شهريًا، وإيرادات سنوية متكررة تقديرية تبلغ حوالي $42M. تقديرات مجمّعة من مصادر القطاع.
Replit (2026-03-13 سجل التحديثات الرسمي + المدونة الرسمية “ما الذي تغيّر من Agent 3 إلى Agent 4”). تم إصدار Agent 4 في 2026-03-11؛ Infinite Design Canvas؛ تغيّر التعاون عبر fork-and-merge إلى مهام متعددة الخيوط داخل نفس المشروع + دمج تلقائي للتعارضات (حل تلقائي لـ 90% منها). تصريح مباشر من المطوّر. https://docs.replit.com/updates/2026/03/13/changelog
AlphaSignal (2026). تقرير تفصيلي حول قدرة Replit Agent 4 على حل 90% من تعارضات الدمج تلقائيًا. تغطية صحفية من القطاع. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically
Atal Upadhyay (2026-03-19). أعلنت Replit في نفس الأسبوع عن جولة تمويل من الفئة D بقيمة 400 مليون دولار، لتصل قيمتها السوقية إلى 9 مليارات دولار (ثلاثة أضعاف خلال ستة أشهر). استنادًا إلى تقارير صناعية متعددة. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything
Cybernews (تحديث 2026-08-01) / The Register (2025-07-28) / segmentationf4u1t (بحث مباشر على GitHub). يستمر Trae في إرسال بيانات العتاد ومعرّفات الأجهزة ونشاط المشاريع إلى خوادم ByteDance حتى عند تعطيل القياس عن بُعد، حيث يصل حجم الدفعة الواحدة إلى 53,606 بايت؛ وخلال 7 دقائق، يتجاوز عدد الاستدعاءات 500 طلب بحجم إجمالي يبلغ حوالي 26 ميغابايت؛ وتؤكد ByteDance رسميًا أن المفتاح يتحكم فقط في جزء إطار عمل VS Code؛ ومن المقرر إطلاق وضع الخصوصية (Privacy Mode) حوالي أغسطس 2026؛ وفي فبراير 2026، ألغت Trae خطة “مجاني للأبد” واعتمدت نظام الدفع القائم على الرموز (token-based paywall). هذا مصدر يجمع بين بحث أمني من الدرجة الأولى وتغطية صحفية متخصصة وبيان رسمي من الشركة المصنعة. https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection 、https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ 、https://github.com/segmentationf4u1t/trae_telemetry_research
OpenAI Tools Hub / Jim Liu (2026-05-18). سجّل Trae 6 ملايين عملية تسجيل خلال 12 شهرًا، مع 1.6 مليون مستخدم نشط شهريًا، وإجمالي 100 مليار سطر من الأكواد المُولَّدة؛ وفي فبراير، أدخل نظام الدفع عبر الرموز (token paywall) ما أنهى وعد “مجاني إلى الأبد”. هذا تقرير تحليلي شامل (بمنظور محلل).
Gartner (مقتبس من Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). بحلول نهاية عام 2026، سيتضمّن 40% من تطبيقات المؤسسات وكلاء ذكاء اصطناعي مخصصين لمهام محددة (مقارنة بأقل من 5% في 2025)؛ وبحلول عام 2035، سيستحوذ الذكاء الاصطناعي الوكيل (agentic AI) على نحو 30% من سوق برمجيات المؤسسات (بقيمة 450 مليار دولار). وثيقة توقعات رسمية. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026
- Gartner(转述自RapidClaw / Hendricks.ai / Arion Research,2025-2026年): از سهماهه اول 2024 تا سهماهه دوم 2025، درخواستهای شرکتها برای مشاوره در زمینه سیستمهای چندعاملی (multi-agent) 1445 درصد رشد داشته است. این موضوع سریعترین زمینه در حال رشد در خدمات مشاوره هوش مصنوعی گارتنر بوده. (تحلیل اولیه/بازگویی)
- Microsoft (پست وبلاگ مرور سال مالی 26، 28 ژوئیه 2026): EY این راهکار را برای 150 هزار کارمند خود به کار گرفته و به 15 درصد افزایش بهرهوری دست یافته است. این شرکت اکنون در حال گسترش آن به 400 هزار کارمند در سراسر جهان است. Atos نیز این راهکار را برای 56 هزار کارمند خود در 54 کشور مستقر کرده و 19 هزار عامل هوش مصنوعی را تحت یک پنل کنترل یکپارچه مدیریت میکند. منبع: سازنده و تأیید مشتری (دیدگاه توأمان تولیدکننده و یکتاپارچهکننده). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Group (2026-06-09 بيان رسمي). وسّعت Atos شراكتها مع Microsoft لنشر Copilot E7 (Frontier Suite) لـ 56,000 موظف، مع توحيد سطح التحكم في Entra/Defender/Intune/Purview/Agent 365، وتشغيل 19,000 وكيل ذكي. تصريح رسمي من الشركة. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos
UpGuard / Cybersecurity Dive (2025). أكثر من 80% من الموظفين وما يقرب من 90% من مسؤولي الأمن يستخدمون أدوات ذكاء اصطناعي غير معتمدة؛ حوالي نصف الموظفين سبق أن لصقوا بيانات سرية في هذه الأدوات (تقارير Mimecast وTeramind المماثلة تتقارب في الأرقام وتؤكد بعضها البعض). بحث أولي + تغطية صحفية متخصصة. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/
Gartner (منقول عن The Hacker News، مايو 2026). 69% من المؤسسات تشتبه أو تؤكد أن موظفيها يستخدمون أدوات ذكاء اصطناعي محظورة؛ فقط 37% لديها سياسات واضحة لاستخدام الذكاء الاصطناعي. نقل عن تغطية صحفية متخصصة.
CodeRabbit (ندوة DORA المشتركة عبر الإنترنت، فبراير 2026 + تقييم Kunal Ganglani الأفقي، يونيو 2026). عدد المشكلات في الكود المُولَّد بمساعدة الذكاء الاصطناعي (بما في ذلك أخطاء المنطق والصحة) يبلغ حوالي 1.7 ضعف ما هو عليه في الكود المكتوب يدويًا بالطرق التقليدية؛ CodeRabbit هو أداة مراجعة الكود بالذكاء الاصطناعي الأكثر تثبيتًا على GitHub/GitLab، مع أكثر من 15,000 عميل مدفوع الأجر، وراجعت 6 ملايين مستودع؛ الرئيس التنفيذي لشركة NVIDIA، Jensen Huang، أيدها علنًا. بحث من المستوى الأول / بيانات من البائعين / تقييمات أفقية من الصناعة. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
Veracode (تقرير 2025 لأمن الكود المولّد بالذكاء الاصطناعي). حوالي 45% من عينات الكود المولّد بالذكاء الاصطناعي تحتوي على ثغرات ضمن قائمة OWASP Top 10 (نسبة فشل الكود المولّد بلغة Java تتجاوز 70%). بحث من المستوى الأول. https://www.veracode.com/blog/genai-code-security-report/ (ملاحظة: ورد في المسودة الأصلية خطأ باعتبار هذه النسبة “45%” مؤشرًا على معدل تبنّي الذكاء الاصطناعي غير المرخّص (Shadow AI)، وقد تم تصحيح هذا الاتجاه — النسبة 45% تشير إلى معدل العيوب في الكود المولّد بالذكاء الاصطناعي، وليست معدل تبنّي الأدوات؛ أمّا معدل تبنّي Shadow AI فترد في تقرير UpGuard بنسبة تتجاوز 80%.)
arXiv:2510.26103. الثغرات الأمنية في الكود المولّد بالذكاء الاصطناعي: تحليل واسع النطاق للمستودعات العامة على GitHub. (دراسة تجريبية مباشرة حول الثغرات الأمنية في الكود المولّد بالذكاء الاصطناعي)
ملاحظة حول منهجية البيانات: جميع الأرقام الكمية في هذا المقال موثّقة المصدر؛ أما الأرقام القليلة التي لم تنشرها الجهات المعنية بشكل رسمي أو لم تخضع للتحقق المستقل (مثل جولة تمويل Lovable البالغة 12 مليار دولار والتي لا تزال قيد التفاوض، والتوقيت الدقيق لحصر 19,000 وكيل لدى Atos) فقد تم التعامل معها بحذر. تم إخفاء هوية حالات العملاء (فريق العمليات التجارية الإلكترونية، مركز التسويق لفرع إقليمي لمشغّل اتصالات، إلخ)، ومصدرها ملاحظات ميدانية واقعية خلال مرافقة عمليات التسليم، ولا تشير إلى شركات محددة. المتطلبات التنظيمية (نقل البيانات عبر الحدود، تصنيف الحماية الأمنية، تسجيل الخوارزميات) تستند إلى اللوائح السارية، ويختلف التطبيق المحدد حسب طبيعة العمل ونوع البيانات؛ ويُرجى الرجوع إلى الرأي القانوني/الامتثالي قبل التنفيذ.
[^1]: بشأن نقل البيانات المهمة خارج الحدود، تنطبق المادة 31 من قانون أمن البيانات (Data Security Law) (تقييم أمن نقل البيانات المهمة)؛ وبشأن نقل المعلومات الشخصية خارج الحدود، تنطبق المواد 38-43 من قانون حماية المعلومات الشخصية (Personal Information Protection Law) (شروط النقل، العقد القياسي، مسار الاعتماد، الموافقة المستنيرة). القواعد المصاحبة: «تدابير تقييم أمن نقل البيانات خارج الحدود» (نافذة في 1 سبتمبر 2022، الأمر رقم 11 لمكتب Cyberspace Space Administration)؛ «تدابير العقد القياسي لنقل المعلومات الشخصية خارج الحدود» (نافذة في 1 يونيو 2023).
[^2]: المادة 21 من قانون أمن الشبكات (Cybersecurity Law) (نظام تصنيف الحماية)؛ «المتطلبات الأساسية لتصنيف حماية أمن الشبكات لتقنية أمن المعلومات» GB/T 22239-2019 (تصنيف الحماية 2.0)؛ «تدابير إدارة تصنيف حماية أمن المعلومات» (الأمر Gong Tong Zi [2007] رقم 43) ينص على أن الأنظمة من المستوى 3 تخضع لتقييم سنوي، والأنظمة من المستوى 2 عادة كل عامين.
[^3]: من المهم التمييز بين ثلاثة أمور مختلفة: ① المادة 24 من “اللوائح المتعلقة بإدارة توصيات الخوارزميات لخدمات المعلومات عبر الإنترنت” (السارية منذ 2022-03-01) (تسجيل توصيات الخوارزميات)؛ ② المادة 17 من “اللوائح المتعلقة بإدارة التركيب العميق لخدمات المعلومات عبر الإنترنت” (السارية منذ 2023-01-10) (تسجيل التركيب العميق)؛ ③ المادة 17 من “التدابير المؤقتة لإدارة خدمات الذكاء الاصطناعي التوليدي” (السارية منذ 2023-08-15) (الخدمات التوليدية الموجهة للجمهور وذات الطابع الرأيي تتطلب تقييمًا أمنيًا — وهذا تقييم وليس تسجيلًا). الكود الذي يولّده مُنشئ التطبيقات لا يُفعّل بالضرورة أيًّا من هذه الفئات الثلاث، لكن إذا كان التطبيق المُنتَج يقدّم خدمات ذكاء اصطناعي توليدي للجمهور أو يتضمن وظائف توصية خوارزمية أو تركيب عميق، فإنه يخضع للأحكام المقابلة.
[^4]: الإطار العام لإدارة التغيير يستند إلى ITIL 4 Change Enablement؛ أما في القطاع المالي، فأحدث مرجع هو “اللوائح الإشرافية على الاستعانة بمصادر خارجية لتكنولوجيا المعلومات في المؤسسات المصرفية والتأمينية” (صادر عن لجنة التنظيم المصرفي والتأمين برقم 46 لسنة 2021) بالإضافة إلى التعميمات ذات الصلة الصادرة عن الإدارة الوطنية للتنظيم المالي في 2024؛ وفي قطاع التأمين، يُضاف “المبادئ التوجيهية لإدارة أعمال المعلوماتية في مؤسسات التأمين” (صادر عن لجنة التنظيم المصرفي والتأمين برقم 17 لسنة 2009، النسخة المعدلة 2024).
[^5]: سجل المعاملات: المصدر الحقيقي هو المادة 31 من قانون التجارة الإلكترونية (يلزم المنصات بتسجيل وحفظ معلومات المعاملات لمدة ≥ 3 سنوات) + المادة 26 من اللوائح الإدارية للإشراف على معاملات الشبكة (تحدد بوضوح 3 سنوات). سجلات التدقيق: تتطلب أنظمة المستوى الثالث في معايير الحماية من التصنيف (等保 2.0) الاحتفاظ بسجلات الشبكة لمدة ≥ 6 أشهر (بموجب المادة 21 من قانون الأمن السيبراني)، لكن الأنظمة الحرجة في القطاع المالي تتطلب عادةً ≥ 5 سنوات وفقًا للمادة 19 من المبادئ التوجيهية لحوكمة البيانات لمؤسسات البنوك والمادة 19 من المبادئ التوجيهية للرقابة الداخلية للبنوك التجارية — 6 أشهر هي الحد الأدنى فقط، وليست القيمة الموصى بها.











