مهندسی عاملیت‌محور برای بانک‌ها: نقشه‌راه ۲۰۲۶ برای مدیران ارشد و مهندسانی که آن را خواهند ساخت

TL;DR. هوش مصنوعی عاملیت‌محور در سراسر بانکداری جهانی از مرحله آزمایشی به تولید عبور کرده است. ۷۰٪ از مؤسسات تا حدی از آن استفاده می‌کنند؛ تنها یک نفر از هر پنج نفر مدل حاکمیتی بالغی دارد. در همین حال، دشمنان خودمختار با سرعت ماشین عمل می‌کنند، پیکره میراثی COBOL که سامانه‌های جدید باید با آن هم‌کنش داشته باشند برای فرض‌های پردازش دسته‌ای دهه ۱۹۶۰ نوشته شده است، و مهلت پرخطر قانون هوش مصنوعی اتحادیه اروپا در اوت ۲۰۲۶ تنها دوازده هفته فاصله دارد. این همان جایگاه مهندسی و حاکمیتی است که یک بانک باید حفظ کند.

نکات کلیدی

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

مهندسی عاملیت‌محور برای بانک‌ها: نقشه‌راه ۲۰۲۶ برای مدیران ارشد و مهندسانی که آن را خواهند ساخت

هوش مصنوعی عاملیت‌محور در سراسر بانکداری جهانی از مرحله آزمایشی به تولید عبور کرده است. هفتاد درصد از مؤسسات تا حدی از آن استفاده می‌کنند؛ تنها یک نفر از هر پنج نفر مدل حاکمیتی بالغی دارد. در همین حال، دشمنان خودمختار با سرعت ماشین عمل می‌کنند، پیکره میراثی COBOL که سامانه‌های جدید باید با آن هم‌کنش داشته باشند برای فرض‌های پردازش دسته‌ای دهه ۱۹۶۰ نوشته شده است، و مهلت پرخطر قانون هوش مصنوعی اتحادیه اروپا دوازده هفته فاصله دارد. این همان جایگاه مهندسی و حاکمیتی است که یک بانک باید حفظ کند.

نکات کلیدی

گذار از vibe coding به توسعه مبتنی‌بر مشخصات دیگر یک آرمان نیست. آندری کارپاتی، که اصطلاح «vibe coding» را در فوریه ۲۰۲۵ ابداع کرد، یک سال بعد اذعان کرد ⧉ که آن دوران در حال پایان است و پیش‌فرض جدید برای حرفه‌ای‌ها مهندسی عاملیت‌محور است — هدایت عامل‌ها در برابر مشخصات دقیق با نظارت انسانی.

پذیرش در بانکداری واقعی و شتابنده است. ۷۰٪ از شرکت‌های بانکی ⧉ گزارش می‌دهند که تا حدی از هوش مصنوعی عاملیت‌محور استفاده می‌کنند (۱۶٪ در تولید، ۵۲٪ در مرحله آزمایشی، EY 2026)؛ ۴۴٪ از تیم‌های مالی امسال از آن استفاده خواهند کرد — رشدی بیش از ۶۰۰٪ نسبت به سال گذشته بنا بر Wolters Kluwer.

حاکمیت با این سرعت پیش نرفته است. گزارش «وضعیت هوش مصنوعی ۲۰۲۶» دیلویت نشان می‌دهد تنها یک شرکت از هر پنج شرکت مدل حاکمیتی بالغی برای عامل‌های خودمختار هوش مصنوعی دارد. تحلیل دیلویت از پایگاه‌داده ریسک هوش مصنوعی MIT بیش از ۳۵۰ ریسک ⧉ را شناسایی می‌کند که می‌تواند از رفتار خودمختار یا عاملیت‌محور برخیزد.

چشم‌انداز تهدید صنعتی شده است. آنتروپیک در نوامبر ۲۰۲۵ افشا کرد که گروه تحت حمایت دولت چین با نام GTG-1002، Claude Code را ربود تا جاسوسی خودمختار را علیه حدود ۳۰ هدف اجرا کند، در حالی که هوش مصنوعی ۸۰ تا ۹۰٪ عملیات تاکتیکی را به‌طور مستقل انجام می‌داد. Flashpoint یک افزایش ۱٬۵۰۰ درصدی در بحث‌های غیرقانونی مرتبط با هوش مصنوعی ⧉ را تنها بین نوامبر و دسامبر ۲۰۲۵ مشاهده کرد.

پیکره میراثی محدودیت خاموش است. ۷۰ تا ۷۵٪ از بودجه‌های فناوری اطلاعات خدمات مالی صرف نگهداشت سامانه‌های میراثی می‌شود، ۶۳٪ از بانک‌ها هنوز به کدی متکی‌اند که پیش از سال ۲۰۰۰ نوشته شده است، و بیشتر بانک‌ها گزارش می‌دهند که تنها یک یا دو نفر در داخل سازمان توانایی نگهداشت COBOLی را دارند که سکوهای اصلی‌شان بر آن اجرا می‌شود. هوش مصنوعی عاملیت‌محور اکنون رویکرد غالب برای بستن این شکاف است.

پشته مقرراتی در حال هم‌گرایی است. تحت قانون هوش مصنوعی اتحادیه اروپا، ۲ اوت ۲۰۲۶ اجرایی‌شدن کامل برای سامانه‌های هوش مصنوعی پرخطر را فعال می‌کند (پیوست III صراحتاً امتیازدهی اعتباری و ارزیابی اعتبارسنجی را شامل می‌شود). DORA هم‌اکنون لازم‌الاجراست. SR 11-7 در رویه ناظران گسترش یافته تا LLMها و سامانه‌های عاملیت‌محور را نیز پوشش دهد. جریمه‌های نقض به ۳۵ میلیون یورو یا ۷٪ گردش مالی سالانه جهانی می‌رسد.

نظارت انسانی یک مفهوم واحد نیست. تمایز میان HITL (انسان‌در‌حلقه، جایی که عامل نمی‌تواند بدون تأیید صریح انسان اجرا کند) و HOTL (انسان‌بر‌حلقه، جایی که عامل به‌طور خودمختار زیر نظارت انسانی اجرا می‌کند) اکنون چارچوب عملی برای انطباق با ماده ۱۴ قانون هوش مصنوعی اتحادیه اروپا است، و هر عامل پرخطر به موضعی صریح درباره اینکه کدام مدل اعمال می‌شود نیاز دارد.

بیشتر عامل‌ها خریده خواهند شد، نه ساخته. مدیریت ریسک شخص‌ثالث تحت DORA پُرصداترین چالش کم‌شناخته‌شده ۲۰۲۶ است. فروشندگان بیشتر ظرفیت عاملیت‌محوری را که بانک‌ها به‌کار می‌گیرند تأمین خواهند کرد؛ الزام مقرراتی نزد بانک باقی می‌ماند، و بیشتر قراردادهای موجود فروشندگان نمی‌توانند الزامات مستندسازی ماده ۱۳ را برآورده کنند.

مهندسی عاملیت‌محور «ChatGPT به‌علاوه سرورهای MCP» نیست. این یک موضع مالکیت ساختاری بر جریان‌های سرتاسری مؤسسه است — مسیرهای مشتری، چرخه‌های عمر تراکنش، صفحه کنترل، بستر ممیزی، بنیان رمزنگاری مقاوم در برابر کوانتوم — که توسط بخش مهندسی خودِ مؤسسه ساخته و بهره‌برداری می‌شود، نه واگذارشده به یک چت‌بات.

سالی که مهندسی عاملیت‌محور گریزناپذیر شد

گفتگو درباره هوش مصنوعی در خدمات مالی، تا همین اواخر، تحت سیطره دو چیز مجاور اما متمایز بوده است: رابط‌های چت مولد (مفید اما محدود)، و الگوهای تولید تقویت‌شده با بازیابی که روی داده‌های سازمانی لایه‌بندی می‌شوند (سودمند، اما باز هم محدود). آنچه بین اواخر ۲۰۲۵ و اوایل ۲۰۲۶ تغییر کرد این بود که دسته سوم — عامل‌های خودمختاری که گردش‌کارهای چندمرحله‌ای را با نظارت انسانی محدود برنامه‌ریزی، اجرا و تکمیل می‌کنند — از نمایش فنی به واقعیت عملیاتی درآمد و هم‌زمان هم به درون سازمان و هم به درون بازیگر تهدید نفوذ کرد.

آندری کارپاتی، که اصطلاح «vibe coding» را در فوریه ۲۰۲۵ ابداع کرد ⧉، سال بعد را صرف تماشای مهندسان حرفه‌ای‌ای کرد که از آن فراتر می‌رفتند. بازنگری او — «مهندسی عاملیت‌محور» — اکنون اصطلاح رایج در سراسر صنعت است. جوهر این تغییر ساده است: در کار جدی نرم‌افزار در ۲۰۲۶، مهندسان ۹۹٪ اوقات کد را مستقیماً نمی‌نویسند. آن‌ها عامل‌هایی را هدایت می‌کنند که این کار را انجام می‌دهند، در حالی که خود نقش نظارت را بر عهده دارند. کار دیگر تایپ‌کردن نویسه‌ها در یک ویرایشگر نیست؛ کار عبارت است از تولید مشخصاتی که آنچه عامل‌ها می‌توانند تولید کنند را محدود می‌کند، طراحی دروازه‌های وارسی‌ای که خروجی باید از آن‌ها بگذرد، و گزینش تصمیمات معماری‌ای که عامل‌ها پیاده‌سازی می‌کنند.

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

