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