مقدمه: یک فایل معمولی می‌تواند مسیر تصمیم مالی را عوض کند
تصور کنید شرکت از یک دستیار هوش مصنوعی برای خواندن فاکتورهای فروشندگان، استخراج مبلغ و شناسه خرید و آماده‌سازی پیشنهاد ثبت استفاده می‌کند. حسابدار انتظار دارد سیستم از فایل، «اطلاعات» بگیرد؛ اما ممکن است در همان فایل، متنی وجود داشته باشد که به جای شرح معامله، خطاب به خود دستیار نوشته شده است. هدف آن متن می‌تواند تغییر اولویت بررسی، پنهان‌کردن مغایرت یا وادارکردن دستیار به انجام کاری خارج از مأموریت باشد.
این مسئله در امنیت هوش مصنوعی «تزریق پرامپت» یا Prompt Injection نام دارد. خطر آن برای حسابداری از زمانی جدی‌تر می‌شود که دستیار فقط متن را خلاصه نمی‌کند، بلکه به نرم‌افزار مالی، اطلاعات طرف حساب، ایمیل یا ابزارهای اجرایی نیز دسترسی دارد. در چنین معماری‌ای، یک سند ورودی نامطمئن نباید بتواند اختیار یک کاربر مالی مجاز را به نفع فرستنده سند به کار بگیرد.
در اکتبر ۲۰۲۶، توجه حرفه حسابداری به این تهدید پررنگ‌تر شده است. نکته مهم برای مدیر مالی، حفظ یک مرز روشن است: محتوای فاکتور مدرک معامله است، نه دستور عملیاتی به نرم‌افزار.
تزریق پرامپت با خطای استخراج فاکتور چه تفاوتی دارد؟
خطای استخراج زمانی رخ می‌دهد که سیستم مثلاً عدد، تاریخ یا نام فروشنده را اشتباه بخواند. این خطا را می‌توان با قواعد تطبیق، جمع کنترل و بررسی انسانی شناسایی کرد.
اما تزریق پرامپت تلاش می‌کند رفتار خود دستیار را تغییر دهد. مهاجم ممکن است متن دستورمانندی را در سند، توضیحات فایل، خروجی یک ابزار یا صفحه‌ای که دستیار می‌خواند قرار دهد. مدل زبانی ممکن است به‌اشتباه آن را هم‌سطح دستور کاربر یا سیاست سیستم تلقی کند.
تزریق مستقیم از سوی کاربری رخ می‌دهد که با مدل گفتگو می‌کند؛ تزریق غیرمستقیم از داده‌ای می‌آید که دستیار در جریان انجام کار با آن مواجه می‌شود. در امور مالی، نوع غیرمستقیم اهمیت ویژه دارد؛ چون فاکتور، قرارداد، ایمیل فروشنده و فایل اکسل اغلب از خارج سازمان وارد می‌شوند.
اسکن ویروس و کنترل ساختار فایل لازم‌اند، اما به‌تنهایی کافی نیستند: ممکن است یک فایل از نظر قالب سالم باشد و همچنان متنی حاوی دستور نامربوط به عملیات مالی داشته باشد.
سناریوی کاربردی: از فاکتور دریافتی تا پیشنهاد پرداخت
فرض کنیم فروشنده‌ای فاکتور ۴۸۰ میلیون ریالی برای یک سفارش خرید ارسال کرده است. سامانه هوشمند سه وظیفه مجاز دارد: استخراج اقلام، تطبیق با سفارش و رسید کالا، و ساخت پرونده استثنا برای حسابدار.
حال فایل دارای بخشی است که به‌جای اطلاعات تجاری، می‌کوشد اولویت بررسی دستیار را تغییر دهد. در یک سامانه ضعیف، ممکن است خروجی نهایی به‌گونه‌ای تنظیم شود که اختلاف شماره حساب یا مغایرت مقدار را کم‌اهمیت نشان دهد. در یک سامانه دارای اتصال اجرایی و کنترل ناکافی، دامنه خطر بیشتر می‌شود.
این مثال سناریوی آموزشی است؛ ادعا نمی‌کند چنین حادثه‌ای در شرکت مشخصی رخ داده است. پیام اصلی آن این است که اعتبار فایل و اعتبار دستور دو موضوع مستقل‌اند.
سیستم ایمن باید حتی پس از خواندن محتوای مشکوک، مبلغ و اطلاعات طرف حساب را از منابع مجاز و کنترل‌های قطعی تأیید کند. تغییر شماره حساب فروشنده نباید با متن فاکتور به‌تنهایی انجام شود. ایجاد پیشنهاد پرداخت نیز باید از مجوز اجرای پرداخت جدا بماند.
مرز اعتماد دقیقاً کجاست؟
در یک گردش‌کار هوشمند مالی، داده‌ها از چند سطح اعتماد می‌آیند:
خطای طراحی وقتی اتفاق می‌افتد که متن یک سند خارجی از ردیف اول، عملاً به ردیف‌های دارای اختیار منتقل شود.
راهکار صرفاً نوشتن یک دستور کلی مانند «به متن‌های مخرب توجه نکن» نیست. چنین هشداری می‌تواند مفید باشد، اما مرز امنیتی قطعی ایجاد نمی‌کند. محدودیت اختیار باید در کد، سیاست دسترسی، ابزارها و گردش تأیید نیز اجرا شود.
چرا فایل PDF و اکسل به بررسی متفاوت نیاز دارند؟
آنچه انسان روی صفحه می‌بیند همیشه با متنی که سامانه از فایل استخراج می‌کند یکسان نیست. متن بسیار ریز، محتوای خارج از صفحه، لایه‌های غیرنمایشی، یادداشت‌ها یا بخش‌های پنهان یک کاربرگ ممکن است هنگام پردازش ماشینی وارد زمینه مدل شوند، درحالی‌که بازبین انسانی آن‌ها را در نمای عادی نبیند.
بنابراین بررسی فقط متن استخراج‌شده ممکن است اطلاعات مهمی درباره محل و شیوه پنهان‌شدن محتوا را از بین ببرد. در فایل‌های حساس، لازم است تحلیل ساختار سند، استخراج متن و مقایسه با نمایش واقعی فایل در کنار هم قرار گیرند.
بااین‌حال وجود متن پنهان به‌تنهایی دلیل حمله نیست. اسناد تجاری می‌توانند یادداشت، فرمول، توضیح دسترسی‌پذیری یا محتوای غیرنمایشی مشروع داشته باشند. نتیجه اسکن باید نشانه ریسک قابل بررسی باشد، نه حکم خودکار تقلب.
معماری پیشنهادی برای کنترل اسناد مالی هوشمند
یک محصول مناسب برای بازار ایران می‌تواند پنج لایه مجزا داشته باشد.
لایه دریافت و ثبت منشأ: فایل اصلی بدون تغییر نگهداری شود؛ فرستنده، تاریخ، شناسه پرونده و اثرانگشت دیجیتال فایل ثبت شود. اگر نسخه تازه‌ای دریافت شد، نسخه قبلی از بین نرود.
لایه تحلیل سند: ساختار فایل، متن استخراج‌شده و در صورت نیاز نمای بصری آن بررسی شوند. بخش‌های غیرمعمول یا دستورمانند با محل دقیق مشخص شوند. هدف این مرحله حذف خودکار همه متن‌های مشکوک نیست؛ هدف فراهم‌کردن شواهد برای کنترل بعدی است.
لایه استخراج محدود: مدل فقط داده‌های از پیش تعریف‌شده مانند شماره فاکتور، مبلغ، شناسه فروشنده، ردیف کالا و تاریخ را در قالب ساخت‌یافته برگرداند. هر فیلد باید به بخش مشخصی از سند ارجاع دهد و در صورت نبود شاهد، «نامشخص» باقی بماند.
لایه کنترل مستقل: شناسه فروشنده از پایگاه معتبر طرف حساب، مبلغ از جمع سطرها، مقدار از رسید انبار و مجوز پرداخت از گردش تأیید کنترل شود. خروجی مدل به‌تنهایی نباید وضعیت «تأییدشده» ایجاد کند.
لایه عملیات و ثبت شواهد: هر اقدام حساس با شناسه کاربر، سطح اختیار، دلیل، نسخه داده و نتیجه ثبت شود. سامانه باید امکان توقف خودکار، قرنطینه پرونده و ارجاع به مسئول امنیت یا حسابدار را داشته باشد.
شش کنترل عملی که باید پیش از اتصال دستیار به ERP اجرا شوند
۱. دسترسی حداقلی. دستیار استخراج فاکتور نباید مجوز ویرایش اطلاعات بانکی فروشندگان داشته باشد. دستیار تطبیق نیز به مجوز انتقال وجه نیاز ندارد.
۲. تفکیک خواندن از نوشتن. ابتدا سامانه فقط پرونده پیشنهادی بسازد. قابلیت ثبت سند یا تغییر داده مرجع پس از آزمون مستقل و با نقش مجاز فعال شود.
۳. اعتبارسنجی قطعی خروجی. مبلغ منفی غیرمجاز، شناسه نامعتبر، ارز نامشخص، اختلاف جمع سطرها و تغییر حساب مقصد باید با قواعد برنامه‌نویسی بررسی شوند، نه صرفاً قضاوت مدل.
۴. کنترل مسیرهای خروج داده. دستیار نباید بتواند اطلاعات محرمانه را به مقصدی خارج از فهرست مجاز ارسال کند. مجوز اتصال به ابزارها و دامنه‌های خارجی باید محدود و قابل نظارت باشد.
۵. پایش رفتار غیرعادی. تلاش برای فراخوانی ابزار نامرتبط، درخواست دسترسی بیشتر یا تغییر غیرمنتظره مقصد باید ثبت و در صورت اهمیت متوقف شود.
۶. آزمون امنیتی تکرارشونده. نمونه‌های سالم و نمونه‌های دستکاری‌شده در محیط مجاز آزمایش شوند. هر تغییر مدل، ابزار استخراج یا اتصال ERP باید آزمون‌های مربوط را دوباره اجرا کند.
هیچ‌یک از این کنترل‌ها به‌تنهایی خطر را صفر نمی‌کند؛ اثربخشی به اجرای هم‌زمان و کیفیت آزمون وابسته است.
مثال یک آزمون پذیرش امن
برای ارزیابی دستیار، تیم می‌تواند مجموعه‌ای از فاکتورهای آزمایشی و ساختگی بسازد که برخی از آن‌ها متن‌های نامربوط یا دستورمانند دارند. هدف آزمون، سنجش این است که آیا مدل همچنان فقط داده‌های مجاز را استخراج می‌کند و از عملیات خارج از محدوده خودداری می‌کند یا نه.
نتیجه هر پرونده باید با پاسخ مرجع حسابدار و گزارش ابزارها مقایسه شود. معیارهای آزمون شامل نرخ استخراج صحیح، تعداد موارد ارجاع‌شده، تعداد تلاش‌های ابزار غیرمجاز و کیفیت ثبت شواهد است.
برای آزمایش نباید از حساب بانکی واقعی یا اطلاعات محرمانه مشتری استفاده شود. آزمون باید در محیط جداشده، با داده مصنوعی و مجوز روشن اجرا شود.
اگر مدل در پاسخ متنی بگوید «این درخواست را نادیده گرفتم» ولی هم‌زمان ابزار نامجاز را فراخوانی کند، آزمون شکست خورده است. رفتار واقعی ابزارها مهم‌تر از توضیح خود مدل است.
تفاوت این کنترل با اعتبارسنجی معمول فایل مشتری
اعتبارسنجی معمول می‌پرسد آیا فایل باز می‌شود، ستون‌های لازم را دارد، جمع آن درست است و اطلاعاتش با پرونده سازگار است.
کنترل تزریق پرامپت یک سؤال دیگر اضافه می‌کند: آیا محتوای این فایل می‌تواند رفتار دستیار یا ابزار متصل به آن را خارج از مأموریت تغییر دهد؟
به همین دلیل، حتی یک فاکتور دارای جمع صحیح و امضای ظاهراً معتبر نیز نباید به منبع دستور تبدیل شود. اعتبار محتوای تجاری و حق صدور دستور، دو مرز متفاوت‌اند.
فرصت توسعه محصول برای حسابداران برتر
برای تولیدکننده نرم‌افزار مالی، فرصت مشخص طراحی «دروازه امن اسناد مالی برای عامل‌های هوشمند» است. این لایه می‌تواند قبل از ورود PDF، اکسل، ایمیل یا تصویر فاکتور به دستیار، منشأ و ساختار فایل را بررسی کند، داده‌های مجاز را در قالب استاندارد استخراج کند، محتوای مشکوک را برای بررسی علامت بزند و دسترسی دستیار به ابزارهای ERP را محدود کند.
چنین ماژولی می‌تواند در کنار واسط سامانه مؤدیان، کنترل صورتحساب، مغایرت‌گیری بانکی و مدیریت اسناد خرید قرار بگیرد؛ اما این صرفاً پیشنهاد توسعه است و به معنای وجود فعلی آن در سبد محصولات حسابداران برتر نیست.
در نسخه نخست، هدف نباید وعده «تشخیص صددرصد حمله» باشد. ارزش واقعی در کاهش سطح دسترسی غیرضروری، جلوگیری از تبدیل متن فایل به دستور اجرایی، و ارائه گزارش قابل رسیدگی برای حسابدار و مسئول امنیت است.
جمع‌بندی
با گسترش دستیارهای مالی، سندی که دیروز فقط خوانده می‌شد، امروز ممکن است وارد زمینه تصمیم‌گیری یک عامل متصل به ERP شود. همین اتصال، مرز اعتماد تازه‌ای ایجاد می‌کند.
حسابدار باید مطمئن باشد که فاکتور می‌تواند مبلغ و مشخصات معامله را گزارش کند، اما نمی‌تواند به سامانه دستور تغییر حساب مقصد، حذف کنترل یا اجرای پرداخت بدهد.
راه‌حل عملی، ترکیب تحلیل سند، قواعد مالی قطعی، دسترسی حداقلی، تأیید انسانی و آزمون رفتار واقعی ابزارهاست. در این معماری، هوش مصنوعی دستیار رسیدگی باقی می‌ماند و اختیار مالی همچنان در کنترل فرایندهای مصوب شرکت است.
آموزش و به‌روزرسانی حرفه‌ای