وضعیت پذیرش در بانکداری

تصویر کلی روشن است. بر اساس پژوهش‌های گردآوری‌شده در چند نظرسنجی سال ۲۰۲۶، ۷۰٪ از مدیران بانکی ⧉ گزارش می‌دهند که شرکت‌هایشان هم‌اکنون تا حدی از هوش مصنوعی عاملیت‌محور استفاده می‌کنند. گارتنر پیش‌بینی می‌کند ⧉ که تا پایان ۲۰۲۶ تقریباً ۴۰٪ از همه شرکت‌های خدمات مالی به‌نوعی عامل‌های هوش مصنوعی را اجرا خواهند کرد. هزینه‌کرد هوش مصنوعی در خدمات مالی در مسیر رسیدن به ۶۷ میلیارد دلار تا سال ۲۰۲۸ است (IDC). مکنزی برآورد می‌کند هوش مصنوعی عاملیت‌محور می‌تواند ۱۰ تا ۱۲ ساعت در هفته را به مدیران روابط در بانکداری بازگرداند.

تصویر اجرا کمتر دلگرم‌کننده است. KPMG گزارش می‌دهد ⧉ که ۹۹٪ از شرکت‌ها قصد دارند عامل‌های خودمختار را به تولید برسانند اما تنها ۱۱٪ چنین کرده‌اند. EY درمی‌یابد که ۳۴٪ از رهبران شروع به استفاده از عامل‌های هوش مصنوعی کرده‌اند و تنها ۱۴٪ آن‌ها را به‌طور کامل پیاده‌سازی کرده‌اند. Forrester درمی‌یابد که ۵۷٪ از سازمان‌ها معتقدند فاقد قابلیت‌های داخلی برای بهره‌بردن از هوش مصنوعی عاملیت‌محور هستند. شکاف میان قصد و اجرا یک محصول تبلیغاتی نیست. بازتاب واقعی کار مهندسی، حاکمیتی و فرهنگی‌ای است که هنوز انجام نشده است.

اداره نظارت مالی بریتانیا (FCA) علناً نگرانی‌هایی مطرح کرده است ⧉ درباره اینکه سرعت به‌کارگیری از بلوغ حاکمیت پیشی می‌گیرد — تنشی که مدیر ارشد داده FCA، جسیکا راسو، آن را به‌عنوان یک ریسک کوتاه‌مدت برای مصرف‌کننده خرد تعریف کرده است. مکنزی جداگانه هشدار داد که بانک‌هایی که در تطبیق مدل‌های کسب‌وکار خود ناکام بمانند ⧉ خطر از دست دادن تا ۱۷۰ میلیارد دلار سود جهانی تا سال ۲۰۳۰ را به جان می‌خرند. هر دو مشاهده هم‌زمان درست‌اند. پرسش این نیست که آیا باید حرکت کرد؛ پرسش این است که چگونه با آن یکپارچگی عملیاتی و حاکمیتی حرکت کنیم که مقررات خدمات مالی همواره طلبیده‌اند و سامانه‌های عاملیت‌محور آن را تیزتر می‌کنند.

سه بردار ریسک که بانک‌ها باید درونی کنند

پیش از هرگونه گفتگوی معماری، توجه هیئت‌مدیره باید بر سه ریسکی متمرکز باشد که ویژه سامانه‌های عاملیت‌محورند و زودتر از آنچه بیشتر بانک‌ها برنامه‌ریزی کرده‌اند فرا می‌رسند.

۱. دشمن خودمختار

گیج‌کننده‌ترین تحول ۲۰۲۶ عملیاتی‌شدن هوش مصنوعی عاملیت‌محور در سمت حمله است. در اوت ۲۰۲۵، آنتروپیک دسته‌ای از فعالیت را افشا کرد که آن را vibe hacking ⧉ نامید: مجرمان سایبری که از هوش مصنوعی عاملیت‌محور برای انجام حملات پیچیده در مقیاس استفاده می‌کنند، در حالی که هوش مصنوعی در سراسر شناسایی، برداشت اعتبارنامه‌ها، نفوذ به شبکه و تحلیل داده‌های سرقتی جاسازی شده است. در نوامبر ۲۰۲۵ ⧉، آنتروپیک افشا کرد که کارزاری از یک گروه تحت حمایت دولت چین (با نام GTG-1002) را مختل کرده است که نمونه‌های Claude Code را ربود تا جاسوسی خودمختار را علیه حدود سی هدف دفاعی، انرژی و فناوری اجرا کند، در حالی که هوش مصنوعی ۸۰ تا ۹۰٪ عملیات تاکتیکی را انجام می‌داد و با هزاران درخواست در ثانیه عمل می‌کرد — سرعت‌هایی که برای اپراتورهای انسانی ناممکن‌اند.

در ژانویه ۲۰۲۶، Step Finance — یک مدیر پرتفوی DeFi مبتنی بر Solana — به‌گونه‌ای در معرض خطر قرار گرفت که یک نفوذ به دستگاه را به زیانی ۲۷ تا ۳۰ میلیون دلاری تبدیل کرد، زیرا عامل‌های معاملاتی هوش مصنوعی این شرکت مجوز اجرای انتقال‌های بزرگ را بدون تأیید انسانی داشتند. مهاجم خودِ هوش مصنوعی را با مهندسی اجتماعی فریب داد و ادعا کرد که در حال اجرای یک برنامه مجاز باگ‌بانتی است. درس ⧉ این نبود که هوش مصنوعی ذاتاً ناامن است؛ درس این بود که یک عامل هوش مصنوعی که مجوز ادعایی را بدون وارسی می‌پذیرد، یک نقطه‌ضعف محیطی است.

روند کلی همان چیزی است که بانک‌ها باید درونی کنند. گزارش اطلاعات تهدید جهانی ۲۰۲۶ Flashpoint یک افزایش ۱٬۵۰۰ درصدی در بحث‌های غیرقانونی مرتبط با هوش مصنوعی ⧉ را بین نوامبر و دسامبر ۲۰۲۵ شناسایی کرد، جایی که مهاجمان فعالانه سامانه‌های خودمختاری می‌سازند که داده‌ها را استخراج می‌کنند، زیرساخت را می‌چرخانند، پیام‌رسانی را تنظیم می‌کنند و بدون نظارت انسانی مستمر از تلاش‌های ناموفق می‌آموزند. جیمی دایمن از JPMorgan علناً صریح بوده است ⧉ که مزیت اولیه در این فناوری به حمله می‌رسد، نه دفاع. دلالت آن ناخوشایند است: بانکی که عملیات امنیتی کلاسیک را علیه دشمنان عاملیت‌محور اجرا می‌کند، از نظر ساختاری، در جایگاه یک شطرنج‌بازی است که به حریفش رایانه‌ای داده‌اند.

۲. پس‌رفت کیفیت کد

بردار دوم درونی و آرام‌تر است. کد تولیدشده توسط LLM، در نبود انضباط مشخصات و وارسی دقیق، با نرخ نقصی به‌مراتب بالاتر از کد نوشته‌شده توسط انسان عرضه می‌شود. یک تحلیل SonarQube از پنج LLM پیشتاز ⧉ که کد Java تولید می‌کردند نشان داد بیش از ۷۰٪ از آسیب‌پذیری‌های شناسایی‌شده در خروجی Llama 3.2 90B با شدت BLOCKER رده‌بندی شدند، و تقریباً دو‌سوم آسیب‌پذیری‌های GPT-4o و OpenCoder-8B با درجه BLOCKER یا CRITICAL ارزیابی شدند. پیرس و همکاران (IEEE S&P) دریافتند تقریباً ۴۰٪ از برنامه‌های تولیدشده توسط LLM در بافت‌های حساس امنیتی حاوی آسیب‌پذیری بودند. یان و همکاران (۲۰۲۵) این بازه را در سراسر معیارهایشان ۹.۸ تا ۴۲.۱٪ برآورد کردند. فهرستی جداگانه از فو و همکاران ۴۳ مورد CWE را در سه ابزار تولید کد هوش مصنوعی شناسایی کرد.

