مدل‌های پرداخت «سقف ثابت» عامل‌های هوش مصنوعی را در معرض جریمه‌های MiCA قرار

یک فراخوانی API به ارزش ۰.۰۲ دلار و استخدام یک عامل شخص ثالث به مبلغ ۸۹ دلار نباید از یک درگاه نظارتی یکسان عبور کنند. اگر امروز از سیستم‌های پرداخت ساده برای عامل‌های خود استفاده می‌کنید، باید بدانید که این ابزارها با یکسان‌انگاری تمام هزینه‌ها، شما را در برابر ریسک‌های قانونی قرار می‌دهند. پلتفرم‌هایی مانند AWS Bedrock AgentCore و Coinbase x402 محدودیت‌های هزینه در سطح جلسه (Session) و مجوزهای هر-درخواست را ارائه کرده‌اند؛ اما این ابزارها با پرداخت تمام هزینه‌ها به عنوان موارد برابر، در واقع مشکل اشتباهی را حل می‌کنند. این ابزارهای استقرار سریع، مانند قابلیت‌های جدید AWS Bedrock در کاهش مراحل استقرار عامل‌ها، در حالی که سرعت توسعه را بالا می‌برند، لزوماً چالش‌های نظارتی پرداخت را برطرف نمی‌کنند. بر اساس مستندات نظارتی، یک تراکنش نیاز به تأیید فوری دارد و تراکنشی دیگر نیازمند تأیید چندمرحله‌ای، امضای مالک بودجه و رکورد حسابی است که ماده ۶۷ قانون MiCA (قانون بازارهای دارایی‌های رمزپایه) را پاس کند.

این شکاف زمانی حیاتی است که صنعت با اجرای الزامات MiCA در ۱ ژوئیه ۲۰۲۶ روبروست. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، نبودِ ساختارهای نظارتی دقیق منجر به بروز حفره‌های عملیاتی می‌شود. اکثر پلتفرم‌های پرداخت عاملی که در سال ۲۰۲۶ عرضه شدند، بر پایه یک ابزار اولیه به نام «سقف ثابت» (Flat Limit) بنا شده‌اند؛ یعنی یک سقف هزینه مشخص برای هر جلسه یا بازه زمانی. طبق مستندات Ramp و Finout، این رویکرد یک خلأ نظارتی ایجاد می‌کند که در آن عملیات‌های حساس «نوشتاری» (Write Operations) بدون بررسی مستقل اجرا می‌شوند و این یک الگوی شکست شناخته شده است.

شکست مدل سقف ثابت

به نقل از گزارشی که ۲۷ ژوئن ۲۰۲۶ در dev.to منتشر شد، سقف‌های ثابت، فراخوانی‌های روتین بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است تا همسایگان معنایی‌اش را بشناسد — را با استخدام‌های پرریسک عامل‌ها یکسان می‌بینند. «مشکل سقف ثابت» تضمین می‌کند که هر پرداخت، صرف‌نظر از میزان ریسک، با رویه یکسانی مواجه شود.

برای مثال، عاملی را در نظر بگیرید که با سقف ۱۰۰ دلار در روز و بدون هیچ مسیر ارجاع (Escalation Path) پیکربندی شده است. در عمل، این عامل ممکن است مجموعه‌ای از تراکنش‌ها را به ترتیب اجرا کند: یک فراخوانی API برای Embedding به مبلغ ۰.۰۲ دلار، یک پرس‌و‌جوی جست‌وجو به مبلغ ۰.۵۰ دلار، یک اشتراک داده به مبلغ ۴.۹۹ دلار، یک جهش محاسباتی ابری (Cloud Compute Burst) به مبلغ ۴۷.۰۰ دلار و در نهایت استخدام یک عامل شخص ثالث به مبلغ ۸۹.۰۰ دلار. چون هر یک از این تراکنش‌ها به صورت مجزا زیر سقف ۱۰۰ دلاری هستند، همگی بدون ارسال اعلان یا نیاز به تأیید مالک بودجه، پاس می‌شوند.

