આ અંગ્રેજી મૂળ લેખનો અનુવાદ છે. સંદર્ભ માટે અંગ્રેજી આવૃત્તિ માન્ય છે. અંગ્રેજીમાં વાંચો
સાર (Abstract)
જે વેપારો AI એજન્ટને પોતાના રેકૉર્ડ પર કામ કરવા દે છે, તેમણે દરેક કામકાજી દિવસે નક્કી કરવું પડે છે કે એજન્ટ કયાં પગલાં એકલો લઈ શકે, કયાં માટે વ્યક્તિની મંજૂરી જોઈએ, અને એજન્ટ પોતાને સાબિત કરે તેમ આ રેખા કેવી રીતે ખસવી જોઈએ. મુખ્ય ગવર્નન્સ ફ્રેમવર્ક જોખમના પ્રમાણમાં દેખરેખ (oversight) માગે છે અને ચલાવવાના નિયમો દરેક સંસ્થા પર છોડે છે. આ પેપર મંજૂરીની સીડી (approval ladder) સૂચવે છે. તે એજન્ટના દરેક પગલાને બે ધરી પર ગ્રેડ આપે છે, પગલું ક્યાં સુધી પહોંચે છે અને તેને પાછું વાળી શકાય કે નહીં, દરેક ગ્રેડને મંજૂરીનું સ્તર સોંપે છે, અને ઘણા રેકૉર્ડને અસર કરતાં કે વેપાર બહારની સામગ્રીથી પ્રેરાયેલાં પગલાં માટે એક સુધારક (modifier) ઉમેરે છે. છૂટ ફક્ત પાછાં વાળી શકાય તેવાં આંતરિક પગલાં માટે વધે છે, અને તે પણ ફક્ત એજન્ટના પોતાના મંજૂર થયેલા કામમાંથી મળેલા પુરાવા પર, એ પુરાવાની આંકડાકીય તાકાત જણાવીને. પેપર સીડીને 2026માં સુધારાયેલા EU Artificial Intelligence Act, NIST AI Risk Management Framework, ISO/IEC 42001, સિંગાપોરના એજન્ટિક AI ગવર્નન્સ ફ્રેમવર્ક, વધુ પડતી સત્તા (excessive agency) અંગે OWASPના માર્ગદર્શન, ભારતની AI Governance Guidelines અને Digital Personal Data Protection Act, 2023, તથા 1978થી ઑટોમેશનનાં સ્તર અને ઑટોમેશન બાયસ પરના સંશોધનની સામે મૂકે છે. પછી તે એક વાસ્તવિક પ્રોડક્ટ, MatruOS,નાં પગલાંને સીડી સામે ગ્રેડ આપે છે અને પ્રોડક્ટ ક્યાં ઊણી ઊતરે છે તે જણાવે છે.
Section 1પ્રશ્ન
AI એજન્ટ અગાઉના બિઝનેસ સૉફ્ટવેરથી એક બાબતમાં જુદો છે, જે અહીં મહત્ત્વની છે: હવે શું કરવું તે તે જાતે પસંદ કરે છે. નિયમ આધારિત વર્કફ્લો શરત પૂરી થાય ત્યારે દર વખતે એક જ કામ કરે છે. એજન્ટ પરિસ્થિતિ વાંચે છે, પગલાંમાંથી પસંદગી કરે છે અને એક પગલું લે છે. આ પસંદગી તેને એવા કેસ સંભાળવા દે છે જેના માટે કોઈએ નિયમ લખ્યો નથી, અને એવી રીતે ખોટી પસંદગી કરવા પણ દે છે જેની કોઈએ કલ્પના કરી નથી.
બિઝનેસ સિસ્ટમમાં પગલાં નક્કર હોય છે: ઇન્વૉઇસનો ડ્રાફ્ટ બનાવવો, ખરીદ બિલ પોસ્ટ કરવું, પેમેન્ટ નોંધવું, ભાવ બદલવો, સ્ટૉક ફરી મંગાવવો, ગ્રાહકને જવાબ આપવો, પેમેન્ટ રિમાઇન્ડર મોકલવું, કર્મચારીનો રેકૉર્ડ અપડેટ કરવો, ડુપ્લિકેટ કાઢી નાખવું. ખોટું હોય તો દરેકનું પરિણામ જુદું આવે છે. વ્યક્તિ જે ખોટો ડ્રાફ્ટ તપાસે તેમાં એક મિનિટ જાય છે. ચૂકવી ચૂકેલા ગ્રાહકને ગયેલું રિમાઇન્ડર સંબંધ બગાડે છે. ખોટી રીતે નોંધાયેલું પેમેન્ટ કોઈના ધ્યાનમાં ન આવે ત્યાં સુધી ચોપડા બગાડે છે. ખોટા ખાતામાં ગયેલું પેમેન્ટ કદાચ ક્યારેય પાછું ન આવે.
આખા એજન્ટ માટે એક જ ચાલુ-બંધ સ્વિચ બહુ સ્થૂળ છે. જો દરેક ફેરફાર માટે મંજૂરી જોઈએ, તો મંજૂરી આપનાર વ્યક્તિ અડચણ બને છે, અને વિભાગ 4.7 તેની કિંમતનો અંદાજ આપે છે. જો કશા માટે મંજૂરી ન જોઈએ, તો વેપાર પોતાના પૈસા અને પ્રતિષ્ઠા એવી સિસ્ટમને સોંપે છે જે અમુક દરે ભૂલો કરશે. મંજૂરીની સીડી આ પ્રશ્નનો જવાબ પગલે પગલે, એકસરખી રીતે, અને પુરાવા ભેગા થાય તેમ બદલાઈ શકે તે રીતે આપે છે.
Section 2ફ્રેમવર્ક શું માગે છે, અને શું ખુલ્લું છોડે છે
2.1 EU Artificial Intelligence Act
Regulation (EU) 2024/1689, એટલે EU Artificial Intelligence Act (યુરોપિયન યુનિયનનો AI કાયદો), તેના Article 14માં માગે છે કે હાઈ-રિસ્ક AI સિસ્ટમ એવી રીતે ડિઝાઇન થાય કે વપરાશ દરમિયાન માણસો તેની અસરકારક દેખરેખ રાખી શકે. Article 14(4) પ્રોવાઇડરો પાસે માગે છે કે દેખરેખ માટે સોંપાયેલા લોકો, યોગ્ય અને પ્રમાણસર રીતે: (a) સિસ્ટમની ક્ષમતાઓ અને મર્યાદાઓ સમજી શકે અને તેના કામ પર નજર રાખી શકે; (b) તેના આઉટપુટ પર વધુ પડતો આધાર રાખવાના વલણથી સાવધ રહે, જેને કાયદો ઑટોમેશન બાયસ કહે છે; (c) આઉટપુટનું સાચું અર્થઘટન કરી શકે; (d) આઉટપુટ ન વાપરવાનો, અથવા તેની અવગણના કરવાનો, તેને ઓવરરાઇડ કરવાનો કે પાછું વાળવાનો નિર્ણય લઈ શકે; અને (e) સ્ટૉપ પ્રક્રિયા દ્વારા સિસ્ટમમાં દખલ કરી શકે કે તેને અટકાવી શકે. Article 26(2) ડિપ્લૉયરો પાસે માગે છે કે દેખરેખ જરૂરી ક્ષમતા, તાલીમ, સત્તા અને સહાય ધરાવતા લોકોને સોંપાય.
ઇન્વૉઇસનો ડ્રાફ્ટ બનાવતા કે પેમેન્ટ રિમાઇન્ડર મોકલતા મોટા ભાગના એજન્ટ આ કાયદા હેઠળ હાઈ-રિસ્ક સિસ્ટમ નથી. Annex III એવા કેટલાક ઉપયોગ ગણાવે છે જેમાં બિઝનેસ એજન્ટ સરકી શકે: મુદ્દા 4 હેઠળ, ભરતી માટે, બઢતી કે નોકરીમાંથી છૂટા કરવાના નિર્ણયો માટે, અને વ્યક્તિગત વર્તન કે અંગત લક્ષણો કે ખાસિયતોના આધારે કામ ફાળવવા માટે વપરાતો AI; મુદ્દા 5(b) હેઠળ, વ્યક્તિઓની ક્રેડિટપાત્રતા મૂલવવા વપરાતો AI. Article 6(3) ફક્ત સાંકડું પ્રક્રિયાગત કે તૈયારીનું કામ કરતી Annex III સિસ્ટમને બાકાત રાખે છે, પણ સિસ્ટમ વ્યક્તિઓનું પ્રોફાઇલિંગ કરે ત્યાં આ બાકાતી ક્યારેય લાગુ પડતી નથી. તેથી જે એજન્ટ વ્યક્તિના નિર્ણય માટે ફક્ત ડ્રાફ્ટ તૈયાર કરે છે, તે પણ જો વ્યક્તિગત કર્મચારીઓ કે ગ્રાહકોનું પ્રોફાઇલિંગ કરે તો હાઈ-રિસ્ક હોઈ શકે.
કાયદો તબક્કાવાર લાગુ પડે છે. Regulation (EU) 2026/1744, Digital Omnibus on AI, 24 જુલાઈ 2026ના રોજ Official Journalમાં પ્રકાશિત થયું અને 27 જુલાઈ 2026થી અમલમાં આવ્યું. તેણે Annex III હાઈ-રિસ્ક સિસ્ટમની જવાબદારીઓ, જેમાં Article 14ની ડિઝાઇન જવાબદારીઓ અને Article 26ની ડિપ્લૉયર જવાબદારીઓ આવે છે, 2 ડિસેમ્બર 2027 સુધી ખસેડી, અને Annex I હેઠળની પ્રોડક્ટમાં જડેલી હાઈ-રિસ્ક સિસ્ટમની જવાબદારીઓ 2 ઑગસ્ટ 2028 સુધી. કોઈ બીજી તારીખ પર આધાર રાખતાં પહેલાં વેપારોએ વર્તમાન સંકલિત લખાણ (consolidated text) તપાસવું જોઈએ.
જ્યાં આ કાયદો લાગુ ન પડે ત્યાં પણ, અર્થપૂર્ણ દેખરેખ માટે શું જરૂરી છે તેનું કાયદામાં સૌથી સ્પષ્ટ નિવેદન Article 14 છે, અને યુરોપિયન ગ્રાહકોને માલ પૂરો પાડતા ભારતીય વેપારોને તેની ભાષા કરારો અને સપ્લાયર પ્રશ્નાવલિઓમાં જોવા મળે છે.
2.2 NIST AI Risk Management Framework
NIST AI Risk Management Framework 1.0 (NIST AI 100-1, જાન્યુઆરી 2023) AI જોખમના કામને ચાર કાર્યોમાં ગોઠવે છે: Govern, Map, Measure અને Manage. પેટા-શ્રેણી MAP 3.5 માગે છે કે માનવ દેખરેખ માટેની પ્રક્રિયાઓ વ્યાખ્યાયિત, મૂલવાયેલી અને દસ્તાવેજીકૃત હોય. GOVERN 3.2 માગે છે કે નીતિઓ માનવ-AI ગોઠવણી અને દેખરેખ માટે ભૂમિકાઓ અને જવાબદારીઓ નક્કી કરે. Generative AI Profile (NIST AI 600-1, જુલાઈ 2024) જનરેટિવ સિસ્ટમનાં ખાસ જોખમો ઉમેરે છે, જેમાં ઉપજાવી કાઢેલું આઉટપુટ (confabulation) અને માહિતીની અખંડિતતા આવે છે. ફ્રેમવર્ક સ્વૈચ્છિક છે અને મર્યાદાઓ દરેક સંસ્થા પર છોડે છે.
2.3 ISO/IEC 42001:2023
ISO/IEC 42001:2023 AI મૅનેજમેન્ટ સિસ્ટમ માટેની જરૂરિયાતો નક્કી કરે છે, જેની સામે કોઈ સંસ્થા પ્રમાણપત્ર મેળવી શકે છે. તે સંસ્થા પાસે AIનાં જોખમો અને અસરોની આકારણી (કલમ 6.1.2થી 6.1.4 અને 8.2થી 8.4) અને Annex Aમાંથી કે તેની બહારથી નિયંત્રણો પસંદ કરવાની માગ કરે છે. વ્યક્તિની મંજૂરી ક્યાં રહે તે આમાંની એક પસંદગી છે; ધોરણ તે નક્કી કરી આપતું નથી.
2.4 ભારતનો Digital Personal Data Protection Act, 2023
જ્યાં એજન્ટ વ્યક્તિગત ડેટા પર પ્રક્રિયા કરે ત્યાં Digital Personal Data Protection Act, 2023 (ડિજિટલ વ્યક્તિગત ડેટા સંરક્ષણ અધિનિયમ, DPDP Act) લાગુ પડે છે. Digital Personal Data Protection Rules, 2025, 13 નવેમ્બર 2025ના રોજ જાહેર થયા, અને મોટા ભાગની જવાબદારીઓ, કલમ 8ની જવાબદારીઓ સહિત, 13 મે 2027થી લાગુ પડે છે. 2026ની શરૂઆતમાં MeitYએ કેટલીક જવાબદારીઓ માટે આ સમયગાળો ટૂંકો કરવા અંગે પરામર્શ કર્યો હતો, એટલે વર્તમાન જાહેરનામું તપાસો. ચાર જોગવાઈઓ એજન્ટને સીધી લાગુ પડે છે.
- કલમ 8(1)
- ડેટા ફિડ્યુશિયરી પોતે કરેલી, અથવા તેના વતી ડેટા પ્રોસેસરે કરેલી પ્રક્રિયા માટે જવાબદાર છે. વેપાર આ જવાબદારી પોતાના AI વેન્ડર પર ઢોળી શકતો નથી.
- કલમ 8(3)
- જ્યાં વ્યક્તિગત ડેટા સંબંધિત વ્યક્તિને અસર કરતો નિર્ણય લેવા માટે વપરાવાની શક્યતા હોય, અથવા બીજા ડેટા ફિડ્યુશિયરીને જાહેર કરાય, ત્યાં ફિડ્યુશિયરીએ તેની સંપૂર્ણતા, ચોકસાઈ અને સુસંગતતા સુનિશ્ચિત કરવી પડે છે. જે કલેક્શન એજન્ટ કોઈ વ્યક્તિગત ગ્રાહકને ડિફૉલ્ટર તરીકે ચિહ્નિત કરે, અથવા જે HR એજન્ટ કર્મચારી સામે તારણ નોંધે, તે આવો નિર્ણય લઈ રહ્યો છે.
- કલમ 8(5)
- વ્યક્તિગત ડેટાના ભંગ સામે વાજબી સુરક્ષા ઉપાયો. Scheduleની આઇટમ 1 તે ન લેવા બદલ ₹250 કરોડ સુધીના દંડની જોગવાઈ કરે છે.
- કલમ 8(10), 11 અને 13
- ફિડ્યુશિયરી પાસે ફરિયાદ નિવારણની વ્યવસ્થા હોવી જોઈએ, અને ડેટા પ્રિન્સિપલને પ્રક્રિયાનો સારાંશ મેળવવાનો અને ફરિયાદનું નિવારણ મેળવવાનો અધિકાર છે. વેપાર આ ત્યારે જ પૂરું કરી શકે જ્યારે તેને ખબર હોય કે કોઈ વ્યક્તિ વિશે એજન્ટે કયા નિર્ણયો સૂચવ્યા અને કોણે મંજૂર કર્યા.
2.5 India AI Governance Guidelines, 2025
ભારતમાં AI માટે અલગ કાયદો નથી. ઇલેક્ટ્રૉનિક્સ અને માહિતી ટેક્નોલૉજી મંત્રાલયે (MeitY) IndiaAI Mission હેઠળ 5 નવેમ્બર 2025ના રોજ બહાર પાડેલી India AI Governance Guidelines બંધનકર્તા નથી. તેનો "People First" સિદ્ધાંત માનવ-કેન્દ્રિત ડિઝાઇન અને માનવ દેખરેખની વાત કરે છે, જેને વિવેચકો મહત્ત્વના નિર્ણય બિંદુઓ પર વ્યક્તિની હાજરી તરીકે વાંચે છે, અને તે પક્ષ શું કાર્ય કરે છે, જોખમનું સ્તર કેટલું છે અને તેણે યોગ્ય ખંત (due diligence) દાખવ્યો કે નહીં, તે મુજબ ક્રમબદ્ધ જવાબદારી સૂચવે છે. જે વેપાર એજન્ટના દરેક મહત્ત્વના પગલા માટે બતાવી શકે કે કોણે અને કઈ માહિતીના આધારે મંજૂરી આપી, તેની પાસે due diligenceની દલીલ માટે જરૂરી રેકૉર્ડ છે.
2.6 બધામાં ખૂટતી સામાન્ય બાબત
આ દરેક જોખમને અનુરૂપ, દસ્તાવેજીકૃત અને સક્ષમ લોકોને સોંપાયેલી દેખરેખ માગે છે, અને દરેક પગલા માટે તેનો અર્થ શું થાય તે વેપાર પર છોડે છે. વ્યવહારમાં સંસ્થાઓ બેમાંથી એક નિષ્ફળતા તરફ ઢળે છે: બધા માટે મંજૂરી, જેને લોકો વાંચવાનું બંધ કરી દે છે, અથવા વેન્ડરના પ્રેઝન્ટેશનના આધારે અપાયેલી વ્યાપક સ્વાયત્તતા.
Section 3સંબંધિત અભ્યાસ અને આ પેપર શું ઉમેરે છે
3.1 ઑટોમેશનનાં સ્તર
Sheridan અને Verplank (1978)એ US Office of Naval Research માટેના દરિયાની અંદરના ટેલિઑપરેટર અંગેના રિપોર્ટમાં, કોઈ મદદ ન આપતા કમ્પ્યૂટરથી લઈને એકલું કામ કરતા અને માણસની અવગણના કરતા કમ્પ્યૂટર સુધીનાં દસ સ્તર વર્ણવ્યાં. Parasuraman, Sheridan અને Wickens (2000)એ કામના દરેક તબક્કા માટે સ્તર અલગથી પસંદ કરવાનું સૂચવ્યું: માહિતી મેળવવી, તેનું વિશ્લેષણ કરવું, નિર્ણય પસંદ કરવો અને પગલાનો અમલ કરવો. તેમણે પસંદગીને પહેલાં માનવ કામગીરી પર તેની અસર (કામનો ભાર, પરિસ્થિતિની જાગૃતિ, બેદરકારી અને કૌશલ્ય) પરથી, અને બીજું ઑટોમેશનની વિશ્વસનીયતા તથા ખોટા નિર્ણય કે પગલાની કિંમત પરથી મૂલવી. તેમના ઍર ટ્રાફિકના ઉદાહરણમાં તેમણે ઊંચા જોખમ વાળાં કાર્યો માટે નિર્ણયની પસંદગીને ઑટોમેશનના નીચા સ્તરે રાખવાની ભલામણ કરી. સીડી આ મર્યાદાને એ તબક્કા સુધી લઈ જાય છે જ્યાં એજન્ટની પસંદગી વેપારના રેકૉર્ડ પર અમલમાં આવે છે કે બહારના પક્ષ સુધી પહોંચે છે.
Shneiderman (2020, 2022)એ દલીલ કરી કે ઊંચું ઑટોમેશન અને ઊંચું માનવ નિયંત્રણ એકબીજાનાં વિરોધી નથી, અને સિસ્ટમ બંને માટે ડિઝાઇન થવી જોઈએ. Feng, McDonald અને Zhang (2025)એ AI એજન્ટ માટે ખાસ સ્વાયત્તતાનાં સ્તર સૂચવ્યાં, જે દરેક સ્તરે વપરાશકર્તા કઈ ભૂમિકા ભજવે છે તેનાથી વ્યાખ્યાયિત થાય છે.
3.2 માનવ સંડોવણી માટે જોખમ મૅટ્રિક્સ
સિંગાપોરનું Model AI Governance Framework (બીજી આવૃત્તિ, 2020) human in the loop, over the loop કે out of the loop વચ્ચે પસંદગી કરવા નુકસાનની સંભાવના અને ગંભીરતાનો મૅટ્રિક્સ વાપરે છે. સિંગાપોરની Infocomm Media Development Authorityએ 22 જાન્યુઆરી 2026ના રોજ શરૂ કરેલું અને મે 2026માં અપડેટ કરેલું Model AI Governance Framework for Agentic AI સંસ્થાઓને એવા ચેકપૉઇન્ટ નક્કી કરવા કહે છે જ્યાં એજન્ટને વ્યક્તિની મંજૂરી જોઈએ, ખાસ કરીને સંવેદનશીલ પગલાં પહેલાં, અને એ મંજૂરીઓ અસરકારક છે કે નહીં તે તપાસવા કહે છે. OWASP Top 10 for Large Language Model Applications (2025) વધુ પડતી સત્તા (LLM06) અને પ્રૉમ્પ્ટ ઇન્જેક્શન (LLM01)ને મુખ્ય જોખમો તરીકે ગણાવે છે, અને એજન્ટનાં કાર્યો અને પરવાનગીઓ મર્યાદિત રાખવાની અને ઊંચી અસર વાળાં પગલાં માટે વ્યક્તિની મંજૂરી ફરજિયાત રાખવાની ભલામણ કરે છે.
3.3 અહીં નવું શું છે
જોખમ મુજબ માનવ સંડોવણીને ગ્રેડ આપવો એ સ્થાપિત પ્રથા છે, અને આ પેપર તેનો દાવો કરતું નથી. તે ચાર બાબતો ઉમેરે છે:
- પહોંચથી અલગ ધરી તરીકે પાછું વાળવાની શક્યતા (reversibility), બિઝનેસ રેકૉર્ડ માટે વ્યવહારુ કસોટી સાથે (વિભાગ 4.2).
- છૂટ ફક્ત પાછું વાળી શકાય તેવા આંતરિક કામ માટે જ મળે, અને પુરાવાની આંકડાકીય તાકાત સંખ્યામાં જણાવેલી હોય (વિભાગ 6).
- વ્યાપ અને સ્રોત માટે સુધારક, જે બલ્ક પગલાં અને બહારની સામગ્રીથી પ્રેરાયેલાં પગલાંને આવરી લે છે (વિભાગ 4.5).
- ભારતના DPDP Act સાથે મૅપિંગ, અને એક પ્રોડક્ટનાં વાસ્તવિક પગલાંની યાદીનું સીડી સામે ગ્રેડિંગ, તે ક્યાં ઊણી ઊતરે છે તે સહિત (વિભાગ 8 અને પરિશિષ્ટ).
Section 4પગલાને ગ્રેડ આપવો
4.1 પહેલી ધરી: પહોંચ
પહોંચ એટલે પગલાની અસર કેટલે દૂર સુધી જાય છે.
| પહોંચ | અર્થ | ઉદાહરણ |
|---|---|---|
| R0. વાંચવું | કોઈ રેકૉર્ડમાં ફેરફાર નહીં | ઓવરડ્યૂ ઇન્વૉઇસનો સારાંશ, ભાવની સરખામણી, પ્રશ્નનો જવાબ |
| R1. ડ્રાફ્ટ | તૈયાર કરીને રોકી રાખેલો રેકૉર્ડ, જેની કોઈ વ્યક્તિ કે પછીનું પગલું તેને વાપરે ત્યાં સુધી કોઈ અસર નથી | ઇન્વૉઇસનો ડ્રાફ્ટ, ખરીદ એન્ટ્રીની તૈયારી, જવાબનો ડ્રાફ્ટ |
| R2. આંતરિક રેકૉર્ડ | વેપારના પોતાના રેકૉર્ડમાં ફેરફાર, જે કોઈ બહારનો પક્ષ જોતો નથી | ખરીદ બિલ પોસ્ટ કરવું, ગણતરી પછી સ્ટૉક સુધારવો, કૉન્ટૅક્ટને ટૅગ કરવો, ડુપ્લિકેટ એન્ટ્રી કાઢવી |
| R3. બહારનો પક્ષ | ગ્રાહક, સપ્લાયર, કર્મચારી કે જનતા સુધી પહોંચતું કંઈક | રિમાઇન્ડર મોકલવું, ગ્રાહકને જવાબ, ઇન્વૉઇસ લિંક શેર કરવી, પોસ્ટ પ્રકાશિત કરવી |
| R4. પૈસા કે કાનૂની અસર | પૈસા ખસેડતું, અથવા જવાબદારી ઊભી કરતું, બદલતું કે પૂરી કરતું કંઈક | પેમેન્ટ નોંધવું કે કરવું, ઇન્વૉઇસ કે ક્રેડિટ નોટ આપવી, પર્ચેઝ ઑર્ડર મંજૂર કરવો, સહી કરવી, રિટર્ન ભરવું |
રેકૉર્ડ કાઢી નાખવાનું પાછું વાળી શકાય કે નહીં તે મુજબ ગ્રેડ થાય છે અને R2માં આવે છે: સૉફ્ટ ડિલીટ V1 છે અને કાયમી ડિલીટ V3.
4.2 બીજી ધરી: પાછું વાળવાની શક્યતા
પાછું વાળવાની શક્યતા એટલે અસર કેટલી પૂરેપૂરી રદ કરી શકાય. કસોટી વ્યવહારુ છે.
| પાછું વાળવાની શક્યતા | કસોટી | ઉદાહરણ |
|---|---|---|
| V0. પૂરેપૂરું પાછું વાળી શકાય | વેપાર એકલો તેને રદ કરી શકે, કોઈ મહત્ત્વનું નિશાન રહે નહીં | કાઢી નાખેલો ટૅગ; ફરી ગોઠવેલી કતાર |
| V1. રેકૉર્ડ સાથે પાછું વાળી શકાય | વેપાર એકલો બીજી એન્ટ્રીથી તેને સુધારી શકે, જે ઑડિટ ટ્રેલમાં રહે છે | ખોટો સ્ટૉક સુધારો બીજા સુધારાથી સુધાર્યો; સૉફ્ટ ડિલીટ થયેલો રેકૉર્ડ પાછો લાવ્યો |
| V2. બીજા પક્ષની મદદથી પાછું વાળી શકાય | સુધારવા માટે બીજા પક્ષને દસ્તાવેજ મોકલવો પડે કે તેણે પગલું લેવું પડે, અને સુધાર્યા પછી વેપારના રેકૉર્ડ બહાર કંઈ રહેતું નથી | ખોટું ઇન્વૉઇસ ક્રેડિટ નોટથી રદ; રવાનગી પહેલાં પાછો ખેંચેલો મંજૂર પર્ચેઝ ઑર્ડર |
| V3. પાછું વાળી શકાય નહીં | શ્રેષ્ઠ ઉપલબ્ધ સુધારા પછી પણ વેપારના રેકૉર્ડ બહાર કોઈ અસર રહી જાય | ગ્રાહકે વાંચેલો સંદેશ; ખોટા ખાતામાં ગયેલું UPI પેમેન્ટ; ભરેલું રિટર્ન; કાયમ માટે કાઢી નાખેલો ડેટા |
આ કસોટી મુજબ બહારના પક્ષ સુધી પહોંચતો દરેક સંદેશ V3 છે: પછીથી માફી માગવાથી ગ્રાહકના ફોનમાંથી સંદેશ જતો નથી. જે દસ્તાવેજની કાનૂની અસર એવા સામા દસ્તાવેજથી રદ થાય જે બીજા પક્ષને પણ મળે, જેમ કે ક્રેડિટ નોટ કે પર્ચેઝ ઑર્ડર રદ કરવો, તે V2 છે; તેને લઈ જનાર સંદેશ અલગથી V3 તરીકે ગ્રેડ થાય છે.
4.3 બંને ધરી ભેગી કરવી
બંને ધરી એકબીજા સાથે સંકળાયેલી છે, કારણ કે વધુ પહોંચ સામાન્ય રીતે વધુ મુશ્કેલ સુધારો સૂચવે છે, પણ તે એક નથી. ખરીદ બિલ પોસ્ટ કરવું R2 અને V1 છે. પેમેન્ટ રિમાઇન્ડર મોકલવું R3 અને V3 છે, ભલે તેની નાણાકીય અસર શૂન્ય હોય. ફક્ત પહોંચ પર ગ્રેડ આપવાથી બહાર જતા સંદેશનું જોખમ ઓછું આંકાય છે, અને પૈસાની કસોટી તેને સાવ ચૂકી જાય છે.
4.4 મંજૂરીનાં પાંચ સ્તર
| સ્તર | નામ | એજન્ટ શું કરે છે | વ્યક્તિ શું કરે છે |
|---|---|---|---|
| L0 | જાણ કરવી | વાંચે છે અને જણાવે છે | ઇચ્છે તો વાંચે |
| L1 | સૂચવવું | શબ્દોમાં પગલું સૂચવે છે; કંઈ તૈયાર કરતો નથી | પગલું લેવું કે નહીં તે નક્કી કરે, અને લે |
| L2 | તૈયાર કરીને રોકવું | ફેરફાર પૂરો તૈયાર કરીને રોકી રાખે છે | દરેક ફેરફાર અમલમાં આવે તે પહેલાં મંજૂર કરે, સુધારે કે નકારે |
| L3 | કરવું અને જણાવવું | ફેરફાર કરે છે અને નોંધે છે | પછીથી સમીક્ષા કરે; પાછું વાળી શકે |
| L4 | કરવું અને ફક્ત અપવાદ જણાવવા | ફેરફાર કરે છે; ફક્ત અપવાદ જણાવે છે | સારાંશ અને નમૂનાની સમીક્ષા કરે |
4.5 ડિફૉલ્ટ મૅપિંગ
| V0 | V1 | V2 | V3 | |
|---|---|---|---|---|
| R0 વાંચવું | L0 | લાગુ નથી | લાગુ નથી | લાગુ નથી |
| R1 ડ્રાફ્ટ | L2 | લાગુ નથી | લાગુ નથી | લાગુ નથી |
| R2 આંતરિક રેકૉર્ડ | L2; L3 અને પછી L4 મેળવી શકે | L2; L3 મેળવી શકે | L2, સ્થિર | L2, સ્થિર |
| R3 બહારનો પક્ષ | લાગુ નથી | લાગુ નથી | લાગુ નથી | L2, સ્થિર |
| R4 પૈસા કે કાનૂની અસર | લાગુ નથી | L2, સ્થિર | L2, સ્થિર | L2, સ્થિર |
"લાગુ નથી" વાળાં ખાનાં ક્યારેય બનતાં નથી. વાંચવાથી કંઈ બદલાતું નથી, એટલે તેમાં પાછું વાળવાનું કંઈ નથી. ડ્રાફ્ટ કંઈ તેને વાપરે ત્યાં સુધી અસર કરતો નથી, એટલે તે હંમેશાં V0 છે; ડ્રાફ્ટને રેકૉર્ડ કે સંદેશમાં ફેરવતું પગલું અલગથી ગ્રેડ થાય છે. ઉપરની કસોટી મુજબ બહારના પક્ષ સુધી પહોંચતું બધું V3 છે. પૈસા કે કાનૂની અસર વાળું પગલું હંમેશાં ઓછામાં ઓછો એક રેકૉર્ડ છોડે છે.
દરેક સ્તર ક્યાં લાગુ પડે છે
L0 વાંચવાને આવરે છે. L1 ત્યાં લાગુ પડે છે જ્યાં વેપાર કોઈ વિભાગને ફક્ત સૂચનો પૂરતો રાખવાનું પસંદ કરે, જે તે કોઈ પણ ખાના માટે કરી શકે. કંઈ પણ બદલતા દરેક પગલા માટે શરૂઆતનું સ્તર L2 છે; ડ્રાફ્ટ તૈયાર કરીને રોકવો વ્યાખ્યાથી જ L2 છે. L3 અને L4 ફક્ત મેળવી શકાય છે, અને તે પણ ફક્ત બે ખાનામાં: વેપાર એકલો સુધારી શકે તેવા આંતરિક ફેરફારો (V0 કે V1 સાથે R2). L4 વધુ મર્યાદિત છે: બીજી અને ઊંચી મર્યાદા પાર કર્યા પછી, ફક્ત V0 સાથે R2, જેમ કે ટૅગિંગ અને ગોઠવણી.
સ્થિર ખાનાં
R3 અને R4માંનું બધું, અને પાછું વાળવામાં મોંઘો કે અશક્ય હોય તેવો દરેક આંતરિક ફેરફાર, એજન્ટનો રેકૉર્ડ ગમે તેટલો સારો હોય તોપણ L2 પર રહે છે. અહીં એક ભૂલ પણ રદ થઈ શકતી નથી, અને વિભાગ 6.2 બતાવે છે કે વ્યક્તિને હટાવવાને વાજબી ઠેરવવા કેટલા પુરાવા જોઈએ.
વ્યાપ અને સ્રોત સુધારક
જે પગલું નહીં તો L3 કે L4 પર ચાલત, તે નીચેનામાંથી કંઈ પણ સાચું હોય ત્યારે L2 પર રોકાય છે:
- તે વેપારે નક્કી કરેલી મર્યાદા કરતાં વધુ રેકૉર્ડને અસર કરે, દાખલા તરીકે 5,000 આઇટમમાં ભાવ ફેરફાર.
- તેનો પૈસાનો સરવાળો વેપારે નક્કી કરેલી મર્યાદાથી વધુ હોય.
- તે વેપાર બહારની સામગ્રીથી પ્રેરાયેલું હોય, જેમ કે સપ્લાયરનો ઇમેલ કે ગ્રાહકની ચૅટ, જેમાં ઘૂસાડેલી (injected) સૂચનાઓ હોઈ શકે.
- એજન્ટે કલાક કે દિવસમાં તે પ્રકારના નક્કી સંખ્યાથી વધુ ફેરફારો પહેલેથી કરી નાખ્યા હોય.
વેપાર હંમેશાં વધુ કડક કરી શકે. તે કોઈ પણ પગલું નીચા સ્તરે રાખી શકે, કોઈ પગલું સંપૂર્ણ બ્લૉક કરી શકે, અથવા અમુક રકમથી વધુના દરેક ફેરફાર માટે મંજૂરી ફરજિયાત કરી શકે. તે સ્થિર ખાનું ઢીલું કરી શકતો નથી.
4.6 L2ને કામ કરતું બનાવવું
મોટા ભાગનાં મહત્ત્વનાં પગલાં L2 પર છે, અને દેખરેખ સૌથી વધુ અહીં જ નિષ્ફળ જાય છે. Parasuraman અને Manzey (2010)એ પુરાવાની સમીક્ષા કરીને જોયું કે વિશ્વસનીય ઑટોમેશનની દેખરેખ રાખતા લોકો તેના પર ઓછી ઝીણવટથી નજર રાખવાનું વલણ ધરાવે છે, ખાસ કરીને જ્યારે બીજાં કામ તેમનું ધ્યાન ખેંચતાં હોય, જે મહિનાના અંતે મોટા ભાગની ફાઇનાન્સ ટીમનું ચિત્ર છે. આ અસર નિષ્ણાતો અને નવા લોકો બંનેમાં દેખાય છે, અને સાવધ રહેવાની સૂચનાથી તે દૂર થતી નથી. રોજ સેંકડો સાચા ફેરફારો મંજૂર કરતી વ્યક્તિ પછીનો ફેરફાર વાંચ્યા વગર મંજૂર કરી દે તેવું જોખમ છે.
તેથી સીડી, Article 14(4)(a), (b) અને (d)ને અનુરૂપ, મંજૂરીના તબક્કાની ડિઝાઇનને નિયંત્રણનો ભાગ ગણે છે:
- રોકાયેલો દરેક ફેરફાર પોતાનો ખુલાસો આપે
- શું બદલાશે, એજન્ટ તે કેમ સૂચવે છે અને તેણે કયા રેકૉર્ડ પર આધાર રાખ્યો.
- સંખ્યા ઓછી રહે,
- કારણ કે પાછું વાળી શકાય તેવું આંતરિક કામ મેળવ્યા પછી L3 પર જાય છે, અને L2 પર ધ્યાન માગતા ફેરફારો જ રહે છે.
- અસામાન્ય ચિહ્નિત થાય
- અમુક રકમથી વધુના, નવા પક્ષ સાથેના, કે સામાન્ય ઢાંચા બહારના ફેરફારો.
- વ્યક્તિ મંજૂર કરતાં પહેલાં સુધારી શકે,
- જેથી ખામી વાળા ફેરફાર અને ઉપયોગી કામ ગુમાવવા વચ્ચે પસંદગી ન કરવી પડે.
- નકારવા સાથે કારણ હોય
- જેમાંથી એજન્ટ શીખી શકે.
4.7 મંજૂરીની કિંમત: એક ઉદાહરણ
ધારો કે એક સિરામિક ટાઇલ ઉત્પાદકની AI ટીમ રોજ 120 ફેરફારો મંજૂરી માટે રોકે છે, અને વ્યક્તિ દરેક પર 20 સેકન્ડ આપે છે. તે રોજની 40 મિનિટ, એટલે 22 કામકાજી દિવસમાં આશરે 15 કલાક (26 દિવસમાં 17 કલાક) થાય. ધારો કે 120માંથી 70 ચોપડામાં પોસ્ટ થતાં ખરીદ બિલ છે (R2, V1). જો આ શ્રેણી L3 મેળવે અને તેના બદલે વ્યક્તિ પછીથી 10 ટકા નમૂનો તપાસે, દરેકમાં એ જ 20 સેકન્ડ ધારીને, તો રોજનું મંજૂરીનું કામ ઘટીને 57 ફેરફારો, એટલે આશરે 19 મિનિટ થાય. આ આંકડા સમજૂતી માટે છે; વેપારે એક અઠવાડિયું પોતાની મંજૂરીઓનો સમય માપવો જોઈએ.
Section 5વ્યક્તિગત ડેટા
જ્યાં એજન્ટનું પગલું કોઈ વ્યક્તિ વિશે કંઈક નક્કી કરવા વ્યક્તિગત ડેટા વાપરે, ત્યાં સીડી DPDP Actમાંથી લીધેલી ત્રણ જરૂરિયાતો ઉમેરે છે.
- નિર્ણય પહેલાં ચોકસાઈ
- કલમ 8(3) હેઠળ ડેટા સંપૂર્ણ, ચોક્કસ અને સુસંગત હોવો જોઈએ. જે એજન્ટ કોઈ વ્યક્તિગત ગ્રાહકને ક્રેડિટ હોલ્ડ પર મૂકવાનું સૂચવે, તેણે જે લેજર એન્ટ્રીઓ પર આધાર રાખ્યો તે બતાવવી જોઈએ, જેથી મંજૂરી આપનાર તે તપાસી શકે. આવા નિર્ણયો L2 પર રહે છે.
- ઓછામાં ઓછી પહોંચ
- એજન્ટ તેની ભૂમિકા માટે જરૂરી વ્યક્તિગત ડેટા સુધી જ પહોંચવો જોઈએ. કલેક્શન એજન્ટને ગ્રાહકના કૉન્ટૅક્ટ અને લેજર જોઈએ; પગારના રેકૉર્ડ નહીં. ભૂમિકા આધારિત પહોંચ મંજૂરીથી અલગ નિયંત્રણ છે.
- કોણે નિર્ણય લીધો તેનો રેકૉર્ડ
- વ્યક્તિને અસર કરતા દરેક નિર્ણય માટે વેપાર બતાવી શકવો જોઈએ કે એજન્ટે તે સૂચવ્યો હતો કે નહીં, કોણે, ક્યારે અને કયા ડેટાના આધારે મંજૂર કર્યો. આ રેકૉર્ડ કલમ 8(10) હેઠળની ફરિયાદ નિવારણની જવાબદારી અને કલમ 11 અને 13 હેઠળ ડેટા પ્રિન્સિપલના અધિકારો માટે કામ આવે છે.
Section 6છૂટ મેળવવી
6.1 નિયમ
એજન્ટ છૂટ એ જ રીતે મેળવે છે જેમ નવો કર્મચારી મેળવે: તેના પોતાના કામના પુરાવા પર, ચોક્કસ શ્રેણીમાં, તાજેતરના સમયગાળામાં. કોઈ નિદર્શન, વેન્ડરના દાવા કે બીજા વેપારનો પુરાવો આ એજન્ટ અહીં આ કામ કેવું કરે છે તે વિશે કંઈ કહેતો નથી.
V0 કે V1 સાથેના R2 પગલાની કોઈ શ્રેણી L2થી L3 પર ત્યારે જઈ શકે જ્યારે નીચેનું બધું સાચું હોય:
- તે શ્રેણીમાં એજન્ટના ઓછામાં ઓછા નક્કી સંખ્યાના ફેરફારો વ્યક્તિએ કોઈ સુધારા વગર મંજૂર કર્યા હોય.
- એ મંજૂરીઓ તાજેતરની સમયમર્યાદામાં હોય.
- તે સમયમર્યાદામાં તે શ્રેણીનો કોઈ ફેરફાર નકારાયો ન હોય.
- સત્તા ધરાવતી વ્યક્તિ સ્તર વધારવાનું સ્વીકારે.
સુધારા પછીની મંજૂરી બતાવે છે કે આઉટપુટને સુધારાની જરૂર હતી, એટલે તે ગણાતી નથી. શ્રેણી મુજબ, રોકાયેલા ફેરફારોમાંથી કેટલાને સુધારાની જરૂર પડી તે હિસ્સો પોતે જ એજન્ટ ક્યાં સૌથી નબળો છે તેનું ઉપયોગી માપ છે.
જ્યારે વ્યક્તિ L3 પર થયેલો ફેરફાર પાછો વાળે, અથવા જ્યારે વેપાર એજન્ટની સૂચનાઓ, ટૂલ્સ કે મૂળ મૉડેલ એવી રીતે બદલે કે તેનું વર્તન બદલાઈ શકે, ત્યારે શ્રેણી L2 પર પાછી આવે છે. છૂટ દરેક શ્રેણી માટે અલગથી મેળવવી પડે છે: જે એજન્ટે 300 ખરીદ બિલ સાચાં પોસ્ટ કર્યાં છે, તેણે સ્ટૉક સુધારા અંગેની પોતાની સમજ વિશે કંઈ સાબિત કર્યું નથી.
6.2 ભૂલ વગરનો ક્રમ કેટલું ઓછું સાબિત કરે છે
જો n સ્વતંત્ર કેસમાં કોઈ ભૂલ ન થઈ હોય, તો સાચા ભૂલ દરની એક બાજુની 95 ટકા ઉપલી મર્યાદા 1 − 0.05^(1/n) છે. Hanley અને Lippman-Hand (1983)એ બતાવ્યું કે n આશરે 30 કે વધુ થાય ત્યારે આ 3 ÷ nની નજીક છે, જેને "rule of three" (ત્રણનો નિયમ) કહે છે.
| સતત ભૂલ વગરના કેસ | ભૂલ દર હજી આટલો ઊંચો હોઈ શકે |
|---|---|
| 10 | 25.9% |
| 30 | 9.5% |
| 100 | 3.0% |
| 300 | 1.0% |
| 3,000 | 0.1% |
10 જેવી મર્યાદા વ્યક્તિને સ્તર વધારવા વિશે વિચારવા પ્રેરે છે; કોષ્ટક બતાવે છે કે તે કેટલું ઓછું સાબિત કરે છે. તેથી જ સીડી મેળવેલી છૂટને વેપાર એકલો સુધારી શકે તેવા ફેરફારો સુધી મર્યાદિત રાખે છે, દરેક સ્થિર ખાના પર વ્યક્તિને રાખે છે, અને પહેલી વાર ફેરફાર પાછો વળે ત્યારે જ છૂટ પાછી ખેંચે છે. પાછું ન વાળી શકાય તેવા પગલા માટે ભૂલ દર 0.1 ટકાથી ઓછો છે તે બતાવવા સતત આશરે 3,000 ભૂલ વગરના, સ્વતંત્ર કેસ જોઈએ, જે થોડા જ વેપારો કોઈ એક શ્રેણી માટે ભેગા કરી શકે. વધુ જથ્થો ધરાવતા વેપારોએ ઊંચી મર્યાદાઓ રાખવી જોઈએ.
Section 7મૉડેલની મર્યાદાઓ
મંજૂરીઓ સ્વતંત્ર નથી
ઉપરની મર્યાદા સ્વતંત્ર કેસ ધારે છે. એક અઠવાડિયાની બધી મંજૂરીઓ એ જ થોડા સપ્લાયરો કે એ જ દસ્તાવેજ લેઆઉટની હોઈ શકે. રોજબરોજના કેસ પર ભૂલ વગરની મંજૂરીઓ અસામાન્ય કેસ વિશે થોડું જ કહે છે, અને ભૂલો ત્યાં જ કેન્દ્રિત હોય છે.
મંજૂરીની ગુણવત્તા મપાતી નથી
મંજૂરી ત્યારે જ પુરાવો છે જ્યારે વ્યક્તિએ ફેરફાર તપાસ્યો હોય. સીડી ઝીણવટભરી મંજૂરી અને યાંત્રિક મંજૂરી વચ્ચે ફરક પારખી શકતી નથી, અને ઑટોમેશન બાયસનો અર્થ એ છે કે પુરાવો જ્યારે સૌથી મજબૂત દેખાય ત્યારે કદાચ સૌથી નબળો હોય.
પાછું વાળવાની શક્યતા હંમેશાં અગાઉથી ખબર નથી હોતી
આંતરિક રીતે સુધારેલો રેકૉર્ડ કદાચ પહેલેથી બહાર એક્સપોર્ટ, શેર થઈ ચૂક્યો હોય કે તેના પર કોઈએ આધાર રાખ્યો હોય. એક્સપોર્ટ, લિંક કે ઇન્ટિગ્રેશન દ્વારા સિસ્ટમ બહાર જતા કોઈ પણ રેકૉર્ડને ઓછામાં ઓછો V2 ગણવો જોઈએ.
બહારથી આવતી સૂચનાઓ
સપ્લાયરના ઇમેલ કે ગ્રાહકના સંદેશ વાંચતા એજન્ટને તે સંદેશ જ સૂચના આપી શકે છે (OWASP LLM01). વિભાગ 4.5નો સ્રોત સુધારક આવાં પગલાંને L2 પર રોકે છે, પણ જે ઘૂસાડેલી સૂચનાએ પહેલેથી કોઈ ડ્રાફ્ટને આકાર આપ્યો હોય અને પછી વ્યક્તિ તે મંજૂર કરે, તેને તે પકડી શકતો નથી. મંજૂરી આપનારે એજન્ટે જે સ્રોત પર પગલું લીધું તે જોવો જોઈએ.
મૉડેલ બદલાય છે
મૂળ મૉડેલ અપગ્રેડ થાય ત્યારે જૂના મૉડેલ હેઠળ ભેગો કરેલો પુરાવો કદાચ ટકે નહીં. મેળવેલી છૂટ ફરી શરૂઆતથી ગણવી પ્રગતિ ગુમાવ્યા જેવું લાગી શકે; તેનો વિકલ્પ એવી સિસ્ટમ વિશેના પુરાવા પર આધાર રાખવાનો છે જે હવે અસ્તિત્વમાં નથી.
Section 8MatruOS અને સીડી
MatruOS એક બિઝનેસ સિસ્ટમ છે જેમાં AI સભ્યો વેપારના લોકોની સાથે કામ કરે છે, દરેક સભ્ય એક ભૂમિકા સાથે, જેમ કે એકાઉન્ટન્ટ કે કલેક્શન અધિકારી. આ વિભાગ આ લખાય છે ત્યારે બનેલાં નિયંત્રણો વર્ણવે છે, પ્રોડક્ટના કોડ પરથી ગ્રેડ કરેલાં, અને તે સીડીથી ક્યાં જુદાં પડે છે તે જણાવે છે.
8.1 બે નિયંત્રણ વ્યવસ્થાઓ
વિભાગ ડાયલ (area dial)
વેપાર collections, stock, customer replies, social media અને bookkeeping માટે સ્તર સેટ કરી શકે છે: "Suggest" (AI શબ્દોમાં સૂચવે છે અને કંઈ બદલતો નથી), "Ask me" (દરેક ફેરફાર વ્યક્તિની રાહ જુએ છે) કે "Auto" (રોજબરોજના ફેરફારો આગળ વધે છે). જ્યારે કોઈ વિભાગનું સ્તર સેટ હોય, ત્યારે જે AI ફેરફારનું પગલું પ્રોડક્ટની "હંમેશાં રાહ જુએ" યાદીમાં હોય તે દરેક સ્તરે વ્યક્તિની રાહ જુએ છે. આ યાદીમાં મોકલવું કે જવાબ આપવો, એક ઇન્વૉઇસનું પેમેન્ટ નોંધવું, મંજૂર કરવું, સહી કરવી, કાઢી નાખવું, void કરવું, રદ કરવું, હટાવવું અને પ્રકાશિત કરવું આવે છે. જે વિભાગનું કોઈ સ્તર સેટ ન હોય, જે શરૂઆતની સ્થિતિ છે, તે દરેક AI સભ્યના પોતાના સેટિંગને અનુસરે છે. જ્યારે લોકોએ કોઈ વિભાગમાં 30 દિવસમાં 10 AI ફેરફારો મંજૂર કર્યા હોય અને એક પણ નકાર્યો ન હોય, ત્યારે MatruOS પછીનું સ્તર ઑફર કરે છે; કોઈ સ્તર સેટ ન હોય ત્યાંથી ઑફર "Auto"ની હોય છે.
Auto mode લૂપ
પાંચ લૂપ રોજબરોજના કામના આખા ટુકડા ચલાવે છે: ગ્રાહકના ઑર્ડર લેવા, પેમેન્ટ મેળવવું, ગ્રાહકોને જવાબ આપવો, સ્ટૉક જાળવવો અને ક્વોટેશનનું ફૉલો-અપ. આજે વેપાર દરેક લૂપને "Watch" (લૂપ શું કરત તે બતાવે છે) કે "Ask" (દરેક પગલું વ્યક્તિની રાહ જુએ છે) પર સેટ કરી શકે છે. ગ્રાહકોને જવાબ આપવાના લૂપમાં પગલું કેસ AI સભ્યને સોંપે છે, અને પછી જવાબ ડાયલના replies વિભાગને અનુસરે છે; જાતે "Ask" પર શરૂ થયેલો લૂપ તે વિભાગ સેટ કરતો નથી. જરૂરી ઍપ અને ભૂમિકાઓ ગોઠવાઈ જાય પછી લૂપ "Ask" પર શરૂ થાય છે. 95 ટકા મેળ સાથે 20 કેસ જોયા પછી MatruOS "Watch"થી "Ask" ઑફર કરે છે. બીજાં બે સ્તર, "Auto" (રોજબરોજનાં પગલાં આગળ વધે છે) અને "Hands off" (રોજબરોજના કામની દૈનિક યાદી વગરનું "Auto"), બનેલાં છે પણ હજી વેપારો માટે ખુલ્લાં નથી. જેવાં બનેલાં છે તે મુજબ, "Auto" પર લૂપ દિવસમાં 3 કેસ નિષ્ફળ જાય તો આપમેળે "Ask" પર પાછો આવે, વેપાર બીજી સંખ્યા નક્કી ન કરે તો દિવસમાં વધુમાં વધુ 25 પગલાં ચલાવે, અને પગલા દીઠ પૈસાની મર્યાદા રાખી શકે. કેટલાંક પગલાં હજી વ્યક્તિ પાસે જાય: પેમેન્ટ મેળવવાના લૂપમાં 45 દિવસથી વધુ મોડાં ઇન્વૉઇસ પરનાં રિમાઇન્ડર; ફૉલો-અપ લૂપમાં 24 દિવસથી જૂનાં ક્વોટેશન.
Inbox જવાબ સહાયક
આવતા ગ્રાહક સંદેશનો જવાબ એક જવાબ સહાયક આપે છે, જે શરૂઆતથી જ ચાલુ હોય છે અને તેમાં AI જવાબ ચાલુ હોય છે. જ્યારે વેપારના નક્કી જવાબોમાંથી કોઈ બંધબેસતો ન હોય, ત્યારે AI જવાબ લખે છે અને તે વ્યક્તિ વગર ગ્રાહક સુધી જાય છે. સુરક્ષા ઉપાયો બહુ લાંબા, વેપારે ન આપેલી લિંક ધરાવતા, કે વેપારે ક્યારેય ન જણાવેલી રકમ ઉલ્લેખતા જવાબ રોકે છે, અને પહેલો જવાબ જણાવે છે કે તે ઑટોમેટેડ છે. સહાયક વિભાગ ડાયલ, સંસ્થાના નિયમો કે પૉઝ સ્વિચને અનુસરતો નથી; વેપાર Inbox સેટિંગ્સમાં AI જવાબ બંધ કરે છે.
સેટિંગ ગમે તે હોય, રોકાતાં પગલાં
કેટલાંક પગલાં પ્રોડક્ટમાં એવાં ચિહ્નિત છે કે AI સભ્ય તે સૂચવે ત્યારે હંમેશાં વ્યક્તિ જોઈએ, જેમાં જર્નલ પોસ્ટ કરવું અને રિવર્સ કરવું અને સમયગાળો બંધ કરવો આવે છે. કાઢી નાખવું હંમેશાં રાહ જુએ છે. સોશિયલ મીડિયા પર પ્રકાશિત કરવું વ્યક્તિનું પગલું છે; AI સભ્યો ફક્ત પોસ્ટનો ડ્રાફ્ટ બનાવી શકે છે.
સંસ્થાના નિયમો
ઍડ્મિનિસ્ટ્રેટર પગલાં બ્લૉક કરી શકે છે, નામ આપેલાં પગલાં માટે અથવા મર્યાદાથી વધુ લાઇન રકમ વાળા AI ફેરફારો માટે મંજૂરી ફરજિયાત કરી શકે છે, AI ખર્ચ પર મહિના અને વિભાગ મુજબ મર્યાદા મૂકી શકે છે, AI સભ્ય કોઈ પણ ચૅનલ પર કલાકમાં કેટલા સંદેશ મોકલી શકે તેની મર્યાદા મૂકી શકે છે (બદલવામાં ન આવે તો 20; તૈયાર રિમાઇન્ડર ગણાતાં નથી), અને આખી AI ટીમને પૉઝ કરી શકે છે. આ નિયમો AI સભ્યોના પોતાના ફેરફારોને લાગુ પડે છે. પૈસાની મર્યાદા ફેરફારની સૌથી મોટી એક લાઇનની ટેક્સ પહેલાંની રકમને મર્યાદા સાથે સરખાવે છે. ₹1 લાખની મર્યાદા હેઠળ ₹9 લાખનું દસ લાઇનનું બિલ રોકાતું નથી, જો કોઈ લાઇન તે મર્યાદાથી વધુ ન હોય. ડ્રાફ્ટ ઇન્વૉઇસ ઇશ્યૂ કરવું, ચૅટ ઑર્ડરનું બિલ બનાવવું અને સેલ્સ ઑર્ડરનું ઇન્વૉઇસ બનાવવું હાલના રેકૉર્ડ પરથી કામ કરે છે અને મર્યાદામાં પકડાતાં નથી; ક્વોટેશનનું રૂપાંતર, ડીલનું ઇન્વૉઇસ અને આઇટમ યાદી પરથી ભાવ લેતી લાઇનો પકડાય છે. જેવા બનેલા છે તે મુજબ, આ નિયમો "Auto" પરના લૂપને લાગુ નહીં પડે, જે પોતાની દૈનિક મર્યાદા અને પૈસાની મર્યાદા રાખે છે.
AI કામના રેકૉર્ડ
રોકાયેલા ફેરફારો AI સભ્યની નોંધ સાથે Approvalsમાં દેખાય છે. AI સભ્યોના ફેરફારો, જે સભ્યે કર્યા તેના નામે, ઑડિટ લૉગમાં નોંધાય છે, અને દરેકને વ્યક્તિએ મંજૂર કર્યો કે નકાર્યો તે પણ. મોકલતાં પહેલાં વ્યક્તિ ડ્રાફ્ટ સુધારે ત્યારે તેણે કાઢી નાખેલા શબ્દો સૂચિત પાઠ (lesson) તરીકે રખાય છે.
8.2 સ્તરોની સરખામણી
| MatruOS સ્તર | સીડીનું સૌથી નજીકનું સ્તર | ફરક |
|---|---|---|
| લૂપ "Watch" પર | L0થી L1 | લૂપ શું કરત તે બતાવે છે; કંઈ બદલતો નથી |
| વિભાગ "Suggest" પર | L1 | કોઈ મહત્ત્વનો ફરક નહીં |
| વિભાગ "Ask me" પર | L2 | કોઈ મહત્ત્વનો ફરક નહીં |
| લૂપ "Ask" પર | L2 | ગ્રાહકોને જવાબ આપવામાં, જવાબ ડાયલના replies વિભાગને અનુસરે છે |
| વિભાગ "Auto" પર | L3 | જુદા જુદા ગ્રેડ વાળો આખો વિભાગ આવરે છે; "હંમેશાં રાહ જુએ" વાળાં પગલાં રોકાયેલાં રહે છે |
| લૂપ "Auto" પર (હજી ખુલ્લું નથી) | L3 | આખો લૂપ આવરશે, કેટલાક બહાર જતા સંદેશ સહિત |
| લૂપ "Hands off" પર (હજી ખુલ્લું નથી) | L4 | આખો લૂપ આવરશે, કેટલાક બહાર જતા સંદેશ સહિત |
8.3 પ્રોડક્ટ સીડીથી ક્યાં ઊણી ઊતરે છે
- Inbox સહાયકના AI જવાબ વ્યક્તિ વગર જાય છે,
- અને ડાયલ, સંસ્થાના નિયમો કે પૉઝ સ્વિચ, કોઈ તેમના સુધી પહોંચતું નથી. સીડી બહાર જતા દરેક સંદેશને L2 પર સ્થિર રાખે છે.
- કોઈ વિભાગ સ્તર સેટ ન હોય ત્યારે સંદેશ અને પેમેન્ટ
- કોઈ વિભાગ સ્તર સેટ ન હોય, જે શરૂઆતની સ્થિતિ છે, ત્યારે રોજબરોજના કામ માટે ભરોસાપાત્ર ગણાયેલો AI સભ્ય મંજૂરી વગર સંદેશ મોકલી શકે છે, પોતાના શબ્દોમાં ફૉલો-અપ સહિત, અને પેમેન્ટ નોંધી શકે છે. પરિશિષ્ટની દરેક "Auto પર ચાલે છે" વાળી લાઇન પણ આ સ્થિતિમાં આવા સભ્ય માટે રોકાયા વગર ચાલે છે. સીડી બહાર જતા દરેક સંદેશ અને દરેક પેમેન્ટને L2 પર સ્થિર રાખે છે.
- "Auto" પરના લૂપ, ખુલ્યા પછી
- જેવા બનેલા છે તે મુજબ, "Auto" પર પેમેન્ટ મેળવવાનો લૂપ 45 દિવસ સુધી મોડાં ઇન્વૉઇસ પર રિમાઇન્ડર, અને ફૉલો-અપ લૂપ 24 દિવસ સુધી જૂનાં ક્વોટેશનનાં ફૉલો-અપ, મંજૂરી વગર મોકલશે, અને લૂપને "Auto" પર કરવાથી ડાયલનો તેનો વિભાગ પણ "Auto" પર થઈ જશે. આ સ્તર હજી ખુલ્લાં નથી; ખોલતાં પહેલાં જરૂરી ફેરફાર અમે નોંધ્યો છે.
- પૈસા અને કાનૂની અસર વાળાં કેટલાંક પગલાં વ્યક્તિ વગર ચાલી શકે છે
- ઇન્વૉઇસ બનાવવું, ડ્રાફ્ટ ઇન્વૉઇસ ઇશ્યૂ કરવું, ચૅટ ઑર્ડરનું બિલ બનાવવું, ક્રેડિટ નોટ આપવી, ગ્રાહકની ક્રેડિટ ઇન્વૉઇસ સામે સેટ કરવી, ઘણાં ઇન્વૉઇસ સામે એક પેમેન્ટ નોંધવું, ઍડવાન્સ નોંધવું, બૅન્ક સ્ટેટમેન્ટની લાઇન પોસ્ટ કરવી, ખરીદ બિલ પોસ્ટ કરવું અને પર્ચેઝ ઑર્ડર બનાવવો, તેમનો વિભાગ "Auto" પર હોય ત્યારે મંજૂરી વગર ચાલી શકે છે. ડિલિવર થયેલા સેલ્સ ઑર્ડરનું ઇન્વૉઇસ બનાવવું કોઈ વિભાગમાં નથી અને AI સભ્યના પોતાના સેટિંગને અનુસરે છે. સીડી આને L2 પર સ્થિર રાખે છે.
- છૂટ આખા વિભાગ કે લૂપ માટે સેટ થાય છે
- વિભાગ કે લૂપમાં જુદા જુદા ગ્રેડનાં પગલાં ભળેલાં હોય છે.
- સુધારા પછીની મંજૂરીઓ સ્તર વધારવામાં ગણાય છે
- સીડી તેને બાકાત રાખે છે.
- ફક્ત આંશિક રીસેટ
- જેવા બનેલા છે તે મુજબ, "Auto" પરના લૂપ દિવસમાં વારંવાર નિષ્ફળતા પછી "Ask" પર પાછા આવશે, પણ વ્યક્તિ ફેરફાર પાછો વાળે કે મૉડેલ બદલાય ત્યારે નહીં. વિભાગ ડાયલમાં આપમેળે રીસેટ નથી.
- આંશિક વ્યાપ સુધારક
- જેવા બનેલા છે તે મુજબ, "Auto" પરના લૂપ દિવસનાં પગલાંની સંખ્યા અને પગલા દીઠ પૈસા મર્યાદિત કરશે. બેમાંથી કોઈ વ્યવસ્થા રેકૉર્ડની સંખ્યા મુજબ બલ્ક ફેરફારો, કે બહારની સામગ્રીથી પ્રેરાયેલા ફેરફારોને, એક વર્ગ તરીકે રોકતી નથી.
- પૈસાની મર્યાદા ટેક્સ પહેલાંની એક એક લાઇન વાંચે છે અને રેકૉર્ડ આધારિત પગલાં ચૂકી જાય છે,
- જેમ વિભાગ 8.1માં વર્ણવ્યું છે.
અમે આને પ્રોડક્ટના કામ તરીકે નોંધ્યું છે. તે પૂરું ન થાય ત્યાં સુધી, જે વેપાર સીડીનું રક્ષણ ઇચ્છે તેણે દરેક વિભાગ "Ask me" પર સેટ કરવો, દરેક AI સભ્યને દરેક ફેરફાર પહેલાં પૂછવા સેટ કરવો, લૂપ "Watch" કે "Ask" પર રાખવા, અને Inbox સેટિંગ્સમાં જવાબ સહાયકના AI જવાબ બંધ કરવા.
AI ભૂલ કરી શકે છે. ઉપરનાં નિયંત્રણો, જણાવેલા અપવાદોની અંદર, વ્યક્તિ જુએ તે પહેલાં ભૂલ ક્યાં સુધી પહોંચી શકે તે મર્યાદિત કરે છે.
8.4 પદ્ધતિ
31 ઑક્ટોબર 2026ના રોજ ચાલુ રિલીઝ (commit fe49e480) વખતના કોડ પરથી પ્રોડક્ટને ગ્રેડ આપવામાં આવ્યો, અને નિયમનો એ જ તારીખે તપાસાયાં. આ પેપરની દરેક નવી આવૃત્તિ પહેલાં લાઇવ પ્રોડક્ટ પર ગ્રેડિંગ ફરી કરવામાં આવશે.
Section 9નિષ્કર્ષ
મંજૂરીની સીડી એજન્ટના દરેક પગલાને તે ક્યાં સુધી પહોંચે છે અને તેને રદ કરી શકાય કે નહીં તે મુજબ ગ્રેડ આપે છે; વેપાર બહાર પહોંચતું, પૈસા ખસેડતું કે વેપાર એકલો સુધારી ન શકે તેવું બધું રોકી રાખે છે; અને પાછું વાળી શકાય તેવા આંતરિક કામને તે શ્રેણીમાં ભૂલ વગરની મંજૂરીઓ પર છૂટ મેળવવા દે છે, દરેક વાર સ્તર વધારવાનું વ્યક્તિ સ્વીકારે ત્યારે. સારાં પરિણામોનો ક્રમ દેખાય છે તેના કરતાં ઓછું સાબિત કરે છે, અને વિભાગ 6.2નું કોષ્ટક કેટલું ઓછું, તેની સંખ્યા આપે છે.
પરિશિષ્ટ: સીડી પર ગ્રેડ કરેલાં MatruOSનાં પગલાં
| પગલું | વિભાગ કે લૂપ | ગ્રેડ | સીડીનું સ્તર | આજે MatruOS | શા માટે રોકાય છે | મેળ |
|---|---|---|---|---|---|---|
| ગ્રાહકને જવાબ | Replies; ગ્રાહકોને જવાબ આપવાનો લૂપ | R3, V3 | L2, સ્થિર | વિભાગનું સ્તર સેટ હોય ત્યારે રાહ જુએ છે | "હંમેશાં રાહ જુએ" યાદી | આંશિક: સ્તર સેટ ન હોય ત્યારે નહીં |
| Inbox જવાબ સહાયકનો AI જવાબ | Inbox (ડાયલની બહાર) | R3, V3 | L2, સ્થિર | કોઈ નક્કી જવાબ બંધ ન બેસે ત્યારે વ્યક્તિ વગર જાય છે; શરૂઆતથી ચાલુ | ફક્ત સામગ્રીના સુરક્ષા ઉપાયો | ના |
| AI સભ્યના પોતાના શબ્દોમાં સંદેશ મોકલવો, જેમ કે ક્વોટેશન ફૉલો-અપ કે નવા લીડને પહેલો સંદેશ | Replies | R3, V3 | L2, સ્થિર | વિભાગનું સ્તર સેટ હોય ત્યારે રાહ જુએ છે; સ્તર સેટ ન હોય ત્યારે રોજબરોજના કામ માટે ભરોસાપાત્ર સભ્ય તે રોકાયા વગર મોકલે છે | "હંમેશાં રાહ જુએ" યાદી | આંશિક |
| AI સભ્યે તૈયાર કરેલું પેમેન્ટ રિમાઇન્ડર મોકલવું | Collections; પેમેન્ટ મેળવવાનો લૂપ | R3, V3 | L2, સ્થિર | વિભાગનું સ્તર સેટ હોય ત્યારે અને લૂપ "Ask" પર હોય ત્યારે રાહ જુએ છે; સ્તર સેટ ન હોય ત્યારે રોજબરોજના કામ માટે ભરોસાપાત્ર સભ્ય તે રોકાયા વગર મોકલે છે; "Auto" પર, ખુલ્યા પછી, લૂપ તે 45 દિવસ સુધી મોડાં ઇન્વૉઇસ પર રોકાયા વગર મોકલશે | "હંમેશાં રાહ જુએ" યાદી; લૂપ "Ask" પર | આંશિક |
| ફૉલો-અપ લૂપમાંથી ક્વોટેશન ફૉલો-અપ મોકલવું | ફૉલો-અપ લૂપ | R3, V3 | L2, સ્થિર | "Ask" પર રાહ જુએ છે; "Auto" પર, ખુલ્યા પછી, લૂપ તે 24 દિવસ સુધી રોકાયા વગર મોકલશે | લૂપ "Ask" પર | આંશિક |
| એક ઇન્વૉઇસનું પેમેન્ટ નોંધવું | Collections | R4, V1 | L2, સ્થિર | વિભાગનું સ્તર સેટ હોય ત્યારે રાહ જુએ છે | "હંમેશાં રાહ જુએ" યાદી | આંશિક: સ્તર સેટ ન હોય ત્યારે નહીં |
| ઘણાં ઇન્વૉઇસ કે બિલ સામે એક પેમેન્ટ નોંધવું | Bookkeeping | R4, V1 | L2, સ્થિર | "Auto" પર ચાલે છે; સપ્લાયરને જતું પેમેન્ટ પેમેન્ટ મંજૂર કરનાર વ્યક્તિની રાહ જુએ છે | બહાર જતા પૈસા માટે પેઆઉટ મંજૂરી | આંશિક |
| ઍડવાન્સ નોંધવું | Bookkeeping | R4, V1 | L2, સ્થિર | "Auto" પર ચાલે છે | કંઈ નહીં | ના |
| બૅન્ક સ્ટેટમેન્ટની લાઇન પોસ્ટ કરવી | Bookkeeping | R4, V1 | L2, સ્થિર | "Auto" પર ચાલે છે | કંઈ નહીં | ના |
| ગ્રાહકની ક્રેડિટ ઇન્વૉઇસ સામે સેટ કરવી | Collections | R4, V1 | L2, સ્થિર | "Auto" પર ચાલે છે | કંઈ નહીં | ના |
| સોશિયલ પોસ્ટનો ડ્રાફ્ટ | Social | R1, V0 | L2 | AI ડ્રાફ્ટ બનાવે છે; વ્યક્તિ પ્રકાશિત કરે છે | ફક્ત વ્યક્તિનું પગલું | હા |
| રેકૉર્ડ કાઢી નાખવો | કોઈ પણ | R2, V1 કે V3 | L2, કાયમી હોય તો સ્થિર | રાહ જુએ છે | વિનાશક | હા |
| ઇન્વૉઇસ લિંકથી જોઈ શકાય તેવું બનાવવું | Collections | R3, V3 | L2, સ્થિર | "Auto" પર ચાલે છે | કંઈ નહીં | ના |
| ચૅટ ઑર્ડરનું બિલ બનાવવું | Replies; ઑર્ડર લેવાનો (intake) લૂપ | R4, V2 | L2, સ્થિર | "Auto" પર ચાલે છે; પૈસાની મર્યાદામાં પકડાતું નથી | કંઈ નહીં | ના |
| ઇન્વૉઇસ બનાવવું, કે ડ્રાફ્ટ ઇન્વૉઇસ ઇશ્યૂ કરવું | Bookkeeping | R4, V2 | L2, સ્થિર | "Auto" પર ચાલે છે | કંઈ નહીં | ના |
| ડિલિવર થયેલા સેલ્સ ઑર્ડર પરથી ઇન્વૉઇસ બનાવવું | કોઈ વિભાગ નહીં; intake લૂપ | R4, V2 | L2, સ્થિર | intake લૂપ "Ask" પર હોય ત્યારે રાહ જુએ છે; નહીં તો સભ્યના પોતાના સેટિંગને અનુસરે છે અને રોજબરોજના કામ માટે ભરોસાપાત્ર સભ્ય માટે રોકાયા વગર ચાલે છે; પૈસાની મર્યાદામાં પકડાતું નથી | કંઈ નહીં | ના |
| ક્રેડિટ નોટ આપવી | Bookkeeping | R4, V2 | L2, સ્થિર | "Auto" પર ચાલે છે | કંઈ નહીં | ના |
| ખરીદ બિલ પોસ્ટ કરવું | Bookkeeping | R2, V1 | L2; L3 મેળવી શકે | "Auto" પર ચાલે છે | કંઈ નહીં | આંશિક: સ્તર વધારવામાં સુધારા પછીની મંજૂરીઓ ગણાય છે |
| પર્ચેઝ ઑર્ડર બનાવવો | Stock; સ્ટૉક જાળવવાનો લૂપ | ડ્રાફ્ટ તરીકે R1; સબમિટ થયા પછી R4, V2 | L2 | "Auto" પર ચાલે છે; ખરીદ મંજૂરી મર્યાદાથી વધુ હોય તો મૅનેજરની રાહ જુએ છે; મર્યાદા ડિફૉલ્ટ રીતે શૂન્ય છે, જેનો અર્થ છે કોઈ મંજૂરીનું પગલું નહીં, એટલે વેપાર મર્યાદા સેટ ન કરે ત્યાં સુધી સબમિટ થયેલો દરેક ઑર્ડર મંજૂર તરીકે ચિહ્નિત થાય છે | ખરીદ મંજૂરી મર્યાદા | આંશિક |
| જર્નલ પોસ્ટ કે રિવર્સ કરવી | Bookkeeping | R2, V1 | L2; L3 મેળવી શકે | હંમેશાં રાહ જુએ છે | સંવેદનશીલ તરીકે ચિહ્નિત | હા, સીડી મંજૂરી આપે તેનાથી વધુ કડક |
| સમયગાળો બંધ કરવો | Bookkeeping | R2, V1 | L2; L3 મેળવી શકે | હંમેશાં રાહ જુએ છે | સંવેદનશીલ તરીકે ચિહ્નિત | હા, સીડી મંજૂરી આપે તેનાથી વધુ કડક |
| ગણતરી પછી સ્ટૉક સુધારવો | Stock | R2, V1 | L2; L3 મેળવી શકે | "Auto" પર ચાલે છે; સ્ટૉક શૂન્ય પર સેટ થાય ત્યારે રાહ જુએ છે | આંશિક સંવેદનશીલ | આંશિક: સ્તર વધારવામાં સુધારા પછીની મંજૂરીઓ ગણાય છે |
31 ઑક્ટોબર 2026ના commit fe49e480 વખતના પ્રોડક્ટના કોડ પરથી ગ્રેડ કર્યું. ઇન્વૉઇસની ડ્યૂ તારીખ પહેલાં અને પછીનાં શેડ્યૂલ કરેલાં રિમાઇન્ડર મોટા ભાગના વેપાર પ્રકારો માટે શરૂઆતથી ચાલુ હોય છે અને ચૅનલ જોડાયા પછી વ્યક્તિ વગર જાય છે. તે વેપાર બદલી કે બંધ કરી શકે તેવા નિયમો છે, અને આ ગ્રેડિંગ ફક્ત AI પગલાંને આવરે છે.
સ્રોત
31 ઑક્ટોબર 2026ના રોજ ચકાસેલ. નિયમનો એ તારીખની સ્થિતિ મુજબ દર્શાવ્યાં છે.
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 6, 14 and 26 and Annex III, EUR-Lex
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), Official Journal, 24 July 2026, EUR-Lex. Summaries: White & Case; Mayer Brown, 30 July 2026
- NIST AI 100-1, AI Risk Management Framework 1.0, January 2023: MAP 3.5 and GOVERN 3.2.
- NIST AI 600-1, Generative Artificial Intelligence Profile, July 2024
- ISO/IEC 42001:2023, Artificial intelligence: Management system
- Digital Personal Data Protection Act, 2023 and Rules, 2025, MeitY: Sections 8(1), 8(3), 8(5), 8(10), 11, 13 and the Schedule.
- India AI Governance Guidelines, Ministry of Electronics and Information Technology, IndiaAI Mission, 5 November 2025. IndiaAI; commentary, JSA
- Personal Data Protection Commission and Infocomm Media Development Authority, Singapore (2020). Model Artificial Intelligence Governance Framework, second edition.
- Infocomm Media Development Authority, Singapore (2026). Model AI Governance Framework for Agentic AI, updated May 2026
- OWASP (2025). Top 10 for Large Language Model Applications: LLM01 Prompt Injection, LLM06 Excessive Agency
- Sheridan, T. B. and Verplank, W. L. (1978). Human and computer control of undersea teleoperators. MIT Man-Machine Systems Laboratory, report for the Office of Naval Research.
- Parasuraman, R., Sheridan, T. B. and Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3), 286–297. https://doi.org/10.1109/3468.844354
- Parasuraman, R. and Manzey, D. H. (2010). Complacency and bias in human use of automation: an attentional integration. Human Factors, 52(3), 381–410.
- Hanley, J. A. and Lippman-Hand, A. (1983). If nothing goes wrong, is everything all right? Interpreting zero numerators. JAMA, 249(13), 1743–1745.
- Shneiderman, B. (2022). Human-Centered AI. Oxford University Press.
- Feng, K. J. K., McDonald, D. W. and Zhang, A. X. (2025). Levels of autonomy for AI agents. arXiv:2506.12469.
ફેરફારોની નોંધ
- 1.4 (31 ઑક્ટોબર 2026): Inbox જવાબ સહાયક ઉમેર્યો; પેઆઉટ અને ખરીદ મંજૂરી મર્યાદાઓની નોંધ લીધી.
- 1.3 (31 ઑક્ટોબર 2026): AI સભ્યોએ લખેલા સંદેશ માટે શરૂઆતની સ્થિતિની ખામીઓ, પૈસાની મર્યાદાની વિગત, ગ્રાહકોને જવાબ આપવા માટે લૂપ "Ask" પર.
- 1.2 (31 ઑક્ટોબર 2026): કોડની સમીક્ષા પછી પ્રોડક્ટ વિભાગ ફરી લખ્યો, Auto mode લૂપ ઉમેર્યા અને પરિશિષ્ટ સુધાર્યું.
- 1.1 (31 ઑક્ટોબર 2026): Regulation (EU) 2026/1744 માટે EU AI Actની તારીખો અપડેટ કરી; પાછું વાળી શકાવાની વ્યવહારુ કસોટી સાથે ગ્રિડ ફરી બનાવી; વ્યાપ અને સ્રોત સુધારક ઉમેર્યો; સંબંધિત અભ્યાસ, India AI Governance Guidelines અને ચોક્કસ આંકડાકીય મર્યાદાઓ ઉમેરી; ખામીઓ જણાવવા પ્રોડક્ટ વિભાગ ફરી લખ્યો; પરિશિષ્ટ ઉમેર્યું.
- 1.0 (ઑક્ટોબર 2026): પહેલી આવૃત્તિ.