برای یک صنعت غیرمقرراتی، این یک مالیات بر بهره‌وری است. برای یک بانک، این یک ریسک مقرراتی و عملیاتی است که انباشته می‌شود. کدی که با نرخ آسیب‌پذیری بالا وارد سامانه‌ای می‌شود که پرداخت‌ها، تسویه یا داده‌های مشتری را مدیریت می‌کند، یک مسئله کیفیت کد در مقام انتزاع نیست؛ سطحی است که دشمنان از جنس GTG-1002 در سال ۲۰۲۷ با همان ابزارهای عاملیت‌محوری که آن را تولید کردند کاوش خواهند کرد. دفاع، ممنوع‌کردن کد تولیدشده توسط LLM نیست (که تجاری‌ناممکن است) بلکه احاطه‌کردن آن با زیرساخت وارسی و مشخصاتی است که تضمین می‌کند نقص‌ها پیش از به‌کارگیری آشکار شوند. این دلیل عملی است که توسعه مبتنی‌بر مشخصات با سرعت پذیرفته می‌شود توسط سازمان‌های مهندسی که ذاتاً شرکت‌های فناوری نیستند.

۳. لنگر میراثی

بردار سوم همان است که بانک‌ها پیش‌تر بهتر از همه درک می‌کنند، و گذار عاملیت‌محور آن را هم‌زمان فوری‌تر و قابل‌حل‌تر کرده است. بیش از ۷۰٪ از شرکت‌های Fortune 500 هنوز به مِین‌فریم‌ها متکی‌اند، همان‌طور که تحلیل Computer Weekly اشاره می‌کند ⧉، که اغلب بر دهه‌ها COBOL و RPG درهم‌تنیده با منطق کسب‌وکار سفارشی بنا شده‌اند. به‌طور خاص در خدمات مالی، فناوری‌های میراثی ۷۰ تا ۷۵٪ از هزینه‌کرد سالانه فناوری اطلاعات ⧉ را می‌بلعند. یک پژوهش CIO که در تحلیل صنعتی ۲۰۲۶ به آن استناد شده دریافت که ۶۳٪ از بانک‌ها هنوز به کدی متکی‌اند که پیش از سال ۲۰۰۰ نوشته شده است، و بیش از ۷۵٪ گزارش دادند که تنها یک یا دو نفر در داخل سازمان مهارت نگهداشت آن را دارند.

آنچه در فوریه ۲۰۲۶ تغییر کرد ورود ابزارهای عاملیت‌محور معتبر برای نوسازی میراثی بود. اعلام آنتروپیک مبنی بر اینکه Claude Code می‌تواند وابستگی‌های COBOL را نگاشت کند، گردش‌کارها را مستند کند و ریسک‌هایی را شناسایی کند ⧉ که آشکارکردن آن‌ها ماه‌ها زمان از تحلیلگران انسانی می‌گرفت — در کنار قابلیت‌های مشابه از مایکروسافت (GitHub Copilot برای COBOL، Watsonx Code Assistant) و AWS (نوسازی مِین‌فریم با هوش مصنوعی عاملیت‌محور) — منحنی هزینه نوسازی را به‌طور محسوسی فشرده کرده است. واکنش در قیمت سهام IBM (یک افت ۱۳ درصدی در روز اعلام) یک سیگنال بازار ناشیانه اما دقیق بود. هوش مصنوعی اکنون تقریباً یک‌سوم سرمایه‌گذاری نوسازی سازمانی را تشکیل می‌دهد، و بیش از ۷۵٪ از سازمان‌ها در راهبرد نوسازی خود از هوش مصنوعی استفاده می‌کنند. لنگر میراثی، برای نخستین بار، یک مسئله مهندسیِ قابل‌حل است تا یک مسئله نسلی.

چرا vibe coding نمی‌تواند پیش‌فرض در بانکداری باشد

ارزش دارد که دقیق باشیم درباره اینکه چرا vibe coding — دستور کوتاه، مشاهده خروجی، تکرار — به‌عنوان یک گردش‌کار پیش‌فرض در یک پیکره مقرراتی شکست می‌خورد. حالت شکست، حالت بدیهی نیست (اینکه LLM گاهی توهم می‌زند). حالت شکست ساختاری است و هم‌زمان در چهار جا نمایان می‌شود.

نخستین نبود قراردادهای مشترک است. چند مهندس که از طریق دستورهای چت کار می‌کنند، در یک کدپایه واحد و ظرف یک سه‌ماهه، پنج روش متفاوت برای انجام یک کار خواهند ساخت. در بافت غیرمقرراتی، این بدهی فنی است. در بافت مقرراتی، این سطحی است که زیر بازرسی می‌شکند.

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

سومین انباشت نامرئی نقص است. یافته‌های پیرس، یان و SonarQube که در بالا به آن‌ها استناد شد موارد استثنایی نیستند. آن‌ها نرخ پایه‌ای هستند که LLMها در نبود انضباط مشخصات و آزمون دقیق کد آسیب‌پذیر تولید می‌کنند. بانکی که گردش‌کارهای vibe-coding را در تولید اجرا می‌کند، این نقص‌ها را با همان نرخ انباشته می‌کند، بدون آن دید سطحی که بداند چه چیزی عرضه شده است.

چهارمین مسئله ردیابی‌پذیری مقرراتی است. ماده ۱۲ قانون هوش مصنوعی اتحادیه اروپا ثبت خودکار ورودی‌ها و خروجی‌ها را برای سامانه‌های هوش مصنوعی پرخطر الزامی می‌کند. SR 11-7 نقش‌های مستندشده مالک و اعتبارسنج مدل، مدیریت تغییر برای به‌روزرسانی‌های مدل، و گزارش‌دهی به هیئت‌مدیره درباره ریسک مدل هوش مصنوعی را الزامی می‌کند. DORA مدیریت جامع ریسک ICT با شواهد مستند را الزامی می‌کند. هیچ‌یک از این تعهدات را نمی‌توان با گردش‌کاری برآورده کرد که مصنوع اصلی‌اش یک تاریخچه چت است که هیچ‌کس آن را پایدار نمی‌سازد.

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

توسعه مبتنی‌بر مشخصات در یک پیکره مقرراتی

توسعه مبتنی‌بر مشخصات (SDD) ترتیب کار را وارونه می‌کند. به‌جای پریدن به پیاده‌سازی و تکرار با یک عامل، تیم نخست یک مشخصات تولید می‌کند — تصمیمات معماری، الزامات، قراردادهای واسط، معیارهای موفقیت، محدودیت‌های امنیتی — و عامل کدی تولید می‌کند که مشخصات را برآورده می‌کند. وارسی ساختارمند است: مشخصات تعریف می‌کند خروجی چه باید بکند، و یک فرایند جداگانه (تولید آزمون، بازبینی کد، وارسی صوری در جایی که قابل‌اعمال است) بررسی می‌کند که آیا انجام شده است.

ابزارِ عملی در اواخر ۲۰۲۵ و اوایل ۲۰۲۶ تثبیت شده است. Spec Kit گیت‌هاب ⧉ (منتشرشده در اواخر ۲۰۲۵) قصد را پیش از تولید کد صوری‌سازی می‌کند. AWS گردش‌کارهای مشخصات‌محور را مستقیماً در محیط توسعه Kiro خود جاسازی می‌کند. JetBrains و Cursor حالت‌های برنامه‌ریزی معرفی کرده‌اند که تعامل با هوش مصنوعی را ساختارمند می‌کنند. چارچوب‌هایی مانند BMAD (روش پیشگامانه برای توسعه چابک مبتنی‌بر هوش مصنوعی) با تیم‌هایی از عامل‌های تخصصی هوش مصنوعی که نقش‌های تحلیلگر، معمار، توسعه‌دهنده و QA را در سراسر چرخه عمر توسعه نرم‌افزار بازتاب می‌دهند فراتر می‌روند. SDD قانون‌اساسی‌محور، که در مقاله‌ای در arXiv در فوریه ۲۰۲۶ صوری‌سازی شد، محدودیت‌های امنیتی صریح را با نگاشت‌های آسیب‌پذیری CWE در خودِ مشخصات جاسازی می‌کند.

برای یک بانک، گونه‌ای که اهمیت دارد همان چیزی است که تحلیل Augment Code آن را توسعه لنگرشده به مشخصات می‌نامد — مشخصات نخست می‌آید، هوش مصنوعی کدی تولید می‌کند که با آن‌ها محدود شده، و لایه‌های حاکمیتی افزوده (محدودیت‌های قانون‌اساسی، ایست‌های بازرسی نظارتی، دروازه‌های تأیید انسانی) میان تولید و ادغام قرار می‌گیرند. این تنها گونه‌ای است که ردِ ممیزی مورد انتظار ماده ۱۲ قانون هوش مصنوعی اتحادیه اروپا، نقش مستند اعتبارسنج مورد الزام SR 11-7، و انضباط مدیریت‌تغییر مورد نیاز DORA را تولید می‌کند.

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

پشته مقرراتی که اکنون اعمال می‌شود

محیط مقرراتی ۲۰۲۶ پیرامون هوش مصنوعی در بانکداری دیگر یک سیاهه وارسی نیست؛ پشته‌ای از تعهدات هم‌پوشان است که باید درباره‌شان با هم اندیشید. مهم‌ترین تاریخ ۲ اوت ۲۰۲۶ است، هنگامی که تعهدات سامانه پرخطر قانون هوش مصنوعی اتحادیه اروپا کاملاً لازم‌الاجرا می‌شوند ⧉. پیوست III صراحتاً امتیازدهی اعتباری، ارزیابی اعتبارسنجی، ارزیابی ریسک در بیمه عمر و سلامت، و ارزیابی یا رده‌بندی وضعیت مالی افراد را پرخطر رده‌بندی می‌کند. تعهداتی که از این رده‌بندی برمی‌خیزند شامل ارزیابی‌های انطباق، سامانه‌های مدیریت کیفیت، چارچوب‌های مدیریت ریسک، مستندسازی فنی، ثبت در پایگاه‌داده اتحادیه اروپا، حاکمیت داده مستحکم، نظارت انسانی، و حفاظت‌های امنیت‌سایبری می‌شوند. جریمه‌های نقض تعهدات پرخطر به ۳۵ میلیون یورو یا ۷٪ گردش مالی سالانه جهانی، هر کدام که بیشتر باشد، می‌رسد.

در کنار قانون هوش مصنوعی:

DORA (قانون تاب‌آوری عملیاتی دیجیتال) از ژانویه ۲۰۲۵ لازم‌الاجرا بوده و ۲۲ تعهد مدیریت ریسک ICT ایجاد می‌کند که صراحتاً سامانه‌های هوش مصنوعی مورد استفاده در کارکردهای مالی حیاتی را پوشش می‌دهند. مدیریت ریسک ICT، نظارت بر شخص‌ثالث، گزارش رخداد، و آزمون تاب‌آوری عملیاتی به همان اندازه که برای هر دارایی ICT دیگر اعمال می‌شوند برای مؤلفه‌های هوش مصنوعی نیز اعمال می‌شوند.
SR 11-7 — راهنمای مدیریت ریسک مدل فدرال‌رزرو و OCC، که در اصل در سال ۲۰۱۱ نوشته شد — در رویه ناظران گسترش یافته است ⧉ تا LLMها و سامانه‌های عاملیت‌محور را پوشش دهد. بازرسی‌های FFIEC اکنون صراحتاً دامنه حاکمیت هوش مصنوعی را شامل می‌شوند. مؤسساتی که نمی‌توانند سیاهه مدل هوش مصنوعی و ارزیابی‌های ریسک را در صورت درخواست ارائه دهند، امروز یافته‌های تخلف دریافت می‌کنند.
NIST AI RMF (۱.۰، ژانویه ۲۰۲۳) در ایالات متحده داوطلبانه است اما به‌عنوان یک خط‌پایه توسط ناظران فدرال به آن ارجاع می‌شود. چهار کارکرد آن (حاکمیت، نگاشت، سنجش، مدیریت) به‌روشنی بر الزامات ساختاری قانون هوش مصنوعی اتحادیه اروپا منطبق می‌شوند.
ISO/IEC 42001 (منتشرشده در دسامبر ۲۰۲۳) نخستین استاندارد قابل‌گواهی سامانه مدیریت هوش مصنوعی است که مانند ISO/IEC 27001 برای امنیت اطلاعات ساختار یافته است. تقاضا برای گواهی 42001 در سه‌ماهه اول ۲۰۲۶ به‌شدت شتاب گرفت چون الزامات تدارکات شروع به استناد به آن کردند.
SM&CR و وظیفه مصرف‌کننده بریتانیا — رژیم مدیران ارشد و صدور گواهی اکنون پاسخگویی نام‌دار برای هر سامانه هوش مصنوعی پرخطر را الزامی می‌کند. وظیفه مصرف‌کننده در راهنمای اخیر FCA ⧉ گسترش یافته تا پیامدهای مشتری خردِ متأثر از هوش مصنوعی را پوشش دهد.
نقشه‌راه پساکوانتومی G7 (ژانویه ۲۰۲۶)، چارچوب مهاجرت سه‌مرحله‌ای NCSC، و یافته‌های Project Leap از BIS در کنار این پشته قرار می‌گیرند. نقطه تلاقی اهمیت دارد: سامانه هوش مصنوعی‌ای که بر بستری رمزنگاری که از گذار پساکوانتومی جان به‌در نمی‌برد آموزش یا بهره‌برداری شده، سامانه هوش مصنوعی‌ای است که ادعاهای ردِ ممیزی و یکپارچگی‌اش نیمه‌عمری کمتر از یک دهه دارند. گفتگو درباره مهندسی عاملیت‌محور و گفتگو درباره رمزنگاری پساکوانتومی، به‌طور فزاینده، یک گفتگو هستند. (برای نگاه عمیق‌تر به جنبه رمزنگاری، به یادداشت مه ۲۰۲۶ درباره مهاجرت پساکوانتومی در مالیه شرکتی مراجعه کنید.)

مقایسه سه حالت توسعه هوش‌مصنوعی‌یار

بُعد	Vibe Coding	توسعه مبتنی‌بر مشخصات	مهندسی عاملیت‌محور
ورودی اصلی	دستور کوتاه	مشخصات صوری	مشخصات + برنامه هدایت عامل
نقش مهندس	تکرارکننده دستور	نویسنده مشخصات	هدایت‌گر و وارسی‌کننده
انضباط خروجی	تولید مستقیم کد	کد محدودشده با مشخصات	گردش‌کارهای چندعاملی تولیدکننده کد، آزمون، مستندات
رد ممیزی	تاریخچه چت (پایدارنشده)	مشخصات + کد تولیدشده + آزمون‌ها	مشخصات + ردهای عامل + مصنوعات وارسی
نرخ نقص (فقط LLM)	نرخ آسیب‌پذیری ۱۰ تا ۴۰٪ (خط‌پایه پژوهش‌ها)	با محدودیت‌های مشخصات به‌طور محسوس کاهش‌یافته	کمترین با دروازه‌های وارسی
ردیابی‌پذیری مقرراتی	ناکافی برای هوش مصنوعی پرخطر	سازگار با ماده ۱۲ قانون هوش مصنوعی اتحادیه اروپا	طراحی‌شده برای ماده ۱۲ + SR 11-7 + DORA
مناسب برای بانکداری؟	خیر، برای تولید	بله، با حاکمیت	بله، با حاکمیت بالغ
سقف قابلیت	محدود به دستوردهی تک‌مرحله‌ای	محدود به کیفیت مشخصات	محدود به کیفیت هدایت

منبع: تلفیقی از تفسیر کارپاتی (۲۰۲۶)، تحلیل SDD از Augment Code ⧉، تحلیل توسعه مبتنی‌بر مشخصات از CGI ⧉، و ادبیات دانشگاهی درباره نرخ آسیب‌پذیری تولید کد توسط LLM (پیرس و همکاران، یان و همکاران، فو و همکاران، ۲۰۲۳–۲۰۲۵).

ساختن بانک عاملیت‌محور: یک نگاه معماری

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

لایه ۴ — صفحه کنترل عامل حاکمیت، ممیزی، کلیدهای توقف، تشخیص ناهنجاری رفتاری، بازپس‌گیری کنترل انسانی. پیکربندی‌های نظارتی HITL و HOTL برای هر رده عامل.

لایه ۳ — گردش‌کارهای عاملیت‌محور مسیرهای مشتری، عملیات داخلی، خط‌لوله توسعه. مشخصات‌محور به‌طور پیش‌فرض برای جریان‌های پرخطر.

لایه ۲ — لایه داده و مدل AIBOM (سیاهه اجزای هوش مصنوعی)، ثبت مدل، بستر بازیابی، کنترل نسخه قالب دستور، تبارشناسی تنظیم‌دقیق.

لایه ۱ — بنیان مقاوم در برابر کوانتوم ML-KEM، ML-DSA، PKI ترکیبی، چابکی رمزنگاری. بستری که ادعاهای یکپارچگی هر لایه بالاتر به آن بستگی دارد.

لایه ۱ — بنیان مقاوم در برابر کوانتوم. هر لایه بالای این، یکپارچگی بستر رمزنگاری را مفروض می‌گیرد. با نقشه‌راه G7، برنامه سه‌مرحله‌ای NCSC، و Project Leap از BIS، همگی در سابقه عمومی، این دیگر یک دغدغه خاص و کم‌اهمیت نیست. سامانه‌های عاملیت‌محوری که ردهای ممیزی‌شان زیر ECDSA کلاسیک امضا شده، یا استقرار کلیدشان به RSA یا ECDH بستگی دارد، ادعاهای یکپارچگی‌شان را همراه با آن رمزنگاری منقضی خواهند دید. مؤسساتی که این را درست انجام می‌دهند، کار پساکوانتومی را به بالادست می‌کشند و ML-KEM، ML-DSA و PKI ترکیبی را به‌عنوان بستری تلقی می‌کنند که تضمین‌های ممیزی و یکپارچگی هر لایه بالاتر بر آن استوار است.

