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