مقدمه: حسابرس با یک تصمیمگیرنده جدید روبهروست
فرض کنید یک شرکت از هوش مصنوعی برای طبقهبندی هزینهها، شناسایی صورتحسابهای مشکوک، محاسبه برآورد ضمانت محصولات و پیشنهاد ثبتهای اصلاحی استفاده میکند. مدیر مالی خروجی پایان ماه را میبیند و بهدلیل سرعت بالای پردازش، آن را قابل اتکا میداند.

حسابرس مستقل باید پرسشی فراتر از تطبیق جمع بدهکار و بستانکار مطرح کند: دادهها از کجا آمدهاند؟ چه اقلامی کنار گذاشته شدهاند؟ نسخه مدل طی دوره تغییر کرده؟ آیا تأیید انسانی واقعی بوده؟ اثر خروجی در کدام حساب منعکس شده است؟

این موضوع با استفاده خود حسابرس از هوش مصنوعی تفاوت دارد. در حالت اول، AI بخشی از سیستم اطلاعاتی و کنترل داخلی شرکت صاحبکار است و میتواند بر خطر تحریف بااهمیت صورتهای مالی اثر بگذارد؛ در حالت دوم، AI ابزاری برای اجرای روشهای حسابرسی است. کنترل این دو وضعیت یکسان نیست.

موضوع جدید نه الزام به حسابرسی تکتک خطوط کد، بلکه شناخت اثر سامانه بر ادعاهای گزارشگری و انتخاب رسیدگی متناسب با ریسک است.

کدام کاربرد AI در صورتهای مالی اهمیت دارد؟
نام محصول یا وجود یک چتبات سازمانی کافی نیست. ابزاری ممکن است فقط شرح سند را پیشنهاد کند و هر نتیجه توسط حسابدار تأیید شود. ابزار دیگری ممکن است نرخ برآورد، مبلغ تعهد یا ثبت مالی را مستقیماً برای ERP آماده کند.

حسابرس باید کاربردهای واقعی را با رویداد مالی مرتبط کند: کدینگ هزینه، تخصیص مرکز هزینه، شناسایی درآمد، برآورد مطالبات، هزینه گارانتی، تعدیلات پایان دوره و تهیه افشاها. کاربردی که صرفاً گزارش مدیریتی داخلی میدهد ممکن است اثری متفاوت از سامانهای داشته باشد که یک مانده بااهمیت مالی را شکل میدهد.

پرسش مناسب این است: «این تصمیم هوشمند، دقیقاً کدام ادعای صورتهای مالی را تحت تأثیر قرار میدهد؟»

کاملبودن، وقوع، ارزشیابی، دورهبندی و ارائه ممکن است هرکدام در معرض خطر متفاوتی باشند.

نقشه وابستگی؛ از مدرک تا رقم نهایی
برای هر کاربرد بااهمیت، یک نقشه جریان داده تا دفتر کل بسازید:

داده مبدأ
سؤال حسابرس
چه اطلاعاتی وارد شده و چه چیزهایی حذف شده؟
شاهد پیشنهادی
شمارش، جمع کنترل، فهرست منابع
آمادهسازی
سؤال حسابرس
کدام تبدیل و فیلتر اجرا شده؟
شاهد پیشنهادی
نسخه قواعد، گزارش تغییرات
مدل
سؤال حسابرس
چه نسخه و آستانهای خروجی را تولید کرده؟
شاهد پیشنهادی
شناسه نسخه، تاریخ اجرا، مجوز تغییر
تأیید
سؤال حسابرس
چه کسی پیشنهاد را بررسی کرده است؟
شاهد پیشنهادی
مسیر تصویب و دلایل پذیرش یا رد
ثبت
سؤال حسابرس
کدام مبلغ به دفتر کل منتقل شد؟
شاهد پیشنهادی
شناسه سند، دوره، ثبت اصلاحی
گزارش
سؤال حسابرس
رقم در کدام سرفصل ارائه شد؟
شاهد پیشنهادی
تطبیق تراز آزمایشی با صورت مالی
وجود شکاف در زنجیره لزوماً تحریف مالی را ثابت نمیکند، اما میتواند قابلیت اتکای شواهد را کاهش داده و روشهای حسابرسی دیگری لازم کند.