لایه ۲ — لایه داده و مدل. اینجا جایی است که سیاهه اجزای هوش مصنوعی (AIBOM) زندگی می‌کند. مشابه سیاهه اجزای رمزنگاری که در برنامه‌ریزی مهاجرت پساکوانتومی به کار می‌رود، AIBOM سیاهه هر مدل، مجموعه‌داده، قالب دستور، شاخص بازیابی، تنظیم‌دقیق و وابستگی هوش مصنوعی شخص‌ثالثی است که مؤسسه بهره‌برداری می‌کند. این همان مصنوعی است که ماده ۴۹ قانون هوش مصنوعی اتحادیه اروپا عملاً الزام می‌کند، همان سیاهه‌ای که بازرسی‌های SR 11-7 اکنون درخواست می‌کنند، و بنیان هر موضع حاکمیتی معتبر. بیشتر مؤسسات یکی ندارند. تا اوت به یکی نیاز خواهند داشت.

لایه ۳ — گردش‌کارهای عاملیت‌محور. این لایه‌ای است که بیشتر مؤسسات در حال حاضر می‌سازند، اغلب بدون توجه کافی به لایه‌های ۱، ۲ و ۴. خودِ گردش‌کارها از داخلی (تولید کد، پیش‌نویس اسناد مقرراتی، دسته‌بندی خدمات مشتری) تا مشتری‌محور (هم‌خلبان‌های مدیر روابط، پذیرش مشتری، هماهنگی KYC، پایش تراکنش، بهینه‌سازی FX) تا کاملاً خودمختار (عملیات خزانه‌داری، برخی کارکردهای معاملاتی و مدیریت ریسک در جایی که تحمل ناظر اجازه دهد) گسترده‌اند. انضباط راهبردی در این لایه این است که آن را مهندسی سامانه تلقی کنیم، نه توسعه کاربرد — الگوهای هدایت، قواعد تشدید، دروازه‌های انسان‌در‌حلقه، و صدور ممیزی، دغدغه‌های طراحی درجه‌یک هستند.

لایه ۴ — صفحه کنترل عامل. این همان چیزی است که دیلویت آن را «اتاق کنترل عامل» توصیف کرده است ⧉: زیرساخت ممیزی بی‌درنگ، ثبت کنش، تشخیص ناهنجاری رفتاری، کلیدهای توقف، و بازپس‌گیری کنترل انسانی که هر عامل را در تولید احاطه می‌کند. زیان Step Finance، از نظر فنی، یک شکست هوش مصنوعی نبود. یک شکست صفحه کنترل بود: عامل‌ها مجوزهایی داشتند که نباید می‌داشتند، و ناهنجاری رفتاری‌ای که باید یک توقف را راه‌اندازی می‌کرد چنین نکرد. مؤسساتی که ابتدا صفحه کنترل را می‌سازند — پیش از مقیاس‌دادن به‌کارگیری عامل — همان‌هایی هستند که در سال ۲۰۲۷ رخدادهایی از جنس Step Finance را نخواهند دید.

مقایسه مرتبط برای مدیران ارشد این نیست که «آیا ما بیش از رقبایمان هوش مصنوعی به کار می‌بریم؟» بلکه این است که آیا مؤسسه همه چهار لایه را در اختیار دارد، یا اینکه یک یا چند لایه به‌طور خاموش به فروشنده‌ای واگذار شده که هیچ توانایی قراردادی برای برآورده‌کردن الزامات مستندسازی ماده ۱۳ قانون هوش مصنوعی اتحادیه اروپا ندارد. مورد دوم جایگاهی است که تا وقتی یک ناظر پرسش را باز نکند خوب به نظر می‌رسد.

نظارت انسانی در عمل: HITL در برابر HOTL

تنها تمایزی درون لایه ۴ که ناظران در ۲۰۲۶ بیش از همه بر آن متمرکزند، میان دو مدل نظارت است. هر دو گونه‌ای از نظارت انسانی‌اند؛ آن‌ها در تأخیر، مقیاس و فرضی که ناظر حاضر است درباره رفتار عامل بپذیرد تفاوت دارند.

انسان‌در‌حلقه (HITL) مدلی است که در آن عامل نمی‌تواند بدون تأیید صریح انسان یک کنش پیامددار را اجرا کند. عامل تصمیم را آماده می‌کند، آن را ارائه می‌دهد، و منتظر می‌ماند. یک عامل رفع‌نقص KYC که یک حساب را برای بستن علامت می‌زند اما نمی‌تواند بدون تأیید یک افسر انطباق آن را ببندد، HITL است. مصالحه عملیاتی است: HITL امن‌تر است و یک ردِ ممیزی روشن مطابق ماده ۱۴ تولید می‌کند، اما به گردش‌کارهای پرحجم و کم‌تأخیر مقیاس نمی‌گیرد.

انسان‌بر‌حلقه (HOTL) مدلی است که در آن عامل به‌طور خودمختار درون پارامترهای محدود اجرا می‌کند، در حالی که انسان‌ها سنجه‌ها را بی‌درنگ پایش می‌کنند و اختیار توقف عامل را در هر نقطه حفظ می‌کنند. یک عامل غربالگری تقلبِ بی‌درنگ که تراکنش‌های منطبق با الگوهای ریسک مشخص را به‌طور خودکار مسدود می‌کند، در حالی که یک تیم عملیات انسانی حجم هشدارها را تماشا می‌کند و در ناهنجاری‌ها مداخله می‌کند، HOTL است. مصالحه وارونه است: HOTL مقیاس می‌گیرد، اما به درست‌بودن پارامترهای عامل و به تشخیص ناهنجاری رفتاری‌ای که پیش از انباشت آسیب انحراف را می‌گیرد متکی است.

ماده ۱۴ قانون هوش مصنوعی اتحادیه اروپا HITL در برابر HOTL را تجویز نمی‌کند؛ الزام می‌کند که نظارت انسانی معنادار باشد. دلالت عملی این است که هر عامل پرخطری که بانک بهره‌برداری می‌کند باید موضعی صریح و مستند درباره اینکه کدام مدل اعمال می‌شود، چرا، و مسیر تشدید چیست هنگامی که عامل با موقعیت‌های بیرون از پارامترهای محدودش روبه‌رو می‌شود، داشته باشد. بیشتر بانک‌هایی که در ۲۰۲۵ آزمایش‌ها را اجرا می‌کردند این مستندسازی را نداشتند. بیشتر بانک‌هایی که تا اوت ۲۰۲۶ عامل‌های تولیدی را اجرا می‌کنند به آن نیاز خواهند داشت.

قاعده تصمیم پیچیده نیست. برای کنش‌های پیامددار، کم‌حجم و برگشت‌ناپذیر — رد اعتبار به یک شخص حقیقی، بستن حساب، مجوز حواله بزرگ‌ارزش، ثبت اظهارنامه مقرراتی — HITL پیش‌فرض قابل‌دفاع است. برای کنش‌های پرحجم، برگشت‌پذیر و پارامتر‌محدود — هشدارهای پایش تراکنش، دسته‌بندی اسناد، دسته‌بندی روزمره خدمات مشتری — HOTL مناسب است، به‌شرط آنکه زیرساخت تشخیص ناهنجاری رفتاری و کلید توقف بالغ باشد. بانک‌هایی که هر گردش‌کار را HITL تلقی می‌کنند اهرم عملیاتی سامانه‌های عاملیت‌محور را به‌دست نخواهند آورد. بانک‌هایی که هر گردش‌کار را HOTL تلقی می‌کنند سرانجام یک لحظه Step Finance خواهند داشت.

خرید در برابر ساخت: مسئله عامل شخص‌ثالث

واقعیت ۲۰۲۶ که به‌آرامی بر بیشتر بانک‌ها چیره شده این است که آن‌ها، عمدتاً، ظرفیت عاملیت‌محور را نخواهند ساخت. آن را خواهند خرید. چشم‌انداز فروشندگان — سکوی بانکداری عاملیت‌محور Oracle که در فوریه ۲۰۲۶ راه‌اندازی شد، Watsonx شرکت IBM، مجموعه Copilot مایکروسافت، AWS Bedrock Agents، Salesforce Agentforce، NowAssist شرکت ServiceNow، و موج فروشندگان عامل متخصص فین‌تک — سریع‌تر از مهندسی داخلی بانک حرکت می‌کند. پیامد راهبردی این است که بیشتر عامل‌هایی که در سال ۲۰۲۷ درون یک بانک عمل می‌کنند توسط شخص دیگری نوشته شده‌اند، و پرسش حاکمیتی دیگر «آیا می‌توانیم به عامل‌هایمان اعتماد کنیم؟» نیست بلکه «آیا می‌توانیم به عامل‌هایی که تدارک دیده‌ایم اعتماد کنیم، و آیا می‌توانیم به یک ناظر ثابت کنیم که می‌توانیم؟» است.

