قرارداد، بخشی از سیستم کنترل داخلی AI است
فرض کنید مدیر مالی یک ابزار هوش مصنوعی برای تحلیل صورت‌های مالی، پردازش فاکتور یا پاسخ‌گویی به پرسش‌های حسابداری انتخاب کرده است. Demo عالی است و فروشنده می‌گوید داده امن است، مدل دقیق است و محصول با استانداردهای روز توسعه یافته. اما شش ماه بعد مدل تغییر می‌کند، کیفیت خروجی افت می‌کند یا مشخص می‌شود بخشی از اطلاعات شرکت برای بهبود سیستم فروشنده نگهداری شده است. در این نقطه سؤال اصلی دیگر این نیست که Demo خوب بوده یا نه؛ سؤال این است که در قرارداد چه چیزی برای محافظت از شرکت نوشته شده بود. با ورود AI به عملیات مالی، Procurement دیگر فقط درباره قیمت، تعداد کاربر و SLA نیست. خود قرارداد به بخشی از سیستم کنترل داخلی تبدیل می‌شود. این موضوع مکمل بحث هوش مصنوعی پنهان در واحد مالی است: حتی ابزار تأییدشده نیز اگر شروط خرید و استفاده آن مبهم باشد، می‌تواند ریسک جدیدی وارد فرایند مالی کند.
وعده فروشنده با تعهد قراردادی فرق دارد
فروشنده ممکن است در جلسه فروش بگوید داده مشتری برای آموزش استفاده نمی‌شود؛ اما اگر قرارداد درباره این موضوع ساکت باشد، واحد مالی باید بداند ضمانت واقعی کجاست. ممکن است فروشنده بگوید سیستم Explainable است، ولی قرارداد مشخص نکند چه اطلاعاتی باید برای توضیح خروجی در اختیار مشتری قرار گیرد. حتی جمله‌ای مثل «مدل دائماً بهتر می‌شود» برای فرایند مالی می‌تواند ریسک باشد، چون نسخه‌ای که شرکت آزموده با نسخه‌ای که ماه بعد تصمیم می‌گیرد یکسان نیست. ICAEW در ۲۸ سپتامبر ۲۰۲۶ بر همین تبدیل اصول حرفه‌ای به وعده‌های قابل‌آزمون و قابل‌اجرا تأکید کرده است؛ از شفافیت درباره منشأ مدل و حقوق داده تا Audit/Verification Right، Change Control، Incident Response و محدودیت استفاده از داده مشتری. نتیجه عملی ساده است: هر ادعای مهم فروشنده باید یا به تعهد قابل سنجش تبدیل شود یا به‌عنوان ریسک پذیرفته‌شده ثبت شود.
قرارداد AI باید درباره رفتار آینده محصول هم حرف بزند
در نرم‌افزار سنتی، شرکت معمولاً نسخه مشخصی را خریداری می‌کرد و تغییرات بزرگ از طریق Release جدید اتفاق می‌افتاد. در سرویس AI ممکن است بخش مهمی از رفتار سیستم بدون تغییر ظاهری رابط کاربری عوض شود. Provider می‌تواند مدل پایه، Promptهای داخلی، Routing، RAG، ابزارهای متصل یا سیاست‌های Safety را تغییر دهد و همین تغییر روی دقت طبقه‌بندی حساب، تحلیل قرارداد یا تشخیص استثنا اثر بگذارد. قرارداد باید روشن کند چه نوع تغییراتی «بااهمیت» محسوب می‌شوند و مشتری در برابر آن‌ها چه حق اطلاع، آزمون مجدد، تعلیق قابلیت، بازگشت به نسخه قبلی یا حتی خاتمه دارد. ICAEW نیز Change Control و پایش مستمر عملکرد را از کنترل‌های مهم می‌داند و توصیه می‌کند در صورت شکست کنترل‌ها حق Step-in یا Suspension پیش‌بینی شود.
داده مالی فقط یک بند محرمانگی نمی‌خواهد
بند Confidentiality کلاسیک برای AI کافی نیست. باید روشن شود داده دقیقاً برای چه هدفی استفاده می‌شود، Prompt و Output و Log چه مدت نگهداری می‌شوند، آیا اطلاعات مشتری برای آموزش یا Fine-tuning مدل عمومی فروشنده استفاده می‌شود و چه اشخاص ثالثی در زنجیره تأمین به پردازش دسترسی دارند. ICAEW توصیه می‌کند استفاده از داده به نیازهای سرویس محدود شود، آموزش مدل عمومی بدون رضایت مشخص ممنوع باشد و نگهداری Prompt، Output و Log حداقل و کنترل‌شده باقی بماند. برای واحد مالی این موضوع حساس‌تر است، چون ورودی ممکن است شامل حقوق و دستمزد، قراردادها، گردش بانکی، اطلاعات مشتریان و داده‌های محرمانه مدیریت باشد. پس «حدود داده» باید به‌صورت Purpose، Retention، Access، Training و Supply Chain در قرارداد قابل تشخیص باشد.
Audit Right را قبل از بحران بخواهید
اگر سیستم AI در یک فرایند مهم مالی استفاده شود، شرکت ممکن است در آینده به شواهدی درباره عملکرد، امنیت یا تغییرات آن نیاز داشته باشد. عبارت کلی «فروشنده از رویه‌های مناسب امنیتی استفاده می‌کند» برای چنین وضعیتی کافی نیست. قرارداد باید مشخص کند چه گزارش‌ها، گواهی‌ها، نتایج آزمون یا اطلاعاتی را می‌توان درخواست کرد و در چه شرایطی امکان Verification یا بررسی مستقل وجود دارد. هدف این نیست که مشتری کد محرمانه مدل را مطالبه کند؛ هدف این است که برای ریسک‌هایی که خودش مسئول مدیریت آن‌هاست، شواهد قابل اتکا دریافت کند. ICAEW نیز Audit و Verification Rights را در کنار تعهد به اصلاح اطلاعات نادرست یا تغییرکرده مطرح می‌کند. برای واحد مالی، این حق باید با نیاز حسابرسی، کنترل داخلی و مستندسازی تصمیم‌های حساس هماهنگ شود.
معیار Go-Live باید فنی و مالی باشد، نه صرفاً تاریخی
Go-Live نباید فقط به رسیدن به تاریخ پروژه وابسته باشد. اگر ابزار فاکتور را پردازش می‌کند، ورود به تولید می‌تواند منوط به عبور از آزمون‌های توافق‌شده روی اسناد نماینده شرکت باشد. اگر سیستم قرارداد می‌خواند، نرخ خطا در شروط حساس باید جداگانه سنجیده شود و اگر خروجی مبنای تصمیم مهم است، مسیر Human Review باید واقعاً کار کند. ICAEW نیز توصیه می‌کند Go-Live به عبور از معیارهای ارزیابی تعریف‌شده وابسته شود، نه صرفاً رسیدن به موعد قراردادی. این موضوع با کنترل داخلی در حسابداری با هوش مصنوعی پیوند مستقیم دارد: حق اجرای آزمون، حق توقف در صورت شکست و پیامد تجاریِ عدم عبور از معیار باید پیش از اجرا روشن شود.
قرارداد مناسب، دغدغه‌های فنی را به سؤال کنترلی تبدیل می‌کند
برای تیم مالی، هدف از قرارداد AI نوشتن تمام جزئیات فنی نیست؛ هدف این است که موضوعات پرریسک به پرسش‌های روشن و قابل مذاکره تبدیل شوند. حقوق داده می‌پرسد فروشنده برای چه هدفی از اطلاعات استفاده می‌کند؛ آموزش مدل می‌پرسد آیا داده، Prompt یا Output مشتری وارد مدل عمومی می‌شود؛ Change Control حق اطلاع و آزمون در برابر تغییر را مشخص می‌کند؛ عملکرد و آزمون، معیار اندازه‌گیری و استفاده از داده نماینده مشتری را روشن می‌کنند؛ Audit/Verification نوع شواهد قابل دریافت را تعیین می‌کند؛ Incident زمان و شیوه اطلاع‌رسانی را می‌بندد؛ Human Oversight حدود تصمیم خودکار را مشخص می‌کند؛ زنجیره تأمین دسترسی اشخاص ثالث را شفاف می‌سازد؛ و Exit تکلیف داده، Log و سوابق را پس از خاتمه قرارداد تعیین می‌کند. این چارچوب جای مشاوره حقوقی نیست؛ ورودی ساختاریافته‌ای برای تیم حقوقی و Procurement است.
| موضوع | سؤال کنترلی |
|---|---|
| حقوق داده | فروشنده دقیقاً برای چه هدفی می‌تواند از داده استفاده کند؟ |
| آموزش مدل | آیا داده، Prompt یا Output مشتری وارد آموزش مدل عمومی می‌شود؟ |
| تغییر مدل | چه تغییراتی باید پیش از اجرا اطلاع داده شوند؟ |
| عملکرد | معیار قابل اندازه‌گیری برای سرویس چیست؟ |
| آزمون | آیا مشتری حق آزمون با داده نماینده خود را دارد؟ |
| Audit / Verification | چه شواهدی باید در اختیار مشتری قرار گیرد؟ |
| Incident | زمان و نحوه اطلاع از رخداد امنیتی یا خطای بااهمیت چیست؟ |
| Human Oversight | کدام تصمیم‌ها نباید کاملاً خودکار شوند؟ |
| زنجیره تأمین | چه اشخاص ثالثی داده یا پردازش را دریافت می‌کنند؟ |
| خروج | داده، Log و سوابق هنگام خاتمه قرارداد چه می‌شوند؟ |
Vendor Benchmark کافی نیست
فروشنده ممکن است اعلام کند مدل در Benchmark داخلی ۹۵ درصد دقت دارد، اما این عدد می‌تواند با جمعیت واقعی شرکت فاصله زیادی داشته باشد. ابزار استخراج اطلاعاتی که روی فاکتورهای انگلیسی و ساختاریافته خوب کار می‌کند، ممکن است روی اسناد فارسی، تاریخ شمسی، اعداد فارسی، اسکن ضعیف یا الگوهای خاص شرکت عملکرد متفاوتی داشته باشد. ICAEW نیز توصیه می‌کند عملکرد مدل با داده نماینده خریدار آزمایش شود، نه فقط با Benchmark فروشنده. قرارداد و فرایند پذیرش باید حق چنین آزمونی را حفظ کنند و روشن کنند افت عملکرد چه پیامدی دارد. SLA برای Uptime لازم است اما کافی نیست؛ سرویس می‌تواند ۹۹٫۹ درصد در دسترس باشد و در عین حال خروجی نامناسب تولید کند. بنابراین Service Level در AI باید کیفیت کنترل و عملکرد مدل را نیز پوشش دهد.
Model Drift باید موضوع قرارداد باشد
کیفیت مدل AI فقط در لحظه خرید ثابت نمی‌ماند؛ داده، مدل، ابزارها و رفتار کاربران تغییر می‌کنند. قرارداد باید مشخص کند چه کسی عملکرد را پایش می‌کند، معیار افت چیست و اگر کیفیت از آستانه تعیین‌شده پایین‌تر آمد چه اقدام اصلاحی لازم است. راه‌حل می‌تواند شامل گزارش دوره‌ای، اطلاع‌رسانی تغییر عمده، امکان تعلیق قابلیت خودکار، بازاجرای آزمون یا بازگشت کنترل‌شده باشد. ICAEW بر Continuous Monitoring و حق Step-in یا Suspension وقتی کنترل‌ها شکست می‌خورند تأکید می‌کند. قرارداد خوب تمام جزئیات فنی آینده را پیش‌بینی نمی‌کند؛ اما حق واکنش به تغییر را حفظ می‌کند و اجازه نمی‌دهد مشتری فقط به این دلیل که محصول «زنده» و دائماً در حال تغییر است، بدون ابزار کنترلی باقی بماند.
Exit Plan را روز خرید طراحی کنید
یکی از خطرناک‌ترین لحظات زمانی است که شرکت تصمیم می‌گیرد Provider را تغییر دهد. باید از ابتدا روشن باشد آیا تاریخچه تصمیم‌ها و Logها قابل Export هستند، تنظیمات و Promptهای سازمانی و دانش واردشده قابل انتقال‌اند، چه مهلتی برای مهاجرت وجود دارد و فروشنده چه زمانی نسخه‌های باقی‌مانده داده را حذف می‌کند. ICAEW نیز «خروج مسئولانه» را مهم می‌داند و به Data Export، ارائه Model Records و حذف یا بازگرداندن امن اطلاعات اشاره می‌کند. اگر این سؤال‌ها فقط هنگام تمدید یا خاتمه مطرح شوند، ممکن است وابستگی فنی و داده‌ای قبلاً شکل گرفته باشد. Exit Plan بخشی از قیمت واقعی خرید است؛ زیرا هزینه ترک فروشنده و بازیابی کنترل را از روز اول قابل مشاهده می‌کند.
مدیر مالی باید یکی از صاحبان تصمیم خرید AI باشد
خرید ابزار AI مالی نباید صرفاً تصمیم IT باشد. فناوری درباره معماری و امنیت نظر می‌دهد، حقوق قرارداد را بررسی می‌کند و Procurement درباره شرایط تجاری مذاکره می‌کند؛ اما مدیر مالی باید اثر سیستم بر ثبت، گزارش، کنترل و مسئولیت حرفه‌ای را مشخص کند. اگر خروجی ابزار مبنای ثبت سند است، خطا چه کسی را درگیر می‌کند؟ اگر مدل تغییر کند، چه کنترل‌هایی باید دوباره اجرا شوند؟ اگر سرویس از دسترس خارج شود، فرایند جایگزین چیست؟ این‌ها سؤال‌های عملیاتی مالی‌اند. در نتیجه RACI خرید AI باید Finance را نه فقط به‌عنوان مصرف‌کننده، بلکه به‌عنوان Owner ریسک کسب‌وکاری و معیار پذیرش وارد کند. قرارداد وقتی مؤثر است که نقش‌های IT، Legal، Procurement و Finance در آن به یک مدل تصمیم مشترک متصل شوند.
Vendor Control Register می‌تواند قرارداد را به عملیات وصل کند
نسل بعدی نرم‌افزار مدیریت AI می‌تواند یک Vendor Control Register داشته باشد. برای هر Provider مشخص شود چه داده‌هایی را می‌بیند، قرارداد چه زمانی منقضی می‌شود، استفاده از داده برای آموزش مجاز است یا نه، آخرین ارزیابی چه زمانی انجام شده، نسخه یا خانواده مدل چیست، چه Subprocessor یا زنجیره تأمینی درگیر است و پس از چه نوع تغییری باید کنترل‌ها دوباره اجرا شوند. چنین رجیستری Procurement را از یک پوشه قرارداد جدا از عملیات خارج می‌کند و مستقیماً با کنترل مالی پیوند می‌دهد. همین منطق با ایده کارخانه هوش مصنوعی مالی هم‌راستاست: کنترل‌های هویت، داده، تغییر، شواهد و Audit Trail باید در سطح پلتفرم قابل مدیریت باشند، نه اینکه برای هر ابزار از صفر ساخته شوند.
جمع‌بندی: قرارداد AI بخشی از معماری کنترل است
در خرید نرم‌افزار سنتی، قرارداد عمدتاً قیمت، دسترسی و پشتیبانی را تعیین می‌کرد. در AI، قرارداد باید بخشی از معماری کنترل باشد. داده، تغییر مدل، آزمون، شواهد، Audit Right، Incident، نظارت انسانی و Exit باید پیش از Go-Live روشن شوند. مهم‌ترین سؤال مدیر مالی دیگر فقط این نیست که «این ابزار چه کاری انجام می‌دهد؟» بلکه این است: «اگر رفتار این ابزار فردا تغییر کرد یا کنترل آن شکست خورد، قرارداد چه حقی برای شرکت باقی گذاشته است؟» راهنمای ICAEW در ۲۸ سپتامبر ۲۰۲۶ دقیقاً همین جهت را تقویت می‌کند: اصول اخلاقی و حرفه‌ای وقتی در Procurement مؤثر می‌شوند که به معیارهای قابل آزمون، شروط قابل اجرا و پیامد مشخص تبدیل شوند. جزئیات نهایی قرارداد باید توسط متخصص حقوقی و بر اساس قوانین و مقررات قابل اعمال بر سازمان بررسی شود.
اگر می‌خواهید مقالات و ابزارهای تخصصی حسابداری، مدیریت مالی و هوش مصنوعی را دنبال کنید، عضویت در حسابداران برتر.