مثال آموزشی: مدل هوشمند با داده خدمات پس از فروش ناقص
یک شرکت فرضی در یک دوره ۱۲ هزار دستگاه مشمول تعهد ضمانت فروخته است. مدل AI براساس اطلاعاتی که دریافت کرده، نرخ رخداد تعمیر را ۲ درصد برآورد میکند. متوسط هزینه فرضی هر مورد ۱٫۵ میلیون ریال است.

محاسبه ساده اولیه برابر ۳۶۰ میلیون ریال است:

۱۲٬۰۰۰ × ۲٪ × ۱٫۵ میلیون ریال = ۳۶۰ میلیون ریال

در بررسی بعدی مشخص میشود داده یک منطقه فروش به علت مشکل اتصال در ارزیابی مدل وجود نداشته است.

اگر با داده کاملتر، برای آزمون حساسیت، نرخ ۳ درصد فرض شود، نتیجه مشابه ۵۴۰ میلیون ریال و اختلاف دو محاسبه ۱۸۰ میلیون ریال خواهد بود.

تعداد واحد مشمول
محاسبه اولیه
۱۲٬۰۰۰
سناریوی حساسیت
۱۲٬۰۰۰
نرخ فرضی رخداد
محاسبه اولیه
۲٪
سناریوی حساسیت
۳٪
متوسط هزینه (میلیون ریال)
محاسبه اولیه
۱٫۵
سناریوی حساسیت
۱٫۵
نتیجه محاسبه (میلیون ریال)
محاسبه اولیه
۳۶۰
سناریوی حساسیت
۵۴۰
این اعداد ساختگیاند. نمیتوان نتیجه گرفت مبلغ درست ذخیره الزاماً ۵۴۰ میلیون ریال است. ماهیت تعهد، هزینه واقعی، دادههای آیندهنگر، قراردادها و مبنای گزارشگری باید جداگانه ارزیابی شوند.

مثال تنها نشان میدهد ناقصبودن ورودی مدل چگونه یک رقم برآوردی را جابهجا میکند.

پاسخ حرفهای حسابرس، درخواست ثبت کورکورانه اختلاف نیست. باید مشخص کند آیا داده ناقص بر برآورد بااهمیت اثر دارد، کنترلهای شرکت چگونه عمل کردهاند و برای دستیابی به شواهد کافی چه روشهایی لازم است.

چرا شمارش رکوردها بهتنهایی کفایت نمیکند؟
ممکن است تعداد رکوردهای پردازششده با گزارش نرمافزار برابر باشد، ولی منبعی از ابتدا در دامنه مدل تعریف نشده باشد.

همچنین مجموعه داده ظاهراً کامل میتواند بهعلت سوگیری نسبت به یک گروه مشتری یا تغییر شرایط بازار، برای برآورد دوره جاری نامناسب باشد.

بنابراین کیفیت داده باید از نظر کاملبودن جمعیت، صحت فیلدها، ارتباط با هدف برآورد، تازگی و پوشش گروههای مختلف آزموده شود.

توضیح متقاعدکننده مدل زبانی نیز جای مدرک مبدأ را نمیگیرد؛ احتمال پاسخهای نادرست یا استناد نامعتبر همچنان وجود دارد.

هشت کنترل کاربردی که باید بررسی شوند
کنترل اول: فهرست کاربرد و اثر مالی
مالک ابزار، حسابهای متأثر، سطح دسترسی و تاریخ استقرار مشخص باشد. صرف خرید اشتراک AI به معنای استفاده مؤثر آن در گزارشگری نیست.

کنترل دوم: منشأ و کاملبودن داده
جمعها و تعداد ورودیها با منبع مستقل تطبیق داده شوند. موارد حذفشده و داده بیرونی باید منشأ و تاریخ معتبر داشته باشند.

کنترل سوم: مدیریت تغییرات مدل
نسخه مدل، پرامپتهای سیستمی، آستانهها و اتصالهای ERP ثبت شوند. تغییر بااهمیت بدون آزمون و مجوز وارد محیط عملیاتی نشود.