این پُرصداترین چالش کم‌شناخته‌شده تحت DORA است. مواد ۲۸ تا ۳۰ این مقررات، مدیریت ریسک شخص‌ثالث ICT را به یک حوزه نظارتی فعال تبدیل می‌کنند، با الزامات صریحی که مفاد قراردادی، پایش مستمر، ارزیابی ریسک تمرکز، و راهبردهای خروج را پوشش می‌دهند. مقامات نظارتی اروپا فهرستی از ارائه‌دهندگان حیاتی شخص‌ثالث ICT را نگهداری می‌کنند، با اختیارات نظارتی مستقیم بر آن‌هایی که چنین تعیین شده‌اند. واقعیت عملیاتی جدید این است که فروشندگان هوش مصنوعی ۲۰۲۶ — ارائه‌دهندگان مدل پیشتاز، فروشندگان سکوی عامل، SaaS مجهز به هوش مصنوعی — به‌طور فزاینده همان اشخاص ثالث ICTی هستند که DORA برای پوشش آن‌ها نوشته شد.

برای بانکی در موضع خرید، سه انضباط عملی اعمال می‌شود:

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

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

قراردادها را بر اساس شرایط ماده ۱۳ بازمذاکره کنید. بیشتر توافق‌نامه‌های موجود فروشنده هوش مصنوعی هیچ‌یک از الزامات مستندسازی، حقوق ممیزی، اطلاع‌رسانی تغییر مدل، گزارش رخداد، یا افشای پردازنده فرعی را که قانون هوش مصنوعی اتحادیه اروپا و DORA با هم می‌طلبند دربر نمی‌گیرند. تحلیل Regulativ از شرکت‌های بریتانیایی ⧉ در این نکته صریح بود: بازبینی حقوقی توافق‌نامه‌های فروشنده هفته‌ها زمان می‌برد، و بیشتر مؤسسات نمی‌توانند ماده ۱۳ را برای مدلی برآورده کنند که فروشنده‌شان هیچ‌گاه قراردادی متعهد به افشای سازوکارهای درونی آن نشده است. الزام مقرراتی نزد به‌کارگیرنده قرار دارد، نه فروشنده. تیم‌های تدارکات باید این را پیش از چرخه تمدید بعدی بدانند، نه پس از یک پرس‌وجوی مقرراتی.

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

این برای هر نوع بانک چه معنایی دارد

پاسخ درست متفاوت است. الگوی زیر یک بخش‌بندی تقریبی است، نه یک نسخه.

بانک‌های جامع رده‌یک

مؤسساتی با ترازنامه‌های بیش از ۱ تریلیون دلار و حضور جهانی هم‌زمان بیشترین در معرض قرار (گسترده‌ترین محیط مقرراتی، بزرگ‌ترین پیکره میراثی، پرارزش‌ترین هدف برای دشمنان خودمختار) و بهترین‌تجهیزشده‌اند. اولویت راهبردی این است که ابتدا صفحه کنترل را بسازند — لایه ۴ معماری بالا — و انضباط توسعه مبتنی‌بر مشخصات را به بخش مهندسی داخلی بیاورند پیش از آنکه به‌کارگیری عامل را بیشتر مقیاس دهند. پیامد رقابتی درست‌انجام‌دادن این کار معنادار است؛ پیامد نادرست‌انجام‌دادن آن، با توجه به در معرض قرار جریمه تحت قانون هوش مصنوعی اتحادیه اروپا و در معرض قرار عملیاتی در برابر الگوهای تهدید از جنس GTG-1002، وجودی است.

بانک‌های رده‌میانی و منطقه‌ای

پرسش رقابتی برای بانک‌های رده‌دو تیزتر از رده‌یک است. آن‌ها با همان محیط مقرراتی بدون همان بودجه حاکمیتی، همان سطح تهدید بدون همان منابع دفاعی، و پایگاه مشتری‌ای روبه‌رویند که به‌طور فزاینده آن‌ها را با فین‌تک‌های هوش‌مصنوعی‌بومی مقایسه می‌کند. پاسخ عملی این است که به‌شدت روی مجموعه کوچکی از فروشندگان بررسی‌شده استانداردسازی کنند (با قراردادهایی که الزامات مستندسازی ماده ۱۳ را برآورده می‌کنند)، در انضباط توسعه مبتنی‌بر مشخصات به‌جای مهندسی سکوی سفارشی سرمایه‌گذاری کنند، و از ابزارهای عاملیت‌محور برای فشرده‌کردن جدول‌زمانی نوسازی COBOL که دو دهه لنگر راهبردی بوده استفاده کنند. مؤسساتی که اینجا زود حرکت کنند، برای نخستین بار در یک نسل، شکاف فناوری با بانک‌های رده‌یک را به‌طور محسوس خواهند بست.

فین‌تک‌ها، مؤسسات پرداخت (PSP) و نهادهای نزدیک به رمزارز

بخش فین‌تک و مؤسسات پرداخت مسئله وارونه دارد: چابکی بالاست، حاکمیت اغلب پایین‌تر از بانک‌های همتاست، و در معرض قرار جریمه قانون هوش مصنوعی اتحادیه اروپا، برای یک فین‌تک متوسط، بالقوه وجودی است. انضباط راهبردی این است که حاکمیت هوش مصنوعی را به‌عنوان یک دروازه آمادگی محصول تلقی کنند تا یک لایه انطباق روکشی — با ساختن AIBOM، بستر ممیزی، و گردش‌کارهای مبتنی‌بر مشخصات در فرهنگ مهندسی از همان آغاز به‌جای نصب مجدد آن‌ها زیر فشار مقرراتی. برای مؤسساتی که زیرساخت پرداختشان با مهلت آدرس ساختاریافته CBPR+ شبکه SWIFT در نوامبر ۲۰۲۶ تلاقی دارد، سرمایه‌گذاری در مهندسی عاملیت‌محور همچنین سازوکار طبیعی برای صنعتی‌کردن کار رفع‌نقص آدرس ساختاریافته است — قواعد اعتبارسنجی، اجرای کیفیت داده، و یکپارچگی خط‌لوله CI دقیقاً همان الگوهایی هستند که گردش‌کارهای مبتنی‌بر مشخصات آن‌ها را قابل‌حل می‌کنند.

بخش‌های مهندسی داخلی

برای مهندسان و پژوهشگرانی که این را می‌خوانند، انضباط کاری‌ای که اهمیت دارد همان انضباط روزانه است. مرکز ثقل کار را از تایپ نویسه‌ها به تولید مشخصات و بست‌های وارسی منتقل کنید. ردهای عامل، برنامه‌های میانی، و دروازه‌های تأیید را به‌عنوان مصنوعات درجه‌یک در کنترل نسخه خود تلقی کنید. در ابزار — Spec Kit، Kiro، حالت برنامه Cursor، Claude Code با فایل‌های مهارت در سطح پروژه — سرمایه‌گذاری کنید که مشخصات را مصنوع پایدار و کد تولیدشده را مصنوع دورریختنی می‌سازد. تغییر ارگونومیک واقعی است. پاداش حرفه‌ای این است که انضباطی که در مرزهای پیشتاز پذیرفته می‌شود همان انضباطی است که از بازرسی مقرراتی جان به‌در می‌برد.

برنامه اقدام ۱۲ هفته‌ای تا اوت ۲۰۲۶

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

هفته‌های ۱ تا ۲ — AIBOM را تولید کنید. سیاهه متمرکز هر سامانه هوش مصنوعی، مدل، مجموعه‌داده، قالب دستور، شاخص بازیابی، تنظیم‌دقیق، و وابستگی هوش مصنوعی شخص‌ثالث در تولید یا در دست توسعه را برپا کنید. هر مدخل را به رده‌بندی پیوست III قانون هوش مصنوعی اتحادیه اروپا نگاشت کنید. تحویل‌دادنی یک منبع واحد حقیقت است که CRO، CCO، CISO و CTO هر یک می‌توانند از آن پرس‌وجو کنند.

هفته‌های ۳ تا ۴ — مدل نظارت را برای هر سامانه رده‌بندی کنید. برای هر عامل پرخطر و پیامددار، صراحتاً مستند کنید که مدل نظارت HITL است یا HOTL، منطق آن، مسیر تشدید، و انسان نام‌داری که تحت SM&CR (بریتانیا) یا رژیم ملی معادل پاسخگو است. جایی که پاسخ نامشخص است، تا تکمیل تحلیل به HITL پیش‌فرض بگیرید.

هفته‌های ۵ تا ۶ — صفحه کنترل عامل را بسازید یا مستحکم کنید. ثبت کنش بی‌درنگ، تشخیص ناهنجاری رفتاری، مسیرهای کلید توقف و بازپس‌گیری کنترل روی هر عامل تولیدی عملیاتی باشد. جایی که صفحه کنترل هنوز برای یک سامانه وجود ندارد، آن سامانه تا زمانی که ایجاد شود به وضعیت به‌کارگیری محدود می‌رود.

هفته‌های ۷ تا ۸ — بازبینی قرارداد فروشنده. بخش حقوقی و تدارکات هر قرارداد فعال فروشنده هوش مصنوعی را از نظر حقوق مستندسازی ماده ۱۳، اطلاع‌رسانی تغییر مدل، گزارش رخداد، حقوق ممیزی، و افشای پردازنده فرعی وارسی می‌کنند. خروجی یک فهرست رده‌بندی‌شده است: منطبق، نیازمند رفع‌نقص، نیازمند جایگزینی. تصمیمات جایگزینی باید همین حالا آغاز شوند تا هر شانسی برای تکمیل امسال داشته باشند.

