چطور هوش مصنوعی را به سیستم‌های قدیمی اضافه کنیم؟

اضافه‌کردن هوش مصنوعی به یک کسب‌وکار همیشه از ساخت یک سیستم جدید شروع نمی‌شود.

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

پس اولین سؤال نباید این باشد که «چطور این سیستم را با AI جایگزین کنیم؟»

سؤال بهتر این است:

چطور AI را به چیزی که همین حالا داریم متصل کنیم، بدون اینکه بخش سالم سیستم را هم به خطر بیندازیم؟

در بسیاری از پروژه‌ها جواب، بازنویسی کامل سیستم نیست. می‌توان قابلیت‌های جدید را در کنار سیستم موجود ساخت و ارتباط بین آن‌ها را از طریق API، لایه‌های واسط، جریان‌های رویداد یا یک لایه داده کنترل‌شده برقرار کرد. معماری‌هایی مثل Strangler Fig نیز دقیقاً برای همین نوع نوسازی مرحله‌ای طراحی شده‌اند: سیستم قدیمی و جدید مدتی کنار هم کار می‌کنند و تغییرات به‌تدریج انجام می‌شود. Microsoft و AWS هر دو این رویکرد را برای کاهش ریسک Modernization سیستم‌های قدیمی توضیح داده‌اند.

اول مشخص کنید AI قرار است چه چیزی را بهتر کند

شروع پروژه با جمله «می‌خواهیم AI داشته باشیم» معمولاً اطلاعات زیادی به تیم فنی نمی‌دهد.

AI باید یک مسئله مشخص داشته باشد.

مثلاً قرار است درخواست‌های پشتیبانی را دسته‌بندی کند؟ از اطلاعات فروش پیش‌بینی بسازد؟ میان هزاران سند سازمانی پاسخ پیدا کند؟ اطلاعات چند سیستم را کنار هم تحلیل کند؟ یا بخشی از یک فرایند دستی را خودکار کند؟

این تفاوت مهم است، چون معماری هرکدام می‌تواند کاملاً متفاوت باشد.

اگر مسئله شما جست‌وجو در مستندات داخلی است، ممکن است RAG انتخاب مناسبی باشد. اگر قرار است AI بر اساس تغییرات لحظه‌ای یک سیستم تصمیم بگیرد، احتمالاً به جریان داده یا معماری Event-driven نیاز دارید. اگر قرار است عملیاتی در ERP قدیمی انجام شود، API و کنترل سطح دسترسی بسیار مهم‌تر می‌شود.

بنابراین قبل از انتخاب مدل، باید Use Case مشخص باشد.

به زبان ساده:

اول مسئله، بعد AI.

قدم بعدی: بفهمید با چه سیستمی طرف هستید

سیستم‌های قدیمی معمولاً یک مشکل مشترک دارند: چیزهای زیادی در طول سال‌ها به آن‌ها وصل شده است.

یک جدول ممکن است توسط سه نرم‌افزار استفاده شود. یک سرویس قدیمی شاید اطلاعات پنج واحد سازمان را تأمین کند. بخشی از Business Logic ممکن است داخل Stored Procedure باشد و بخشی دیگر در کدی که سال‌هاست کسی به آن دست نزده.

به همین دلیل اتصال AI بدون شناخت این وابستگی‌ها می‌تواند خطرناک باشد.

AWS در مستندات جدید AWS Transform نیز به همین مسئله اشاره می‌کند: در Codebaseهای Legacy، مستندات محدود، وابستگی‌های درهم‌تنیده و Business Logic پراکنده باعث می‌شوند بعضی محدودیت‌ها تازه در مراحل بعدی پروژه دیده شوند؛ درست زمانی که تغییرشان پرهزینه‌تر شده است.

قبل از اتصال AI باید حداقل تصویر روشنی از این موارد داشته باشیم: داده موردنیاز کجاست، چه کسی آن را تغییر می‌دهد، چه سیستم‌هایی به آن وابسته‌اند، چه API یا Interfaceهایی در دسترس است، اطلاعات با چه سرعتی تغییر می‌کنند و AI دقیقاً باید دسترسی Read داشته باشد یا Write هم لازم است.

قرار نیست برای شروع، تمام تاریخچه بیست‌ساله نرم‌افزار را مستند کنیم. باید همان بخشی را بشناسیم که Use Case انتخاب‌شده به آن وابسته است.

راه اول: یک لایه API یا Adapter بین AI و سیستم قدیمی

یکی از کاربردی‌ترین روش‌ها این است که AI مستقیماً با جزئیات سیستم Legacy درگیر نشود.

بین آن‌ها یک لایه واسط قرار می‌گیرد.

Microsoft این معماری را Anti-Corruption Layer می‌نامد: یک Facade یا Adapter بین سیستم قدیمی و بخش جدید قرار می‌گیرد و درخواست‌ها، فرمت داده یا مدل‌های متفاوت دو طرف را به یکدیگر ترجمه می‌کند. در نتیجه سیستم جدید مجبور نیست تمام محدودیت‌ها و قراردادهای قدیمی را وارد طراحی خودش کند.

فرض کنید نرم‌افزار فروش قدیمی شما اطلاعات مشتری را با ساختاری عجیب ذخیره می‌کند.

به‌جای اینکه AI مستقیماً آن ساختار را بشناسد، Adapter می‌تواند یک Interface تمیز ارائه کند:

درخواست «سابقه خرید این مشتری» وارد می‌شود؛ Adapter داده لازم را از سیستم Legacy می‌گیرد، آن را به فرم استاندارد تبدیل می‌کند و فقط همان اطلاعات موردنیاز را به سرویس AI می‌دهد.

این کار یک مزیت دیگر هم دارد: کنترل.

می‌توان مشخص کرد AI دقیقاً چه داده‌ای را ببیند و چه عملیاتی را اصلاً نتواند انجام دهد.

راه دوم: وقتی Real-time لازم است، از Event استفاده کنید

همه ارتباط‌ها نباید به شکل درخواست مستقیم بین دو سیستم باشند.

گاهی بهتر است سیستم قدیمی فقط اعلام کند که «اتفاقی افتاده است».

مثلاً:

• یک سفارش جدید ثبت شد.
• وضعیت مشتری تغییر کرد.
• یک تراکنش مشکوک ثبت شد.
• موجودی از حد مشخصی پایین‌تر رفت.

این Event می‌تواند وارد Message Broker یا Event Stream شود و سرویس AI آن را بدون ایجاد وابستگی مستقیم به نرم‌افزار اصلی پردازش کند.

Microsoft در معماری‌های Enterprise Integration توضیح می‌دهد که استفاده از Message Broker و Event می‌تواند سیستم‌ها را از یکدیگر Decouple کند و در شرایطی که Backend موقتاً در دسترس نیست، پیام‌ها را برای پردازش بعدی نگه دارد. معماری Event-driven همچنین اجازه می‌دهد Consumerهای جدید بدون تغییر Producer به جریان اضافه شوند.

این مدل برای AI کاربرد زیادی دارد؛ چون مدل می‌تواند در کنار Core System کار کند، بدون اینکه هر بار مجبور باشیم منطق داخلی سیستم قدیمی را تغییر دهیم.

راه سوم: AI لازم نیست همیشه وارد خود سیستم شود

یک سناریوی بسیار رایج این است که AI فقط به دانش و داده موجود در سیستم نیاز دارد، نه به خود نرم‌افزار.

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

در این حالت ممکن است اصلاً لازم نباشد مدل را داخل نرم‌افزار Legacy قرار دهیم.

می‌توان داده‌های مجاز را از منابع موجود استخراج و وارد یک Retrieval Pipeline کرد و سپس با معماری RAG یا Retrieval-Augmented Generation پاسخ مدل را بر اساس همان اطلاعات سازمانی Ground کرد.

Microsoft، RAG را الگویی معرفی می‌کند که یک سیستم بازیابی را در کنار مدل زبانی قرار می‌دهد تا اطلاعات مرتبط هنگام درخواست در اختیار مدل قرار بگیرد. Google Cloud نیز در معماری RAG سازمانی خود، Data Ingestion و Serving را به‌عنوان دو بخش مجزا در نظر می‌گیرد و منابع داده می‌توانند Application، Database یا Streaming Service باشند.

این تفاوت مهمی با این تصور دارد که برای استفاده از اطلاعات شرکت باید مدل را با تمام داده‌های داخلی دوباره Train کنیم.

در بسیاری از Use Caseهای دانشی، RAG می‌تواند مسیر کنترل‌پذیرتری برای استفاده از اطلاعات به‌روز سازمان باشد.

راه چهارم: سیستم را مرحله‌ای نوسازی کنید

گاهی هنگام اضافه‌کردن AI مشخص می‌شود که بخشی از سیستم قدیمی واقعاً باید تغییر کند.

باز هم لازم نیست همه‌چیز هم‌زمان بازنویسی شود.

در الگوی Strangler Fig یک لایه واسط بین Client و Backend قرار می‌گیرد. ابتدا بیشتر درخواست‌ها همچنان به سیستم قدیمی می‌روند. بعد هر بخش که نوسازی می‌شود، بخشی از ترافیک به سرویس جدید هدایت خواهد شد. این روند ادامه پیدا می‌کند تا مسئولیت سیستم قدیمی کمتر شود یا در صورت نیاز کاملاً کنار گذاشته شود.

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

Google Cloud نیز در رویکرد Lean Modernization پیشنهاد می‌کند به‌جای نوسازی کامل یک Application قدیمی به‌صورت یکجا، سرویس‌های جدید برای Use Caseهای مشخص ساخته شوند و سیستم به‌تدریج تغییر کند.

معماری ساده یک پروژه AI روی سیستم Legacy چه شکلی است؟

یک معماری منطقی معمولاً AI را مستقیم روی Database اصلی و با بالاترین سطح دسترسی رها نمی‌کند.

سیستم موجود همچنان Core Business را اجرا می‌کند.

• یک API، Adapter یا Event Layer ارتباط را کنترل می‌کند.
• داده لازم وارد سرویس AI یا لایه Retrieval می‌شود.
• مدل نتیجه را تولید می‌کند.
• نتیجه قبل از ورود دوباره به Workflow اعتبارسنجی می‌شود.
• و تمام این مسیر Log و Monitor می‌شود.

این جداسازی شاید در نگاه اول یک لایه اضافه به نظر برسد، اما دقیقاً همان لایه‌ای است که بعدها اجازه می‌دهد مدل، Provider یا حتی معماری AI را عوض کنیم، بدون اینکه قلب سیستم عملیاتی را دوباره دستکاری کنیم.

برای شروع، Read بهتر از Write است

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

برای Pilot اول، تا جایی که Use Case اجازه می‌دهد، Read-only انتخاب امن‌تری است.

مثلاً AI می‌تواند سفارش‌های مشکوک را شناسایی کند، اما خودش سفارش را حذف نکند.

می‌تواند پیشنهاد خرید تولید کند، اما خودش Purchase Order نهایی را ثبت نکند.

می‌تواند پاسخ پیشنهادی برای مشتری آماده کند، ولی در مراحل حساس ارسال نهایی با انسان باشد.

این مسئله با Agentهای هوشمند مهم‌تر هم شده است.

OWASP درباره Excessive Agency هشدار می‌دهد؛ یعنی زمانی که یک سیستم مبتنی بر LLM قابلیت، سطح دسترسی یا اختیار بیشتری از چیزی که واقعاً لازم دارد دریافت می‌کند. توصیه OWASP این است که Toolها و Permissionها به حداقل لازم محدود شوند و برای عملیات مهم از Human Approval استفاده شود.

قاعده ساده‌ای که ارزش به خاطر سپردن دارد:

AI نباید فقط به این دلیل که می‌تواند کاری را انجام دهد، اجازه انجام آن را هم داشته باشد.

امنیت را بعداً اضافه نکنید

وصل‌کردن مدل به سیستم‌های سازمانی یک Trust Boundary جدید ایجاد می‌کند.

AI ممکن است به اطلاعات مشتری، فایل‌های داخلی، اطلاعات مالی یا APIهایی دسترسی پیدا کند که پیش از این فقط برنامه‌های مشخصی آن‌ها را می‌دیدند.

به همین دلیل کنترل دسترسی باید از ابتدا جزئی از معماری باشد.

OWASP در راهنمای امنیتی GenAI، Prompt Injection، افشای اطلاعات حساس، مدیریت نامناسب خروجی و Excessive Agency را از ریسک‌های مهم برنامه‌های مبتنی بر LLM می‌داند. نسخه ۲۰۲۶ OWASP GenAI LLM Top 10 نیز در اوت ۲۰۲۶ منتشر شده و همچنان تمرکز ویژه‌ای روی امنیت برنامه‌های LLM و Agentic دارد.

NIST نیز در AI Risk Management Framework تأکید می‌کند که مدیریت ریسک باید در طراحی، توسعه، استفاده و ارزیابی سیستم AI حضور داشته باشد؛ نه اینکه بعد از Production به پروژه اضافه شود.

پس دسترسی AI به سیستم Legacy باید مثل دسترسی هر سرویس حساس دیگری طراحی شود: فقط داده لازم، فقط Permission لازم و با امکان Audit.

کیفیت داده معمولاً از انتخاب مدل مهم‌تر می‌شود

می‌توان بهترین مدل موجود را به یک سیستم وصل کرد و باز هم نتیجه ضعیفی گرفت.

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

قبل از AI باید مشخص شود Source of Truth کجاست.

• کدام داده معتبر است؟
• کدام داده به‌روز است؟
• چه اطلاعاتی نباید در اختیار مدل قرار بگیرد؟
• و اگر دو سیستم جواب متفاوتی درباره یک مشتری دادند، کدام‌یک مرجع است؟

در معماری‌های RAG نیز همین مسئله وجود دارد. Google Cloud برای RAG سازمانی بر Data Ingestion، آماده‌سازی داده، Index و Metadata تأکید می‌کند تا سیستم بتواند Context مناسب‌تری بازیابی کند.

AI می‌تواند روی داده شما کار کند؛ اما کیفیت همان داده همچنان مسئولیت سیستم است.

از یک Pilot کوچک شروع کنید

اولین پروژه AI لازم نیست مهم‌ترین فرایند شرکت را کاملاً خودکار کند.

اتفاقاً بهتر است نکند.

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

مثلاً اگر کارکنان روزانه زمان زیادی برای پیدا کردن اطلاعات بین اسناد صرف می‌کنند، یک Knowledge Assistant داخلی می‌تواند Pilot خوبی باشد.

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

اگر مدیران مجبورند چند گزارش را دستی کنار هم بگذارند، AI می‌تواند ابتدا نقش تحلیل‌گر کمکی را داشته باشد.

در Pilot باید قبل از شروع مشخص کنیم «موفقیت» یعنی چه.

• زمان کمتر؟
• خطای کمتر؟
• پاسخ سریع‌تر؟
• پیش‌بینی دقیق‌تر؟
• کاهش کار دستی؟

وقتی معیار روشن باشد، تصمیم برای ادامه، تغییر یا توقف پروژه هم روشن‌تر می‌شود.

چه زمانی بهتر است فعلاً AI اضافه نکنیم؟

قدیمی‌بودن سیستم دلیل کافی برای اضافه‌کردن AI نیست؛ همان‌طور که جدیدبودن AI دلیل کافی برای استفاده از آن نیست.

اگر مسئله با یک Rule ساده حل می‌شود، احتمالاً LLM لازم نیست.

اگر داده قابل‌اعتمادی وجود ندارد، اول باید مشکل داده حل شود.

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

و اگر نمی‌توانیم توضیح دهیم AI دقیقاً چه KPIای را بهتر خواهد کرد، شاید پروژه هنوز آماده شروع نیست.

بهترین پروژه‌های AI معمولاً از سؤال «کجا می‌توانیم AI بگذاریم؟» شروع نمی‌شوند.

از سؤال «کدام مشکل ارزش حل‌کردن دارد؟» شروع می‌شوند.

یک مسیر عملی برای تصمیم‌گیری

جمع‌بندی

سیستم Legacy لزوماً مانع ورود هوش مصنوعی نیست.

خیلی وقت‌ها مشکل اصلی نه سن سیستم، بلکه راه دسترسی به داده و فرایندهای آن است.

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

گاهی این مرز یک API است.

گاهی Adapter.

گاهی Event Stream.

و گاهی یک Data Pipeline و RAG.

مهم این است که AI را مستقیماً به قلب سیستم وصل نکنیم و امیدوار نباشیم همه‌چیز درست پیش برود.

سیستم قدیمی لازم نیست یک‌شبه جدید شود؛ کافی است مسیر درستی برای ارتباط با چیزهای جدید داشته باشد.

→بازگشت به مقالات