शुरू से अंत तक की मार्गदर्शिका
नियमों के अधीन enterprise में software कैसे बनाएँ
लोगों को AI से prototype बनाने में मदद करें। वास्तविक डेटा या API access देने से पहले security जाँचें, फिर enterprise requirements के अनुसार software deliver और operate करें।
प्रकाशक Taigaहम कैसे लिखते हैं
संक्षिप्त उत्तर
लोगों को समय, tool चुनने की स्वतंत्रता, synthetic data और उपयोगी prototypes से maintained services तक पहुँचने का रास्ता दें। वास्तविक API access या गोपनीय जानकारी देने से पहले application, platform और data flows जाँचें। सुरक्षित delivery, compliance प्रमाण और संचालन जोड़ने के लिए internal platform या software factory इस्तेमाल करें। पूरे lifecycle में जिम्मेदार लोगों की जवाबदेही बनाए रखें।
अधिक लोगों को विचारों से software बनाने में मदद करें
CTO पूरे संगठन के लोगों को AI से prototypes बनाने के लिए आमंत्रित कर सकता है। Finance teams अपनी approval समस्याएँ जानती हैं। Operations teams अपना दोहराया manual काम जानती हैं। बेहतर workflow दिखाने के लिए उन्हें समय और tools दें।
Installation, accounts और स्वीकार्य inputs के स्पष्ट नियमों के भीतर अलग tools से विचार परखने दें। Synthetic datasets, sandbox APIs और व्यावहारिक सहायता दें। Production systems जोड़े बिना मूल्य दिखाने का रास्ता लोगों को स्पष्ट होना चाहिए।
फिर अगला निर्णय तय करें: app को गोपनीय जानकारी, वास्तविक API permissions या production traffic मिलने से पहले क्या जाँचना है? यह रास्ता prototype बनाने वाले को समझ आए।
Prototype को वास्तविक access चाहिए तो क्या बदलता है?
काम करता feature service का एक हिस्सा है। संगठन को यह भी बताना है कि उसे कौन इस्तेमाल कर सकता है, वह डेटा कैसे सँभालता है और कैसे recover होता है। ये जिम्मेदारियाँ release के बाद भी जारी रहती हैं।
लागू requirements service, sector, jurisdiction, contracts और डेटा पर निर्भर हैं। जिम्मेदार legal, privacy और security specialists से उन्हें पहचानने को कहें। Development framework या vendor certificate आपकी खास service की compliance सिद्ध नहीं करता।
नीचे के चरण engineering workflow देते हैं। Requirements को decisions और प्रमाण से जोड़ने के लिए उनका उपयोग करें। NIST SSDF सुरक्षित development practices देता है जो मौजूदा SDLC में मदद कर सकती हैं। यह लागू दायित्व पहचानने की जगह नहीं लेता।
1. उपयोगी prototype को service brief में बदलें
उसे बनाने वाले से समस्या बताने, workflow दिखाने और users ने क्या सीखा यह दर्ज करने को कहें। उसे विषय के विशेषज्ञ के रूप में शामिल रखें। Technical assessment और लगातार संचालन उन teams को दें जिनकी ये जिम्मेदारियाँ हैं।
User task, इच्छित परिणाम और failure का असर लिखें। Product owner, service owner, security contact और बचा जोखिम स्वीकार कर सकने वाला व्यक्ति तय करें। सहमति लें कि release कौन रोक सकता है।
उदाहरण के लिए, customer-data export को download button से अधिक चाहिए। तय करें कि कौन, कौन-से records, किस उद्देश्य से और कितनी retention अवधि के लिए export कर सकता है। पहचानें कि unauthorized export की जाँच कौन करता है। यह काल्पनिक उदाहरण है।
सुरक्षित रखने वाला प्रमाण: service brief, responsibility map और approved acceptance criteria।
आगे requirements और traceability तथा service की जिम्मेदारी पढ़ें।
2. डेटा या API access देने से पहले सीमा जाँचें
गोपनीय जानकारी, personal data, credentials और दूसरी restricted सामग्री पहचानें। Prompts, retrieved context, logs और generated outputs कहाँ जाते हैं, यह map करें। चुनी service की retention, training, access और regional processing terms जाँचें।
विचार परखते समय synthetic या approved test data इस्तेमाल करें। सफल prototype यह सिद्ध नहीं करता कि provider production data process कर सकता है। हर provider और deployment configuration जाँचें।
मंगलवार को बना काल्पनिक bank dashboard मनगढ़ंत transactions से अच्छा काम कर सकता है। Read-only account access भी गोपनीय records उजागर कर सकता है। Payment permissions से वित्तीय परिणाम जुड़ सकते हैं। Connection enable करने से पहले वास्तविक दायरा, credential handling, authorization और failure behavior जाँचें। बैंकिंग prototype के उदाहरण पर काम करें।
यह review पहले संवेदनशील input या वास्तविक connection से पहले होना चाहिए। App को prototype कहने से उसके मौजूदा अधिकार कम नहीं होते।
Agents को केवल काम के लिए जरूरी tools और permissions दें। Repository files और retrieved documents को untrusted input मानें। Secrets prompts से बाहर रखें।
सुरक्षित रखने वाला प्रमाण: data-flow diagram, provider assessment और permission policy।
डेटा की सीमाएँ और agent permissions पढ़ें।
3. Production तक समर्थित रास्ता दें
Service को संगठन के identity, network, logging और deployment controls के भीतर रखें। Supported environments और infrastructure as code तय करें। Container और database पूरे operating environment का प्रमाण नहीं हैं।
Policy अपने infrastructure की माँग करे तो आपके cloud accounts या networks में deployment जाँचें। Runtime controls को development और model data flows से अलग जाँचें। आपके account में hosting compliance सिद्ध नहीं करती या हर AI request उसी account के भीतर नहीं रखती।
समर्थित रास्ता internal platform, software factory या दोनों इस्तेमाल कर सकता है। तय करें कि verification, deployment, vulnerability fixes और संचालन के लिए हर एक क्या देता है। इस रास्ते पर आने से पहले prototype में बदलाव या replacement code चाहिए हो सकता है।
स्वीकार्य outage duration और data loss पर सहमति लें: RTO और RPO। इन objectives के अनुसार availability और recovery mechanisms चुनें। Multi-AZ, multi-region और backups अलग failure scenarios हल करते हैं। Dependencies और restored data समेत पूरी recovery प्रक्रिया जाँचें।
सुरक्षित रखने वाला प्रमाण: architecture decision record, environment definitions और मापे recovery results।
Enterprise infrastructure और RTO व RPO पढ़ें। फिर recovery अभ्यास करें।
4. जाँची जा सकने वाली requirements से छोटे बदलाव बनाएँ
Developer या agent को स्पष्ट काम और acceptance criteria दें। Requirement को implementation, tests और review से जोड़ें। बदलाव निरीक्षण किए जा सकने जितने छोटे रखें।
Testing से पहले security requirements तय करें। OWASP ASVS application security verification की requirements देता है। संबंधित requirements चुनें और दायरा दर्ज करें। अकेला scanner result application का व्यवहार verify नहीं करता।
सफल कार्रवाइयों के साथ अस्वीकार की जाने वाली कार्रवाइयाँ भी जाँचें। Export के उदाहरण में जाँचें कि unauthorized user दूसरे customer के records नहीं माँग सकता।
सुरक्षित रखने वाला प्रमाण: requirement, change diff, test results और review decision।
आगे tests को प्रमाण की तरह इस्तेमाल करना और AI-generated code का review पढ़ें।
5. Release decision को दोहराने योग्य बनाएँ
Reviewed revision से पहचान योग्य artifact build करें। Target environment, configuration, required checks, बचे risks और release decision दर्ज करें। जरूरत पड़ने से पहले rollback या recovery तरीका जाँचें।
तय करें कि human authorization कब जरूरी है। Exception का owner, कारण, दायरा और expiry date रखें। Approved exception को policy में स्थायी बदलाव न मानें।
सुरक्षित रखने वाला प्रमाण: artifact identity, release record, approval या policy decision और rollback instructions।
Release decisions और compliance प्रमाण पढ़ें।
6. Deployment के बाद software का रखरखाव करें
Dependencies और deployed components में नई बताई गई vulnerabilities scan करें। नया code commit हुए बिना service vulnerable हो सकती है। हर finding का owner और remediation decision तय करें।
Fix जाँचें, deploy करें और running version की पुष्टि करें। स्वीकार किए risks दर्ज करें और परिस्थितियाँ बदलने पर फिर review करें। Prototype को finished product मानने पर यह लगातार काम अक्सर छूट जाता है।
सुरक्षित रखने वाला प्रमाण: component inventory, scan date, triage decision, remediation change और deployment verification।
लगातार vulnerability management workflow अपनाएँ।
7. चलाएँ, प्रतिक्रिया दें और सुधारें
उपयोगी service outcomes, failures और security signals monitor करें। Incident roles, escalation प्रक्रियाओं और SOC व SIRT की जिम्मेदारियों पर सहमति लें। उन व्यवस्थाओं का अभ्यास करें।
NIST Cybersecurity Framework risk management को governance, protection, detection, response और recovery से जोड़ता है। Operating model तय करते समय lifecycle की यह दृष्टि अपनाएँ।
Incidents और बार-बार की समस्याओं को reviewed changes में बदलें। Self-healing को verification और stop conditions वाली अधिकृत कार्रवाइयों तक सीमित करें। Automatic restart मूल दोष ठीक होने का प्रमाण नहीं है।
सुरक्षित रखने वाला प्रमाण: service measures, incident records, recovery results और सत्यापित सुधार के changes।
Incident management और सीमित self-healing देखें।
8. तय करें कि कौन-सी जिम्मेदारियाँ खुद बनाएँ या खरीदें
Internal platform, coding assistants और AI software factory की समान requirements के आधार पर तुलना करें। पूछें कि हर काम कौन करता है, कौन-सा प्रमाण उपलब्ध है और आपकी जिम्मेदारी क्या बचती है। Maintenance, recovery, integration और exit की लागतें शामिल करें।
लोग अपने पसंदीदा exploration tools रख सकते हैं, जबकि संगठन production का साझा रास्ता बनाए रखता है। जाँचें कि कौन-सा code, specifications और tests tools के बीच ले जा सकते हैं। जरूरी infrastructure में deployment और पूरी maintenance प्रक्रिया का demo माँगें।
Taiga governance जानकारी और shared responsibility विवरण प्रकाशित करता है। इन्हें एक supplier की सामग्री मानकर अपनी requirements के अनुसार जाँचें। यह learning site Taiga प्रकाशित करता है; ये links स्वतंत्र समर्थन नहीं हैं।
जिम्मेदारियों की तुलना से शुरू करें। फिर Taiga learning path दिखाता है कि ये प्रश्न खास product workflows से कैसे जुड़ते हैं।
सामान्य प्रश्न
क्या नियमों के अधीन enterprise में vibe coding इस्तेमाल कर सकते हैं?
हाँ। संगठन की स्पष्ट सीमाओं में लोगों को synthetic data, sandbox APIs और tool choice दें। उन्हें विचार परखने दें और उपयोगी prototypes को समर्थित delivery रास्ते तक लाने दें। गोपनीय डेटा या वास्तविक permissions देने से पहले controls जाँचें, औपचारिक production से पहले भी। Vibe coding: उपयोग और सीमाएँ देखें।
क्या AI-generated code को अलग acceptance criteria चाहिए?
जरूरी व्यवहार और risk controls फिर भी लागू हैं। AI से context, डेटा के उपयोग, permissions और output की reliability पर अतिरिक्त प्रश्न जुड़ते हैं। बदलाव किसने या किस चीज ने बनाया, इससे अलग वास्तविक change और उसका प्रमाण review करें।
हमें पहले क्या तैयार करना चाहिए?
Synthetic data वाला exploration environment और अगले चरण के लिए तय contact तैयार करें। उपयोगी prototype का उद्देश्य, इच्छित डेटा, owners, requirements और recovery objectives दर्ज करें। Access बढ़ाने से पहले missing decisions पहचानने के लिए software lifecycle अभ्यास इस्तेमाल करें।