همه مقاله‌ها
امنیت سایبریامنیت هوش مصنوعیفناوری بانکیمدیریت آسیب‌پذیری

کشف آسیب‌پذیری با هوش مصنوعی در ۲۰۲۶: شکاف وصله، مهلت بانک مرکزی اروپا و آنچه بانک‌ها باید تغییر دهند

در آبان ۱۴۰۵ کشف آسیب‌پذیری با هوش مصنوعی از پیش‌بینی به واقعیت رسید. یک مدل متن‌باز وصله‌های منتشرنشده فایرفاکس را با حدود هزار دلار به اکسپلویت واقعی تبدیل کرد، گوگل تازه‌ترین مدل پیشرو خود را فقط در اختیار مدافعان سایبری گذاشت، انتشار PostgreSQL 19 به تعویق افتاد چون بازبین‌های هوش مصنوعی بیش از توان توسعه‌دهندگان باگ پیدا کردند، شمار CVEها بیش از دو برابر شد و مهلت ۳۱ اکتبر بانک مرکزی اروپا برای برنامه اقدام بانک‌ها در برابر تهدیدهای سایبری مبتنی بر هوش مصنوعی به پایان رسید. شواهد چه می‌گویند، چرا شکاف وصله اکنون پنجره حیاتی است و یک راهنمای عملی برای مدیران فناوری بانک‌ها.

نویسنده: یاسینه پورابراهیم · · ۱۴ دقیقه مطالعه

بیشتر امسال، کشف آسیب‌پذیری با هوش مصنوعی (AI Vulnerability Discovery) چیزی بود که گفته می‌شد به‌زودی امنیت را دگرگون می‌کند. در هفته آخر اکتبر ۲۰۲۶ (اوایل آبان ۱۴۰۵) شواهدش یک‌جا رسید. Epoch AI نشان داد یک مدل متن‌باز (Open-Weight) که همه به آن دسترسی دارند می‌تواند وصله‌های منتشرشده اما هنوز عرضه‌نشده فایرفاکس را با حدود هزار دلار برای هر نسخه به اکسپلویت واقعی تبدیل کند. گوگل قوی‌ترین مدل خود، Gemini 4 Carbon، را معرفی کرد و آن را ابتدا فقط در اختیار مدافعان سایبری تأییدشده گذاشت. انتشار PostgreSQL 19 به آبان موکول شد، چون بازبینی کد با کمک هوش مصنوعی بیش از آنچه توسعه‌دهندگان اصلی پروژه بتوانند به‌موقع رفع کنند، نقص پیدا کرد. و ۳۱ اکتبر (۹ آبان)، مهلتی که بانک مرکزی اروپا (ECB) برای ارائه برنامه اقدام بانک‌های بزرگ در برابر تهدیدهای سایبری مبتنی بر هوش مصنوعی تعیین کرده بود، به سر رسید. کنار هم که بگذاریم، این رویدادها می‌گویند گلوگاه امنیت جابه‌جا شده است: یافتن آسیب‌پذیری ارزان می‌شود و منبع کمیاب اکنون توان اولویت‌بندی، وصله و مهار آن‌هاست.

در اکتبر ۲۰۲۶ چه اتفاقی افتاد

یک مدل متن‌باز از شکاف وصله فایرفاکس سوءاستفاده کرد

Epoch AI در ۲۹ اکتبر پژوهشی منتشر کرد که نشان می‌داد GLM 5.3، مدل متن‌بازی که Z.ai در اوت عرضه کرده، می‌تواند از شکاف وصله (Patch Gap) سوءاستفاده کند؛ یعنی فاصله میان زمانی که یک وصله امنیتی عمومی می‌شود و زمانی که به دست کاربران می‌رسد. پژوهشگران به مدل ابزارهای ساده و فقط اطلاعاتی را دادند که در زمان انتشار هر نسخه عمومی بود، بدون دسترسی به اینترنت. مدل صفحه وبی ساخت که وقتی کاربر فایرفاکس آن را باز می‌کرد، فایلی از رایانه او می‌خواند و بدون هیچ تعامل دیگری برای مهاجم می‌فرستاد.