کنترل چهارم: آزمون موارد نامتعارف
علاوه بر پروندههای ساده، اسناد اصلاحی، اقلام پایان دوره، دادههای متناقض و استثناهای بااهمیت آزمون شوند.

کنترل پنجم: تأیید واقعی انسانی
تأییدکننده باید بتواند سند و دلیل پیشنهاد را ببیند. تأیید دستهجمعی بدون فرصت رسیدگی ممکن است کنترل صوری ایجاد کند.

کنترل ششم: دسترسی حداقلی و تفکیک وظایف
دستیار استخراج یا کدینگ سند نباید بیدلیل مجوز تغییر اطلاعات بانکی فروشنده یا ثبت نهایی داشته باشد.

کنترل هفتم: ردپای اجرای واقعی
نتیجه مدل باید به شناسه رویداد، دوره، سند و صورت مالی متصل شود. ارائه نمایش آزمایشی، اثبات عملکرد در دوره مورد رسیدگی نیست.

کنترل هشتم: سازوکار اصلاح خطا
موارد شکست، علت ریشهای، مالک رفع مشکل و نتیجه آزمون مجدد ثبت شود. اصلاح یک نسخه مدل نباید خطای نسخه قدیم را از تاریخچه حذف کند.

حسابرس چه زمانی میتواند به این کنترلها اتکا کند؟
داشتن سیاست مکتوب یا داشبورد موفقیت کافی نیست.

حسابرس باید طبق استانداردهای قابل اعمال تعیین کند کدام کنترل در پیشگیری یا کشف تحریف مالی مرتبط است، طراحی و استقرار آن را بفهمد و اگر در برنامه حسابرسی به اثربخشی آن اتکا میکند، آزمونهای لازم را طراحی کند.

کنترل مناسب لزوماً رسیدگی محتوایی را حذف نمیکند؛ کنترل ضعیف نیز خودبهخود تحریف را ثابت نمیکند. پاسخ حسابرسی با توجه به ریسک، اهمیت و کیفیت شواهد تعیین میشود.

نرخ کلی «۹۸ درصد صحت خروجی» برای یک واحد مالی معیار تصمیم کافی نیست.

خطای برچسبگذاری یک هزینه کماهمیت و خطای برآورد بااهمیت اثر یکسان ندارند. آستانه پذیرش باید براساس نوع عملیات، ادعای گزارشگری و پیامد خطا تعیین شود.

آزمون فنی مدل با آزمون صورتهای مالی یکی نیست
تیم فناوری معمولاً نسبت پاسخهای درست در مجموعه آزمون را میسنجد. حسابرس درباره احتمال و پیامد تحریف بااهمیت در صورتهای مالی قضاوت میکند.

حتی یک مدل دقیق با داده ناکامل یا دسترسی نامناسب میتواند خروجی غیرقابل اتکا تولید کند. نتیجه آزمون یک نسخه نیز بدون بررسی تغییرات به نسخههای دیگر قابل تعمیم نیست.

در موارد بااهمیت، ممکن است برای شناخت فرایند از متخصص فناوری، داده، امنیت یا برآوردهای مالی استفاده شود.

استفاده از متخصص، مسئولیت نتیجهگیری حسابرس را منتقل نمیکند.

وضعیت دوم؛ وقتی مؤسسه حسابرسی خودش از AI استفاده میکند
اگر حسابرس برای خلاصهکردن قرارداد، تحلیل نوسانات یا تدوین پیشنویس کاربرگ از AI بهره ببرد، باید ابزار مجاز، محرمانگی، آموزش تیم، بازبینی خروجی و نظارت بر اجرای کار را کنترل کند.

اما این کنترلها جای ارزیابی سامانه AI شرکت صاحبکار را نمیگیرند.

ممکن است حسابرس اصلاً از AI استفاده نکند، ولی صاحبکار برآوردی مهم را با AI تهیه کرده باشد. در این صورت شناخت ریسک مرتبط با آن برآورد همچنان موضوع حسابرسی است.

حفاظت از اطلاعات محرمانه
پرونده مالی و حسابرسی ممکن است حاوی حقوق کارکنان، قراردادهای محرمانه، اطلاعات مشتریان یا مانده بانک باشد.

