الطريقة البديهية لبناء محاسب ذكاء اصطناعي أن تدعه يرحّل. وهي أيضًا أسرع طريقة لخسارة ثقة لجنة المراجعة. عندما صممنا التنفيذ داخل MFT Intelligence بدأنا من الطرف المقابل: ما الذي يحتاج مراجع حريص أن يراه قبل أن يسمح لآلة بلمس الدفتر أصلًا؟
ثلاث قواعد، مفروضة في الكود
- الوكلاء يُعدّون مسودات فقط. القيد التصحيحي أو تسوية المخزون مقترح مرفق بدليله، لا ترحيل أبدًا.
- الاعتماد بالاسم وبالمستوى. شخص مسجّل يعتمد تحت حد الأهمية النسبية (ISA 320) الخاص بك؛ وعنده أو فوقه يجب أن يعتمد مراجع أو مدير مسجّل ثانٍ. الأسماء غير المسجّلة تُرفض.
- لا يُحذف شيء. القيد الخاطئ يُصحَّح بقيد عكسي جديد يشير إلى الأصل ويُعتمد بنفس المستويات.
دليل أو صمت
كل ملاحظة يُنتجها وكيل يجب أن تستشهد بمعرّفات السجلات التي استرجعها فعلًا في تلك التشغيلة. الملاحظة التي لا تستشهد بشيء، أو تذكر رقمًا ليس في السجلات المستشهد بها، ترفضها بوابة الأدلة وتُعرض للمراجع مشطوبة، لا كحقيقة أبدًا. يُسمح للوكيل بأن يقول إنه لم يجد شيئًا. ولا يُسمح له أن يخمّن.
السجل هو المنتج
كل تشغيلة تسجّل أي نموذج عالج البيانات وهل عمل في السحابة، والتوكنات المستخدمة، والعميل والمهمة، وكل اعتماد وتنفيذ وعكس مع رقم القيد الناتج. يُحتفظ بالسجل سبع سنوات افتراضيًا وفق أعراف أوراق العمل. عندما يسأل مراجع العميل كيف وصل هذا الرقم إلى هنا، تكون الإجابة سطرًا في ملف، لا اجتماعًا.
الحوكمة التي تعيش في وثيقة يُتنازل عنها. والحوكمة التي تعيش في الكود تحتاج طلب دمج.
أين نحن اليوم
وكيلا المراجعة والمدير المالي الافتراضي متاحان كخدمة مُدارة يراجع محاسبو MFT كل مخرجاتها. مسار التنفيذ مبني ومُختبَر؛ والكتابة الفعلية في Odoo تُضبط لكل عميل بعد تهيئة موصّله، وحتى ذلك الحين تُسلَّم المسودات المعتمدة للفريق كقيود جاهزة للترحيل. ويُدمَج الوكيلان نفساهما في خط إنتاج تقارير seg-audit حتى يُراجَع كل تقرير بالذكاء الاصطناعي قبل أن يراجعه إنسان. ولا يُفعَّل هذا الدمج إلا بعد نشر إفصاح معالجة الذكاء الاصطناعي في شروط المنصة.