این یک فاجعه عملیاتی است. در این سناریو، یک استخدام ۸۹ دلاری دقیقاً همان میزان نظارتی را دریافت می‌کند که یک فراخوانی ۰.۰۲ دلاری. بدتر از آن، اگر ۵۰ عامل هر کدام سقف ۱۰۰ دلار در روز داشته باشند، سازمان با ۵,۰۰۰ دلار هزینه روزانه مواجه می‌شود در حالی که هیچ نظارتی بر این مخارج وجود ندارد. این عدم تفکیک منجر به شکست در انطباق با ماده ۶۷ قانون MiCA می‌شود. وقتی یک بازرس MiCA بپرسد چه کسی پرداخت پرریسک خاصی را که زیر سقف جلسه بوده تأیید کرده است، پاسخ «هیچ‌کس» به معنای عدم انطباق قانونی تلقی می‌گردد.

این مسئله در مقاله «چارچوب Dynamic Tiered AgentRunner» در arxiv فرموله شده و استدلال می‌کند که سقف‌های سطح جلسه، «حاکمیت» (Governance) نیستند، بلکه صرفاً «محدودیت» (Cap) هستند و در محیط‌های عملیاتی خطرات جدی به دلیل نبود قابلیت مدیریت کافی ایجاد می‌کنند.

مکانیسم سطح‌بندی خودمختاری

برای رفع این مشکل، RosudPay یک مدل حاکمیتی سطح‌بندی شده را پیاده کرده است. در این مدل، جریان‌های تأیید بر اساس پروفایل ریسک تعیین می‌شوند، نه فقط مبلغ کل. مبلغ تنها یکی از سیگنال‌هاست؛ دسته‌بندی، سطح اعتماد به گیرنده، الگوی تکرار و حوزه قضایی همگی در تصمیم اثر دارند. این سامانه از چهار سطح متمایز برای طبقه‌بندی تراکنش‌ها استفاده می‌کند:

• خودمختار (Autonomous): طراحی شده برای فروشندگان تأییدشده و کم‌ریسک.
  • شرایط: حداکثر مبلغ ۱.۰۰ دلار؛ دسته‌هایی مانند فراخوانی‌های API، Embeddingها و جست‌وجو؛ حداکثر فرکانس ۱,۰۰۰ مورد در ساعت.
  • حاکمیت: بدون نیاز به تأیید انسانی؛ اجرای فوری.
  • انطباق: حسابرسی دسته‌ای-روزانه و رکوردهای ساده‌شده MiCA.
• نظارتی (Supervised): برای نهادهایی که قبلاً با آن‌ها تراکنش انجام شده و شناخته‌شده هستند.
  • شرایط: حداکثر مبلغ ۵۰.۰۰ دلار؛ دسته‌هایی مانند محاسبات (Compute)، دسترسی به داده‌ها و ابزارهای SaaS؛ حداکثر فرکانس ۲۰ مورد در ساعت.
  • حاکمیت: مدل «اعلان با حق وتو»؛ انسان یک پنجره زمانی ۳۰ ثانیه‌ای برای مسدود کردن پرداخت دارد.
  • انطباق: رکوردهای مجزا برای هر تراکنش و رکوردهای استاندارد MiCA.
• همکارانه (Collaborative): رزرو شده برای تدارکات با ارزش بالا.
  • شرایط: حداکثر مبلغ ۵,۰۰۰.۰۰ دلار؛ شامل استخدام عامل، تدارکات خدماتی و اشتراک‌های سازمانی؛ حداکثر فرکانس ۵ مورد در هر ۲۴ ساعت.
  • حاکمیت: تأیید صریح انسانی الزامی است؛ مهلت ۴ ساعته برای رد خودکار در صورت عدم پاسخ.
  • انطباق: زنجیره‌های حسابرسی تقویت‌شده برای هر تراکنش همراه با توجیه (Justification) و رکوردهایی که توسط رگولاتور قابل پرس‌وجو باشند.
• ممنوعه (Prohibited): مسدودسازی‌های سخت برای جلوگیری از فعالیت‌های غیرقانونی.
  • شرایط: دسته‌های مربوط به قمار، عامل‌های تأییدنشده یا حوزه‌های قضایی تحریمی؛ عدم اعتماد به گیرنده.
  • حاکمیت: مسدود کردن کامل اجرا.
  • انطباق: هر تلاش ثبت شده و منجر به ارسال هشدار فوری برای مالک می‌شود.

MiCA و آزمون تناسب (Proportionality Test)

ماده ۶۷ قانون MiCA ایجاب می‌کند که مدیریت ریسک «متناسب با ماهیت، مقیاس و پیچیدگی» سرویس دارایی رمزپایه باشد. یک سقف یکسان ۱۰۰ دلاری این آزمون تناسب را رد می‌کند چون ذاتاً غیرمتناسب است.

