چرا نبودِ حاکمیت بر فرآیندها مانعِ گسترش عامل‌های هوش مصنوعی می‌شود؟

یک دموی دست‌چین‌شده، تریلر است نه محصول نهایی. سوبهان دالری (Sobhan Daliry)، مدیر محصول و رهبر استراتژی هوش مصنوعی در Pipefy، استدلال می‌کند که بیشتر طرح‌های آزمایشی در سازمان‌ها شکست می‌خورند چون فقط ثابت می‌کنند مدل «کار می‌کند»، اما ثابت نمی‌کنند که فرآیند در مقیاس تولید به‌صورت سرتاسری پاسخگو است.

این تغییر دیدگاه در حالی رخ می‌دهد که سازمان‌ها از چت‌بات‌های ساده به سمت ارکستراسیون عامل‌محور (Agentic Orchestration) حرکت می‌کنند. در حالی که صنعت روی «باهوش‌ترین» مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تمرکز کرده است، گلوگاه واقعی برای کسب ارزش تجاری، «بستر» (Context) است؛ یعنی دانستن دقیق اینکه نسخه فرآیند یک مشتری خاص چگونه است و نرده‌های ایمنی کجا قرار دارند. این رویکرد با دیدگاه مدیرعامل Zyter همسو است که معتقد است هوش مصنوعی عامل‌محور باید منجر به بازطراحی بنیادین جریان‌های کاری شود تا بتوان از پتانسیل واقعی آن بهره برد.

شکاف قابلیت اطمینان

رویکرد دالری ریشه در تجربه‌ای دارد که از مهندسی مخابرات در Claro و Oi تا نقش‌های مدیریتی در Peixe Urbano و PSafe را در بر می‌گیرد. او همچنین به‌عنوان مدیرعامل و مدیر محصول در NZN فعالیت کرده و در آنجا رهبری بازسازی و تحول شرکت را بر عهده داشت. او همچنین Polen.me را بنیان‌گذاری کرده است. او ذهنیتی شبیه به «دکل مخابراتی» را در هوش مصنوعی به کار می‌برد: اگر قابلیتی تحت فشار واقعی و در غیاب نظارت لحظه‌ای دوام نیاورد، شکست خورده است.

تجربیات حرفه‌ای او درس‌های متمایزی درباره توسعه محصول به او آموخت. مخابرات به او یاد داد که زیرساخت باید در مقیاس عظیم با خطای صفر کار کند؛ چون در این صنعت هیچ جایی برای جملاتی مثل «بیشتر اوقات کار می‌کند» وجود ندارد. قطع شدن یک تماس، شکست در یک دمو نیست، بلکه به معنای ترک مشتری و رفتن او به سراغ رقیب است. در Peixe Urbano و PSafe آموخت که محصولات مصرفی بر اساس حل مشکلات واقعی و ملموس امروز زنده می‌مانند، نه مسائل تئوریک و فرضی.

مدیریت NZN در نقش مدیرعامل و مدیر محصول او را مجبور کرد بین دو حقیقت تعادل برقرار کند: اول اینکه نمی‌توان با اجرای عالی، یک فرضیه بد را جبران کرد، و دوم اینکه نمی‌توان با فرضیه عالی، اجرای بد را پوشاند. بنیان‌گذاری Polen.me گران‌ترین درس او بود؛ اینکه سرمایه و زمان محدود هستند. او دریافت هر قابلیتی که ساخته می‌شود، به معنای نساختن چیزی در جای دیگر است. هزینه تعقیب یک دموی چشم‌گیر به‌جای یک جریان کاری واقعی، ماه‌ها بعد در عملیات ظاهر می‌شود، نه روی صحنه نمایش.

او اشاره می‌کند که در سال ۲۰۲۳، فرض رایج این بود که LLM عامل محدودکننده است. اما طبق بررسی‌های او، کیفیت مدل‌ها روی یک منحنی پیش‌بینی‌پذیر رشد می‌کند، در حالی که بستر فرآیندها به‌طور خودکار بهبود نمی‌یابد چون به‌ندرت ساختاریافته است. او همچنین دریافت که سازمان‌ها استقلال کامل نمی‌خواهند، بلکه «استقلال محدود» (Bounded Autonomy) می‌خواهند؛ عامل‌هایی که درون قوانین شکست‌ناپذیر تصمیم بگیرند و ردپایی قابل اثبات به جای بگذارند. او استدلال می‌کند استقلال کامل بدون حاکمیت، جاه‌طلبی نیست، بلکه صرفاً ریسک است که با یک رابط کاربری زیباتر ارائه شده است.

قطعیت در برابر استدلال

شرکت Pipefy که در سال ۲۰۱۵ تأسیس شد، از یک پلتفرم اتوماسیون بدون کد (No-code) به یک محیط ارکستراسیون متمرکز بر هوش مصنوعی تبدیل شده است. این پلتفرم عامل‌های هوش مصنوعی، جریان‌های کاری، فرم‌ها، پورتال‌ها، اپلیکیشن‌ها، داده‌ها، تحلیل‌ها، پیام‌رسانی و یکپارچه‌سازها را با هم ترکیب می‌کند. این محیط به تیم‌ها اجازه می‌دهد با زبان طبیعی و ابزارهای بدون کد، عامل‌هایی بسازند که حاکمیت سازمانی، امنیت و قابلیت مشاهده را حفظ می‌کنند.

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

• اتوماسیون قطعی (Deterministic Automation): برای درخت‌های تصمیم شناخته‌شده بهترین است (مثلاً مسیریابی یک فاکتور به تاییدکننده خاص اگر مبلغ زیر حد معینی باشد). استفاده از عامل در اینجا فقط باعث تأخیر غیرضروری و پیش‌بینی‌ناپذیری در مسئله‌ای می‌شود که قبلاً حل شده است.
• عامل‌های هوش مصنوعی: برای ابهامات ضروری هستند؛ مثلاً وقتی فاکتور دقیقاً با سفارش خرید مطابقت ندارد، یک فیلد خالی است، یا درخواست مشتری در هیچ دسته‌بندی موجود نمی‌گنجد. اینجاست که مدل استدلالی (Reasoning Model) — مدلی که قبل از جواب، یک قدم درنگ می‌کند و فکر می‌کند، شبیه شطرنج‌بازی که چند حرکت جلوتر را می‌بیند — ارزش واقعی ایجاد می‌کند، زیرا تصمیم می‌گیرد وقتی «گام بعدی» از پیش نوشته نشده است، چه کاری انجام دهد.

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

معماری ارکستراسیون

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

بدون این ساختار، ابزار شما صرفاً یک «چت‌بات با دسترسی به API» است. تفاوت در این است که آیا هوش مصنوعی حافظه فرآیند را دارد یا فقط حافظه پرامپت را. یک کمک‌خلبان (Copilot) به سوال شما پاسخ می‌دهد، اما ارکستراسیون، اقدامات را در سیستم‌های مختلف مثل ERP، CRM یا APIهای شرکا هماهنگ می‌کند و همان قوانین، دسترسی‌ها و ردپاهای حسابرسی را به ارث می‌برد که بقیه فرآیند تجاری دارند.

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

حل مشکل هوش مصنوعی سایه

برای دموکراتیزه کردن هوش مصنوعی بدون ایجاد ریسک امنیتی، دالری استدلال می‌کند که حاکمیت باید «بخشی از مسیر» باشد، نه یک مسیر جداگانه. Pipefy به تیم‌ها اجازه می‌دهد عامل‌ها را با زبان طبیعی بسازند در حالی که نظارت سازمانی حفظ می‌شود.