هفته‌های ۹ تا ۱۰ — تمرین اجرای ارزیابی انطباق. برای هر سامانه پرخطر تحت پیوست III، گردش‌کار ارزیابی انطباق را چنان تکمیل کنید که گویی یک نهاد اعلام‌شده هفته بعد از راه می‌رسد. این کار شکاف‌هایی را آشکار می‌کند که روی کاغذ جزئی به نظر می‌رسند و زیر بازرسی از نظر عملیاتی جدی‌اند. آنچه قابل‌رفع است را رفع کنید؛ باقی‌مانده را مستند کنید.

هفته‌های ۱۱ تا ۱۲ — اعتبارسنجی پیش از راه‌اندازی و تأیید هیئت‌مدیره. بازبینی نهایی AIBOM، رده‌بندی‌های HITL/HOTL، شواهد صفحه کنترل، وضعیت رفع‌نقص فروشنده، و خروجی‌های ارزیابی انطباق. پاسخگویی مدیر ارشد نام‌دار تأیید‌شده. موضع در صورت‌جلسه هیئت‌مدیره ثبت شود. جایی که چارچوب انتظار پیش‌اعلام دارد، به ناظر اطلاع دهید.

مؤسساتی که این توالی دوازده‌هفته‌ای را تکمیل کنند مهندسی عاملیت‌محور را حل نکرده‌اند. آن‌ها کف موردنیاز یک برنامه معتبر را برپا کرده‌اند. مؤسساتی که تا زمان انتشار این مقاله شروع نکرده‌اند، همان‌طور که تحلیل Regulativ همین نکته را در سمت SWIFT بیان کرد، به‌طور منحصربه‌فرد سهل‌انگار نیستند. آن‌ها اکثریت‌اند. پرسشی که هر CCO، CRO و CTO باید در دو هفته آینده به آن پاسخ دهد این است که آیا شرکت در مه اقدام می‌کند یا در ژوئیه دست‌وپا می‌زند.

نتیجه‌گیری

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

مؤسساتی که این موضع را به‌طور داخلی در اختیار می‌گیرند — که مهندسی عاملیت‌محور را یک قابلیت ساختاری بانک تلقی می‌کنند تا یک لایه بهره‌وری روکشیِ خریداری‌شده از یک فروشنده — دو سال آینده را صرف انباشت مزیت خواهند کرد. مؤسساتی که چنین نکنند دو سال آینده را صرف کشف — در گزارش‌های رخداد و یافته‌های ناظر — آنچه باید می‌ساختند خواهند کرد. انتخاب میان این دو پیامد یک تصمیم سطح هیئت‌مدیره در ۲۰۲۶ است، نه یک تصمیم فناوری در ۲۰۲۸.

برای بافت پیشین در این سایت، یادداشت آوریل ۲۰۲۶ درباره آستانه‌های کوانتومی مسیر سخت‌افزاری‌ای را پوشش داد که زیربنای لایه ۱ معماری بالاست، یادداشت مه ۲۰۲۶ درباره مهاجرت پساکوانتومی برای مالیه شرکتی بستر رمزنگاری را به‌طور عمیق پوشش داد، تحلیل مه ۲۰۲۶ درباره مهلت آدرس ساختاریافته pacs.008 انضباط مقرراتی و مهندسی‌ای را پوشش داد که اعتبارسنجی مبتنی‌بر مشخصات آن را قابل‌حل می‌کند، و کار متن‌باز Rust روی KyberLib، pain001 و pacs008 در تلاش گسترده‌تری برای گذاشتن ابتدایی‌های در سطح تولید — مقاوم در برابر کوانتوم، منطبق با پرداخت، آماده ممیزی — در دستان تیم‌های مهندسی‌ای قرار دارد که بانک عاملیت‌محور را خواهند ساخت. پیوند میان این نوشته‌ها اتفاقی نیست. شکل کاری است که دو سال آینده می‌طلبد.

پرسش‌های پرتکرار

تفاوت میان هوش مصنوعی مولد، هوش مصنوعی عاملیت‌محور و مهندسی عاملیت‌محور چیست؟

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

چرا مهلت اوت ۲۰۲۶ قانون هوش مصنوعی اتحادیه اروپا برای بانک‌ها این‌قدر پیامددار است؟

پیوست III قانون هوش مصنوعی صراحتاً چند کاربرد اصلی هوش مصنوعی در بانکداری را پرخطر رده‌بندی می‌کند: ارزیابی اعتبارسنجی و امتیازدهی اعتباری اشخاص حقیقی، ارزیابی ریسک و قیمت‌گذاری در بیمه عمر و سلامت، و ارزیابی یا رده‌بندی وضعیت مالی افراد. از ۲ اوت ۲۰۲۶، به‌کارگیرندگان این سامانه‌ها باید انطباق با سامانه‌های مدیریت کیفیت، چارچوب‌های مدیریت ریسک، مستندسازی فنی، ارزیابی‌های انطباق، ثبت در پایگاه‌داده اتحادیه اروپا، حاکمیت داده مستحکم، نظارت انسانی، و حفاظت‌های امنیت‌سایبری را نشان دهند. ماده ۱۲ ثبت خودکار ورودی‌ها و خروجی‌ها را الزامی می‌کند. ماده ۱۴ نظارت انسانی معنادار (HITL یا HOTL، متناسب با سامانه) را الزامی می‌کند. جریمه‌های نقض به ۳۵ میلیون یورو یا ۷٪ گردش مالی سالانه جهانی می‌رسد. کار برای برآورده‌کردن این تعهدات کارِ مهندسی است — نه کار مستندسازی — و همان دلیل عملی است که انضباط مبتنی‌بر مشخصات در سه‌ماهه اول ۲۰۲۶ شتاب گرفته است.

تفاوت عملی میان HITL و HOTL چیست، و هر یک چه زمانی باید اعمال شود؟

HITL (انسان‌در‌حلقه) یعنی عامل نمی‌تواند کنش‌های پیامددار را بدون تأیید صریح انسان اجرا کند. HOTL (انسان‌بر‌حلقه) یعنی عامل به‌طور خودمختار درون پارامترهای محدود اجرا می‌کند، در حالی که انسان‌ها سنجه‌ها را پایش می‌کنند و اختیار توقف را در هر نقطه حفظ می‌کنند. ماده ۱۴ قانون هوش مصنوعی اتحادیه اروپا الزام می‌کند نظارت معنادار باشد اما تجویز نمی‌کند کدام مدل. قاعده تصمیم این است که HITL را جایی اعمال کنیم که کنش پیامددار، کم‌حجم و برگشت‌ناپذیر است (رد اعتبار، بستن حساب، مجوز حواله بزرگ‌ارزش، ثبت اظهارنامه مقرراتی)؛ و HOTL را جایی که کنش پرحجم، برگشت‌پذیر و پارامتر‌محدود است (هشدارهای پایش تراکنش، دسته‌بندی اسناد، دسته‌بندی روزمره خدمات مشتری). هر دو نیازمند آن‌اند که زیرساخت کلید توقف و بازپس‌گیری کنترل عملیاتی و آزموده باشد؛ تفاوت در این است که آیا انسان بالادست اجراست (HITL) یا در کنار آن (HOTL).

بیشتر عامل‌های ما از فروشندگان خواهند آمد. چگونه DORA و قانون هوش مصنوعی اتحادیه اروپا را برای سامانه‌هایی که نساخته‌ایم برآورده کنیم؟

الزام مقرراتی نزد به‌کارگیرنده قرار دارد، نه فروشنده. پاسخ عملی سه‌بخشی است. نخست، پیش از امضا یک AIBOM مستند از فروشنده مطالبه کنید — تبار مدل، منشأ داده آموزش، تنظیم‌دقیق‌ها، قالب‌های دستور، شاخص‌های بازیابی، زنجیره وابستگی. دوم، آزمون رفتاری عامل را تحت شرایطی مشابه با تولید انجام دهید، از جمله کاوش خصمانه برای تزریق دستور و مقاومت در برابر مهندسی اجتماعی. سوم، قراردادهای فروشنده را بازمذاکره کنید تا حقوق مستندسازی ماده ۱۳، اطلاع‌رسانی تغییر مدل، گزارش رخداد، حقوق ممیزی، و افشای پردازنده فرعی را دربر گیرند — بیشتر قراردادهای موجود هیچ‌یک از این‌ها را ندارند. مواد ۲۸ تا ۳۰ DORA مدیریت ریسک شخص‌ثالث ICT را پوشش می‌دهند و لنگر مقرراتی مرتبط در سمت اروپا هستند؛ راهنمای FFIEC معادل آن در سمت ایالات متحده است. کار معنادار است؛ نمی‌توان آن را به تعویق انداخت.

بانک‌ها واقعاً باید چقدر نگران دشمنان عاملیت‌محور باشند؟

