هوش مصنوعی را خریده ایم؛ مسئول نتیجه کیست؟

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

امروز ابزار ها فرق کرده اند، اما پرسش همان است: وقتی هوش مصنوعی به گردش کار سازمان وارد می شود، چه کسی مالک نتیجه است؟ جواب «تیم فناوری» یا «کسب و کار» به تنهایی کافی نیست. باید برای هر تصمیم، یک مسئول روشن و شریکانی داشته باشیم که واقعیت کار را می شناسند.

مسئولیت را بر اساس تصمیم تقسیم کنید

جمله ی «نتیجه مال کسب وکار است و سامانه مال فناوری» شروع خوبی است. اما برای اداره ی یک پروژه به اندازه ی کافی دقیق نیست.

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

«قرارداد پیاده سازی» زیر این مرز ها را قابل دیدن می کند:

این مالکیت جمعی نیست که در آن همه مسئول اند و هیچ کس نمی تواند تصمیم بگیرد. هر ردیف یک مالک اصلی دارد. شراکت یعنی مالک نمی تواند بدون دانشی که در دست بقیه است، پاسخ را تعریف کند.

این تمایز مهم است. یادداشت پلتفرم هوش مصنوعی را متمرکز کنید، نه همه ی تصمیم ها را توضیح می دهد چرا زیرساخت مشترک و اختیار محلیِ هر حوزه به مرز های متفاوتی نیاز دارند. یک تیم مرکزی می تواند مدل های تأییدشده، هویت، ثبت رویداد ها، ابزار ارزیابی و یکپارچه سازی های قابل استفاده ی مجدد را فراهم کند. اما بدون کسانی که آن کار را می فهمند، نمی تواند تعیین کند یک استثنای درست در خرید، یک تحویل ایمن در درمان یا یک پاسخ قابل قبول به مشتری چه شکلی دارد.

فرایند واقعی را ببینید، نه فقط نمودار را

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

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

اگر تیم نمودار رسمی را خودکار کند، دستیار ممکن است در نمایش عالی کار کند و در اولین استثنای جدی شکست بخورد.

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

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

پس تناسب با گردش کار، کاربرپسندی ای نیست که نزدیک راه اندازی اضافه شود. یک ورودی طراحی است. کسانی که کار را انجام می دهند کمک می کنند قاعده ی پایدار از استثنای ضروری و از مرحله ی قدیمیِ غیرضروری جدا شود.

اعتماد از اطلاعات درست و اصلاح خطا می آید

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

یک دستیار بازیابی نمی تواند اسناد سیاستیِ متناقض را تعمیر کند. یک مدل پیش بینی نمی تواند اختلاف دو واحد را بر سر تعریف یک مفهوم کسب وکاری حل کند. یک ایجنت وقتی شناسه ها ناسازگارند نمی تواند سوابق را ایمن به روز کند. یک استخراج گر اسناد ممکن است خروجی ساخت یافته ی معتبری بدهد، در حالی که دارد یک فرم منسوخ را می خواند.

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

قرارداد اطلاعات باید به پرسش های عملی پاسخ دهد:

• برای این تصمیم کدام منبع معتبر است؟
• چه کسی می تواند آن را تغییر دهد و با چه سرعتی؟
• سامانه منبع، نسخه یا عدم قطعیت را چطور به کاربر نشان می دهد؟
• وقتی دو منبع تأییدشده با هم تعارض دارند چه می شود؟
• مدل کدام داده را می تواند بازیابی کند و کدام مجوز های کاربر باید همراهش منتقل شوند؟
• یک مشکل داده ایِ گزارش شده چطور به یک اصلاح و یک آزمون رگرسیون تبدیل می شود؟

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

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

نظر کاربران وقتی ارزش دارد که چیزی را عوض کند

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

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

تیم پیاده سازی مجبور نیست همه ی درخواست ها را بپذیرد. اما باید حلقه را ببندد: چه شنیده شد، چه تغییر کرد، چه تغییر نکرد و چرا.

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

مجموعه ی بهترین رویه های OECD در سال ۲۰۲۵ برای پذیرش انسان محور هوش مصنوعی در کار هم به همین شکل پذیرش قابل اعتماد را به مشورت، آموزش، شفافیت، نظارت انسانی و پاسخ گویی گره می زند. این ایده ها نباید به یک کمپین اطلاع رسانی تقلیل پیدا کنند. آن ها الزامات سامانه را تغییر می دهند.

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

اگر مشارکت نتواند چیزی را تغییر دهد، آدم ها متوجه می شوند. پروژه از آن ها اعتماد می خواهد، در حالی که به آن ها یاد می دهد شواهدشان هیچ اثری ندارد.

از اول مرز اختیار ماشین را مشخص کنید

نرم افزار سنتی می تواند قضاوت را درون قواعد، فرم ها و مسیر های تأیید پنهان کند. هوش مصنوعی مولد عدم قطعیت را آشکارتر می کند.

یک مدل می تواند پاسخی باورپذیر اما بی پشتوانه تولید کند. یک ایجنت می تواند ابزاری معتبر را برای موقعیتی اشتباه انتخاب کند. یک طبقه بند می تواند در مجموع خوب عمل کند و در گروه کوچکی از موارد پرپیامد شکست بخورد. یک دستیار برنامه نویسی می تواند تولید کد را سریع کند و گلوگاه را به بازبینی، آزمون یا امنیت منتقل کند.

قرارداد قضاوت تعیین می کند خروجی ماشین کجا تمام می شود و اقدام پاسخ گوی انسانی کجا شروع می شود.

یک ایجنت خرید داخلی را در نظر بگیرید. «ایجنت در خرید کمک می کند» طراحیِ اختیار نیست. تیم باید تصمیم بگیرد آیا ایجنت می تواند کاتالوگ را جست وجو کند، کالایی را پیشنهاد دهد، پیش نویس درخواست خرید بنویسد، آن را ثبت کند، تأمین کننده انتخاب کند یا خریدی را تأیید کند. هر مرحله پیامد های متفاوتی دارد. هر کدام به یک مالک مشخص، یک مرز داده، یک روش ارزیابی و شاید یک دروازه ی انسانی نیاز دارد.

تیم باید این قرارداد را با موارد واقعی بیازماید:

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

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

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

گسترش را به نتیجه ی آزمون وابسته کنید

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

قرارداد یادگیری به پیاده سازی مسیری منضبط می دهد: از شواهد محلی به تعهدی گسترده تر.

با تیمی شروع کنید که آمادگی دارد، مسئله اش واقعی است و مدیرش مالکیت را می پذیرد. پیش از معرفی سامانه، وضعیت پایه را بسنجید. برای یک گردش کار خدماتیِ متکی به هوش مصنوعی، این می تواند شامل زمان رسیدگی، تماس های تکراری، کیفیت ارجاع، زحمت اصلاح و تجربه ی کاربر باشد. شاخص های سامانه را هم اضافه کنید: نرخ پاسخ های مستند، کیفیت بازیابی، تأخیر، هزینه به ازای هر مورد تکمیل شده و دفعات نادیده گرفتن خروجی توسط انسان.

بعد نتایج را با کسانی که کار را انجام می دهند بازبینی کنید. کاهش زمان رسیدگی ممکن است دوباره کاریِ بیشتری را در مراحل بعد پنهان کند. استفاده ی زیاد ممکن است نشانه ی اجبار باشد، نه ارزش. نادیده گرفتن های مکرر ممکن است یعنی نظارت سالم، یا ممکن است ضعف مدل را آشکار کند. نرخ شکست پایین هم ممکن است غیرقابل قبول باشد، اگر شکست های باقی مانده موارد پرپیامد را درگیر کنند.

تصمیم در پایان هر مرحله باید صریح باشد:

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

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

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

مخالفت را بررسی کنید، اما هر بار عقب نشینی نکنید

شراکت در پیاده سازی به معنای منتظر ماندن برای اشتیاق همگانی نیست.

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

مدیران باید پیش از واکنش، نوع مقاومت را تشخیص دهند.

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

شنیدن به معنای واگذاری اختیار نیست. شواهدی را بهتر می کند که اختیار بر پایه ی آن عمل می کند.

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

پیاده سازی وقتی تمام می شود که کار هم تغییر کند

تجربه ی من در سازمان آب و برق خوزستان در ذهنم ماند، چون تغییر نتایج با یک ادعای فنیِ چشمگیرتر شروع نشد. وقتی شروع شد که پیاده سازی آن قدر به کار نزدیک شد که آدم ها بتوانند شکلش دهند و بهبودی باورپذیر ببینند.

هوش مصنوعی سازمانی پرسش های مهندسیِ تازه ای درباره ی مدل ها، بازیابی، ارزیابی، ایجنت ها، مجوز ها، مشاهده پذیری، هزینه و بازبینی انسانی پیش می کشد. اما آن نیاز سازمانیِ قدیمی را حذف نمی کند: کسانی که سامانه را می سازند و کسانی که با آن زندگی می کنند، باید به اندازه ی کافی واقعیت مشترک داشته باشند تا تصمیم های درست بگیرند.

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

اعتماد دستوری نیست که روز راه اندازی صادر شود. نتیجه ی انباشته ی تصمیم هایی است که دیده می شوند: گردش کار، کار واقعی را بازتاب می دهد، مشکلات اطلاعاتی اصلاح می شوند، مشارکت طراحی را تغییر می دهد، مرز های سامانه روشن اند و گسترش دنبال شواهد می آید.

این طور است که پیاده سازی چیزی بیش از نصب می شود. به شراکتی عملیاتی تبدیل می شود که می تواند فناوری را پس از رفتن تیم پروژه هم سر پا نگه دارد.