टैक्स अकाउंटिंग फर्म में Claude Code: क्लाइंट डेटा को अनाम और सुरक्षित कैसे रखें

टैक्स अकाउंटिंग फर्म में क्लाइंट की ट्रायल बैलेंस शीट या पेरोल CSV को Claude Code देने से पहले केवल कंपनी का नाम मिटा देना पर्याप्त नहीं है। प्रतिनिधि का नाम, ईमेल पता, बैंक खाता, लेन-देन करने वाली कंपनी का नाम या जापान का My Number किसी दूसरी कॉलम या फ़ाइल के नाम में रह सकता है। इन संकेतों को जोड़कर यह अनुमान लगाया जा सकता है कि डेटा किस क्लाइंट का है। इसलिए सबसे पहले प्रॉम्प्ट नहीं, बल्कि मूल डेटा की फ़ोल्डर और AI की कार्य फ़ोल्डर के बीच की सीमा ठीक करनी चाहिए।

उदाहरण के लिए, मासिक टिप्पणी तैयार करने के लिए मूल CSV खुलवाना जरूरी नहीं है। कंपनी का नाम “क्लाइंट A” करने और सटीक बिक्री को “1 करोड़ से 1.5 करोड़ येन” जैसी सीमा में बदलने के बाद बने कार्य JSON से पुष्टि के प्रश्न तैयार किए जा सकते हैं। टैक्स की राशि, रिटर्न संबंधी निर्णय और संदेश भेजने का अधिकार इंसान के पास ही रहता है।

इस लेख में हम मूल क्लाइंट डेटा को अलग रखकर केवल अनाम की गई कार्य प्रति Claude Code को देने की प्रक्रिया बनाएंगे। सुरक्षा का आधार सिर्फ अनुमति सेटिंग नहीं होगा; इनपुट से पहले मशीन जांच और इंसानी मंजूरी भी जोड़ी जाएगी। मुख्य CTA प्रशिक्षण और परामर्श है, जहां फर्म के अंदर भूमिकाएं और मंजूरी की प्रक्रिया भी तय की जाती है।

इस लेख के मुख्य बिंदु

• मूल फ़ाइलें raw-client-data/ में और AI के लिए प्रतियां ai-work/ में रखें। Claude Code को मूल फ़ाइलें पढ़ने से रोकें।
• अनामीकरण में केवल नाम नहीं, बल्कि संपर्क विवरण, बैंक खाता, पहचान संख्या, कारोबारी पक्ष, जरूरत से अधिक सटीक रकम और स्वतंत्र टिप्पणी भी जांचें।
• Claude Code को अनाम सामग्री का वर्गीकरण, अंतर तालिका, पुष्टि के प्रश्न और टिप्पणी का मसौदा सौंपें। टैक्स निर्णय, भेजना, भंडारण अवधि और अपवाद की मंजूरी इंसान तय करे।
• तीन Use case हैं: मासिक टिप्पणी, अधूरे दस्तावेजों का ईमेल और रिटर्न से पहले की चेकलिस्ट।
• ROI को प्रति केस तैयारी समय, वापस आए मामलों, इनपुट जांच में रोके गए मामलों और मंजूरी में लगे मिनटों से मापें।

कार्यप्रवाह: मूल फ़ाइल खुलने से पहले कार्य प्रति बनाएं

फर्म की कार्य फ़ोल्डर को चार हिस्सों में बांटें: मूल डेटा, रूपांतरण, AI कार्य और स्वीकृत आउटपुट। मूल फ़ोल्डर में अकाउंटिंग CSV, पेरोल लेजर, रिटर्न के दस्तावेज और क्लाइंट ईमेल रखें। AI फ़ोल्डर में केवल उद्देश्य के लिए जरूरी फ़ील्ड वाला JSON, Markdown या CSV रखें। स्वीकृत आउटपुट को जांचने वाले व्यक्ति के नाम और जांच की तारीख के साथ अलग सहेजें।

