أصبحت عبارة "محاسبة مدعومة بالذكاء الاصطناعي" سطرًا معتادًا على الصفحة الرئيسية لكل منتج فوترة تقريبًا خلال العامين الماضيين، و Wahabooks ليس استثناءً. لكن هناك تصميمين مختلفين تمامًا يختبئان خلف هذه العبارة، والفرق بينهما مهم جدًا إذا كانت دفاترك ستخضع يومًا لتدقيق من زاتكا، أو بنك، أو محاسبك الخاص.
1. التصميمان الكامنان خلف "المحاسبة بالذكاء الاصطناعي"
التصميم الأول، والأكثر شيوعًا، يترك لنموذج لغوي كبير قراءة طلبك، وتحديد ما يجب أن تكون عليه الأرقام، وكتابتها مباشرة في دفتر الأستاذ. الذكاء الاصطناعي هنا هو المحاسب. أما التصميم الثاني فيستخدم الذكاء الاصطناعي فقط لفهم القصد وتنظيم سير العمل — قراءة ما طلبته، وجمع التفاصيل الناقصة، وترتيب الخطوات الصحيحة — بينما تقوم شيفرة برمجية منفصلة، حتمية النتائج ومُختبرة بدقة، بكل عملية حسابية وكل قيد في دفتر الأستاذ. هنا الذكاء الاصطناعي مساعد؛ والشيفرة البرمجية هي المحاسب. كلا التصميمين يُسوَّق باعتباره "محاسبة بالذكاء الاصطناعي". واحد منهما فقط يستحق الثقة بإقرار ضريبة القيمة المضافة.
2. لماذا يفشل "الذكاء الاصطناعي يقوم بالحسابات" مع تراكم الخطوات
النماذج اللغوية احتمالية بطبيعتها. حتى نموذج دقيق بنسبة 95% في خطوة واحدة يتراكم خطؤه بشكل سيئ عبر عملية متعددة الخطوات: خمس خطوات متتالية بدقة 90% لكل منها تنتج دقة إجمالية تقارب 59%، لا 90%. إصدار فاتورة بمبلغ معين، وتطبيق فئة الضريبة الصحيحة، والتقريب إلى الهللة، وتوليد بنية XML متوافقة، وترحيل قيد محاسبي متوازن بنظام القيد المزدوج — كل ذلك خمس خطوات أو أكثر. إن كان النموذج اللغوي يقوم بالحساب في كل خطوة، يتراكم الخطأ تمامًا بهذا الشكل — ويتراكم بصمت، لأن المُخرَج لا يزال يبدو فاتورة عادية ومعقولة.
3. ما الذي تحصل عليه فعليًا من "الحتمية" (Deterministic)
محرك ضريبة القيمة المضافة الحتمي يحسب الضريبة بالطريقة نفسها في كل مرة، بنفس المدخلات — لأنه شيفرة برمجية، لا توزيع احتمالي. وهذا ما يجعل أقدم قاعدة ثابتة في القيد المزدوج قابلة للتطبيق فعليًا في البرمجية، لا مجرد هدف مأمول: يجب أن يتساوى إجمالي المدين مع إجمالي الدائن في كل قيد، دون أي استثناء، لأن محرك الترحيل لن يسمح بوجود قيد غير متوازن أصلاً. النموذج اللغوي المطلوب منه "ترحيل هذا كقيد متوازن" قد يُصيب في معظم الأحيان، ثم يُخطئ في النهاية بطريقة لا يلاحظها أحد حتى المطابقة — أو التدقيق.
4. هذه أيضًا مشكلة تتعلق بزاتكا، لا الدقة فقط
لا تتسامح المرحلة الثانية من الفوترة الإلكترونية إطلاقًا مع أي انحراف في التقريب بين إجمالي الفاتورة وبند الضريبة والمبلغ المُرمّز في رمز QR — وهذا التعارض من أكثر أسباب رفض التصديق شيوعًا. النظام الذي يُولّد فيه نموذج ذكاء اصطناعي هذه الأرقام يُدخل بالضبط نوع المخاطرة غير الحتمية التي صُممت فحوصات التصديق لدى زاتكا لرصدها. يجب أن تكون برمجيات الامتثال مملّة ويمكن التنبؤ بها في طبقة الحسابات، حتى وهي ذكية فعليًا في طبقة الواجهة.
5. السؤال الذي يجب طرحه على أي مزوّد
عندما يخبرك أي مزوّد "محاسبة بالذكاء الاصطناعي" أن الذكاء الاصطناعي يتولى دفاترك، اطرح سؤالًا مباشرًا واحدًا: هل يحسب الذكاء الاصطناعي الرقم بنفسه، أم يستدعي دالة مُختبرة تحسب الرقم؟ إن كانت الإجابة غامضة، أو "النموذج دقيق جدًا"، فاعتبر ذلك إجابتك. المزوّد الذي بنى هذا بشكل صحيح فعليًا سيتمكن من شرح هذا الفصل بوضوح، لأنه اضطر لتصميمه عن قصد — لا يحدث ذلك صدفة.
التصميم خلف Wahabooks
هذا هو مبدأ التصميم الذي بُني عليه Wahabooks: نظام من ثلاث طبقات يضم إجراءات عمل موثّقة، ووكيل ذكاء اصطناعي ينظّمها بالعربية أو الإنجليزية، وأدوات حتمية أسفلها — محرك ضريبة يعمل بوحدات هللة صحيحة، وأداة توليد رمز QR وملف XML بصيغة UBL 2.1 المتوافقين مع زاتكا، وترقيم تسلسلي خالٍ من الفجوات، ومحرك ترحيل بالقيد المزدوج يفرض التوازن في الشيفرة البرمجية، لا بالأمل في أن يكون النموذج مصيبًا. الذكاء الاصطناعي يجعل الاستخدام سريعًا. والشيفرة البرمجية تجعله صحيحًا. إن أردت رؤية الفرق بنفسك، اطلب عرضًا توضيحيًا.