AI assistant বন্ধ হলে কাজও থামে? ৩০ মিনিটে fallback চালুর পরিকল্পনা

AI assistant বন্ধ হলে প্রথম লক্ষ্য সব automation সচল রাখা নয়; ভুল বা duplicate action আটকিয়ে সবচেয়ে জরুরি workflow নিরাপদে চালু রাখা। ৩০ মিনিটের response tier-এ নতুন write action থামান, চলমান কাজের অবস্থা সংরক্ষণ করুন, read-only fallback খুলুন এবং অনুমোদনযোগ্য কাজ human queue-তে পাঠান।

এই ৩০ মিনিট provider-এর recovery-time প্রতিশ্রুতি নয়—এটি প্রতিষ্ঠানের নিজস্ব fallback চালুর লক্ষ্য। শুধু বিকল্প model রাখলে হবে না; identity, data connector, prompt ও source, tool action এবং human approval—প্রতিটি স্তরের বিকল্প পথ আগে থেকে প্রস্তুত থাকতে হবে।

Provider নয়, পুরো workflow ভেঙে দেখুন

প্রথমে একটি গুরুত্বপূর্ণ workflow শুরু থেকে শেষ পর্যন্ত লিখুন: কে অনুরোধ করে, AI কোন data পড়ে, কোন prompt চালায়, ফল কোথায় পাঠায় এবং শেষ action কে অনুমোদন করে। প্রতিটি ধাপকে তিন শ্রেণিতে ভাগ করুন—বন্ধ থাকবে, manual mode-এ চলবে অথবা সীমিত fallback-এ চলবে।

Payment, customer record পরিবর্তন, production deployment, access grant এবং গ্রাহকের কাছে স্বয়ংক্রিয় বার্তা পাঠানোর মতো high-impact write action default হিসেবে বন্ধ রাখুন। Knowledge search, খসড়া তৈরি কিংবা পুরোনো নথি দেখা read-only mode-এ চলতে পারে। Fallback থেকে কোনো write action ছাড়তে হলে আলাদা human approval প্রয়োজন হবে।

এক provider-এর সব component একই সময়ে recover করে না। ৩ সেপ্টেম্বর ২০২৬-এর Claude status history-তে একাধিক model-এর elevated error, fix deployment, monitoring এবং modelভেদে recovery-এর আলাদা ধাপ নথিভুক্ত আছে। তাই সামগ্রিক status উন্নত হলেও নির্দিষ্ট model ও connector পরীক্ষা না করে workflow প্রস্তুত ধরে নেওয়া ঠিক নয়।

প্রথম ৩০ মিনিট: side effect থামিয়ে অবস্থা ধরে রাখুন

প্রথম আধঘণ্টায় পূর্ণ diagnosis শেষ করার চেষ্টা না করে অনিয়ন্ত্রিত side effect বন্ধ করুন। Runbook-এ আগে থেকেই incident commander, technical owner এবং business approver নির্ধারিত রাখুন, যাতে outage শুরু হলে দায়িত্ব বণ্টনে সময় নষ্ট না হয়।

1. AI-নির্ভর scheduler, agent ও retry worker pause করুন; request queue মুছবেন না।
2. শেষ সফল request, অসমাপ্ত job ID, tool call এবং approval state-এর timestamp-সহ snapshot নিন।
3. Provider status notification দেখুন এবং internal incident channel-এ একটি authoritative update রাখুন।
4. Write permission বন্ধ করে cached source-সহ read-only search বা retrieval path চালু করুন।
5. জরুরি request human queue-তে পাঠিয়ে owner, deadline ও approval record যুক্ত করুন।

৩০ মিনিট শেষে লিখিতভাবে জানান কোন workflow বন্ধ, কোনটি manual, কোনটি read-only এবং পরবর্তী review কখন হবে। Fallback model কেবল তখনই চালু করুন, যখন তার identity, data boundary, retention এবং output handling আগে থেকে অনুমোদিত; incident চলাকালে নতুন vendor account খুলে production data পাঠানো continuity নয়, নতুন ঝুঁকি।

চার ঘণ্টা: সীমিত fallback-এ কাজ বাছাই করুন

চার ঘণ্টার tier-এ backlog জমতে শুরু করলে revenue impact, security risk, regulatory deadline এবং customer harm অনুযায়ী queue সাজান। সব workflow-তে “আগে এসেছে, আগে যাবে” নীতি কার্যকর নয়। প্রতিটি item-এর সঙ্গে মূল request ID রাখুন, যাতে recovery-এর পরে একই কাজ দ্বিতীয়বার সম্পন্ন হয়েছে কি না বোঝা যায়।

Fallback model-কে primary model-এর সমান permission দেবেন না। Versioned ও approved prompt, প্রয়োজনীয় source-এর read-only copy, সীমিত context এবং allowlisted tool দিন। Output সরাসরি publish বা execute না করে reviewer-এর কাছে পাঠান; approve, reject বা edit—যে সিদ্ধান্তই হোক, request ID-এর সঙ্গে নথিভুক্ত করুন।

একই সময়ে একাধিক AI service ব্যাহত হওয়া মানেই তাদের একটি shared failure ছিল—এ সিদ্ধান্তে পৌঁছানো যায় না। ৩ সেপ্টেম্বরের disruption নিয়ে WIRED-এর অনুসন্ধানে OpenAI ও Anthropic কোনো shared external cause নির্দেশ করেনি; OpenAI routing error-এর কথা বলেছিল, আর Anthropic নিজস্ব cause শনাক্ত করার কথা status update-এ জানিয়েছিল। তাই অন্য provider সব সময় সচল থাকবে ধরে না নিয়ে একটি manual path রাখুন।

এক দিন: controlled degradation নির্ধারণ করুন

এক কর্মদিবস ধরে disruption চললে পূর্ণ automation অনুকরণ না করে controlled degradation চালু করুন। শর্তসাপেক্ষ উদাহরণ হিসেবে customer support-এ শুধু জরুরি category নেওয়া, sales enrichment বন্ধ রেখে verified contact ব্যবহার করা, কিংবা code suggestion চালু রেখেও merge ও deployment মানুষের হাতে রাখা যায়। কোনটি গ্রহণযোগ্য, তা প্রতিষ্ঠানের ঝুঁকি ও আইনি বাধ্যবাধকতার ওপর নির্ভর করবে।

Business owner ঠিক করবেন কোন service level সাময়িকভাবে কমবে এবং intake সীমিত করা হবে কি না। Customer-facing team-কে অনুমোদিত বার্তা দিন, তবে provider নিশ্চিত না করলে recovery time দাবি করবেন না। Backlog-এর আকার, সবচেয়ে পুরোনো item, manual processing capacity এবং আটকে থাকা high-risk action নথিভুক্ত করুন।

Outage-এর আগেই data, identity ও approval প্রস্তুত রাখুন

Primary AI service ছাড়া প্রয়োজনীয় উপকরণ পাওয়া না গেলে runbook কাজে আসবে না। Prompt, system instruction, evaluation criteria, connector configuration এবং source manifest version control-এ রাখুন। প্রয়োজনীয় business data নির্ধারিত বিরতিতে export করে encryption ও retention policy বজায় রাখুন; test environment-এ restore করে schema ও access সত্যিই ব্যবহারযোগ্য কি না পরীক্ষা করুন।

বিকল্প identity path-ও drill করুন। Primary provider-এর single sign-on, একই secrets vault কিংবা একই administrator account ব্যর্থ হলে fallback যেন তার সঙ্গে অচল না হয়। Break-glass credential সময়সীমাবদ্ধ ও auditযোগ্য রাখুন, শক্তিশালী অনুমোদন আরোপ করুন এবং export করা data থেকে অপ্রয়োজনীয় field বাদ দিন।

• প্রতি critical workflow-এর owner ও deputy
• Provider status subscription এবং escalation contact
• শেষ সফল data export ও restore test-এর তারিখ
• Approved prompt, source snapshot ও fallback model
• Read-only role এবং পৃথক write approval
• Manual queue-এর location, capacity ও priority rule

Recovery মানে শুধু status সবুজ হওয়া নয়

Provider incident resolved বললেও session, authentication বা remote state পুনরায় যাচাই করতে হতে পারে। ৩ সেপ্টেম্বর ২০২৬-এর OpenAI incident log-এ ChatGPT ও Codex-এর elevated errors resolved করার পর কিছু Codex remote control ব্যবহারকারীকে mobile device আবার pair করতে হতে পারে বলে উল্লেখ করা হয়। এটি recovery-পরবর্তী state check বাদ না দেওয়ার একটি বাস্তব উদাহরণ।

Automation একবারে চালু করবেন না। প্রথমে read-only health check, তারপর একটি low-risk canary request চালিয়ে connector permission ও tool destination যাচাই করুন। Canary সফল হলেও write queue ছাড়ার আগে primary log, fallback log এবং manual approval register মিলিয়ে নিন।

1. প্রতিটি request ID-এর পাশে primary, fallback ও manual ফল বসান।
2. একই email, payment, ticket update বা deployment একাধিকবার হয়েছে কি না দেখুন।
3. অসম্পূর্ণ action retry করার আগে destination system-এর বর্তমান state যাচাই করুন।
4. অনুমোদনহীন output quarantine বা বাতিল করুন।
5. Backlog ছোট batch-এ ছাড়ুন; ফল স্বাভাবিক থাকলে ধাপে ধাপে automation ফেরান।

Incident timeline, নেওয়া সিদ্ধান্ত, বাদ পড়া কাজ এবং reconciliation-এর ফল সংরক্ষণ করুন। পরবর্তী drill-এ primary provider-এর সঙ্গে primary identity এবং একটি গুরুত্বপূর্ণ connector-ও অনুপলব্ধ ধরে একই ৩০ মিনিট, চার ঘণ্টা ও এক দিনের tier পরীক্ষা করুন।