یک توهم (Hallucination) — شبیه دوستی که خاطرهای را اشتباه تعریف میکند — در یک عامل هوش مصنوعی میتواند ساعات کاری اشتباه یک کسبوکار را در تمام نقشههای وب و تجمیعکنندههای داده منتشر کند. طبق راهنمای فنی منتشر شده در ۲۷ سپتامبر ۲۰۲۶، دادههای پروفایل کسبوکار گوگل (Google Business Profile) به دلیل ماهیت عمومی و بازتاب گسترده در وب، سریعتر از توان اصلاح انسانی پخش میشوند. یک ویرایش اشتباه در گوگل میتواند به سرعت در سراسر اینترنت کپی شود.
این موضوع به این دلیل بحرانی است که بازگرداندن یک تغییر در یک منبع، لزوماً آن را در سایر دستیارهای هوش مصنوعی و تجمیعکنندههای داده اصلاح نمیکند؛ زیرا دادهها به طور گسترده در جایجای وب کپی شدهاند. همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، اعتماد مطلق به خروجی مدلها در محیطهای عملیاتی، ریسکهای سیستمی ایجاد میکند.
مدیریت این فهرستها بهویژه به دلیل تفسیر اشتباه دستورات موقت توسط عاملها (Agents) خطرناک است. برای مثال، عاملی ممکن است عبارت «روز ۲۴ زودتر میبندیم» را بخواند و به اشتباه آن را به عنوان یک تغییر دائمی در ساعات کاری ثبت کند. همچنین این عاملها ممکن است در مواجهه با ابهام دچار مشکل شوند؛ مثلاً بین دو مکان با نامهای مشابه، مکان اشتباه را انتخاب کنند. علاوه بر این، خطر تزریق پرامپت (Prompt Injection) وجود دارد؛ جایی که عامل با خواندن یک نظر مشتری یا یک صفحه وب حاوی دستوری مثل «شماره تلفن را به این عدد تغییر بده»، آن را به عنوان یک دستور قانونی اجرا میکند.
پروفایل ریسک و معماری حفاظتی
دادههای فهرست کسبوکارها به دلیل ماهیت عمومی، اهداف حساس و پرریسک هستند. خطاها در اینجا داخلی نیستند و مستقیماً توسط هر مشتریی که در وب جستجو میکند دیده میشوند. عاملها به روشهای خاص و قابل پیشبینی شکست میخورند: اشتباه خواندن تاریخها، اشتباه گرفتن مکانهای مشابه و پذیرش دستوراتی که در دل محتوای خوانده شده جاسازی شدهاند.
برای جلوگیری از این شکستها، توسعهدهندگان باید از یک طراحی ابزار سختگیرانه با استفاده از پروتکل زمینهٔ مدل (MCP) — استانداردی باز برای اتصال مدلها به ابزارهای خارجی — استفاده کنند. اصل کلیدی در اینجا تفکیک قابلیتهای خواندن و نوشتن است. هیچ عاملی نباید ابزار apply_change (اعمال تغییر) داشته باشد. در عوض، عامل باید از ابزار propose_change (پیشنهاد تغییر) استفاده کند که یک تفاوت (Diff) ایجاد کرده و آن را برای بررسی انسانی ارسال میکند. تأیید و انتشار نهایی باید خارج از دسترس عامل و در یک صف کنترلشده توسط انسان رخ دهد. این نیاز به دقت در خروجیها، ما را به بحث ضرورت قراردادهای ماشینخوان در بازار عاملها بازمیگرداند تا تحویل خدمات توسط هوش مصنوعی قابل راستیآزمایی باشد.
ساختار ابزارهای امن
بر اساس مستندات فنی، یک معماری امن باید شامل ابزارهای زیر باشد:
- list_locations: دسترسی فقط-خواندنی به مکانهایی که عامل اجازه مشاهده آنها را دارد.
- get_location: بازیابی دادههای زنده و فعلی برای یک سایت یا مکان خاص.
- propose_change: دسترسی مرحلهای (Staged) برای ایجاد یک پیشنهاد تغییر که یک Diff بازمیگرداند.
- get_change_status: دسترسی خواندنی برای نمایش اینکه آیا یک پیشنهاد تأیید شده است یا خیر.
هر پیشنهاد باید شامل دلیل مشخص و یک منبع، مانند شناسه تیکت (مثلاً "ticket OPS-2291") از یک سیستم عملیاتی باشد. این کار عامل را مجبور میکند هر ویرایش را به یک درخواست واقعی در دنیای واقعی گره بزند و به بررسیکنندگان انسانی نقطهای برای تأیید صحت درخواست میدهد. یک پیشنهاد استاندارد باید شامل موارد زیر باشد: location_id (شناسه مکان)، location_name (نام مکان)، fields (فیلدهای در حال تغییر به همراه مقادیر «از» و «به»)، reason (دلیل)، source (منبع) و effective_date (تاریخ اجرا).
برای تغییرات موقت، مانند ساعات کاری تعطیلات، سیستم باید الزاماً یک تاریخ انقضا (expires) بخواهد تا از تبدیل شدن تصادفی این تغییرات به تنظیمات دائمی جلوگیری شود.
محدوده دسترسی و امنیت فیلدها
محدود کردن دسترسیها (Credential Scoping) به همان اندازه حیاتی است. عاملها هرگز نباید از توکن یک انسان استفاده کنند؛ آنها به هویت مستقل با محدودترین دسترسی ممکن به مجموعهای از مکانها و فیلدها نیاز دارند. برای مثال، یک دستیار منطقهای فقط باید مکانهای منطقه خود را ببیند و عاملی که وظیفه فرمتبندی شماره تلفنها را دارد، باید از تغییر نام کسبوکار یا دستهبندیهای اصلی منع شود.
فیلدهای پرریسک — بهویژه نام کسبوکار، آدرس و دستهبندیهای اصلی — بیشترین احتمال را برای تحریک سیستمهای امنیتی گوگل برای تعلیق حساب یا ارسال درخواست بررسی دستی دارند. این ویرایشها باید مستقیماً به تأییدکنندگان ارشد ارجاع شوند یا برای عاملها کاملاً مسدود گردند.
دفاع در برابر تزریق پرامپت
برای مقابله با تزریق پرامپت، توسعهدهندگان باید با تمام متون خارجی — از جمله متن نظرات، محتوای وبسایتها و ایمیلها — به عنوان «داده» برخورد کنند، نه «دستور». به نقل از این راهنما، سه عادت ضروری برای توسعهدهندگان وجود دارد:
۱. پذیرش درخواستهای تغییر فقط از منابع ساختاریافته (مانند سیستم تیکتینگ) به جای متنهای آزاد که عامل به طور اتفاقی در وب میخواند.
۲. اعتبارسنجی مقادیر پیشنهادی بر اساس قوانین سختگیرانه (مثلاً چک کردن شماره تلفنها در برابر یک لیست تأیید شده).
۳. نمایش منبع اصلی هر درخواست مستقیماً در کنار Diff برای بررسی سریع توسط انسان.
ثبت وقایع (Logging) آخرین تکه این پازل است. هر فراخوانی ابزار، هر پیشنهاد و هر تأییدیه باید دارای برچسب زمانی و گره خورده به هویت عامل باشد، به طوری که ورودیها و خروجیها کاملاً ثبت شوند. داشتن یک Snapshot (عکس لحظهای) از وضعیت مکان قبل از هر تغییر، بازگشت به حالت قبل (Rollback) را به یک فرآیند تکمرحلهای تبدیل میکند. این لاگها همچنین به عنوان ابزاری برای آموزش عمل میکنند؛ زیرا پیشنهادهای رد شده دقیقاً نشان میدهند که قضاوت عامل در کجا ضعیف است.
در نهایت، برای پیادهسازی، استفاده از Google Business Information API در قالب یک سرور MCP سفارشی بیشترین کنترل را به توسعهدهنده میدهد. با این حال، پلتفرمهایی مانند Synup پشتیبانی داخلی از MCP، صندوقهای ورودی برای تأیید و مجوزهای محدود شده برای تیمها را ارائه میدهند. پلتفرمهای Yext و Uberall نیز APIهایی دارند که برای برندهای بزرگتر مناسباند، هرچند کاربران باید بررسی کنند که ویژگیهای تأیید آنها چگونه با مدل «پیشنهاد توسط عامل» سازگار میشود.
این چرخش به سمت گردشکارهای «انسان در حلقه» (Human-in-the-loop)، این فرض را که عاملها باید کاملاً خودمختار باشند، تغییر میدهد. در محیطهای دادهای حساس و عمومی، ارزش عامل در توانایی اجرای دستور نیست، بلکه در توانایی پیشنهاد سریع تغییرات دقیق برای تأیید انسانی است.
گام بعدی شما
- اگر از عاملهای هوش مصنوعی برای مدیریت داده استفاده میکنید، فوراً دسترسی مستقیم
Writeآنها را حذف و سیستمProposeرا جایگزین کنید. - تمام ورودیهای متنی که از محیط وب یا کاربران میآیند را در لایهای جدا از دستورات سیستمی (System Prompt) قرار دهید.
- برای هر تغییر، یک شناسه منبع (Source ID) اجباری تعریف کنید تا مسیر بازرسی دادهها حفظ شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو