اگر امروز مدیریت پرداخت‌های شرکتتان را به یک عامل هوش مصنوعی بسپارید، احتمالاً اولین کلاهبرداری مالی را با لبخند تأیید خواهید کرد. ایمن‌ترین راه برای استفاده از AI در امور مالی این است که اجازه دهید مدل داده‌ها را بخواند، اما هرگز اجازه ندهید پرداخت را تأیید کند. با جداسازی لایه استخراج داده از لایه تصمیم‌گیری، سیستم ریسک اینکه یک مدل زبانی (LLM) به‌طور تصادفی یک فاکتور جعلی را تأیید کند یا مبلغ کل را اشتباه محاسبه کند، به‌طور کامل از بین می‌رود.
بسیاری از دموهای اتوماسیون هوش مصنوعی به محض تبدیل یک PDF به JSON به پایان می‌رسند. اما در یک محیط تجاری واقعی، «مایل آخر» — یعنی همان مرحله تأیید و اعتبارسنجی — جایی است که بیشترین ریسک نهفته است. این چالش‌ها اغلب به دلیل نادیده گرفتن موارد لبه‌ای رخ می‌دهند، موضوعی که در بررسی نقاط کور جریان‌های کاری توسعه‌دهندگان به تفصیل مورد بحث قرار گرفته است. بخش دشوار کار، تصمیم‌گیری در مورد این است که چه کسی پرداخت را تأیید کند و جلوگیری از این اتفاق است که یک ایمیل جعلی با مضمون «ما جزئیات بانکی خود را تغییر داده‌ایم» مستقیماً به مرحله پرداخت برسد. این راهنمای پیاده‌سازی نشان می‌دهد چگونه می‌توان سیستمی ساخت که در آن کد، و نه یک پرامپت، قدرت وتوی نهایی را در اختیار داشته باشد.
تصور کنید ایمیل یک تأمین‌کننده هک شده و یک هکر فاکتوری با جزئیات بانکی به‌روزرسانی شده ارسال می‌کند. یک عامل هوش مصنوعی استاندارد ممکن است این درخواست را ببیند و به‌سادگی رکورد را به‌روزرسانی کند. اما الگوی n8n با اجرای یک سری بررسی‌های قطعی (Deterministic) که هیچ مدل زبانی نمی‌تواند آن‌ها را دور بزند، جلوی این اتفاق را می‌گیرد.
لایه استخراج داده
این گردش‌کار با یک تریگر Gmail آغاز می‌شود که ایمیل‌های دارای پیوست PDF را شناسایی می‌کند. گردش‌کار با استفاده از گره Execute Workflow، برای هر ایمیل یک بار خودش را فراخوانی می‌کند. این تفکیک بسیار مهم است؛ زیرا اگر در یک اجرای دسته‌ای، پنج فاکتور پردازش شوند و سومی با خطا مواجه شود، از ایجاد یک وضعیت نیمه‌پردازش‌شده و آشفته جلوگیری می‌شود. اجرای مجزا برای هر فاکتور به این معناست که شما یک اجرای قرمز (خطا) دارید که می‌توانید به‌تنهایی آن را دوباره امتحان کنید.
سپس فایل PDF در گوگل درایو ذخیره شده و سیستم از مدل Claude برای استخراج داده‌ها بر اساس یک اسکیما (Schema) ثابت استفاده می‌کند. پرامپت از مدل می‌خواهد موارد زیر را استخراج کند: نام تأمین‌کننده، کد مالیاتی، شماره فاکتور، تاریخ‌ها، ارز، مبلغ خالص (Subtotal)، مالیات، مبلغ کل، شماره سفارش خرید (PO)، جزئیات بانکی و اقلام تفکیکی (Line Items).
به‌طور حیاتی، از مدل خواسته می‌شود دو فیلد متادیتای خاص را ارائه دهد:
- is_invoice: این فیلد مشخص می‌کند که آیا سند واقعاً یک صورت‌حساب است یا صرفاً یک پیش‌فاکتور، صورت‌حساب کلی، رسید یا یادآوری پرداخت. درخواست از مدل برای شناسایی این مورد در همان ابتدا، مانع از تبدیل اسناد غیرمالی به فاکتورهای پرداخت می‌شود.
- confidence: یک امتیاز خودارزیابی بین ۰ تا ۱. اگرچه این امتیاز کاملاً کالیبره نیست، اما مقادیر بسیار پایین به‌طور قابل‌اعتمادی اسکن‌های تار یا قالب‌های غیرمعمول را برای بررسی انسانی علامت‌گذاری می‌کنند.
اعتبارسنجی قطعی
پس از استخراج داده‌ها، گردش‌کار به یک گره کد (Code Node) منتقل می‌شود. برای جلوگیری از باگ‌های رایج «عدم تطبیق رشته‌ای» (String Mismatch) — جایی که مثلاً "Acme Inc" با "ACME, Inc." مطابقت نمی‌کند — سیستم از توابع نرمال‌سازی استفاده می‌کند.
یک تابع به نام norm تمام رشته‌ها را به حروف کوچک تبدیل کرده و کاراکترهای غیرالفبایی و غیرعددی را حذف می‌کند. تابع nameKey به‌طور خاص پسوندهای قانونی مانند "incorporated"، "inc"، "llc"، "ltd"، "gmbh"، "corp" و "plc" را حذف می‌کند تا "Acme Inc" و "ACME, Inc." با هم مطابقت یابند. برای شماره فاکتورها، کدهای مالیاتی و شماره‌های PO، تابع idKey آن‌ها را به حروف بزرگ تبدیل کرده، کاراکترهای غیرالفبایی را حذف می‌کند و صفرهای ابتدایی را می‌برد.
تأمین‌کنندگان ابتدا بر اساس کد مالیاتی و در مرتبه دوم بر اساس نام مطابقت داده می‌شوند، زیرا نام‌ها ممکن است تغییر کنند اما کدهای مالیاتی معمولاً ثابت می‌مانند.
بررسی‌های امنیتی و دقت
اعتبارسنجی در چندین بعد حساس و استراتژیک انجام می‌شود:
- هویت و دامنه: سیستم بررسی می‌کند که آیا تأمین‌کننده در لیست فعال است و آیا ایمیل از دامنه‌ای ارسال شده که در رکورد تأمین‌کننده ثبت شده است یا خیر. اگر فاکتوری از
acme-billing.coارسال شود در حالی که در رکورد سیستمacme.comثبت شده است، تراکنش فوراً متوقف و نگه داشته می‌شود. - تشخیص کلاهبرداری: اگر جزئیات بانکی با رکورد ذخیره شده برای تأمین‌کننده متفاوت باشد، فاکتور متوقف شده و به عنوان کلاهبرداری احتمالی در پرداخت علامت‌گذاری می‌شود. برای ارتقای این سطح از امنیت، می‌توان از روش‌های پیشرفته‌تری مانند هشینگ SHA-256 برای تأیید پرداخت‌های ایجنت‌ها استفاده کرد تا صحت تراکنش‌ها تضمین شود. سیستم همچنین یک Regex روی متن ایمیل و یادداشت‌های مدل اجرا می‌کند تا عباراتی مانند «updated bank details» یا «remit to our new account» را پیدا کند. این کار باعث شناسایی کلاهبرداری‌های ایمیلی تجاری (BEC) می‌شود که معمولاً با همین عبارات دقیق اعلام می‌شوند.
- محاسبات ریاضی: کد بررسی می‌کند که مجموع مبلغ خالص به‌همراه مالیات برابر با مبلغ کل باشد و اقلام تفکیکی با مبلغ خالص مطابقت داشته باشند (با در نظر گرفتن یک تلورانس کوچک برای گرد کردن اعداد). این کار خطاهای تک‌رقمی را که در مدل‌های زبانی رایج است، شناسایی می‌کند.
- جلوگیری از تکرار: سیستم از سه روش بررسی می‌کند: تطبیق تأمین‌کننده و شماره فاکتور در لاگ؛ تطبیق تأمین‌کننده و مبلغ در بازه زمانی N روز (برای شناسایی فاکتورهای ارسالی مجدد با شماره‌های جدید)؛ و بررسی اینکه آیا صورت‌حساب از قبل در QuickBooks وجود دارد یا خیر.
- تطبیق سفارش خرید (PO): سیستم بررسی می‌کند که آیا PO در لیست است، هنوز باز است، برای تأمین‌کننده درست صادر شده و ارز آن یکسان است یا خیر. سپس تمام مبالغی که قبلاً در برابر آن PO تأیید شده‌اند را کسر می‌کند تا اطمینان حاصل شود که سه فاکتور مختلف نمی‌توانند هر کدام در یک PO جای بگیرند که فقط فضای یک فاکتور را دارد.
منطق تأیید
مسیردهی توسط دو آرایه مدیریت می‌شود: holds (هر چیزی که باعث توقف فاکتور تا بررسی انسانی شود) و notes (هر چیزی که باعث شود فاکتور به جای تأیید خودکار، به یک تأییدکننده انسانی ارسال شود).
اگر فاکتوری با PO مطابقت داشته باشد، زیر سقف autoApproveLimit باشد و هیچ یادداشتی نداشته باشد، وضعیت آن روی auto_approve قرار می‌گیرد. در غیر این صورت، به مسیر approve یا hold هدایت می‌شود. هر بررسی به جای ارسال یک کد خطا، یک جمله ساده به زبان انگلیسی را در این آرایه‌ها قرار می‌دهد. این جملات مستقیماً به پیام Slack و لاگ‌ها می‌روند تا تأییدکننده دلیل رسیدن فاکتور به دست خود را بخواند (مثلاً به جای ERR_PO_MISMATCH می‌خواند: «شماره سفارش خرید با رکوردها مطابقت ندارد»).
برای حفظ تفکیک وظایف (Separation of Duties)، سیستم دو قانون سخت‌گیرانه را با استفاده از عملیات send-and-wait در گره Slack اجرا می‌کند:
۱. پرداخت‌های بالاتر از یک آستانه دوم، نیاز به تأیید نفر دوم دارند.
۲. اگر شخص تأییدکننده معمول، همان کسی باشد که PO را صادر کرده است، درخواست به یک تأییدکننده جایگزین ارسال می‌شود. کسی که کالا را سفارش داده است، نباید همان کسی باشد که پرداخت را تأیید می‌کند.
مدیریت خطاها
همه موارد توقف (Hold) یکسان برخورد نمی‌شوند. یک فاکتور متوقف شده یکی از سه واکنش زیر را تحریک می‌کند:
- ریسک کلاهبرداری: یک هشدار Slack به بخش مالی ارسال می‌شود، اما سیستم هرگز به فرستنده ایمیل پاسخ نمی‌دهد. پاسخ دادن به یک رشته ایمیل هک شده، به مهاجم تأیید می‌کند که کسی در حال خواندن پیام‌ها است.
- خطاهای تأمین‌کننده: برای شماره‌های PO ناشناخته یا مبالغی که با هم نمی‌خوانند، سیستم یک ایمیل خودکار و محترمانه ارسال می‌کند و درخواست فاکتور اصلاح‌شده می‌نماید.
- بررسی کلی: سایر موارد در Gmail برچسب‌گذاری شده و برای بررسی دستی ثبت می‌شوند.
این معماری، صندوق ورودی Gmail را با استفاده از برچسب‌ها (تأیید شده، متوقف شده، رد شده) به یک تخته وضعیت تبدیل می‌کند، در حالی که تمام فاکتورهای نهایی تنها پس از عبور از هر یک از بررسی‌های سخت‌افزاری (Hard-coded)، مستقیماً به QuickBooks منتقل می‌شوند.
این تغییر در رویکرد، هوش مصنوعی را از یک «تصمیم‌گیرنده» به یک «کارمند ورود داده» تبدیل می‌کند. برای تیم‌های مالی، این بدان معناست که ردپای حسابرسی (Audit Trail) مجموعه‌ای از قوانین شفاف کد است، نه تاریخچه مبهم یک پرامپت. این رویکرد در واقع تبدیل تصمیمات جعبه‌سیاه ایجنت‌ها به شواهد قابل‌حسابررسی است که شفافیت عملیاتی را افزایش می‌دهد. این موضوع اصلی‌ترین مانع پذیرش AI در سازمان‌های بزرگ را حل می‌کند: ناتوانی در توضیح دلیل یک پرداخت خاص برای حسابرسان.
اگر در حال ساخت گردش‌کارهای مشابه هستید، مدل را فقط در بخش استخراج نگه دارید و موارد توقف را به صورت جملات بنویسید. تکرارها را با اجرای دو بار یک فاکتور مشابه تست کنید. در نهایت، گردش‌کار را به گونه‌ای تنظیم کنید که خودش گردش‌کار خطای خود باشد، تا در صورت شکست، پیامی به کانال AP ارسال شود و در پس‌زمینه به‌طور بی‌صدا شکست نخورد.
گام بعدی شما
- مدل‌های زبانی را فقط برای استخراج داده (Extraction) به کار ببرید و منطق تأیید را در لایه کد بنویسید.
- برای هر مورد توقف (Hold)، یک جمله توصیفی ساده بنویسید تا فرآیند تأیید انسانی سریع‌تر شود.
- گردش‌کار خود را با ارسال تکراری یک فاکتور تست کنید تا از کارکرد صحیح سیستم ضد-تکرار مطمئن شوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو