پیاده‌سازی هوش مصنوعی در سازمان، مال کیست؟

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

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

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

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

پس پیاده‌سازی هوش مصنوعی در سازمان مال کیست؟

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

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

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

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

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

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

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

از جایی شروع کنید که کار سخت می‌شود

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

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

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

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

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

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

اطلاعات قابل‌اتکا بخشی از رابطه است

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

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

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

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

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

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

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

مشارکت باید پیاده‌سازی را تغییر دهد

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

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

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

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

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

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

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

هوش مصنوعی قرارداد قضاوت را آشکار می‌کند

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

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

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

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

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

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

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

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

شواهد باید تعهد بعدی را به دست بیاورند

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

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

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

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

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

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

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

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

مقاومت شاهد است، اما همیشه حق وتو نیست

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

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

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

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

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

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

شراکت یک انضباط تحویل است

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

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

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

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

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