مدل در برابر هر شش نسخه فایرفاکس که میان ۱۷ سپتامبر و ۲۶ اکتبر منتشر شده بود (156.0 تا 158.0.1) موفق شد. برای هر هدف تا ۴۸ ساعت فرصت داشت و سریع‌ترین تلاشش ۱۲ ساعت طول کشید. پس از ساخت محیط آزمایش، هزینه نهایی حمله به هر نسخه فایرفاکس با قیمت API حدود هزار دلار بود، هرچند کل هزینه پژوهش از ۱۰۰ هزار دلار بیشتر شد. سه نکته برای صاحبان ریسک مهم است. اول، مدل تشخیص داد کدام تغییرات کد وصله امنیتی‌اند، با اینکه این وصله‌ها عمداً به شکل بهبودهای معمولی پنهان می‌شوند. دوم، همه زنجیره‌های موفق به یک آسیب‌پذیری جداگانه و منتشرنشده هم تکیه داشتند که مدل در هر تلاش دوباره کشفش کرد؛ Epoch آن را به Mozilla گزارش داد و Mozilla در ۲۷ اکتبر در نسخه 159.0 فایرفاکس وصله‌اش کرد. سوم، پژوهشگران کار را تمرین امنیتی معرفی کردند و هیچ امتناع یا سازوکار حفاظتی از سوی هیچ ارائه‌دهنده‌ای فعال نشد. تلاش‌های مشابه علیه Google Chrome، با حدود ۱۰۰ هزار دلار هزینه API دیگر، تا زمان انتشار گزارش موفق نشده بود و Epoch با احتیاط تأکید می‌کند این را نباید دلیل امن بودن کروم دانست.

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

آزمایشگاه‌های پیشرو مدل‌های خود را محدود کردند

Google DeepMind در ۲۸ اکتبر Gemini 4 Carbon را معرفی کرد و آن را قوی‌ترین مدل خود برای امنیت سایبری و کارهای بلندمدت خواند. گوگل نتیجه ۸۸٫۲ درصد در SEC-bench Pro برای یافتن آسیب‌پذیری، ۵۴٫۸ درصد در ExploitGym برای بهره‌برداری و ۷۱٫۰ درصد در CWE-bench برای وصله کردن گزارش کرد. به‌جای عرضه عمومی، گوگل گفت Carbon ابتدا به گروهی از مدافعان سایبری و سپس از طریق برنامه Fairwind به شرکای مورد اعتماد بیشتری می‌رسد و هم‌زمان در فرایند داوطلبانه آزمون پیش از انتشار دولت آمریکا شرکت می‌کند. به گفته گوگل، Fairwind اکنون بیش از ۶۵۰ شریک دارد و دولت‌ها، گردانندگان زیرساخت‌های حیاتی از جمله شبکه‌های مالی و پلتفرم‌های اصلی فناوری را در اولویت قرار می‌دهد. شرکا باید از احراز هویت چندعاملی مقاوم در برابر فیشینگ استفاده کنند و فقط می‌توانند به تیم‌های داخلی امنیت، پاسخ به حادثه یا تست نفوذ دسترسی بدهند.

این همان الگویی است که CERT-EU در آوریل توصیف کرد: Anthropic مدل Claude Mythos Preview را فقط از طریق Project Glasswing توزیع کرد و OpenAI یک مدل ویژه امنیت سایبری را از طریق برنامه دسترسی مورد اعتماد عرضه کرد. نتیجه Epoch روی دیگر سکه است. محدود کردن قوی‌ترین مدل‌های بسته به مدافعان فرصت شروع زودتر می‌دهد، اما مدل‌های متن‌باز توانمند همین حالا برای دسته‌ای مشخص و ارزشمند از حملات کافی‌اند.

PostgreSQL 19 عقب افتاد چون هوش مصنوعی بیش از حد باگ پیدا کرد

همین تحول در سمت دفاع هم دیده می‌شود و بی‌هزینه نیست. PostgreSQL 19 که معمولاً در سپتامبر یا اوایل اکتبر منتشر می‌شد، اکنون برای ۱۹ نوامبر (۲۸ آبان) برنامه‌ریزی شده و هشت تا ده قابلیت به PostgreSQL 20 منتقل شده‌اند. پیتر آیزنتراوت، از توسعه‌دهندگان اصلی پروژه، به The Register گفت بازبینی کد با کمک مدل‌های زبانی بزرگ فهرست بلندی از مشکلات مربوط به حالت‌های مرزی را آشکار کرده که پیش‌تر طی سال‌ها پیدا می‌شدند: «به فهرستی از چهل گزارش نقص خیره شده‌اید... و بعد وقت تمام می‌شود.» به گفته او «سطح مؤثر کیفیت پس از نوشته و ثبت شدن قابلیت‌ها بالا رفته است.»

زولت پاراگی از Percona بعد امنیتی ماجرا را هم افزود. به شمارش او PostgreSQL در سال ۲۰۲۵ هفت مشکل امنیتی و در ۲۰۲۶ تاکنون ۴۴ مشکل امنیتی را رفع کرده که ۲۸ مورد آن فقط در اوت بوده است. پیش‌تر یک یا دو نفر از توسعه‌دهندگان اصلی وصله‌های امنیتی یک نسخه فرعی را مدیریت می‌کردند؛ در اوت ده نفر درگیر بودند. پروژه اکنون درباره انتشار نسخه‌های فرعی هر یک و نیم تا دو ماه یک بار بحث می‌کند تا وصله‌ها زودتر به کاربران برسند.

شمار CVEها دو برابر شد؛ بهره‌برداری تأییدشده نه

اعداد پشت برچسب «آخرالزمان آسیب‌پذیری» (Vulnpocalypse) را باید با دقت خواند. تحلیلی از Iru که ۲ نوامبر منتشر شد، حدود ۸۸٬۷۰۰ CVE را در پایگاه ملی آسیب‌پذیری آمریکا (NVD) میان ۱ ژانویه تا ۲۹ اکتبر ۲۰۲۶ می‌شمارد؛ تقریباً ۲٫۳ برابر همین بازه در ۲۰۲۵. در همین بازه، فهرست آسیب‌پذیری‌های شناخته‌شده بهره‌برداری‌شده (KEV) سازمان CISA حدود ۳۱ درصد رشد کرد و از ۲۱۲ به ۲۷۸ مورد افزوده‌شده رسید. گروه اطلاعات تهدید گوگل سهم CVEهای ۲۰۲۶ را که بهره‌برداری از آن‌ها دیده شده حدود ۰٫۲۳ درصد برآورد می‌کند. به‌روزرسانی ماهانه امنیتی اکتبر مایکروسافت (Patch Tuesday) رکورد شمار آسیب‌پذیری‌ها را زد، بسته به روش شمارش حدود ۱٬۴۰۰ مورد، و دقیقاً یکی از آن‌ها بهره‌برداری‌شده تأیید شد.

اقلیت بهره‌برداری‌شده متمرکز و سریع است. از ۳۸ مورد افزوده‌شده به KEV میان ۲۱ سپتامبر و ۲۰ اکتبر، ۱۵ مورد فایروال، VPN، دروازه شبکه یا ابزار دسترسی از راه دور بودند. در ماجرای PHP2Shell، تلاش برای بهره‌برداری از ۱۷ اکتبر گزارش شد؛ چهار روز پیش از وصله ۲۱ اکتبر. Trend Micro در ژوئیه گزارش داد CISA مهلت ثابت ۱۴روزه رفع آسیب‌پذیری‌های KEV را با مدلی مبتنی بر ریسک جایگزین کرده که می‌تواند در پرریسک‌ترین موارد ظرف سه روز اقدام بخواهد. CERT-EU با استناد به گزارش M-Trends 2026 گوگل، میانگین زمان بهره‌برداری از آسیب‌پذیری‌های تازه افشاشده را حدود منفی هفت روز برآورد می‌کند، در برابر ۶۳ روز در ۲۰۱۸، در حالی که چرخه وصله سازمان‌ها معمولاً هنوز ۳۰ تا ۶۰ روز است.

چرا نامه بانک مرکزی اروپا برای همه بانک‌ها مهم است، نه فقط در اروپا

کلودیا بوخ، رئیس هیئت نظارت بانک مرکزی اروپا، در ۷ ژوئیه ۲۰۲۶ (۱۶ تیر ۱۴۰۵) به مدیران عامل همه مؤسسه‌های بزرگ نامه نوشت. در این نامه آمده است مدل‌های نوظهور هوش مصنوعی می‌توانند آسیب‌پذیری‌ها را شناسایی کنند و اکسپلویت‌های کارا را «با سرعتی بی‌سابقه» بسازند و این «تغییری بلندمدت در چشم‌انداز تهدید است، نه پدیده‌ای موقت یا ریسکی وابسته به یک ابزار خاص». نامه مسئولیت را بر عهده هیئت‌مدیره‌ها می‌گذارد و از بانک‌ها می‌خواهد سرمایه‌گذاری فناوری اطلاعات، تخصیص منابع و چارچوب‌های تحمل ریسک را بازبینی کنند.

هر بانک بزرگ باید تا ۳۱ اکتبر ۲۰۲۶ برنامه اقدام خود را به تیم نظارت مشترکش ارائه می‌داد. در کوتاه‌مدت، بانک مرکزی اروپا از بانک‌ها خواست:

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

اقدام‌های ساختاری بلندمدت‌ترند: دفاع در عمق، اصول اعتماد صفر (Zero Trust)، جایگزینی یا محافظت از فناوری‌های قدیمی و پایان‌عمر، و پاسخ و بازیابی آزموده‌شده که سناریوهای حمله پرسرعت و پرحجم را پوشش دهد. دو جزئیات عملی برجسته‌اند. بانک مرکزی اروپا می‌خواهد چارچوب‌های اشتهای ریسک شاخص‌ها و آستانه‌های تحمل برای مواردی مانند تناوب وصله را دربر گیرند، و انتظار دارد مدیریت تغییر و توافق‌نامه‌های سطح خدمت با تأمین‌کنندگان از رفع سریع و مبتنی بر ریسک پشتیبانی کنند. برای آزاد کردن ظرفیت، مهلت پرسش‌نامه سالانه ریسک فناوری اطلاعات را از سپتامبر ۲۰۲۶ به فوریه ۲۰۲۷ منتقل کرد و همه برنامه‌های ارسالی را به‌صورت افقی تحلیل خواهد کرد. هیئت ریسک سیستمی اروپا (ESRB) هم در همان روز هشداری درباره ریسک‌های سایبری سیستمی ناشی از مدل‌های پیشرو هوش مصنوعی منتشر کرد.

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

واقعاً چه چیزی تغییر کرده است

شواهد اکتبر را که کنار هم بگذاریم، به سه تحول می‌رسیم.

۱. هزینه تبدیل یک وصله به اکسپلویت فروریخته است. هزار دلار و یک محیط آزمایش ساده در دسترس بازیگران بسیار بیشتری است تا تیم‌های تخصصی که پیش‌تر کار مقایسه وصله‌ها (Patch Diffing) را انجام می‌دادند. هر وصله منتشرشده در نرم‌افزاری که شما اجرا می‌کنید اکنون علامتی برای مهاجمان است.

۲. گلوگاه مدافعان ظرفیت انسانی است، نه تشخیص. PostgreSQL کمبود یافته نداشت؛ کمبود ساعت کاری توسعه‌دهندگان اصلی داشت. تیم‌های عملیات امنیت، مدیریت تغییر و توسعه نرم‌افزار شما هم با همین حساب روبه‌رو هستند.

۳. حجم برابر ریسک نیست، اما سرعت هست. بیشتر CVEهای تازه هرگز بهره‌برداری نمی‌شوند. اندک مواردی که می‌شوند، به‌ویژه روی تجهیزات لبه شبکه، ظرف چند روز یا حتی پیش از وجود وصله مورد حمله قرار می‌گیرند. اولویت‌بندی، نه پوشش کامل، نتیجه را تعیین می‌کند.

دیدگاه من: مدیریت وصله امنیتی را بر پایه ساعت بسازید، نه چرخه

بخش بزرگی از کارنامه من صرف اداره سامانه‌های حیاتی بانکی شده است؛ جایی که هر پنجره تغییر رویدادی بود که با دقت درباره‌اش مذاکره می‌شد. آن مدل فرض می‌کرد مهاجمان برای تبدیل یک وصله عمومی به سلاح چند هفته وقت لازم دارند. دیگر این‌طور نیست. این راهنمای مدیریت وصله امنیتی است که با تیم مدیریت یک بانک به کار می‌برم.

۱. دارایی‌های در معرض خود را دقیق بشناسید. سیاهه‌ای زنده از دارایی‌های در معرض اینترنت، تجهیزات لبه شبکه، نرم‌افزارهای اشخاص ثالث و مؤلفه‌های متن‌باز با یک مالک مشخص برای هر مورد نگه دارید. بانک مرکزی اروپا بی‌دلیل این را در صدر فهرست نگذاشته است: چیزی را که در چند دقیقه پیدا نمی‌کنید، نمی‌توانید در چند ساعت وصله کنید.

۲. وصله را به دو مسیر تقسیم کنید. چرخه عادی را برای بیشتر وصله‌ها نگه دارید و یک مسیر اضطراری برای آسیب‌پذیری‌های فهرست KEV یا در حال بهره‌برداری روی سامانه‌های در معرض بسازید؛ با رویه‌های تغییر از پیش تأییدشده و هدفی که با ساعت تا روز سنجیده می‌شود.

۳. شکاف وصله تأمین‌کنندگان حیاتی را زیر نظر بگیرید. فقط زمان انتشار نسخه را دنبال نکنید؛ زمانی را دنبال کنید که وصله مؤلفه‌های کلیدی متن‌باز و تجاری شما عمومی می‌شود، و برای همان پنجره کنترل‌های جبرانی مانند قواعد فایروال برنامه وب (WAF)، وصله مجازی و محدودیت دسترسی را از پیش آماده کنید.

۴. اعداد را وارد اشتهای ریسک کنید. زمان رفع آسیب‌پذیری‌های بحرانی روی سامانه‌های در معرض، سهم تجهیزات لبه شبکه روی نسخه‌های پشتیبانی‌شده و فاصله ثبت در KEV تا اجرای راهکار کاهش ریسک باید در داشبورد هیئت‌مدیره باشد؛ همان چیزی که بانک مرکزی اروپا اکنون انتظار دارد.

۵. سرعت وصله را وارد قرارداد تأمین‌کنندگان کنید. از برون‌سپاری‌ها، ارائه‌دهندگان ابری و تأمین‌کنندگان کور بانکی بپرسید افشای شتاب‌گرفته را چطور مدیریت می‌کنند و به چه زمانی برای رفع آسیب‌پذیری متعهد می‌شوند. در چارچوب بانک مرکزی اروپا، بانک همچنان پاسخ‌گوی کامل ریسک فناوری برون‌سپاری‌شده است.

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

۷. سامانه‌های پایان‌عمر را بازنشسته یا جدا کنید. پلتفرم‌های بدون پشتیبانی هرگز وصله‌ای را که یک سامانه هوش مصنوعی سرانجام پیدا می‌کند دریافت نخواهند کرد. همان‌طور که در مقاله نوسازی کور بانکینگ در ۲۰۲۶ توضیح دادم، کورهای قدیمی را می‌توان پوشاند و گام‌به‌گام نوسازی کرد، اما هر چیزی که وصله‌پذیر نیست باید بخش‌بندی شود و از نزدیک پایش شود.

۸. برای موج وصله نیرو بگذارید و تمرین کنید. برای وصله‌های پرتکرارتر بودجه در نظر بگیرید، سناریوهای پرحجم و روز صفر (Zero-Day) را تمرین کنید و به سازوکارهای قابل‌اعتماد تبادل اطلاعات تهدید بپیوندید. بانک‌هایی که واجد شرایط‌اند باید برنامه‌های دسترسی مدافعان مانند Fairwind را هم، با رعایت حاکمیتی که این برنامه‌ها لازم دارند، ارزیابی کنند.

این الگو آشناست. در مقاله رمزنگاری پساکوانتومی در ۲۰۲۶ توضیح دادم چطور سیاهه رمزنگاری و چابکی رمزنگاری یک تهدید دور را به برنامه‌ای قابل مدیریت تبدیل می‌کند. نامه بانک مرکزی اروپا هم همین پیوند را برقرار می‌کند و می‌گوید پذیرش رمزنگاری پساکوانتومی «باید از همین حالا آغاز شود» و نامه‌ای جداگانه درباره ریسک کوانتومی در راه است. سیاهه دارایی، تغییر سریع و ایمن و مالکیت پاسخ‌گو، پایه مشترک هر دو است.