در یک سیستم سطح‌بندی شده، عمق حاکمیت با ریسک همخوانی دارد: تدارکات یک سرویس ۵,۰۰۰ دلاری برای تحلیل نقدینگی EURC، یک ردپای حسابرسی تقویت‌شده با منشأ کامل (Provenance) دریافت می‌کند، در حالی که یک پرداخت خرد (Micro-payment)، رکوردی سبک دریافت می‌کند. اگر نوع حاکمیت «سقف ثابت» باشد، بررسی تناسب شکست می‌خورد زیرا تفاوتی بین ماهیت یا مقیاس قائل نمی‌شود و شرکت را در معرض ریسک سازمان‌های ملی صلاحیت‌دار (NCA) قرار می‌دهد. در مقابل، حاکمیت سطح‌بندی شده با تفکیک ماهیت (از طریق دسته‌ها)، مقیاس (از طریق حداکثر مبلغ) و پیچیدگی (از طریق تأیید صریح انسانی)، این آزمون را پاس می‌کند.

شکاف پیاده‌سازی

تا اواسط سال ۲۰۲۶، پنج نوع کنترل هزینه وجود دارد: توکن‌های یک‌بار مصرف، JWTهای محدود به زمان، مجوزهای برنامه‌ریزم روی زنجیره (on-chain allowances)، دستورات رمزنگاری‌شده (Cryptographic Mandates) و جریان‌های تأیید آنی. هر یک از این‌ها دقیقاً یک بعد از مشکل را حل می‌کنند. در حالی که استراتژی‌های کاهش هزینه‌های استنتاج بر بهینه‌سازی مصرف توکن‌ها تمرکز دارند، این ابزارهای کنترلی بر مدیریت دسترسی مالی متمرکز هستند. در حال حاضر، هیچ‌کدام از این موارد در یک چارچوب واحد ترکیب نشده‌اند که هم سرعت عملیاتی و هم سخت‌گیری نظارتی را یک‌زمان تأمین کند.

با طبقه‌بندی هر تراکنش بر اساس مبلغ، دسته، اعتماد به گیرنده و الگوی تکرار، خودمختاری سطح‌بندی شده به عاملی اجازه می‌دهد تا تحت یک هویت اما با قوانین مختلف عمل کند. عاملی که ۱,۰۰۰ فراخوانی خرد API را در ساعت پردازش می‌کند و عاملی که هفته‌ای یک‌بار یک سرویس ۵,۰۰۰ دلاری تهیه می‌کند، دیگر پروفایل ریسک یکسانی ندارند.

این چرخش، صنعت را از دوران «چرخ‌های کمکی» — که فقط از هزینه‌های فاجعه‌بار جلوگیری می‌کردند — به دوران حاکمیت واقعی می‌برد. برای اپراتورها، جایگزینِ «خودمختاری سطح‌بندی شده»، سهل‌انگاری در نگاه بازرسان NCA است. عبارت «هر چه زیر ۱۰۰ دلار باشد خودکار تأیید می‌شود»، یک استراتژی نیست؛ یک ریسک حقوقی و بدهی است. شرکت‌ها باید جریان‌های پرداخت فعلی خود را ارزیابی کنند تا مطمئن شوند پیش از ضرب‌الاجل ژوئیه، می‌توانند بین هزینه‌های روتین API و تدارکات استراتژیک تفکیک قائل شوند. خودمختاری سطح‌بندی شده، حداقل حاکمیت پذیرفتنی (Minimum Viable Governance) برای پرداخت‌های عاملی در یک محیط قانون‌گذاری شده است.

گام بعدی شما

• جریان‌های پرداخت فعلی عامل‌های خود را بررسی کنید تا مطمئن شوید هزینه‌های API روتین از خریدهای استراتژیک تفکیک شده‌اند.
• پیش از ضرب‌الاجل ژوئیه ۲۰۲۶، مدل دسترسی‌های مالی عامل‌ها را از «سقف ثابت» به «سطح‌بندی بر اساس ریسک» تغییر دهید.
• معیارهای اعتماد به گیرنده (Recipient Trust) را در لایه پرداخت‌های خود تعریف کنید.

اما تأثیر این سختگیری‌های نظارتی بر سرعت توسعه مدل‌های بازمتن حتی پیچیده‌تر است — به تحلیل ما درباره استانداردهای جدید انتشار مدل‌ها مراجعه کنید.