پاسخ صادقانه این است که تهدید واقعی است و از نظر عملیاتی از تهدیدهای سایبری پیشین متمایز است. افشای نوامبر ۲۰۲۵ آنتروپیک درباره GTG-1002 نمونه شاخص است: هوش مصنوعی عاملیت‌محور که ۸۰ تا ۹۰٪ عملیات تاکتیکی را در یک کارزار جاسوسی تحت حمایت دولت در سراسر حدود سی هدف دفاعی، انرژی و فناوری انجام می‌داد، و با هزاران درخواست در ثانیه عمل می‌کرد. رخداد Step Finance در ژانویه ۲۰۲۶ — زیانی ۲۷ تا ۳۰ میلیون دلاری که با عامل‌های معاملاتی هوش مصنوعیِ دارای اختیار پرمجوز رقم خورد — نمونه شاخص آن است که چگونه یک به‌کارگیری داخلی هوش مصنوعی می‌تواند به یک سطح حمله تبدیل شود. گزارش GTIR سال ۲۰۲۶ Flashpoint یک افزایش ۱٬۵۰۰ درصدی در بحث‌های غیرقانونی مرتبط با هوش مصنوعی را در یک ماه واحد مشاهده کرد. این‌ها سناریوهای فرضی نیستند؛ مواد گزارش رخداد ۲۰۲۵–۲۰۲۶ هستند. بانک‌هایی که عملیات دفاعی کلاسیک را علیه دشمنان عاملیت‌محور اجرا می‌کنند، از نظر ساختاری، به‌طور نامتقارن در معرض قرارند، و پاسخ درست ساختن ظرفیت دفاعی هوش‌مصنوعی‌علیه‌هوش‌مصنوعی است تا کندکردن گذار عاملیت‌محور در سمت تهاجمی.

آیا هوش مصنوعی عاملیت‌محور صرفاً «ChatGPT به‌علاوه سرورهای MCP» است؟

خیر، و این یکی از پیامددارترین کژفهمی‌ها در بازار کنونی است. یک رابط چت که با سرورهای MCP تقویت شده الگوی سودمندی برای بازیابی و کنش روی داده درون یک نشست محدود است. مهندسی عاملیت‌محور یک قابلیت ساختاری مؤسسه است — AIBOM، صفحه کنترل عامل، خط‌لوله توسعه مبتنی‌بر مشخصات، بستر ممیزی، بنیان رمزنگاری مقاوم در برابر کوانتوم، الگوهای هدایت در سراسر مسیرهای سرتاسری مشتری. این‌ها ویژگی‌هایی نیستند که از یک فروشنده خریده شوند؛ یک موضع مالکیت نهادی هستند. بانک‌هایی که پرسش را یک تصمیم تدارکاتی تلقی می‌کنند با به‌کارگیری‌های کم‌عمقی به پایان می‌رسند که زیر بازرسی شکست می‌خورند. بانک‌هایی که آن را یک پرسش مالکیت مهندسی و حاکمیتی تلقی می‌کنند با دارایی‌ای به پایان می‌رسند که انباشته می‌شود.

مهم‌ترین کار واحدی که یک بانک باید در دوازده هفته آینده انجام دهد چیست؟

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

منابع

Sebastien Rousseau, (2026). ایمن‌سازی دفتر کل: راهنمای سطح هیئت‌مدیره برای مهاجرت پساکوانتومی در مالیه شرکتی.
Sebastien Rousseau, (2026). مهلت نشانی ساختاریافته pacs.008 در نوامبر ۲۰۲۶: نگاهی شش‌ماهه.
Sebastien Rousseau, (2026). Quantum Thresholds Are Moving Again.
Sebastien Rousseau, (2023). CRYSTALS-Kyber: الگوریتم محافظ در عصر کوانتومی.
Mansurova, M. (2026). From Vibe Coding to Spec-Driven Development ⧉. Towards Data Science.
CGI, (2026). Spec-driven development: From vibe coding to intent engineering ⧉. CGI.
Augment Code, (2026). What Is Spec-Driven Development? A Complete Guide ⧉. Augment Code.
BCMS, (2026). Spec-Driven Development: The Definitive 2026 Guide ⧉. BCMS.
Deloitte, (2026). Managing the new wave of risks from AI agents in banking ⧉. Deloitte Center for Financial Services.
Anthropic, (2025). Detecting and countering misuse of AI: August 2025 ⧉. Anthropic.
Anthropic, (2025). Disrupting the first reported AI-orchestrated cyber espionage campaign ⧉. Anthropic.
Flashpoint, (2026). 2026 Global Threat Intelligence Report ⧉. HSToday / Flashpoint.
Beam AI, (2026). 5 Real AI Agent Security Breaches in 2026 and Their Lessons ⧉. Beam.
Congressional Research Service, (2026). Agentic Artificial Intelligence and Cyberattacks ⧉. Congress.gov.
European Commission, (2024). Regulation (EU) 2024/1689 on Artificial Intelligence (EU AI Act).
Knowlee, (2026). EU AI Act for Financial Services: Annex III Obligations for Banks, Fintechs, and Insurers ⧉. Knowlee.
Regulativ, (2026). The EU AI Act's August 2026 Deadline: What Financial Services Firms Must Do Now ⧉. Finextra.
AegisAI Compliance, (2026). AI Governance for Banks: SR 11-7 & EU AI Act Compliance Guide ⧉. AegisAI.
The Financial Brand, (2026). How Autonomous AI Agents Will Really Redefine Banking Growth ⧉. The Financial Brand.
UXDA, (2026). Could Agentic AI Banking Threaten Global Financial Services? ⧉. UXDA.
Neurons Lab, (2026). Agentic AI in Financial Services: A Research Roundup for 2026 ⧉. Neurons Lab.
Computer Weekly, (2026). AI to help mainframes remain business critical in 2026 ⧉. Computer Weekly.
The Financial Revolutionist, (2026). Legacy systems are putting banks at risk ⧉. The Financial Revolutionist.
CIO Magazine, (2025). Using AI to modernize mainframes: Turning legacy tech into a strategic advantage ⧉. CIO Magazine.
Microsoft Azure, (2025). How We Use AI Agents for COBOL Migration and Mainframe Modernization ⧉. Microsoft DevBlogs.
VentureBeat, (2026). Agentic coding at enterprise scale demands spec-driven development ⧉. VentureBeat.
The News (Pakistan), (2026). Why British banks' push for agentic AI is worrying UK regulators ⧉. The News International.
CNBC, (2026). Anthropic's Mythos set off a cybersecurity 'hysteria' ⧉. CNBC.

آخرین بازبینی 2026-07-17.

بازنشر این مقاله

مهندسی عاملیت‌محور برای بانک‌ها: نقشه‌راه ۲۰۲۶ برای مدیران ارشد و مهندسانی که آن را خواهند ساخت — Sebastien Rousseau

هوش مصنوعی عاملیت‌محور در سراسر بانکداری جهانی از مرحله آزمایشی به تولید عبور کرده است. ۷۰٪ از مؤسسات تا حدی از آن استفاده می‌کنند؛ تنها یک نفر از هر پنج نفر مدل حاکمیتی بالغی دارد. در همین حال، دشمنان خودمختار با سرعت ماشین عمل می‌کنند، پیکره میراثی COBOL که سامانه‌های جدید باید با آن هم‌کنش داشته باشند برای فرض‌های پردازش دسته‌ای دهه ۱۹۶۰ نوشته شده است، و مهلت پرخطر قانون هوش مصنوعی اتحادیه اروپا در اوت ۲۰۲۶ تنها دوازده هفته فاصله دارد. این همان جایگاه مهندسی و حاکمیتی است که یک بانک باید حفظ کند.

این مقاله تحت مجوز زیر منتشر شده است Creative Commons Attribution 4.0 International. بازنشر مستلزم ذکر منبع با ارجاع به نشانی اصلی (canonical) است.

مهندسی عاملیت‌محور برای بانک‌ها: نقشه‌راه ۲۰۲۶ برای مدیران ارشد و مهندسانی که آن را خواهند ساخت — Sebastien Rousseau

هوش مصنوعی عاملیت‌محور در سراسر بانکداری جهانی از مرحله آزمایشی به تولید عبور کرده است. ۷۰٪ از مؤسسات تا حدی از آن استفاده می‌کنند؛ تنها یک نفر از هر پنج نفر مدل حاکمیتی بالغی دارد. در همین حال، دشمنان خودمختار با سرعت ماشین عمل می‌کنند، پیکره میراثی COBOL که سامانه‌های جدید باید با آن هم‌کنش داشته باشند برای فرض‌های پردازش دسته‌ای دهه ۱۹۶۰ نوشته شده است، و مهلت پرخطر قانون هوش مصنوعی اتحادیه اروپا در اوت ۲۰۲۶ تنها دوازده هفته فاصله دارد. این همان جایگاه مهندسی و حاکمیتی است که یک بانک باید حفظ کند.

Originally published at https://sebastienrousseau.com/fa/2026-05-17-agentic-engineering-banks-blueprint-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER