تصور کنید تحلیلگر مالی شما ابزاری حیاتی برای تطبیق حسابها میسازد، آن را در یک بعدازظهر با کمک هوش مصنوعی توسعه میدهد، در محیط عملیاتی مستقر میکند و سپس شرکت را ترک میکند. او دو هفته دوره تسلیم و تحویل خود را میگذراند، ناهار خداحافظیاش را میخورد و تیم IT چکلیست خروج اداری او را اجرا میکند. تمام خانهها تیک میخورند: حسابهای کاربری غیرفعال میشوند، لپتاپ به کمد بازمیگردد و دسترسیهای SSO لغو میشود. منابع انسانی تیکت را میبندد. هیچکس اشتباهی نکرده است، اما شش هفته بعد، بسته گزارشات तिमाही به دلیل خطا به تعویق میافتد. ابزاری که چهار نفر در سکوت به آن وابسته بودند، شروع به تولید اعداد اشتباه میکند، به گونهای که تا مدتی هیچکس متوجه آن نمیشود.
این ابزار در محیط عملیاتی فعال است، پشت سیستم احراز هویت سازمان (SSO) قرار دارد و یک اعتبارنامه (Credential) زنده برای دسترسی به پایگاهداده در اختیار دارد. اما هیچ مخزن کدی (Repository) وجود ندارد که کسی آن را بشناسد، هیچ دفترچه راهنمایی (Runbook) در کار نیست و هیچ نام تیمی در هیچکدام از سیستمها به آن متصل نشده است. این سناریو، واقعیت جدید عصر «پرامپت به محصول» (Prompt-to-Prod) است؛ جایی که توانایی خلق نرمافزار دموکراتیزه شده، اما مدل عملیاتی برای نگهداری از آن، خیر.
برای دههها، گلوگاه نرمافزارهای داخلی شرکتها «صف انتظار» بود. یک کاربر کسبوکار مجبور بود مشکلی را برای یک متخصص IT توصیف کند که احتمالاً آن را درک نمیکرد، دو فصل منتظر توسعه بماند و در نهایت چیزی دریافت کند که اغلب با آنچه مد نظرش بود، فاصله داشت. اکثر ایدههای خوب در یک فرم درخواست (Intake Form) در سکوت میمردند؛ فرآیندی که همه توافق کرده بودند نام آن را «اولویتبندی» بگذارند. اما امروز این محدودیت از بین رفته است. اکنون کسی که مشکل را میبیند، همان کسی است که راهکار را میسازد و از AI برای پر کردن شکاف فنی در عرض چند ساعت (به جای چند فصل) استفاده میکند. آنها با درک کامل از زمینه (Context) میسازند، زیرا خودشان «زمینه» هستند. من افرادی را دیدهام که هرگز خود را فنی نمینامیدند، اما چیزهایی را عرضه کردند که واقعاً خوب بود و هیچ تمایلی وجود ندارد که این قدرت را دوباره به جعبه برگردانیم.
با این حال، این چرخش، «بستهی نامرئی» تحویل نرمافزار را پاره کرده است. در گذشته، چه نرمافزاری را از یک فروشنده میخریدید و چه مهندسان داخلی آن را میساختند، نرمافزار همراه با یک ساختار سازمانی میآمد؛ یک توافقنامه سطح خدمات (SLA)، یک تیم پشتیبانی یا مدیری که پاداشش در صورت از کار افتادن سیستم تغییر میکرد. حتی آن سرویسهای قدیمی جاوا که همه از آنها شکایت میکنند، یک نام تیم در CMDB داشتند و انسانی وجود داشت که وقتی نام آن سرویس در جلسات میآمد، کمی چهرهاش درهم میرفت. ابزارهای تولید شده توسط AI بدون این داربستها وارد سازمان میشوند. ساختن دموکراتیزه شد، اما مدل عملیاتی نه. آن شکاف، جایی است که ابزار تطبیق حسابها در آن زندگی میکند.
ابعاد شکاف حاکمیتی
به نقل از مطالعهای در سال ۲۰۲۲ توسط Gartner، حدود ۴۱٪ از کارکنان «تکنولوژیستهای کسبوکار» هستند که در حالی که خارج از دپارتمان IT گزارش میدهند، قابلیتهای نرمافزاری میسازند. این عدد در واقع یک کف است، زیرا AI از آن زمان به بعد فرآیند ساخت را بسیار ساده کرده است. مقیاس (Scale) است که این موضوع را از یک مزاحمت برای تیم پلتفرم به یک مشکل برای مدیر ارشد فناوری (CIO) تبدیل میکند. وقتی ده مهندس نرمافزار چیزی را عرضه میکنند، شما ده سرویس با ده مالک مشخص دارید؛ اما وقتی چهارصد غیربرنامهنویس این کار را میکنند، با دم بلند (Long Tail) از صدها ابزار کوچک مواجه میشوید که اکثرشان توسط سه نفر استفاده میشوند و هیچ راه قابل اعتمادی وجود ندارد تا بفهمید کدامیک «حامل بار» و حیاتی هستند، مگر اینکه شکست بخورند.
پیامدهای امنیتی این خلاء مالکیت در گزارش سال ۲۰۲۶ Saviynt / Cybersecurity Insiders به وضوح و به صورت قابل اندازهگیری دیده میشود:
- ۷۵٪ از مدیران امنیت اطلاعات (CISO) ابزارهای AI تاییدنشدهای را در محیط عملیاتی یافتهاند.
- ۱۶٪ دیگر از CISOها مطمئن نیستند که آیا چنین ابزارهایی در محیط آنها وجود دارد یا خیر.
- ۹۲٪ از کسانی که ابزارها را پیدا کردند، فاقد دید کامل نسبت به هویتهای AI در محیط خود هستند.
- ۷۱٪ گزارش دادهاند که ابزارهای AI دسترسی به سیستمهای هستهای مانند Salesforce و SAP دارند.
- تنها ۱۶٪ معتقدند که این دسترسیها به طور موثر مدیریت میشوند.
- عدد تکاندهنده ۵٪ کسانی هستند که اطمینان دارند میتوانند یک عامل AI هکشده را مهار کنند.
نکته مهم این است که هیچکدام از اینها آمارهای «روز اول» نیستند. هر ابزاری که در آن نظرسنجی ذکر شده، در روز استقرار، هر بررسی امنیتی که در آن زمان وجود داشت را پاس کرده بود.
توهم «روز اول» در برابر «روز دوم»
لیران بابا (Liran Baba)، مدیر AI در تیم CIO شرکت JFrog، استدلال میکند که صنعت، «روز اول» (استقرار/Deployment) را حل کرده اما «روز دوم» (نگهداری/Maintenance) را نادیده گرفته است. روز دوم دورهای است که سالها پس از لانچ رخ میدهد؛ زمانی که چیزی در ساعتی نامناسب میشکند و کسی باید پاسخگو باشد. استقرار قبلاً یک دیوار بود، اما اکنون آن دیوار فرو ریخته است. این چالشها در واقع بخشی از مسیرهای شکست در استقرار تجاری عاملهای هوش مصنوعی هستند که مانع از تبدیل شدن نمونههای اولیه به محصولات پایدار میشوند.
در JFrog، تیمی به رهبری نیتزان گوتلیب در سازمان CISO، یک مسیر داخلی ساختند که کاربر را از یک پرامپت به یک سرویس فعال میرساند، بدون اینکه مهندسی در این چرخه دخیل باشد. این سیستم بخشهایی را مدیریت میکند که قبلاً هزینه سه تیکت و دو هفته زمان داشت:
- احراز هویت: برنامه را به Okta متصل میکند تا احراز هویت واقعی باشد و نه به صورت بداهه و غیررسمی.
- آدرسدهی: DNS را تخصیص میدهد تا ابزار یک آدرس مناسب داشته باشد، به جای اینکه یک IP در Slack چسبانده شود.
- امنیت: یک بررسی امنیتی خودکار را پیش از فعال شدن هر چیزی اجرا میکند.
در حالی که این یک «در ورودی» عالی است، بابا اشاره میکند که یک بررسی امنیتی صرفاً «عکسی از یک بعدازظهر» است. این بررسی به شما میگوید برنامه در لحظه استقرار امن بود، اما هیچ چیز درباره ۱۸ ماه بعد نمیگوید؛ زمانی که یک مدل منسوخ میشود، یک توکن چرخانده (Rotate) میشود، یا یک API بالادستی شکل پاسخ خود را تغییر میدهد و تنها کسی که میتوانست آن را توضیح دهد، اکنون در جای دیگری کار میکند. ما یک در ورودی عالی ساختیم اما هرگز به سراغ ساختن خودِ ساختمان نرفتیم. مولد (Generator) یک کالای عمومی است؛ هر آنچه دور آن پیچیده شده، محصول واقعی است.
چرا چارتهای سازمانی فعلی شکست میخورند؟
وقتی این ابزارهای بیصاحب میشکنند، شرکتها معمولاً سعی میکنند مشکل را در سه جعبه موجود جای دهند که هر سه به روشهای آموزندهای شکست میخورند:
۱. واحد کسبوکار (Business Unit): سپردن مالکیت به تحلیلگری که ابزار را ساخته، یک تخیل عملیاتی است. اگرچه از نظر فلسفی درست است، اما یک تحلیلگر مالی، چرخه پشتیبانی (On-call)، سیستم مانیتورینگ و پوشش کاری در زمان تعطیلات ماه اوت ندارد. شما مسئولیت را به گروهی سپردهاید که هیچ ابزاری برای اجرای آن ندارد. این بدترین نتیجه را ایجاد میکند: نامی در یک فیلد که باعث میشود داشبورد حاکمیتی «سبز» به نظر برسد، در حالی که در واقعیت هیچکس مراقب سیستم نیست.
۲. IT مرکزی: این مقصد پیشفرض تمام تیکتهاست، فارغ از هر سیاستی. این منجر به این میشود که تیمهای IT مجبور شوند برنامههایی را دیباگ کنند که ننوشتهاند، در پشتههای تکنولوژی (Stacks) که انتخاب نکردهاند و توسط غیربرنامهنویسانی ساخته شده که هیچ مستنداتی ارائه ندادهاند. IT مسئولیت نرمافزاری را میپذیرد که هرگز بررسی نکرده است. دادههای سال ۲۰۲۶ شرکت Fixify نشان میدهد که نرمافزارها و اپلیکیشنها به تنهایی بیش از یکسوم حجم تیکتهای Help Desk را در یک بنچمارک ۱۴ ماهه با ۵۰,۰۰۰ تیکت تشکیل میدهند. وقتی موارد Onboarding، Offboarding و مدیریت هویت را اضافه کنید، این دستهها بیش از ۷۰٪ از کل حجم تیکتها را به خود اختصاص میدهند. مشکل دقیقاً روی دستههایی نشسته است که همین حالا هم بر صف انتظار تسلط دارند.
۳. تیم پلتفرم: درخواست از تیمی که «جاده» (DNS، احراز هویت، Runtime) را مدیریت میکند تا «ماشین» (منطق تجاری داخل ۴۰۰ اپلیکیشن مختلف) را هم مالک شود، صرفاً همان صفهای انتظار توسعه مرکزی را بازسازی میکند که شرکتها یک دهه سعی کردند از شر آن خلاص شوند. حل کردن مشکل روز دوم با بازسازی صف انتظار، حل کردن آن نیست. این نشان میدهد که ما به یک جعبه جدید در چارت سازمانی نیاز داریم، نه جابجایی مسئولیت در جعبههای فعلی.
چارچوبی برای بقا در عصر AI
برای حل خلاء مالکیت، بابا سه تغییر ساختاری در خط لوله استقرار پیشنهاد میکند. اینها سیاست (Policy) نیستند، بلکه الزامات زیرساختی هستند:
- مالکیت به عنوان شرط سخت (Hard Requirement): مالکیت باید یک الزام در زمان استقرار باشد. کنترلی که مودبانه درخواست رعایت میکند، کنترل نیست؛ بلکه استقراری که از تکمیل شدن خودداری میکند، کنترل است. شما نمیتوانید بدون ثبت نام یک انسان و یک تیم در سوابق، به محیط عملیاتی برسید. این رکورد باید به فرآیند خروج کارکنان متصل شود تا وقتی کارمندی میرود، اپلیکیشنهای او به عنوان یک تصمیم صریح ظاهر شوند: «تخصیص مجدد یا خاموش کردن». مالکیت باید در زیرساخت باشد، نه در مستندات.
- تاریخ انقضای اجباری: «دم بلند» ابزارهای کوچک باید به طور پیشفرض عمر ۹۰ روزه داشته باشند. الزام به یک اقدام آگاهانه برای تمدید، شرکت را مجبور میکند بپرسد: «آیا این ابزار هنوز نیاز به وجود دارد؟». اکثر این ابزارها باید در سکوت بمیرند. مواردی که واقعاً حامل بار هستند تمدید میشوند و همین عمل تمدید است که شرکت میفهمد آنها چه هستند. حذف (Decommissioning) بخش بزرگتری از روز دوم است تا تعمیر.
- خطوط مرزی صریح زیرساخت: شرکتها باید مرز مسئولیت را به وضوح تعریف کنند و آن را جایی منتشر کنند که مسیریاب تیکتها بتواند ببیند. تیم پلتفرم مالک جاده است (احراز هویت، DNS، Runtime، مسیر استقرار، مانیتورینگ، ایمیجهای پایه، اعتبارنامهها). واحد کسبوکار مالک منطقی است که نوشته است. این کار مانع از آن میشود که تیکتهای «برنامه من قطع شده» به بازیهای متهمکننده مبهم تبدیل شوند؛ بلکه به طور شفاف به «جاده خراب است» یا «منطق شما اشتباه است» تقسیم میشود.
نقش «کیوریتور» (Curator)
از آنجا که هیچ نیروی انسانی نمیتواند صدها اپلیکیشن کوچک را مدیریت کند، خط اول تریاژ باید توسط عاملهای هوش مصنوعی (AI Agents) مدیریت شود. AI حجم را ایجاد کرد و تنها چیزی است که میتواند آن را جذب کند. عاملها باید تریاژ خط اول، تشخیص، شکار مالکان، پیشنویس اصلاحات و ثبت پیشنهادهای حذف را بر عهده بگیرند. میز خدمات (Service Desk) در حال حاضر در ورودی است؛ فقط به mandate (اختیار)، دسترسی برای اقدام و فهرستی برای مسیریابی نیاز دارد.
بالای این عاملها، بابا نقش جدیدی به نام کیوریتور یا «گردآورنده» را پیشنهاد میکند. این یک نقش پشتیبانی نیست، بلکه یک نقش مدیریت محصول برای نرمافزارهایی است که هیچکس قصد ساختنشان را نداشت. ماموریت کیوریتور، مدیریت پورتفولیو است نه هر اپلیکیشن به صورت مجزا. آنها چرخههای تمدید را زیر نظر میگیرند و تصمیم میگیرند کدام ابزارها به اندازه کافی «حامل بار» شدهاند تا به مالکیت مهندسی رسمی با SLAهای رسمی ارتقا یابند و کدام باید بدون هیچ مراسمی خاموش شوند. مهارت کمیاب در اینجا، «قضاوت» درباره این است که چه چیزی شایستگی بقا دارد.
سوالات متداول
منظور از «پشتیبانی روز دوم» در اینجا چیست؟
هر چیزی بعد از لانچ: چه کسی آن را در ساعت ۲ صبح تعمیر میکند، چه کسی وقتی یک وابستگی (Dependency) تغییر میکند آن را وصله میکند، چه کسی متوجه میشود که ابزار پاسخهای اشتباه میدهد و چه کسی تصمیم میگیرد که این ابزار هنوز باید وجود داشته باشد. از آنجا که اکثر ابزارهای داخلی برای تعداد کمی از کاربران هستند، حذف کردن بخش بزرگتری از روز دوم است تا تعمیر.
آیا این فقط همان Shadow IT با یک نام جدید نیست؟
خیر. Shadow IT طبق تعریف، تاییدنشده بود، بنابراین کشف و تجمیع راه حل بود. این نرمافزارها کاملاً تایید شدهاند؛ آنها مسیر استقرار تایید شده را طی کردهاند، بررسی امنیتی را پاس کردهاند و پشت SSO هستند. شما نمیتوانید با «کشف کردن» از شر این مشکل خلاص شوید.
آیا باید اجازه استقرار به غیربرنامهنویسان را متوقف کنیم؟
این کار باعث از دست رفتن بزرگترین بهرهوری فعلی میشود. علاوه بر این، طبق گزارش Verizon DBIR (2026)، ۴۵٪ از کارکنان اکنون کاربران منظم AI روی دستگاههای شرکتی هستند (در مقایسه با ۱۵٪ در سال قبل). ممنوعیتها صرفاً ساختوساز را از جادههای آسفالت شده شما دور میکند، نه از داخل شرکت.
اگر بررسی امنیتی قبلاً انجام شده، جایگاه امنیت کجاست؟
بررسیها عکسهای لحظهای هستند؛ اما ریسک مستمر است. ۹۲٪ از CISOها گزارش دادهاند که فاقد دید کامل نسبت به هویتهای AI هستند و تنها ۱۶٪ میگویند دسترسیها به طور موثر مدیریت میشوند (Saviynt / Cybersecurity Insiders, 2026). تاریخهای انقضا، جمعیت مورد نظارت شما را موثرتر از یک بررسی امنیتی دوم کاهش میدهند.
کوچکترین گام مفید اول چیست؟
مالکیت را به یک فیلد اجباری در لحظه استقرار تبدیل کنید و آن را به فرآیند خروج کارکنان متصل کنید. یک هفته کار، بدون هیچ زرق و برق، اما بدترین حالت شکست (اپلیکیشنی که هیچکس نمیدانست وجود دارد) را به یک تصمیم روتین در چکلیست خروج تبدیل میکند.
جمعبندی نهایی
رساندن یک غیربرنامهنویس از یک ایده به یک سرویس عملیاتی در محیط تولید، یک دستاورد واقعی بود و ماشینآلات آن — مسیر استقرار، اتصال به Okta، DNS و بررسی خودکار — ارزش ساختن دارند. اما لحظه لانچ هرگز بخش سخت کار نبود. هر تکه نرمافزاری که شرکت شما تا به حال اجرا کرده است، با یک مالک و کسی ظاهر شد که وقتی سیستم میشکند بیدار شود، زیرا تنها راه موجود برای به دست آوردن نرمافزار، شما را مجبور میکرد ابتدا این موضوع را حل کنید.
ما راه جدیدی یافتیم که این مرحله را دور میزند. اگر به تپهای در حال رشد از چیزهایی نگاه میکنید که کارکنانتان ساختهاند، سوال مفید این نیست که آیا مسیر استقرار امن است (احتمالاً هست). سوال این است که سازمان شما ۱۸ ماه دیگر وقتی یکی از آنها میشکند چه میکند، و آیا پاسخ به آن یک «نام» است یا یک «شانه بالا انداختن».
گفتگو