دو سال است که بانک‌ها ایجنت‌های هوش مصنوعی را در خدمات مشتری، عملیات مقابله با تقلب، کار اعتباری و توسعه نرم‌افزار سریع‌تر از آن به کار می‌گیرند که ناظران بتوانند توضیح دهند «کنترل خوب» چه شکلی دارد. در ۱۳ آبان ۱۴۰۵ (۴ نوامبر ۲۰۲۶) اداره کنترل‌کننده پول آمریکا (Office of the Comptroller of the Currency یا OCC) نخستین پاسخ جدی را منتشر کرد. بخشنامه OCC شماره 2026-54 یک چارچوب نظارتی معرفی می‌کند که به بازرسان این نهاد می‌گوید استفاده بانک‌ها از هوش مصنوعی مولد و عاملی را چطور ارزیابی کنند؛ فناوری‌ای که این نهاد به پیروی از فرمان اجرایی 14434 مورخ ۱۰ مهر ۱۴۰۵ (۲ اکتبر ۲۰۲۶) اکنون «ابرهوش» (Super Intelligence یا SI) می‌نامد. این چارچوب از نظر رسمی فروتن است: انتظار تازه‌ای از بانک‌ها تعیین نمی‌کند و استاندارد الزام‌آوری نمی‌سازد. اما در عمل، همان‌طور که مؤسسه‌های حقوقی مشاور بانک‌ها به‌سرعت یادآوری کردند، روشن‌ترین بیان تا امروز از چیزی است که بازرسان هنگام بررسی یک ایجنت هوش مصنوعی خواهند خواست. برای مدیران فناوری در هر کشوری، نه فقط بانک‌های ملی آمریکا، این سند یکی از کاربردی‌ترین چک‌لیست‌های حاکمیت هوش مصنوعی است که یک نهاد ناظر منتشر کرده است.
چارچوب نظارتی هوش مصنوعی OCC دقیقاً چیست
این بسته سه بخش دارد: اطلاعیه خبری 2026-97، بخشنامه 2026-54 و یک سند بیست‌صفحه‌ای برای بازرسان با عنوان چارچوب نظارتی OCC برای استفاده بانک‌ها از ابرهوش. OCC «ابرهوش» را به معنای همان فناوری‌هایی به کار می‌برد که پیش‌تر زیر تعریف قانونی هوش مصنوعی (15 USC 9401(3)) قرار داشتند، «و نیز نوید، توان بالقوه و قابلیت‌های به‌سرعت رو به پیشرفت این فناوری‌ها». به بیان دیگر، موضوع این سند همان هوش مصنوعی‌ای است که بانک‌ها امروز اجرا می‌کنند، نه یک سامانه فرضی آینده.
چهار گزاره جایگاه و دامنه چارچوب را تعیین می‌کند:
- منبعی برای بازرسان است. OCC می‌گوید این سند انتظار نظارتی، استاندارد الزام‌آور یا الزام دستوری تعیین نمی‌کند و از بانک‌ها انتظار نمی‌رود با آن مدیریت ریسک هوش مصنوعی خود را بسنجند. به بازرسان گفته شده کارشان را با اهمیت هر مورد استفاده و با اندازه، پیچیدگی و نیمرخ ریسک بانک، از جمله در بانک‌های محلی کوچک، متناسب کنند.
- هوش مصنوعی دسته ریسک جداگانه‌ای نیست. بازرسان نباید ابرهوش را دسته‌ای مستقل ببینند و بانک‌ها ملزم نیستند اشتهای ریسک جداگانه‌ای برای آن تعریف کنند. هوش مصنوعی عاملی دیده می‌شود که ریسک‌های موجود عملیاتی، انطباق و اعتباری را ایجاد، تشدید یا دگرگون می‌کند.
- هدف آن سامانه‌های مولد و عاملی است. یک پانویس توضیح می‌دهد که راهنمای بازنگری‌شده مدیریت ریسک مدل (بخشنامه OCC 2026-13) بر مدل‌های غیرمولد و غیرعاملی اعمال می‌شود و بنابراین این چارچوب «بیشتر برای ابرهوش مولد و عاملی کاربرد دارد».
- سندی زنده است. OCC قصد دارد آن را با تغییر فناوری، موارد استفاده و درک نظارتی و در پاسخ به بازخورد ذی‌نفعان به‌طور منظم به‌روزرسانی کند.
بافت این تصمیم مهم است. در ۲۸ فروردین ۱۴۰۵ (۱۷ آوریل ۲۰۲۶) OCC، فدرال رزرو و FDIC راهنمای مدیریت ریسک مدل سال ۲۰۱۱ (SR 11-7 / OCC 2011-12) را با نسخه‌ای کوتاه‌تر و ریسک‌محور جایگزین کردند. آن راهنما تعریف مدل را محدودتر کرد، اعلام کرد بیشترین ارتباط را با بانک‌های دارای بیش از ۳۰ میلیارد دلار دارایی دارد و هوش مصنوعی مولد و عاملی را صریحاً به‌عنوان فناوری «نوظهور و به‌سرعت در حال تحول» از دامنه خود بیرون گذاشت. نهادهای ناظر همچنین وعده یک درخواست اطلاعات درباره مدیریت ریسک مدل و هوش مصنوعی را دادند. بخشنامه 2026-54 خلأیی را پر می‌کند که راهنمای فروردین باز گذاشته بود.
ایده اصلی: پیامد و خودمختاری، نه پیچیدگی مدل
اصل فراگیر چارچوب یک جمله است که هر برنامه هوش مصنوعی باید آن را جلوی چشم داشته باشد: شدت کنترل‌های بانک می‌تواند با پیامدهای بالقوه شکست یا سوءاستفاده از یک ایجنت هوش مصنوعی افزایش یابد. طبقه‌بندی ریسک می‌تواند بر پایه پیامدهای بالقوه، میزان واگذاری اختیار (Transfer of Agency) و درجه نظارت انسانی باشد، «نه پیچیدگی فنی» سامانه.
OCC مثال ساده‌ای می‌زند: یک ایجنت قاعده‌محور ساده که مجاز به آغاز تراکنش است، می‌تواند ریسکی بیشتر از یک مدل پیشرفته داشته باشد که فقط به نگارش اسناد داخلی کمک می‌کند. این نگاه، شیوه‌ای را وارونه می‌کند که بسیاری از سازمان‌ها هنوز هوش مصنوعی را اولویت‌بندی می‌کنند؛ جایی که بزرگ‌ترین مدل طولانی‌ترین بازبینی را می‌گیرد و یک خودکارسازی «ساده» با مجوز پرداخت، در قالب یک تغییر عادی فناوری اطلاعات رد می‌شود.
شش ستون و شانزده مؤلفه
شانزده مؤلفه در شش ستون گروه‌بندی شده‌اند و هر ستون به یک پرسش نظارتی پاسخ می‌دهد:
۱. هدف: سامانه یا ایجنت مجاز به انجام چه کاری است؟ (هدف تعریف‌شده و کاربرد مجاز)
۲. ریسک: اگر خروجی یا اقدام آن مناسب هدف نباشد، چه رخ می‌دهد؟ (طبقه‌بندی ریسک و ارزیابی حیاتی‌بودن)
۳. کنترل: چه چیزی جلوی اقدام غیرمجاز، نامناسب یا ناایمن را می‌گیرد؟ (کنترل‌های انسان در حلقه و انسان بر حلقه، تعمیم مدیریت ریسک مدل، حاکمیت داده، حریم خصوصی، انطباق، امنیت سایبری)
۴. نظارت: چه کسی آن را پایش می‌کند و چه کسی پاسخ‌گوست؟ (حاکمیت و پاسخ‌گویی، نظارت انسانی، پایش عملکرد، گزارش‌دهی و شفافیت)
۵. تاب‌آوری: آیا بانک می‌تواند خطاها را تشخیص دهد، مهار کند، از آن‌ها بازیابی شود و آثارشان را جبران کند، در حالی که فرایندهای حیاتی ادامه دارند؟ (تاب‌آوری عملیاتی، امنیت سایبری)
۶. اطمینان‌بخشی: آیا شواهدی هست که کنترل‌ها همچنان کار می‌کنند؟ (آزمون، مستندسازی و حسابرسی‌پذیری، ریسک طرف سوم و تأمین‌کننده، حسابرسی داخلی و چالش مستقل)
طبقه‌بندی ریسک چهارسطحی هوش مصنوعی
بخش ۳ چارچوب روشی نمونه پیشنهاد می‌کند تا هر مدل و هر مورد استفاده عاملی، فارغ از واحد کسب‌وکار، با عوامل یکسانی امتیاز بگیرد: پیامد تصمیم (اطلاع‌رسانی، تصمیم‌گیری یا اقدام مستقیم)، برگشت‌پذیری، اثر بر مشتری و اثر مالی، سطح خودمختاری، حساسیت داده، توضیح‌پذیری و منشأ (ساخت داخلی، تنظیم‌شده روی مدل پایه طرف سوم یا مصرف به‌صورت سرویس بیرونی). این عوامل در یک سطح ترکیبی جمع می‌شوند:
| سطح | ویژگی‌های نمونه | موارد استفاده نمونه |
|---|---|---|
| سطح ۱: حیاتی | اقدام مستقیم، برگشت‌پذیری کم یا صفر، اثر مالی یا مشتری بالا، خودمختار یا نیمه‌خودمختار | ایجنت پرداخت خودمختار؛ تصمیم اعتباری بلادرنگ؛ آزادسازی تراکنش مسدودشده به‌دلیل ظن تقلب؛ دسترسی به بازار |
| سطح ۲: بالا | اقدام مستقیم یا پشتیبانی تصمیم با وزن بالا، انسان بر حلقه، اثر متوسط تا بالا | اعتبارسنجی با کمک هوش مصنوعی؛ ارتباط با مشتری به ابتکار ایجنت؛ رسیدگی به هشدارهای مبارزه با پول‌شویی؛ دستیار کدنویسی برای تغییر کد داخلی یا دسترسی به داده |
| سطح ۳: متوسط | پشتیبانی تصمیم با انسان در حلقه الزامی، حساسیت داده محدود، برگشت‌پذیر | خلاصه‌سازی اسناد داخلی برای یادداشت‌های اعتباری؛ پژوهش با کمک ایجنت |
| سطح ۴: کم | بدون دسترسی به داده مشتری یا مالی، بدون اقدام مستقیم، کاملاً تحت کنترل انسان | ابزارهای بهره‌وری داخلی؛ دستیار کدنویسی؛ پرسش و پاسخ عمومی کارکنان |
قابل‌نقل‌ترین جمله زیر همین جدول است: ایجنت پرداخت کاملاً خودمختار و رو به مشتری در سطح ۱ قرار می‌گیرد، «فارغ از اینکه در آزمون چقدر خوب عمل کند». نتیجه خوب آزمون سطح پایین‌تری نمی‌خرد؛ فقط پیامد کمتر، برگشت‌پذیری بیشتر یا نظارت بیشتر چنین می‌کند.
حاکمیت هوش مصنوعی در بانک: پنج نکته که شیوه ساخت ایجنت‌ها را تغییر می‌دهد
فراتر از ساختار کلی، چند نکته مشخص ارزش خواندن دقیق دارد، چون اصول کلی را به چیزهایی تبدیل می‌کند که بازرس می‌تواند بررسی کند.
۱. انحراف از دامنه، شکست کنترلی است. بانک باید پیش از استقرار و پس از هر تغییر مهم مستند کند سامانه برای چه کاری طراحی شده و برای چه کاری نه، چه کسی می‌تواند آن را فراخواند، به کدام داده‌ها و سامانه‌ها دسترسی دارد، چه اقدام‌هایی می‌تواند انجام دهد و چه زمانی باید بازبینی یا متوقف شود. فعالیت بیرون از هدف تأییدشده «می‌تواند شکست کنترلی تلقی شود، حتی اگر خروجی یا اقدام حاصل معقول به نظر برسد». ابزاری که برای پژوهش داخلی تأیید شده، ممکن است پیش از رو به مشتری شدن به بازبینی تازه نیاز داشته باشد.
۲. انسان در حلقه باید واقعی باشد. چارچوب میان انسان در حلقه (Human-in-the-Loop، تأیید پیش از استفاده از خروجی یا اجرای اقدام) و انسان بر حلقه (Human-on-the-Loop، پایش فعال با اختیار و توان عملی برای مداخله) تمایز می‌گذارد. بازبین باید تخصص، اطلاعات و اختیار کافی برای رد، اصلاح، مکث یا توقف سامانه داشته باشد. تأیید باید «بیش از یک کلیک صوری» باشد و حجم بالا یا تأیید دسته‌جمعی می‌تواند کیفیت بازبینی را پایین بیاورد و به خستگی از هشدار بینجامد. از بانک‌ها پرسیده می‌شود یک نفر به‌طور باورپذیر چند ایجنت، حساب یا هشدار را می‌تواند پایش کند.
۳. سامانه هوش مصنوعی می‌تواند در دسترس باشد و همچنان خطا کند. تاب‌آوری عملیاتی «هم از دست رفتن سرویس و هم عملکرد نادرست» را در بر می‌گیرد: یک ایجنت می‌تواند در دسترس بماند و در همان حال اقدام‌های زیان‌بار انجام دهد. ترمزهای پیشنهادی برای هر کسی که با سامانه‌های پرداخت سروکار داشته آشناست: پایش و مشاهده‌پذیری، ایجنت‌های کنترلی، قواعد قطعی، قطع‌کننده مدار (Circuit Breaker)، محدودیت نرخ، کمترین سطح دسترسی و کلید توقف اضطراری (Kill Switch)؛ به‌علاوه بازگشت آزموده‌شده به کارکنان آموزش‌دیده یا ایجنتی محدودتر و یک جریان کاری جداگانه برای جبران خسارت مشتریان وقتی خطای سامانه به آن‌ها آسیب می‌زند. ایجنت‌های بیرونی که بانک کنترلشان نمی‌کند، از سوی مشتریان، فین‌تک‌ها یا سکوهای تجارت عاملی، ریسک کانال تلقی می‌شوند.
۴. ایجنت‌ها کاربران ممتازند. در مؤلفه امنیت سایبری، تزریق پرامپت (Prompt Injection)، مسموم‌سازی داده و مدل، استخراج مدل و «اختیار بیش از حد» (Excessive Agency) صریحاً نام برده شده‌اند. گستره مجوزها و دسترسی ابزاری ایجنت می‌تواند بخشی از سطح حمله به حساب آید و هویت، اعتبارنامه و لاگ‌های ایجنت‌ها می‌تواند مانند کاربران ممتاز (Privileged Users) حاکمیت شود.
۵. یک اجرای موفق آزمون چیز زیادی ثابت نمی‌کند. برای سامانه‌های غیرقطعی، آزمون تکراری، نمونه‌های تعریف‌شده، سنجه‌های توزیعی و آستانه‌های سازگاری شواهد مفیدتری از یک اجرای موفق می‌دهند. چارچوب به آزمون خصمانه، تیم قرمز (Red Teaming)، بازبینی کارشناسی متناسب با نرخ خطایی که بانک می‌خواهد کشف کند، سنجش توهم (Hallucination) و استفاده از مدل زبانی به‌عنوان داور (LLM-as-a-Judge) با توجه به اعتبارسنجی، سوگیری و خطاهای هم‌بسته خود مدل داور می‌پردازد. مستندسازی باید به کسی جز توسعه‌دهندگان امکان دهد یک تصمیم مهم را از روی ورودی‌ها، خروجی‌ها، منابع بازیابی‌شده، فراخوانی ابزارها، تأییدها و لغوها بازسازی کند.
قراردادهای تأمین‌کنندگان هم توجه ویژه‌ای گرفته‌اند. بانک‌ها می‌توانند تعیین کنند ایجنت‌های تأمین‌کننده درون سامانه‌های بانک چه کاری مجازند، واژگان مشخصی برای رخدادهای هوش مصنوعی (توهم، عملکرد نادرست، رانش، دست‌کاری) با مهلت‌های اطلاع‌رسانی توافق کنند، مسئولیت خطاهای مدل و آسیب به مشتری را روشن کنند و اطلاع پیشین را وقتی تأمین‌کننده‌ای قابلیت هوش مصنوعی تازه‌ای اضافه می‌کند یا مدل محصولی را که در حال استفاده است عوض می‌کند، الزامی کنند. به گفته چارچوب، پاسخ‌گویی معمولاً با خود بانک می‌ماند، حتی اگر توسعه یا میزبانی میان چند تأمین‌کننده پخش شده باشد.
«الزام‌آور نیست» را چطور بخوانیم
وسوسه‌انگیز است سندی را که می‌گوید «از بانک‌ها انتظار نمی‌رود از آن استفاده کنند» در قفسه مطالعه اختیاری بگذاریم. من این کار را نمی‌کنم. تحلیل King & Spalding صریح است: این چارچوب روشن‌ترین بیان موجود از چیزی است که تیم‌های بازرسی OCC به دنبالش خواهند بود و مؤسسه‌ها باید انتظار داشته باشند درخواست‌های بازرسان، دامنه بازرسی و گفت‌وگو با مدیریت را شکل دهد. Jones Day هم یادآوری می‌کند که بازرسان ممکن است در بازرسی‌های پیش رو به آن ارجاع دهند و این سند نشان می‌دهد بازرسان استفاده از هوش مصنوعی را بر پایه استانداردهای موجود چطور ارزیابی خواهند کرد.
یک تنش کوچک هم هست که بهتر است آگاهانه حل شود. بانک‌ها به اشتهای ریسک جداگانه برای هوش مصنوعی نیاز ندارند، اما مؤلفه حاکمیت می‌گوید هیئت‌مدیره و مدیریت ارشد «می‌توانند اشتهای ریسک ابرهوش تعیین کنند» که خودمختاری، اقدام‌های مجاز، اثر بر مشتری و تمرکز را پوشش دهد. برداشت من عملی است: هوش مصنوعی را درون اشتهای ریسک سازمانی موجود بگذارید، اما خودمختاری و اقدام‌های مجاز را ابعاد صریح آن کنید تا هیئت‌مدیره ببیند چه مقدار اختیار به نرم‌افزار واگذار کرده است.
در نهایت، این چارچوب تنها نیست. تحلیل‌های حقوقی آن را به واژه‌نامه هوش مصنوعی و چارچوب مدیریت ریسک هوش مصنوعی خدمات مالی که وزارت خزانه‌داری آمریکا در فوریه ۲۰۲۶ منتشر کرد، به بازنگری پیشنهادی راهنمای بین‌نهادی ریسک طرف سوم و به راهنماهای ایالتی مانند راهنمای اداره بانکداری کانتیکت در سپتامبر ۲۰۲۶ پیوند می‌دهند. بانکی که در چند حوزه قضایی فعالیت می‌کند، بهتر است کنترل‌هایش را یک بار نگاشت کند و شواهد را دوباره به کار ببرد، نه اینکه برای هر ناظر برنامه‌ای جدا بسازد.
راهنمای حاکمیت هوش مصنوعی برای مدیران فناوری بانک
این چارچوب برای بازرسان نوشته شده، اما اگر از سوی دیگر خوانده شود یک مشخصات طراحی است. من آن را برای دو فصل آینده این‌طور به کار تبدیل می‌کنم.
۱. سیاهه‌ای از هوش مصنوعی بسازید که ایجنت‌ها و قابلیت‌های تعبیه‌شده تأمین‌کنندگان را هم شامل شود. برای هر مورد استفاده، مالک، تأمین‌کننده، مدل و نسخه، مجوزها، داده‌های در دسترس، وضعیت استقرار، پایش و سازوکار جایگزین را ثبت کنید. بسیاری از سازمان‌ها می‌توانند فهرست مدل‌هایشان را بدهند؛ اما تعداد بسیار کمتری می‌توانند هر محصول SaaS را که بی‌سروصدا یک دستیار هوش مصنوعی به آن اضافه شده فهرست کنند؛ دقیقاً همان ریسک تغییر تأمین‌کننده که چارچوب توصیف می‌کند.
۲. سطح‌بندی را بر پایه پیامد و واگذاری اختیار انجام دهید. هر مورد استفاده را بر اساس اقدام در برابر توصیه، برگشت‌پذیری، اثر، خودمختاری، حساسیت داده، توضیح‌پذیری و منشأ امتیاز دهید. منتظر غافلگیری باشید: یک ایجنت قاعده‌محور ساده با مجوز پرداخت یا دسترسی به داده ممکن است بالاتر از چت‌بات شاخص شما قرار گیرد.
۳. بیانیه‌های هدف آزمون‌پذیر بنویسید. «به خدمات مشتری کمک می‌کند» آزمون‌پذیر نیست. «می‌تواند سابقه تراکنش کارت مشتری احرازهویت‌شده را بخواند، می‌تواند پیام پیش‌نویس کند اما ارسال نکند، نمی‌تواند سقف‌ها را تغییر دهد و اعتراض‌های بالاتر از مبلغ معین را ارجاع می‌دهد» آزمون‌پذیر است. سپس انحراف از آن را پایش کنید.
۴. مجوزها را بیرون از مدل اعمال کنید. اعتبارنامه با کمترین سطح دسترسی، هویت جداگانه برای ایجنت، محدودیت نرخ و مبلغ، قطع‌کننده مدار و کلید توقفی که کسی واقعاً آزموده باشد. این همان اصلی است که در مقاله پرداخت با ایجنت هوش مصنوعی از آن دفاع کردم: کنترل‌هایی که به خوش‌رفتاری ایجنت وابسته نیستند.
۵. نظارت انسانی را با در نظر گرفتن ظرفیت طراحی کنید. تعیین کنید چه کسی چه چیزی را، با کدام شواهد و در چه مدت بازبینی می‌کند. نرخ لغو و تأیید را بسنجید؛ بازبینی که در هر ساعت صدها اقدام ایجنت را تأیید می‌کند، مهر لاستیکی است، نه کنترل.
۶. ارزیابی را آماری و پیوسته کنید. نمونه‌گیری تکراری، آزمون خصمانه و تیم قرمز، نرخ توهم روی پرامپت‌های نماینده و محرک‌های اعتبارسنجی دوباره وقتی پرامپت، مدل، ابزار یا مجوزها تغییر می‌کنند. در مقاله بنچمارک ایجنت هوش مصنوعی در ۲۰۲۶ توضیح دادم چرا امتیاز جدول رتبه‌بندی تا وقتی روی وظایف خودتان تأیید نشده فقط یک فرضیه است؛ این چارچوب همان نکته را به زبان نظارتی می‌گوید.
۷. آن‌قدر لاگ ثبت کنید که بتوان یک تصمیم را بازسازی کرد. ورودی‌ها، منابع بازیابی‌شده، فراخوانی ابزارها، تأییدها، لغوها و اقدام‌های حاصل، همراه با تغییرات نسخه و مجوز که به شواهد آزمون پیوند خورده باشند. اگر ایجنت با یک کور بانکینگ قدیمی کار می‌کند، جای این کار لایه یکپارچه‌سازی است؛ این معماری را در مقاله نوسازی کور بانکینگ در ۲۰۲۶ بررسی کرده‌ام.
۸. عملکرد نادرست را تمرین کنید، نه فقط قطعی را. تمرین‌هایی برگزار کنید که در آن ایجنت آنلاین می‌ماند و کار اشتباه انجام می‌دهد: چقدر سریع تشخیص داده، مهار و به عقب برگردانده می‌شود، چه کسی مشتریان آسیب‌دیده را شناسایی می‌کند و فرایند کسب‌وکار بدون آن چطور ادامه می‌یابد؟
۹. شرایط هوش مصنوعی را با تأمین‌کنندگان دوباره مذاکره کنید. اطلاع پیشین برای قابلیت‌های تازه هوش مصنوعی و تعویض مدل، محدودیت استفاده از داده بانک برای آموزش مدل‌هایی که به مشتریان دیگر عرضه می‌شوند، تعریف و مهلت رخدادهای هوش مصنوعی، حق دسترسی حسابرسی و مسئولیت آسیب به مشتری.
۱۰. به هیئت‌مدیره تصویری از اختیار واگذارشده بدهید. موارد استفاده مهم را بر اساس سطح، تغییر مجوزها، رخدادها، جبران خسارت مشتریان و نتایج اطمینان‌بخشی گزارش کنید و آن را با سیاهه تطبیق دهید. هیئت‌مدیره اشتهای ریسک را تصویب می‌کند؛ باید ببیند بانک چه مقدار خودمختاری را به ماشین‌ها سپرده است.
سخن پایانی
مهم‌ترین ایده بخشنامه 2026-54 واژگان تازه آن نیست، بلکه جابه‌جایی توجه از اینکه یک مدل هوش مصنوعی چیست به اینکه اجازه دارد چه کاری انجام دهد است. این همان‌قدر مهندسی خوب است که نظارت خوب. بانک‌هایی که ایجنت‌ها را بر پایه هدف صریح، سطح‌بندی مبتنی بر پیامد، نظارت انسانی واقعی و ترمزهای آزموده‌شده طراحی کنند، بازرسی‌ها را آسان‌تر خواهند یافت؛ اما مهم‌تر از آن، می‌توانند زودتر و با اطمینان بیشتری مسئولیت بیشتری به ایجنت‌ها بسپارند تا سازمان‌هایی که هنوز بر سر چشمگیرترین مدل بحث می‌کنند.
منابع
- OCC Issues Supervisory Framework on Bank Use of Super Intelligence، اداره کنترل‌کننده پول آمریکا (OCC)، اطلاعیه خبری 2026-97، ۱۳ آبان ۱۴۰۵
- Super Intelligence: Supervisory Framework، اداره کنترل‌کننده پول آمریکا (OCC)، بخشنامه 2026-54، ۱۳ آبان ۱۴۰۵
- OCC Supervisory Framework for Bank Use of Super Intelligence (PDF)، اداره کنترل‌کننده پول آمریکا (OCC)، آبان ۱۴۰۵
- Model Risk Management: Revised Guidance، اداره کنترل‌کننده پول آمریکا (OCC)، بخشنامه 2026-13، ۲۸ فروردین ۱۴۰۵
- The OCC Issues Examiner Framework for Bank Use of AI: What OCC Bulletin 2026-54 Means، Matthew L. Biben، Kimberly A. Prior، Michael Regan، Russell David Sacks و Kent Jordan، King & Spalding، ۱۸ آبان ۱۴۰۵
- OCC Issues Super Intelligence Supervisory Framework، Keegan King، Jones Day، آبان ۱۴۰۵
- OCC releases framework for supervising artificial intelligence، ABA Banking Journal، ۱۳ آبان ۱۴۰۵