आपके stack में कहीं न कहीं, किसी agent ने वह संख्या पहले ही तैयार कर दी है जो एक दिन किसी auditor के सामने रखी जाएगी। उसने वह figure compute किया — या generate किया; शायद आप नहीं जानते कौन-सा — किसी ने उसे एक deck में paste किया, और deck भेज दी गई। महीनों बाद वह सवाल आता है जो हर production AI system को अंततः मिलता है: यह संख्या कहाँ से आई, और क्या हम इसे आज फिर से पाएँगे?
अधिकांश teams एक transcript से जवाब देती हैं। Q1 2026 के एक सर्वेक्षण में, जिसमें production में AI agents चला रहे 420 organizations शामिल थे, केवल 17% ही किसी विशिष्ट agent task के पीछे tool calls, inputs, और outputs का पूरा क्रम बाद में पुनर्निर्मित कर सके (AgentNode, 2026)। बाकी 83% के पास आंशिक logs थे, कोई logs नहीं थे, या ऐसे logs थे जिन्होंने model की reasoning तो capture की लेकिन उसने वास्तव में क्या invoke किया वह नहीं। एक transcript और एक अनुमान।
Record अब कानून बन रहा है
कुछ समय तक यह एक engineering की शर्मिंदगी थी। अब यह एक कानूनी शर्मिंदगी बनने वाली है।
EU AI Act के अनुसार high-risk AI systems को तकनीकी रूप से — बाद में जोड़ा नहीं, बल्कि शुरू से ही डिज़ाइन किया हुआ — "system के जीवनकाल में events की automatic recording (logs)" की अनुमति देनी होगी (European Commission, 2024)। Manual record-keeping Article 12 को संतुष्ट नहीं करती। Logs इतने सक्षम होने चाहिए कि वे जोखिम या महत्वपूर्ण बदलाव की स्थितियों की पहचान कर सकें, post-market monitoring को सहयोग दे सकें, और यह दर्शा सकें कि system वास्तव में कैसे काम करता है। Remote biometric identification के लिए, article न्यूनतम आवश्यकताएँ सीधे बताता है: उपयोग की प्रत्येक अवधि, जाँची गई reference database, वह input data जिसने match दिया, और उन natural persons की पहचान जिन्होंने परिणाम सत्यापित किया। यह "कुछ logs रखो" नहीं है। यह है निर्णय को पुनर्निर्मित करो।
तारीखें नज़दीक हैं। Act 1 अगस्त 2024 को लागू हुआ; prohibitions फरवरी 2025 से, general-purpose model obligations अगस्त 2025 से — और high-risk obligations, जिनमें Article 12 शामिल है, 2 अगस्त 2026 से लागू होती हैं (Future of Life Institute, 2026)। इस post की तारीख से आठ दिन बाद। Regulated products (Annex I) में embedded high-risk systems अगस्त 2027 में आते हैं।
Retention की भी एक न्यूनतम सीमा है। Providers को automatically generated logs कम से कम छह महीने तक रखने होंगे, और Article 26(6) deployers पर भी यही दायित्व डालता है — जहाँ GDPR जैसे अन्य कानून अधिक समय की माँग करें वहाँ उससे भी अधिक, और हर स्थिति में system के intended purpose के अनुरूप, न कि केवल न्यूनतम (artificialintelligenceact.eu, 2024)।
यह सब शून्य में नहीं आया है। GDPR Article 30 ने 2018 से ही processing के written records — उद्देश्य, data की श्रेणियाँ, प्राप्तकर्ता, erasure की समय-सीमाएँ, सुरक्षा उपाय — की अपेक्षा की है, जो supervisory authority के अनुरोध पर प्रस्तुत किए जा सकें (gdpr-info.eu, 2016)। SOC 2 का CC7.2 यह अपेक्षा करता है कि आप system components में anomalies की निगरानी करें और जो पाएँ उसका विश्लेषण करें; CC7.3 यह अपेक्षा करता है कि आप यह मूल्यांकन करें कि किसी event ने आपके objectives को प्रभावित किया या नहीं (AICPA, 2022)। Type II audit में वे criteria पूरी review period — आमतौर पर बारह महीने — के log evidence के विरुद्ध परखे जाते हैं (AgentNode, 2026) — न कि उस दिन के screenshot से जब auditor आया था।
"अधिक log करो" क्यों काम नहीं करता
स्वाभाविक प्रतिक्रिया है verbosity: tracing चालू करो, सब कुछ store करो, एक dashboard खरीदो। तीन समस्याएँ फिर भी बनी रहती हैं।
Transcripts यह record करते हैं कि क्या कहा गया, न कि क्या चला। एक chat log model का अपने व्यवहार का वर्णन है। ऊपर के 83% में से एक हिस्सा ठीक यही है: reasoning capture हुई, tool invocations नहीं। जब narration और execution में अंतर हो, तो transcript बेदाग बना रहता है — computed और generated पृष्ठ पर एक जैसे दिखते हैं। वे एक जैसे नहीं हैं।
एक log जिसे आप re-execute नहीं कर सकते, वह testimony है, evidence नहीं। यहाँ तक कि जो teams हर tool call capture करती हैं, वे भी आमतौर पर उसे दोबारा नहीं चला सकतीं और तुलना नहीं कर सकतीं, क्योंकि किसी ने उस दुनिया को pin नहीं किया जिसमें वह चला था। SQL उस दिन fresh generate हुआ था, एक ऐसे database के विरुद्ध जो तब से बदल चुका है; arithmetic एक ऐसे model से sample हुआ था जो कभी stable था ही नहीं। उसे छह महीने — या बारह — तक retain करने का मतलब है दावों को अधिक समय तक store करना, न कि उन्हें जाँचने योग्य बनाना। Article 12 की भाषा सटीक है: system को recording की तकनीकी अनुमति देनी होगी। जो reproducibility शुरू से design नहीं की गई, उसे बाद में logging library से नहीं जोड़ा जा सकता।
Metadata correctness नहीं है। न्यूनतम viable audit record — छह core fields, जिनमें trace ID, timestamp, और agent identity शामिल हैं (AgentNode, 2026) — यह स्थापित करता है कि कौन और कब। यह यह नहीं बताता कि संख्या सही थी या नहीं, या आज भी वही आएगी या नहीं। LLM-agent observability पर शोध भी यही निष्कर्ष देता है: traceability को पूरे agent lifecycle के artifacts को cover करना होगा, केवल messages को नहीं (CSIRO Data61, 2024)।
विफलता structural है। Free-form execution — एक model जो strings emit करता है जिन्हें कोई और चलाता है — कुछ भी इतना stable नहीं उत्पन्न करता जिसे record किया जा सके, चाहे आप कितना भी लिख लें।
Provenance को result का हिस्सा बनाना
SQAI का उत्तर है record को logging की विशेषता के बजाय execution की property बनाना। हर executed result चार hashes वहन करता है, जिनमें से प्रत्येक एक अलग audit प्रश्न का उत्तर देता है:
contract_hash— क्या चल सकता था: वह exact capability contract जो लागू था (sha256:79f1c5a6c716…)।plan_hash— request किस पर resolve हुई: validated plan, उसके resolution के साथ (decision_path: "exact_spec")।invocation_hash— क्या चला, किस पर: capability और canonicalized inputs, जिसमें data काinput_hashभी शामिल है जैसा वह उस समय था।computation_hash— क्या निकला: invocation और value दोनों से बँधा हुआ।
Constructions domain-separated हैं, इसलिए कोई artifact दूसरे का रूप नहीं ले सकता:
invocation_hash = sha256("sqai:invocation:v1\0" + canonicalJson(identity))
computation_hash = sha256("sqai:computation:v1\0" + invocation_hash + canonicalJson(value))
Hashes के साथ determinism envelope भी होता है — recorded execution environment: runtime_bundle_version 0.1.0 और उसका sha256, platform और architecture, precision_mode: float64, thread_count: 1, और जहाँ आवश्यक हो वहाँ seed। दस simulation capabilities जिन्हें seed चाहिए, वे उसके बिना चलने से मना कर देती हैं — seed_required, चुपचाप अलग जवाब नहीं। जो कुछ भी संख्या बदल सकता है वह या तो pin है या लिखा हुआ है।
यह व्यावहारिक रूप से क्या देता है। मार्च में, एक agent net present value compute करता है:
finance.npv(0.1, [-1000, 300, 420, 560, 680])
→ 505.020148896933
computation_hash b74f67d0d7a594aa…
जुलाई में, auditor पूछता है। आप invocation replay करते हैं — वही typed spec, वही pinned runtime — और hashes की तुलना करते हैं: b74f67d0d7a594aa… फिर से, byte-identical। इससे कोई फर्क नहीं पड़ता कि replay TypeScript में चले या Python में। canonicalJson और canonical_json एक cross-language serialization contract हैं — keys sorted, -0 को 0 में normalize किया, fixed unicode escaping — इसलिए एक ही value दोनों में एक ही bytes देती है, एक ही hash देती है। Determinism page इन दो envelopes को, महीनों के अंतर से, साथ-साथ दिखाता है।
और जब replay मेल नहीं खाता, तो वह एक संकेत है। एक बदला हुआ source schema_revision_mismatch के साथ स्पष्ट रूप से विफल होता है — engine चुपचाप अलग data के विरुद्ध अलग संख्या compute करके उसे अतीत से जोड़ने से मना कर देता है। Mismatch बताता है कि क्या बदला।
इसे obligations से जोड़ें। System के जीवनकाल में automatic recording: हर executed result construction से खुद को record करता है — कोई unrecorded path नहीं है, क्योंकि execution surface typed inputs वाली 4,574 read-only capabilities है, free-form strings नहीं। छह या बारह महीने का retention: result envelopes store करें; retention एक storage निर्णय बन जाता है, archaeology नहीं। SOC 2 review period को cover करने वाले evidence: artifacts ही evidence हैं — auditor का जवाब एक replay है, जाँच नहीं। वही pipeline हर capability के लिए record produce करता है, और persistent audit trail SQAI के Pro tier के साथ आता है।
आठ दिन, फिर उसके बाद हर audit
अगस्त की तारीख EU में high-risk systems को औपचारिक रूप से बाध्य करती है। लेकिन इस तरह की deadlines हर उस review का template तय करती हैं जो बाद में आती है — SOC 2 auditor, procurement questionnaire, आपका अपना CFO जो मार्च में जनवरी की किसी संख्या के बारे में पूछता है। Agents से उनके जवाबों का औचित्य उसी तरह माँगा जाएगा जैसे employees से माँगा जाता है: records के साथ। अधिकांश stacks यह नहीं दे सकते, क्योंकि generated SQL और sampled arithmetic कुछ भी इतना stable नहीं छोड़ते जिसे record किया जा सके — एक समस्या जो audit से बहुत पहले शुरू होती है।
जिस जवाब को आप replay कर सकते हैं, वही जवाब आप defend कर सकते हैं। बाकी सब एक screenshot है।