फ़ोल्डर	इसमें क्या रखें	Claude Code का व्यवहार
raw-client-data/	क्लाइंट से मिली मूल फ़ाइलें	पढ़ना और लिखना दोनों अस्वीकार
transform/	अनामीकरण स्क्रिप्ट और फ़ील्ड तालिका	इंसान सामग्री देखकर चलाए
ai-work/	छद्म नाम और सीमाओं वाली कार्य प्रति	पढ़ना और लिखना स्वीकार
approved-output/	इंसान से स्वीकृत पाठ और चेकलिस्ट	इंसान स्वयं सहेजे और भेजे

पहला काम एक पंक्ति में लिखना है कि AI से क्या चाहिए। “मासिक रिपोर्ट बनाओ” बहुत व्यापक है। इसे सीमित करके लिखें: “बिक्री की सीमा, पिछले महीने से सकल लाभ दर का अंतर और बकाया मामलों की संख्या देखकर निदेशक से पूछने के लिए तीन प्रश्न बनाओ।” उद्देश्य जितना सीमित होगा, उतने ही कम फ़ील्ड देने पड़ेंगे।

इसके बाद फ़ील्ड तालिका बनाएं। कंपनी का नाम, व्यक्ति का नाम, पता, फोन, ईमेल, बैंक खाता और My Number हटाने वाले फ़ील्ड हैं। लेन-देन करने वाली कंपनी का नाम, असामान्य व्यवसाय, सटीक बिक्री और स्वतंत्र टिप्पणी को भी छद्म नाम या सीमा में बदलें। यह भी दर्ज करें कि रूपांतरण किसने, कब और किस नियम से किया।

जापान का Personal Information Protection Commission इस क्लाउड सेवा संबंधी चेतावनी में उन स्थितियों के लिए सावधानियां बताता है जहां क्लाउड सेवा का उपयोग व्यक्तिगत डेटा की प्रोसेसिंग को आउटसोर्स करने के बराबर हो सकता है। फर्म को सेवा के सुरक्षा उपाय, अनुबंध में भूमिकाएं और प्रदाता की निगरानी जांचनी होती है। My Number वाले विशेष व्यक्तिगत डेटा के लिए व्यवसायों की अलग गाइडलाइन भी देखें। इस लेख की सेटिंग कानूनी या अनुबंध संबंधी जांच का विकल्प नहीं है।

Claude Code को क्या सौंपें और इंसान क्या तय करे

Claude Code को केवल अनाम सामग्री क्रम में लगाने, कमी खोजने, पुष्टि के प्रश्न बनाने और मसौदा लिखने तक सीमित रखें। जैसे, “बिक्री की सीमा पिछले महीने से बढ़ी, लेकिन सकल लाभ दर घटी” और “बकाया मामलों में दो की वृद्धि हुई” जैसे तथ्यों से वह क्लाइंट से पूछे जाने वाले प्रश्न सुझा सकता है। इसके लिए असली कंपनी नाम या बैंक का सटीक शेष जरूरी नहीं है।

टैक्स निष्कर्ष, संख्याओं की पुष्टि, क्लाइंट से पूछने की भाषा, प्राप्तकर्ता, भंडारण अवधि, मिटाना और अपवादों का निर्णय इंसान करे। AI का निष्कर्ष सीधे न भेजें। टैक्स अकाउंटेंट आधार दस्तावेज और लागू शर्तें देखकर मंजूरी दे।

अनुमतियों को भी दो परतों में समझें। Claude Code की Read/Edit रोक उसकी अंतर्निहित टूल पर लागू होती है। आधिकारिक अनुमति सेटिंग बताती है कि Bash से शुरू होने वाली child process हमेशा उसी तरह नहीं रुकती; इसलिए ऑपरेटिंग सिस्टम स्तर की रोक वाला sandbox भी लगाना चाहिए। नियम deny, ask, allow के क्रम में जांचे जाते हैं। पहले मूल डेटा को रोकें, फिर केवल कार्य फ़ोल्डर को अनुमति दें।

तीन Use case

Use case 1: मासिक टिप्पणी के लिए पुष्टि के प्रश्न बनाना

• इनपुट: क्लाइंट ID, बिक्री की सीमा, सकल लाभ दर में मासिक अंतर, बकाया मामलों की संख्या और जिम्मेदार व्यक्ति का तथ्यात्मक नोट।
• आउटपुट: क्लाइंट से पूछने के तीन प्रश्न, मासिक टिप्पणी का मसौदा और आधार बने इनपुट फ़ील्ड।
• इंसानी जांच: अकाउंटिंग संख्याएं, टैक्स मूल्यांकन, क्लाइंट की विशेष परिस्थिति, भेजा जाने वाला पाठ और प्राप्तकर्ता मंजूर करना।

सटीक बिक्री या कंपनी नाम के बिना भी टिप्पणी की संरचना बन सकती है। Claude Code को निर्देश दें कि वह बढ़ोतरी या गिरावट का कारण तय न करे, इनपुट में न होने वाला कारण न जोड़े और अनिश्चितता को प्रश्न में बदले। जिम्मेदार व्यक्ति मूल फ़ाइल देखकर प्रश्नों की प्राथमिकता तय करे। पूरी मासिक रिपोर्ट का ढांचा टैक्स अकाउंटिंग फर्म की मासिक रिपोर्ट वाले लेख में दिया गया है।

Use case 2: अधूरे दस्तावेजों के ईमेल का मसौदा बनाना

• इनपुट: क्लाइंट A, संबंधित महीना, न मिले दस्तावेजों के प्रकार, अपेक्षित उत्तर तारीख और भेजने के विकल्प।
• आउटपुट: विषय, ईमेल का मुख्य पाठ, अधूरे दस्तावेजों की सूची और उत्तर देते समय की सावधानी।
• इंसानी जांच: वास्तव में अधूरे दस्तावेज, समय सीमा, प्राप्तकर्ता, अटैचमेंट और किसी दूसरी कंपनी के नाम का न होना।

अधूरे दस्तावेजों के ईमेल में लेखन की गुणवत्ता से अधिक गलत प्राप्तकर्ता या बचे हुए दूसरे क्लाइंट का नाम दुर्घटना पैदा करता है। AI कार्य प्रति में असली नाम न डालें; मंजूरी के बाद ईमेल सिस्टम में नाम जोड़ें। क्लाइंट ईमेल और पुष्टि चेकलिस्ट में दिए लेखन प्रवाह से पहले यह इनपुट सीमा बनाएं।

Use case 3: रिटर्न से पहले की चेकलिस्ट में कमी खोजना

• इनपुट: छद्म नाम वाली कॉर्पोरेट श्रेणी, संबंधित प्रक्रिया, दस्तावेज श्रेणियां, प्राप्ति के फ्लैग और जांचकर्ता की भूमिका।
• आउटपुट: न मिले दस्तावेज, जिम्मेदार व्यक्ति को लौटाए जाने वाले प्रश्न और मंजूरी कॉलम वाली चेकलिस्ट का मसौदा।
• इंसानी जांच: रिटर्न की बाध्यता, समय सीमा, आवश्यक दस्तावेज, लागू शर्तें, ई-फाइलिंग और अंतिम जमा तय करना।

यहां भी Claude Code को रिटर्न की पात्रता तय न करने दें। वह मौजूदा प्रक्रिया से चेकलिस्ट के आइटम मिलाकर संभावित कमी बताए। इंसान मूल डेटा में टैक्स का प्रकार, वित्तीय वर्ष, नोटिफिकेशन की स्थिति और विशेष नियमों की शर्तें देखे। आउटपुट में “जांचकर्ता”, “जांच तारीख” और “आधार दस्तावेज” के कॉलम छोड़ें।

कॉपी करके इस्तेमाल करने वाला प्रॉम्प्ट

यह प्रॉम्प्ट मानता है कि ai-work/ में केवल अनाम सामग्री रखी गई है। प्रॉम्प्ट में असली नाम या सटीक पहचान संख्या न जोड़ें।

आप टैक्स अकाउंटिंग फर्म की मासिक जांच में सहायता करते हैं।
केवल ./ai-work/client-C017.json पढ़ें और इस क्रम में आउटपुट दें।

1. इनपुट में लिखे तथ्य
2. वे बातें जो केवल इनपुट से तय नहीं की जा सकतीं
3. क्लाइंट से पूछने के लिए तीन पुष्टि प्रश्न
4. मासिक टिप्पणी का मसौदा
5. मूल फ़ाइल में इंसान द्वारा जांचे जाने वाले आइटम

पाबंदियां:
- टैक्स संबंधी निष्कर्ष निश्चित रूप से न लिखें
- इनपुट में न मौजूद कंपनी, व्यक्ति, रकम या कारण न जोड़ें
- ईमेल न भेजें, फ़ाइल न मिटाएं और बाहरी संचार न करें
- व्यक्तिगत डेटा जैसा कोई मान मिले तो काम रोकें और केवल फ़ील्ड का नाम बताएं
- आउटपुट के अंत में "टैक्स अकाउंटेंट की जांच से पहले भेजना मना है" लिखें

प्रॉम्प्ट चलाने से पहले मशीन से जांचें कि कार्य प्रति में केवल अपेक्षित फ़ील्ड हैं। इस लेख के साथ रखा scripts/check-tax-accountant-ai-input.mjs JSON, CSV, Markdown और टेक्स्ट स्कैन करता है। नाम या संपर्क से जुड़े फ़ील्ड नाम, ईमेल, फोन, 12 अंकों की पहचान संख्या या पोस्टल कोड मिलने पर यह exit code 1 से रुकता है।

node scripts/check-tax-accountant-ai-input.mjs
node scripts/check-tax-accountant-ai-input.mjs ./ai-work
if ($LASTEXITCODE -ne 0) { throw "AI入力前チェックで停止しました" }

यह जांच डेटा लीक न होने की गारंटी नहीं देती। स्वतंत्र टिप्पणी का अर्थ और कई फ़ील्ड मिलाकर दोबारा पहचान बनाने की संभावना इससे पूरी तरह नहीं पकड़ी जाती। जांच के बाद भी इंसान कार्य प्रति खोलकर देखे।

काम करने वाली अनुमति सेटिंग

