مشکل AI سازمانی بیشتر زیرساخت است تا کیفیت کدنویسی

هوش مصنوعی در چند دقیقه می‌تواند چیزی بسازد که قبلاً یک تیم توسعه برایش ساعت‌ها یا روزها وقت می‌گذاشت. همین سرعت یک توهم خطرناک هم ایجاد کرده است: چون نمونه اولیه سریع ساخته می‌شود، پس حتماً سازمان هم به همان سرعت می‌تواند آن را وارد عملیات واقعی کند. آمار نقل‌شده از SAP شکاف را روشن می‌کند؛ ۸۱ درصد سازمان‌ها استراتژی تفصیلی AI دارند، اما تنها حدود ۱۲ تا ۱۶ درصد به اجرای واقعاً مبتنی بر هوش مصنوعی رسیده‌اند. مشکل معمولاً این نیست که مدل نتوانسته کد خوبی بنویسد؛ مشکل از جایی شروع می‌شود که آن کد باید وارد ساختمان قدیمی و پیچیده شرکت شود.

در یک شرکت بزرگ، نرم‌افزار فقط باید «کار کند» نیست. باید با داده واقعی وصل شود، مجوزهای درست داشته باشد، مقررات و امنیت را رعایت کند، در برابر تغییرات مقاوم باشد و سال‌ها قابل نگهداری بماند. مایکل املینگ (Michael Ameling)، مدیر ارشد محصول SAP Business Technology Platform، می‌گوید در برخی مشتریان بزرگ SAP کد ۱۰ تا ۲۰ سال در محیط عملیاتی می‌ماند. یعنی کسی باید سال‌ها بعد هنوز بفهمد این منطق چه می‌کند، بتواند آن را وصله کند و مسئولیتش را بر عهده بگیرد. هوش مصنوعی می‌تواند کد تولید کند، اما چرخه عمر نرم‌افزار را خودکار و جادویی تولید نمی‌کند.

مانع بعدی یکپارچه‌سازی است. محیط واقعی سازمان شبیه یک آپارتمان تازه‌ساز با سیم‌کشی مرتب نیست؛ بیشتر شبیه ساختمانی است که طی چند دهه اتاق‌های جدید به آن اضافه شده‌اند. سرویس‌های ابری، سیستم‌های قدیمی داخل شرکت، انبارهای داده جداگانه و ده‌ها برنامه کسب‌وکار باید با هم کار کنند. اگر عامل هوش مصنوعی قرار است از یک توصیه ساده فراتر برود و واقعاً عملیاتی انجام دهد، باید قبل از اجرا به داده ساخت‌یافته، تصویر کامل فرایندها و APIهای سیستم‌های جدید و قدیمی دسترسی قابل کنترل داشته باشد. SAP برای این لایه به ابزارهایی مانند Joule Studio، Integration Suite، Business Data Cloud و معماری عامل‌های سازمانی خود تکیه می‌کند تا AI فقط داده خام نبیند، بلکه بفهمد کسب‌وکار چگونه کار می‌کند.

مسئله وقتی حساس‌تر می‌شود که AI از «پیشنهاد دادن» به «عمل کردن» برسد. یک عامل ممکن است رکوردی را تغییر دهد، فرایندی را آغاز کند یا با سیستم تراکنشی زنده ارتباط داشته باشد. در این مرحله باید همان سؤالاتی را درباره آن بپرسیم که درباره یک کارمند می‌پرسیم: هویت این عامل چیست؟ به چه چیزی اجازه دسترسی دارد؟ از طرف چه کسی عمل می‌کند؟ و اگر اشتباه کرد، مسیر تصمیمش قابل بررسی است؟ مقاله دو مدل را توضیح می‌دهد: گاهی عامل مجوزهای کاربر را به ارث می‌برد و از طرف او عمل می‌کند؛ گاهی هم هویت مستقل و نقش تعریف‌شده خودش را دارد. در هر دو حالت، شرکت به یک مرکز کنترل نیاز دارد که نشان دهد چه عامل‌هایی وجود دارند، به چه APIهایی دسترسی دارند و دقیقاً مجاز به انجام چه کارهایی هستند.

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

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