پیش از بارگذاری باید مجازبودن ابزار، شرایط پردازش داده، دوره نگهداری، دسترسی اشخاص ثالث و الزامهای قراردادی بررسی شوند.

دادههای آزمایشی بهتر است مصنوعی یا بهطور مناسب ناشناس شده باشند. ناشناسسازی نیز نباید روابط ضروری برای آزمون را از بین ببرد.

نقشه اجرای آزمایشی چهار هفتهای
هفته نخست: از میان کاربردهای متصل به صورتهای مالی، دو مورد پرریسک انتخاب کنید. مالک، داده مبدأ، حساب متأثر و سطح اختیار را مستند کنید.

هفته دوم: نقشه داده تا دفتر کل را ترسیم کنید؛ کاملبودن ورودی، ثبت نسخهها و تأییدهای انسانی را بررسی کنید.

هفته سوم: سناریوهای عادی و دشوار را در محیط مجاز اجرا کنید؛ خروجی مدل، تصمیم بازبین و ثبت واقعی را جداگانه نگه دارید.

هفته چهارم: موارد شکست را برحسب علت و اثر مالی طبقهبندی کنید و برای اصلاح کنترل یا تغییر برنامه حسابرسی تصمیم مستند بگیرید.

شاخصها شامل سهم اقلام دارای منشأ روشن، تعداد حذف داده بدون دلیل، دفعات تغییر مدل بدون مجوز، خطاهای کشفشده پس از تأیید و زمان تعیین تکلیف استثناها هستند.

مقدار هدف باید برای هر شرکت جداگانه تعیین شود.

کاربرد برای شرکتها و حسابرسان ایرانی
در ایران، ابزارهای AI ممکن است از راه افزونه اکسل، ماژول ثبت خودکار، واسط سامانه مؤدیان یا سرویس متصل به ERP به فرایند مالی وارد شوند.

باید روشن شود این ابزارها فقط تحلیل میکنند یا به سند و گزارش رسمی اثر میگذارند.

تطبیق ریال و تومان، تاریخهای شمسی و میلادی، شناسه اشخاص و نسخه کدینگ حسابها در کنترل داده اهمیت خاص دارد.

راهنمای خارجی یادشده استاندارد جدید و الزامآور حسابرسی یا مالیاتی در ایران نیست؛ استانداردهای حرفهای و مقررات قابل اعمال بر هر مأموریت مبنای تصمیماند.

فرصت محصولی برای حسابداران برتر
یک محصول پیشنهادی مستقل، ماژول «نقشه ریسک AI در زنجیره گزارشگری مالی» است: ثبت کاربردهای هوش مصنوعی، اتصال آنها به حسابها و ادعاهای صورت مالی، حفظ نسخه داده و مدل، اجرای کنترلهای قطعی و تولید پرونده شواهد برای مدیر مالی و حسابرس.

مزیت آن ادعای کشف تمام خطاهای مدل نیست؛ بلکه آشکارکردن این است که هر خروجی هوشمند چگونه بر یک عدد مالی اثر گذاشته و چه کسی مسئول تأیید بوده است.

این ایده میتواند در آینده کنار ابزارهای اتوماسیون مالی و کنترل صورتحساب حسابداران برتر بررسی شود. معرفی آن به معنای وجود فعلی چنین محصولی نیست.

جمعبندی
وقتی هوش مصنوعی به بخشی از سیستم مالی شرکت تبدیل میشود، حسابرس نباید تنها به ظاهر قابلقبول خروجی تکیه کند.

منشأ داده، تغییرات مدل، کنترل انسانی، سطح دسترسی و ارتباط خروجی با دفتر کل باید به تناسب اهمیت شناخته شوند.

در عین حال، استفاده از AI به معنی اشتباهبودن صورتهای مالی یا ضرورت حسابرسی مستقل همه اجزای فنی مدل نیست.

پاسخ حرفهای باید متناسب با ریسک تحریف بااهمیت و شواهد در دسترس باشد.

آینده حسابرسی هوشمند فقط آن نیست که خود حسابرس از AI بیشتر استفاده کند؛ باید بتواند اثر AI شرکت صاحبکار را نیز بر ارقام گزارشگری بسنجد.

قضاوت و مسئولیت انسان در هر دو سوی این رابطه پابرجاست.


