هوش مصنوعی در مالی؛ خرید، ساخت یا امانت‌گرفتن ابزار
بازار ابزارهای هوش مصنوعی برای تیم مالی شلوغ و گیج‌کننده است و هر نرم‌افزاری ادعا می‌کند «هوشمند» است. پرسش درست این نیست که کدام ابزار بهتر است؛ پرسش این است که برای هر مسئله، هوش مصنوعی در کدام لایه و با چه نقشی وارد کار شده و آیا باید آن را خرید، ساخت یا از دیگری امانت گرفت.
پنج نوع محصول پشت برچسب «هوش مصنوعی»
پیش از تصمیم باید بدانید با چه چیزی روبه‌رو هستید. محصولاتی که امروز با این برچسب عرضه می‌شوند را می‌توان در پنج گروه گذاشت.
۱. مدل‌های بنیادین به‌صورت مستقیم. همان چت‌بات‌های عمومی. قدرت استدلال خام است و تنها حفاظ، قضاوت خود مدل و کیفیت دستور شماست. برای کارهایی که تفکر و تحلیل می‌خواهند خوب است: نوشتن روایت تحلیل انحراف برای گزارش هیئت‌مدیره، جمع‌بندی پرسش‌های محتمل سرمایه‌گذاران پیش از جلسه، یا مقایسه‌ی بند یک قرارداد تأمین‌کننده با شرایط استاندارد شرکت. ضعفش خطای کاربر، پاسخ‌های ناهمسان برای یک دستور یکسان، نگرانی حریم داده و رشد پنهان هزینه است. یک کاربر مسئول این‌ها را مدیریت می‌کند، ولی در مقیاس تیم کنترلشان سخت است.
۲. افزونه‌ها و ابزارهای ساخته‌شده روی مدل. مثل ابزارهای تحقیق عمیق، دستیارهای داخل نرم‌افزارهای اداری، ابزارهای ساخت جریان کاری ساده و ابزارهای تولید برنامه. این‌جا هوش مصنوعی «شرح وظایف» دارد و به داده و اقدام مشخصی دسترسی دارد. اما همین حفاظ‌ها اعتمادبه‌نفس کاذب می‌سازند، چون کیفیت خروجی هنوز به دستور و طراحی گردش کار بستگی دارد.
۳. پوشش‌های هوش مصنوعی (wrapper). لایه‌ی نازکی روی مدل‌های زبانی، یا یک چت‌بات که به ERP قدیمی اضافه شده است. در کوتاه‌مدت می‌تواند مفید باشد؛ مثلاً دسترسی فقط‌خواندنی و گفت‌وگومحور به اطلاعات فاکتور یا بدهی برای مدیری که نمی‌خواهد سراغ سیستم برود. اما خطرش «نمایش هوش مصنوعی» است: حس می‌کنید کار هوش مصنوعی انجام می‌دهید، در حالی که نحوه‌ی انجام کار عوض نشده است. شرکت‌های نوپایی که فقط یک لایه‌ی نازک روی مدل‌اند هم با هر قابلیت تازه‌ی ارائه‌دهندگان مدل می‌توانند ناگهان بی‌معنا شوند.
۴. پلتفرم‌های بومی هوش مصنوعی. نرم‌افزارهایی که مدل داده و تجربه‌ی کاربرشان از ابتدا حول هوش مصنوعی طراحی شده است. چون روی داده و گردش کار تخصصی مالی ساخته می‌شوند، ریسک خطای ساختگی (hallucination) را نسبت به مدل عمومی کاهش می‌دهند و داده را درون یک محیط کنترل‌شده نگه می‌دارند. مسیر تکاملی‌شان روشن است: مالکیت کامل گردش کار (بستن حساب‌ها و گزارش را سیستم اجرا می‌کند و فقط استثناها را به انسان می‌دهد)، عامل‌هایی که درون سیستم کار مشخص مثل تحلیل انحراف یا وصول مطالبات را انجام می‌دهند، و یادگرفتن سیاست‌ها و تصمیم‌های پیشین شرکت.
۵. ساخت اختصاصی. تیم‌های مالی همیشه ابزار شخصی ساخته‌اند و یک صفحه‌گسترده‌ی بسیار پیچیده را هم می‌توان نرم‌افزار حساب کرد. تازه این است که حالا ساخت نرم‌افزار بسیار ساده‌تر شده است. اما «هر کسی می‌تواند بسازد» یعنی «هر کسی می‌تواند نرم‌افزار خوب بسازد» نیست. هزینه و ریسک هر ابزار کم شده، ولی تعداد ابزارها منفجر شده و مجموع ریسک ممکن است بالا برود.
ساخت اختصاصی کجا معنا دارد؟
سه وضعیت مناسب است:
- سازمان توانمند فنی. شرکتی با تیم مهندسی قوی، فرهنگ محصول و بودجه می‌تواند زیرساخت جدی بسازد و از آن مزیت رقابتی بگیرد.
- شکاف بازار. فرایند بسیار خاصی که هیچ نرم‌افزار آماده خوب پوشش نمی‌دهد، مثل مدیریت موجودی امانی نزد شرکت لجستیک با منطق تجاری ویژه.
- لایه‌های کم‌ریسک پشته‌ی فناوری. نمایش، گزارش‌دهی یا هماهنگی گردش کار در لبه‌ی سیستم، مثل داشبورد و ابزار سناریو؛ جایی که خطا دیدنی و محدود است و کار سخت داده در لایه‌ی عمیق‌تر انجام شده است.
خطر اصلی این است که بی‌کنترل، مجموعه‌ای از «چیزهایی که یک‌جورهایی کار می‌کنند» شکل بگیرد؛ ابزارهایی وابسته به یک نفر، بی‌مستندات و غیرقابل ممیزی.
سه پرسش برای انتخاب ابزار مناسب
به‌جای اینکه بپرسید «ما کدام گروه هستیم؟»، بدانید هر کسب‌وکاری در عمل از هر پنج گروه کمی دارد. مهم ترکیب و رویکرد برای هر مسئله است. سه پرسش کمک می‌کند:
پرسش ۱: داده چقدر حساس است؟ هرچه داده حساس‌تر، باید به سمت راه‌حل‌های کنترل‌شده و تخصصی بروید و از جعبه‌سیاه خام مدل عمومی فاصله بگیرید.
پرسش ۲: خروجی به دفاتر و سوابق رسمی برمی‌گردد؟ اگر نتیجه‌ی کار، مستقیم یا غیرمستقیم، وارد سیستم ثبت می‌شود، تحمل ریسک باید بسیار پایین باشد. یعنی ابزار قطعی (deterministic) به ابزار احتمالی ترجیح دارد، حفاظ‌ها سفت‌تر است، ردپای حسابرسی روشن است و تأیید انسانی دقیق‌تر. استدلال خام مدل نباید نزدیک داده‌ی پایه یا دستور پرداخت برسد. در نقطه‌ی مقابل، کارهایی که فقط از سیستم می‌خوانند (تحلیل، جمع‌بندی، استدلال) ریسک کمتری دارند، چون خطا نزدیک سطح و قابل مشاهده است.
پرسش ۳: توان داخلی ساخت و نگهداری چقدر است؟ این پرسش آینه‌ای است. شرکتی با فرهنگ مهندسی عالی و بدهی فنی اندک می‌تواند همه‌چیز را اختصاصی بسازد؛ بیشتر شرکت‌ها فاصله‌ی زیادی با این وضعیت دارند و ریسک‌پذیری و روش‌شان باید با واقعیت هماهنگ باشد.
خرید، ساخت یا امانت‌گرفتن؟
هر تعهد فناوری را می‌توان در یکی از سه حالت دید:
| حالت | معنا | جای مناسب |
|---|---|---|
| خرید | نصب نرم‌افزار تخصصی بومی هوش مصنوعی | ستون اصلی: دفتر کل، صورتحساب، خرید تا پرداخت، موجودی، لایه‌ی داده |
| ساخت | ابزار اختصاصی درون‌سازمانی | مدل‌های مالی، داشبورد، عامل‌های ساده و تک‌منظوره |
| امانت‌گرفتن | ساخت سفارشی توسط یک تیم بیرونی | برنامه‌های پیچیده‌تر، بدون نیاز به توان داخلی |
«امانت‌گرفتن» حد وسط است: تناسب یک ساخت سفارشی را دارید، ولی بخش بزرگی از دردسر کنترل دسترسی، امنیت داده و نگهداری را به دیگری می‌سپارید. بازار شرکت‌هایی که نمونه‌ی اولیه‌ی برنامه را در چند روز می‌سازند در حال رشد است.
برداشت منطقی این است که هسته‌ی بیشتر پشته‌های مالی ترکیبی از خرید و امانت‌گرفتن خواهد بود: ستونی از ابزارهای تخصصی بومی هوش مصنوعی، به‌علاوه‌ی برنامه‌های سفارشی مناسب هر کار؛ پیچیده‌ها را بیرون بسپارید و ساده‌ی تک‌منظوره را درون‌سازمانی بسازید. بیشترین بازده هوش مصنوعی در مالی از نصب جدی زیرساخت بومی هوش مصنوعی در هسته می‌آید، نه از انباشت ابزارهای جانبی.
امنیت داده؛ هفت نکته
پاسخ کاملاً رضایت‌بخشی برای نگرانی داده وجود ندارد، ولی این نکات به تصمیم کمک می‌کند:
- قرارداد سازمانی ضمانت مطلق نیست. ارائه‌دهندگان بزرگ معمولاً تعهد می‌کنند داده‌ی شما برای آموزش مدل استفاده نشود، اما ضمانت جبران خسارت در قراردادها ضعیف است و عملاً به قول طرف مقابل تکیه می‌کنید.
- تجربه‌ی رایانش ابری را به یاد بیاورید. پانزده سال پیش، بردن داده به بیرون از سازمان همین‌قدر ناممکن به نظر می‌رسید. دلیلی برای بی‌خیالی نیست، ولی برای فلج‌شدن هم دلیل نیست.
- فقط مدل ریسک نیست. افزونه‌ی دانلودشده‌ی هفته‌ی پیش یا پلاگینی که به سیستم مشتریان وصل شده، ممکن است همان حفاظ‌ها را نداشته باشد. باید قرارداد تأمین‌کنندگان را وارسی کرد.
- فراتر از پایگاه داده فکر کنید. بسته‌های هیئت‌مدیره، صفحه‌گسترده‌ها، ضبط جلسه‌ها، صورت‌جلسه‌ها و تصاویر هم داده‌ی حساس‌اند.
- کارکنان خودشان ناقل ریسک‌اند. هیچ قراردادی مانع چسباندن یک گزارش محرمانه در پنجره‌ی چت نمی‌شود. سیاست حاکمیتی و آموزش تیم به اندازه‌ی قرارداد مهم است.
- بازگشت به سرورهای داخلی ممکن است. نگرانی حاکمیت داده، به‌ویژه در صنایع مقرراتی، می‌تواند بخشی از بار را دوباره به زیرساخت داخلی برگرداند.
- ایده‌ها را هم محافظت کنید. وقتی اجرا ارزان شود، ایده‌های متمایز و تفکر اختصاصی ارزشمندتر می‌شود.
پرسش‌های متداول
آیا باید فقط یک نوع ابزار انتخاب کنیم؟
خیر. هر سازمان عملاً ترکیبی از همه‌ی انواع را دارد. تصمیم باید برای هر مسئله جداگانه و با سه پرسش حساسیت داده، اتصال به دفاتر رسمی و توان داخلی گرفته شود.
چرا ابزار قطعی برای کارهای مرتبط با دفاتر رسمی بهتر است؟
چون نتیجه باید قابل تکرار و قابل ممیزی باشد. مدل احتمالی ممکن است برای یک ورودی در دو بار اجرا پاسخ متفاوت بدهد، و این در سیستم ثبت پذیرفتنی نیست.
ساخت اختصاصی با هوش مصنوعی خطرناک است؟
لزوماً نه، اما بدون مهندسی، مستندسازی و حاکمیت، مجموع ابزارهای پراکنده ریسک بالایی می‌سازد. بهتر است از لایه‌های کم‌ریسک شروع کنید.
جمع‌بندی
هسته‌ی سیستم مالی‌تان را بر ابزارهای تخصصی بومی هوش مصنوعی بنا کنید، سفارشی‌سازی را فقط جایی انجام دهید که بازار پاسخ نمی‌دهد، و برای هر مورد سه پرسش حساسیت داده، ارتباط با دفاتر رسمی و توان نگهداری را بپرسید. برای ادامه‌ی مسیر می‌توانید حاکمیت هوش مصنوعی در مالی، موارد کاربرد عامل‌ها و سه مرحله‌ی شروع را هم بخوانید.