سخن پایانی

اکتبر ۲۰۲۶ ثابت نکرد هوش مصنوعی برتری دائمی به مهاجمان داده است. کشف آسیب‌پذیری در هر دو سو شتاب گرفته و بخش بزرگی از آنچه هوش مصنوعی آشکار می‌کند، بدهی امنیتی چند دهه است که سرانجام پرداخت می‌شود. آنچه ثابت شد این است که فاصله میان انتشار یک وصله و وجود یک اکسپلویت را اکنون می‌توان با ساعت و دلار سنجید، نه با هفته و تیم‌های متخصص. بانک‌هایی که از این دوره به‌خوبی عبور می‌کنند، آن‌هایی نیستند که بیشترین اسکنر را دارند؛ آن‌هایی‌اند که دارایی‌های در معرض خود را سریع پیدا می‌کنند، در چند ساعت تصمیم می‌گیرند، ایمن تغییر می‌دهند و اعداد را به ناظرانشان نشان می‌دهند.

منابع

مقاله‌های مرتبط

رمزنگاری پساکوانتومیامنیت بانکیرایانش کوانتومیچابکی رمزنگاری

رمزنگاری پساکوانتومی در ۲۰۲۶: چرا بانک‌ها مهلت مهاجرت را جلو می‌کشند

گوگل و کلودفلر حالا سال ۲۰۲۹ را هدف گرفته‌اند، یک فرمان اجرایی در آمریکا مهلت‌های ۲۰۳۰ و ۲۰۳۱ را تعیین کرده و نهادهای پرداخت از تأمین‌کنندگان پرسش‌نامه آمادگی می‌خواهند. در ۲۰۲۶ چه تغییر کرد، تهدید کوانتومی برای سامانه‌های بانکی واقعاً چه معنایی دارد و مدیر فناوری چطور یک برنامه مرحله‌ای مهاجرت به رمزنگاری پساکوانتومی را به هیئت‌مدیره ارائه کند.

· ۱۳ دقیقه مطالعه

کور بانکینگایجنت هوش مصنوعیفناوری بانکیحاکمیت هوش مصنوعی

نوسازی کور بانکینگ در ۲۰۲۶: ایجنت‌های هوش مصنوعی روی سامانه‌های قدیمی، حفاظ‌های زمان اجرا و انتخاب میان پوشش یا جایگزینی

در مهر ۱۴۰۵ چهار خبر، بحث نوسازی کور بانکینگ را از نو تعریف کرد. Sutherland و FlowX.AI پیشنهاد دادند بیش از ۲۲۰ ایجنت هوش مصنوعی را روی همان سامانه کور بانکی که بانک‌ها امروز دارند اجرا کنند، Emprise Bank یک کور بومیِ هوش مصنوعی از Maximum برگزید، SBS هوش مصنوعی مولد حاکمیتی را درون پلتفرم کور خود آورد و BBVA اعلام کرد معماری مرجع OpenShell انویدیا را برای کنترل ایجنت‌ها در زمان اجرا بررسی می‌کند. هر مسیر برای سامانه‌های کور بانکی قدیمی چه معنایی دارد، ریسک‌ها کجاست و یک راهنمای عملی برای مدیران فناوری بانک.

· ۱۴ دقیقه مطالعه

ایجنت هوش مصنوعیارزیابی ایجنتبنچمارکفناوری بانکی

بنچمارک ایجنت هوش مصنوعی در ۲۰۲۶: چرا جدول‌های رتبه‌بندی گمراه می‌کنند و بانک‌ها چطور باید ایجنت‌ها را ارزیابی کنند

در مهر ۱۴۰۵ دانشگاه استنفورد، Salesforce AI Research و گروهی به رهبری Tencent پژوهش‌های تازه‌ای درباره بنچمارک ایجنت هوش مصنوعی منتشر کردند و بانک‌های Santander و TD توضیح دادند ایجنت‌ها را پیش از استقرار چطور می‌آزمایند. نتایج تازه درباره اعتبار جدول‌های رتبه‌بندی، کارهای طولانی و امتیاز پیشرفت جزئی چه می‌گویند و یک راهنمای عملی ارزیابی ایجنت برای بانک‌ها و سازمان‌ها.

· ۱۰ دقیقه مطالعه