• حاکمیت ساختاری: هر عاملی که توسط کاربر تجاری ساخته می‌شود، باید به‌طور خودکار دسترسی‌های مبتنی بر نقش (RBAC)، ردپاهای حسابرسی و قوانین تجاری فرآیند را به ارث ببرد. این‌ها الزامات ساختاری هستند، نه تنظیمات اختیاری.
• اصلاح معماری: «هوش مصنوعی سایه» (Shadow AI) یک مشکل معماری است، نه مشکل سیاست‌گذاری. این اتفاق زمانی می‌افتد که ابزارهای رسمی سخت‌تر از ابزارهای غیررسمی باشند و کاربران را مجبور کند عامل‌ها را در حساب‌های شخصی ChatGPT یا ابزارهای تصادفی با عدم نظارت IT بسازند.

اگر تجربه بدون کد سریع باشد و حاکمیت به‌دلیل خودکار بودن، نامرئی شود، دلیلی برای دور زدن بخش IT وجود ندارد. لحظه‌ای که حاکمیت به یک مرحله دستی تبدیل شود که کسی باید به یاد آورد، سیستم شکست خورده است.

مدیریت استقلال و ریسک

با حرکت عامل‌ها از پیشنهاد اقدام به سمت اجرای آن، سازمان‌ها باید تصمیم بگیرند استقلال کامل کجا مناسب است. دالری معتقد است این تصمیم باید بر اساس «قابلیت بازگشت و شعاع تخریب» باشد، نه هوش عامل.

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

دالری «انسان در حلقه» (Human-in-the-Loop) را نه به عنوان مالیاتی بر سرعت، بلکه به عنوان مرحله جمع‌آوری شواهد می‌بیند. با نگه داشتن انسان در مراحل پرریسک، شرکت‌ها اعتماد و شواهدی می‌سازند که در نهایت اجازه می‌دهد آن‌ها را از مراحل کم‌ریسک حذف کنند. این رویکرد به سازمان‌ها اجازه می‌دهد ثابت کنند عامل در کدام تصمیمات به‌طور مداوم درست عمل می‌کند.

ادغام حاکمیت در تولید

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

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

مکانیزم‌های حاکمیت

برای تضمین قابلیت اطمینان در سطح تولید، دالری بر مکانیزم‌های ساختاری خاصی تأکید می‌کند:

• ردپاهای حسابرسی (Audit Trails): هر اقدام عامل باید همان شواهدی را بر جای بگذارد که یک اقدام انسانی می‌گذارد.
• کنترل دسترسی مبتنی بر نقش (RBAC): عامل‌ها باید در همان محدوده دسترسی کاربرانی که از آن‌ها پشتیبانی می‌کنند، عمل کنند.
• قابلیت ردیابی (Traceability): توانایی ردیابی یک تصمیم در طول جریان کاری تا منشأ آن.
• قوانین تجاری: محدودیت‌های سختی که عامل نمی‌تواند بشکند، فارغ از اینکه استدلال LLM چه باشد.

تفاوت بین یک طرح آزمایشی موفق و یک سیستم آماده تولید در این است که آزمایشی فقط باید «کار کند»، اما سیستم تولیدی باید «قابل دفاع» باشد. حاکمیت پلی است که این دو سطح به هم وصل می‌کند.

اندازه‌گیری بازگشت سرمایه (ROI) واقعی

دالری به معیارهای مبتنی بر «ساعت‌های ذخیره شده» بی‌اعتماد است چون اغلب حکایاتی غیرقابل تأیید هستند. او معیارهای تأییدپذیر توسط حسابرس را پیشنهاد می‌کند که بتوانند در برابر نظارت مدیر مالی (CFO) مقاومت کنند:

۱. زمان چرخه (Cycle Time): اندازه‌گیری زمان یک فرآیند خاص قبل و بعد از پیاده‌سازی هوش مصنوعی.
۲. نرخ خطا/بازکاری: ردیابی کاهش اشتباهات و نیاز به اصلاح مجدد.
۳. درصد بدون تماس (Touchless Percentage): درصدی از جریان کاری که بدون هیچ دخالت انسانی تکمیل می‌شود.
۴. پوشش تبار حسابرسی: توانایی نمایش دقیق دلیل هر تصمیم عامل‌محور.