प्रोजेक्ट की .claude/settings.json में पहले मूल डेटा को रोकें और केवल AI फ़ोल्डर की अनुमति दें। Claude Code सेटिंग में /raw-client-data/** के शुरू का / प्रोजेक्ट रूट के सापेक्ष पथ बताता है। कंप्यूटर रूट से absolute path // से शुरू होता है; दोनों को न मिलाएं।

{
  "permissions": {
    "deny": [
      "Read(/raw-client-data/**)",
      "Edit(/raw-client-data/**)",
      "Read(/secrets/**)",
      "Edit(/secrets/**)",
      "Bash(git push *)"
    ],
    "allow": [
      "Read(/ai-work/**)",
      "Edit(/ai-work/**)",
      "Bash(node scripts/check-tax-accountant-ai-input.mjs *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./raw-client-data", "./secrets"],
      "denyWrite": ["./raw-client-data", "./secrets"]
    }
  }
}

आधिकारिक sandbox विवरण के अनुसार sandbox शुरू न हो पाने पर डिफ़ॉल्ट व्यवहार चेतावनी देकर बिना sandbox के आगे बढ़ना है। यहां failIfUnavailable: true प्रक्रिया को रोकता है और allowUnsandboxedCommands: false बाहर निकलने का रास्ता बंद करता है। sandbox समर्थन के लिए macOS, Linux या WSL2 माना गया है। Windows वाली फर्म इसे WSL2 के अंदर चलाए और जिस कंप्यूटर पर सेटिंग लागू न हो, वहां क्लाइंट डेटा का उपयोग न करे।

सेटिंग के बाद यह भी जांचें कि अनुरोध सच में अस्वीकार होता है। केवल काल्पनिक डेटा वाली परीक्षण फ़ोल्डर में पुष्टि करें कि raw-client-data/ पढ़ना रोका जाता है और ai-work/ की कार्य प्रति पढ़ी जा सकती है। सिर्फ सेटिंग फ़ाइल का मौजूद होना पास होने का प्रमाण नहीं है। Claude Code अनुमति गाइड deny नियमों की सोच को और स्पष्ट करती है।

Pitfall: अनामीकरण और अनुमति कहां टूटती है

पहली गलती केवल कंपनी का नाम मिटाकर डेटा को अनाम मान लेना है। प्रतिनिधि का नाम, दुर्लभ लेन-देन, सटीक रकम या स्वतंत्र टिप्पणी से स्रोत पहचाना जा सकता है। हर उद्देश्य के लिए अनुमत फ़ील्ड तय करें और केवल रूपांतरण के बाद की फ़ाइल ai-work/ में निकालें।

दूसरी गलती यह मानना है कि Read रोकने से Bash भी रुक जाता है। अंतर्निहित Read/Edit नियम और child process की रोक अलग परतें हैं। sandbox के denyRead और denyWrite साथ लगाएं और sandbox शुरू न हो तो failIfUnavailable से पूरा काम रोकें।

तीसरी गलती शून्य detection को सुरक्षा का प्रमाण मानना है। regular expression चित्र, PDF के अंदर के अक्षर, अलग वर्तनी और अर्थ से पहचाने जाने वाले व्यक्तिगत डेटा को छोड़ सकती है। अनुमत फ़ील्ड की सूची, इनपुट जांच, इंसानी दृश्य जांच, प्रोसेसिंग लॉग और मिटाने की समय सीमा को एक साथ लागू करें।

चौथी गलती वास्तविक डेटा से परीक्षण करना है। परीक्षण के लॉग और स्क्रीनशॉट में मान रह सकते हैं। काल्पनिक डेटा से अनुमति और रोक दोनों जांचें तथा दुर्घटना होने पर काम रोकने की प्रक्रिया एक पन्ने पर लिखें।

छोटा ROI कैसे मापें

पहले दो सप्ताह परीक्षण को एक क्लाइंट और एक प्रकार की मासिक टिप्पणी तक सीमित रखें। लागू करने से पहले पांच बार “मूल डेटा देखने से मसौदा पूरा होने तक के मिनट”, “जिम्मेदार व्यक्ति के सुधारों की संख्या” और “फर्म प्रमुख से वापस आए मामलों की संख्या” दर्ज करें। लागू करने के बाद वही आंकड़े लें और इनपुट जांच में रुके मामलों की संख्या भी जोड़ें।

उदाहरण के लिए, महीने के 20 मामलों में प्रति केस तैयारी 18 मिनट से घटकर 11 मिनट हो तो महीने में 140 मिनट बचते हैं। मंजूरी का समय बढ़ा हो तो उसे घटाएं। केवल बिक्री मूल्य नहीं, बल्कि गलत प्राप्तकर्ता, दूसरी कंपनी का नाम और मूल डेटा तक पहुंच पहले ही रुकने के मामलों को भी दर्ज करें। सिर्फ गति मापने से अनामीकरण छोड़ने का दबाव बनता है।

लागू करने से पहले और बाद में मामलों की संख्या × (तैयारी मिनट + मंजूरी मिनट + दोबारा काम के मिनट) और रोके गए मामलों को साथ रखें। इससे गति और सुरक्षा दोनों एक ही जगह दिखेंगे।

अक्सर पूछे जाने वाले प्रश्न

प्र. क्लाइंट का नाम छद्म नाम करने के बाद फ़ाइल सीधे इस्तेमाल कर सकते हैं?

नहीं। प्रतिनिधि का नाम, पता, ईमेल, बैंक खाता, My Number, कारोबारी पक्ष, सटीक रकम और स्वतंत्र टिप्पणी भी देखें। अंत में इंसान जांचे कि कई मानों को जोड़कर क्लाइंट पहचाना तो नहीं जा सकता।

प्र. स्थानीय कंप्यूटर पर चलाने से यह सुरक्षित हो जाता है?

केवल चलाने की जगह से सुरक्षा तय नहीं होती। सेवा की डेटा नीति, authentication, डिवाइस, लॉग, बाहरी संचार, अनुमति और अनुबंध जांचें। पहले ऐसी सीमा बनाएं जिससे मूल डेटा तक पहुंच न हो।

प्र. क्या जांच स्क्रिप्ट PDF और चित्र भी देखती है?

इस लेख की स्क्रिप्ट केवल JSON, CSV, Markdown और टेक्स्ट के लिए है। PDF और चित्रों को रोककर अलग स्वीकृत रूपांतरण प्रक्रिया से गुजारें। दायरे से बाहर के फ़ॉर्मेट को चुपचाप आगे न जाने दें।

प्र. क्या My Number को अनाम बनाकर AI को दे सकते हैं?

यह लेख किसी खास मामले का फैसला नहीं करता। सामान्य नियम के रूप में उसे कार्य प्रति में न रखें। फर्म का जिम्मेदार व्यक्ति जापान के Personal Information Protection Commission की गाइडलाइन, अनुबंध, उपयोग का उद्देश्य और आंतरिक नियम जांचे।

प्रशिक्षण या परामर्श में सीमा तय करें

टैक्स अकाउंटिंग फर्म में Claude Code चलाते समय केवल सेटिंग फ़ाइल बनाना पर्याप्त नहीं है। यदि यह साफ नहीं है कि अनामीकरण कौन करेगा, अपवाद कौन मंजूर करेगा और आउटपुट कहां सहेजा जाएगा, तो व्यवहार में नियम टूटेगा। मूल डेटा, कार्य प्रति, AI आउटपुट और स्वीकृत पाठ के जिम्मेदार लोगों को अलग करना जरूरी है।

प्रशिक्षण और परामर्श में क्लाइंट डेटा की फ़ील्ड तालिका, फ़ोल्डर सीमाएं, अनुमति सेटिंग, इनपुट जांच और मंजूरी तालिका को वास्तविक डेटा लाए बिना डिजाइन किया जाता है। पहली बैठक में केवल मौजूदा फ़ोल्डर नाम और वांछित परिणाम देखे जाते हैं; मूल फ़ाइल साझा नहीं की जाती।

वास्तव में किए गए परीक्षण का परिणाम

इस लेख के लिए केवल काल्पनिक क्लाइंट JSON का उपयोग करके scripts/check-tax-accountant-ai-input.mjs का self-test चलाया गया। सुरक्षित नमूने में शून्य detection मिली; प्रतिनिधि का नाम, ईमेल और 12 अंकों की पहचान संख्या वाले जोखिम नमूने को प्रक्रिया रोकने के लिए बनाया गया है। प्रकाशन से पहले कोड, कमांड, आंतरिक लिंक, आधिकारिक URL, CTA, frontmatter और मुख्य चित्र भी जांच सूची में शामिल किए गए।

आज का पहला काम खाली raw-client-data/ और ai-work/ फ़ोल्डर बनाना और काल्पनिक फ़ाइलों से यह जांचना है कि मूल फ़ोल्डर अस्वीकार होता है और केवल कार्य प्रति पढ़ी जाती है। जांच पास होने के बाद भी शुरुआत हमेशा अनाम कार्य प्रति से करें।