حالة تطبيقية: صور الفواتير والصوت وحدود التفويض في مصروفات مؤسسية

حالة تطبيقية: صور الفواتير والصوت وحدود التفويض في مصروفات مؤسسية

حدود الحالة الافتراضية

تستخدم شركة افتراضية بوابة تعتمد على الذكاء الاصطناعي لتحويل صور فواتير ومقاطع صوتية قصيرة إلى مسودات مصروفات. لا تعتمد الحالة على تنفيذ هجوم عملي، بل على تقييم ضوابط التفويض ومصدر البيانات والتكلفة ضمن بيئة تجريبية آمنة. تستلهم جوانبها من قسم Multimodal & Non-Text Attack Surfaces ومن Economic and Resource-Exhaustion Attacks وAgentic System Attack Vectors في OWASP GenAI Red Teaming Manual v1.0، أكتوبر 2026. لا تمثل حادثة منشورة أو شركة بعينها، ولا تدعي أن الوثيقة الأصلية فرضت مسار تنفيذ محاسبي واحداً. الهدف فهم كيف يؤدي تغير الوسيط من صورة أو صوت إلى نص إلى حدود ثقة جديدة، وكيف يُثبت منع العمليات غير المأذونة دون استخدام بيانات أو معاملات حقيقية.

الوظائف المسموحة

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

مكونات النظام

تتصل واجهة الرفع بخدمة تخزين ملفات وخدمة OCR وطبقة تنسيق ونموذج استدلال ونظام فواتير تجريبي. تمر البيانات من صورة إلى نص مستخرج، ثم إلى حقول مهيكلة، ثم إلى شاشة مراجعة، ثم إلى أداة CreateExpenseDraft، ويمكن أن تضيف خدمة الصوت ملاحظة ملحقة. ينبغي أن يسجل جرد AI-BOM إصدارات خدمة الاستخراج والنموذج ومخططات أدوات المحاسبة ومواقع التخزين وسياسات نقل البيانات إلى مورد خارجي. لا يكفي تسجيل اسم المساعد دون بيان الخدمات التي قد تحتفظ بنسخ من الملفات أو تتعامل مع معرفات الحسابات. تضاف حدود ثقة لكل انتقال بين أصل معلوماتي وقرار أو إجراء.

الصورة بوصفها مصدر معلومات

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

التسجيل الصوتي مصدر إضافي

قد يحمل التسجيل شرحاً من موظف أو من شخص آخر داخل ملف مرفق، ولا يعني أن كل جملة فيه أمر صادر من صاحب الحساب. ينبغي أن تستخدمه الخدمة لتكوين ملاحظة قابلة للمراجعة، وأن لا تسمح باعتماد عملية أو تغيير مستفيد استناداً إلى تفريغ صوتي فقط. يمكن اختبار ذلك في بيئة حسابات مصطنعة بملفات مسجلة خصيصاً للتجربة، مع حماية حقوق المتحدثين وعدم رفع تسجيلات أشخاص غير مشاركين إلى مورد خارجي. يُسجل معرف الملف ونسخة خدمة التفريغ وكيفية إدخال النص إلى مسودة المصروف، وأين تتحقق موافقة المستخدم على المعلومات التي ستدخل إلى نظام الأعمال.

المراقبة في مسار التحويل

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

فرضية التحقق من التفويض

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

قواعد حجم الملفات والتكلفة

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

خط أساس للطلب الصحيح

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

ملاحظة جودة منفصلة

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

ملاحظة أمن مستقلة

في اختبار آخر قد يظهر أن موظفاً منخفض الصلاحية يستطيع طلب اعتماد مسودة اصطناعية على المستوى التقني، لكن الخدمة الخلفية ترفضه وفق الدور. هنا سجل النموذج أو الواجهة قد يحتوي اقتراحاً غير مناسب، بينما ثبت نجاح ضابط المنع. إذا سمح ERP فعلاً بتغيير حالة المسودة دون موافقة مستخدم مخول، تصبح هناك قضية تفويض مؤكدة في البيئة التجريبية، تحتاج إلى احتواء وتحقيق في سبب عدم تمرير هوية المستفيد أو عدم فحص الدور. لا ينبغي خلط الحالتين ضمن عنوان واحد مثل «النظام مُخترق»، ويجب أن تحمل كل نتيجة سجل تنفيذ مستقل وحدود تأثير واضحة.

مخاطر تخزين النسخ

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

حساب نطاق الأثر

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

خطة تحسين الضوابط

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

تقييم المورد الخارجي

قد يكون تحويل الصور لدى خدمة سحابية والنموذج لدى أخرى ونظام المحاسبة لدى المؤسسة. ينبغي أن يعرف مالك التطبيق مسار البيانات والمكونات التي قد تتغير دون نشر محلي وما الذي يُرسل إلى كل طرف. يمكن اختبار سياسات التطبيق المحلية ومنع الأدوات مع الاحتفاظ بقيود الرؤية داخل المزود، ولا يحق الادعاء بفحص أوزان نموذج أو آليات OCR مغلقة لم تُكشف. عند تحديث المورد يُراجع أثر التغيير على دقة الحقول وقواعد السلامة والتكلفة وعلى مدى صلاحية نتائج اختبار سابق، مع عدم تحويل ذلك إلى طلب بإجراء فحص خارج تصريح الاستخدام.

تمرين حسابات مصطنعة

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

خاتمة الحالة ومصدرها

هذه الحالة تطبيق تخيلي من سيادة AI يستفيد من موضوعات OWASP GenAI Red Teaming Manual v1.0، أكتوبر 2026، لا سيما 4.4 Multimodal & Non-Text Attack Surfaces و4.5 Agentic System Attack Vectors و4.6 Economic and Resource-Exhaustion Attacks وPhase 7 Evaluation. لا تمثل عملية موثقة في مؤسسة حقيقية، ولا هي وصف رسمي من OWASP لتطبيق مالي محدد. الهدف بيان طريقة تأمين انتقال الوسائط إلى القرارات والأدوات وربط الأدلة بالسلطة والأثر، وتُحترم رخصة المصدر CC BY-SA 4.0 عند اقتباس أو تكييف المادة الأصلية.