این نگاه به اندازه‌گیری خروجی به‌جای زمان، با دیدگاه مدیرعامل ProHance همخوانی دارد که استدلال می‌کند در عصر هوش مصنوعی، بهره‌وری واقعی باید بر اساس نتایج و خروجی‌ها سنجیده شود، نه ساعت‌های کاری.

اگر شرکتی نتواند ردپای حسابرسی برای یک تصمیم عامل ارائه دهد، به باور دالری آن‌ها یک «حکایت» دارند، نه عدد ROI. طرح‌های آزمایشی معمولاً در مقیاس‌پذیری شکست می‌خورند چون برای اثبات کارکرد مدل در یک محیط ایزوله ساخته شده‌اند، نه برای اثبات کارکرد سرتاسری فرآیند در ادغام با سیستم‌های ثبت رسمی شرکت. مقیاس‌پذیری در واقع یک مسئله ادغام سیستم‌هاست که لباس هوش مصنوعی پوشیده است.

عنصر انسانی

پذیرش موفق هوش مصنوعی ۲۰٪ تکنولوژی و ۸۰٪ مدیریت تغییر است. تکنولوژی عمدتاً کار می‌کند؛ چالش این است که آیا کارکنان به اندازه کافی اعتماد می‌کنند تا بررسی‌های دستی ده ساله‌شان را متوقف کنند و آیا مدیریت حاضر است فرآیند را بازطراحی کند یا فقط هوش مصنوعی را روی لایه‌های قدیمی بچسباند.

دالری مثالی داخلی از Pipefy درباره ابزارهای مهندسی می‌زند. تکنولوژی اتوماسیون ساخت نرم‌افزار مدت‌ها قبل وجود داشت، اما تیم به آن اعتماد نداشت. گشایش نه با مدل بهتر، بلکه با اثبات بصری و تکرار شونده در طول زمان رخ داد که نشان داد قضاوت سیستم با انسان‌ها یکی است. مدیریت تغییر، تمرین جمع‌آوری شواهد است، نه تمرین ارتباطات؛ اعتماد در دسته‌های کوچک و قابل تأیید به دست می‌آید، نه با اعلامیه در جلسات عمومی.

آینده عملیات

دالری پیش‌بینی می‌کند نرم‌افزارهای جریان کاری از جایی که کار در آن مستند می‌شود، به یک «زمان اجرای زنده» (Live Runtime) تبدیل شوند. در این آینده، انسان‌ها، عامل‌های هوش مصنوعی و سیستم‌های سازمانی به‌طور مستمر درون یک فرآیند تحت نظارت با هم همکاری می‌کنند.

این موضوع «سیستم ثبت» (System of Record) را تغییر می‌دهد. پیش از این، ثبت یک پایگاه داده بود که بعد از انجام کار به‌روز می‌شد. در لایه ارکستراسیون، ثبت و اجرا یکی هستند. فرآیند تبدیل به رابط کاربری می‌شود که از طریق صفحه، API، CLI یا سرورهای MCP قابل دسترسی است. این به هر عاملی، چه داخلی و چه شریک، اجازه می‌دهد تحت همان قوانینی که انسان دارد، درون فرآیند عمل کند.

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

گام بعدی شما

• بررسی کنید کدام ۲۰٪ از فرآیندهای شما واقعاً مبهم هستند و برای آن‌ها عامل بسازید، به‌جای اتوماسیون ۸۰٪ موارد قطعی.
• برای هر عامل هوش مصنوعی، یک «ردپای حسابرسی» تعریف کنید که دقیقاً نشان دهد تصمیم بر اساس کدام داده گرفته شده است.
• معیارهای ROI خود را از «ساعت‌های ذخیره شده» به «زمان چرخه» و «درصد بدون تماس» تغییر دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.