AI ਗਵਰਨੈਂਸ ਫਰੇਮਵਰਕ ਪੜ੍ਹਨ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੁੰਦੇ ਹਨ। ਉਹ ਭੂਮਿਕਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ, ਸਿਧਾਂਤਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਰਿਵਿਊ ਬੋਰਡਾਂ ਦਾ ਨਕਸ਼ਾ ਤਿਆਰ ਕਰਦੇ ਹਨ। ਪਰ ਇੱਕ ਫਰੇਮਵਰਕ ਉਸੇ ਪਲ ਆਪਣੀ ਉਪਯੋਗਤਾ ਗੁਆ ਲੈਂਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਕਰਮਚਾਰੀ ਗਾਹਕਾਂ ਦੇ ਫੀਡਬੈਕ ਨੂੰ ਕਿਸੇ ਪਬਲਿਕ ਚੈਟਬੋਟ ਵਿੱਚ ਪੇਸਟ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਕੋਈ ਬੈਕਐਂਡ API ਚੁੱਪਚਾਪ ਨਿੱਜੀ ਪਛਾਣ ਵਾਲੀ ਜਾਣਕਾਰੀ (personally identifiable information) ਨੂੰ ਕਿਸੇ ਬਾਹਰੀ ਮਾਡਲ ਨੂੰ ਭੇਜ ਦਿੰਦਾ ਹੈ। ਗਵਰਨੈਂਸ ਦਾ ਅਸਲ ਕੰਮ ਕਿਸੇ ਕਮੇਟੀ ਰੂਮ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਐਕਸੈਸ ਪਾਥ (access path) 'ਤੇ ਹੁੰਦਾ ਹੈ। ਇਹ ਉਹ ਸਹੀ ਬਿੰਦੂ ਹੈ ਜਿੱਥੇ ਕੋਈ ਵਿਅਕਤੀ, ਐਪਲੀਕੇਸ਼ਨ, ਜਾਂ API ਐਂਡਪੁਆਇੰਟ ਪਹਿਲੀ ਵਾਰ ਕਿਸੇ AI ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਉੱਥੇ ਆਪਣੇ ਨਿਯਮ ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਗਵਰਨੈਂਸ ਨਹੀਂ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਇੱਛਾ ਸੂਚੀ (wish list) ਹੈ।
ਫਰੇਮਵਰਕ ਅਤੇ ਹਕੀਕਤ ਵਿਚਕਾਰਲੀ ਦੂਰੀ
ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ ਨੇ ਪਿਛਲੇ ਦੋ ਸਾਲ AI ਕੌਂਸਲਾਂ ਬਣਾਉਣ, ਸਵੀਕਾਰਯੋਗ-ਵਰਤੋਂ ਦੀਆਂ ਨੀਤੀਆਂ ਤਿਆਰ ਕਰਨ ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਦੀ ਸਿਖਲਾਈ ਚਲਾਉਣ ਵਿੱਚ ਬਿਤਾਏ ਹਨ। ਇਹ ਕੋਸ਼ਿਸ਼ਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਉਹ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰਦੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ, ਉਹ ਇਹ ਨਹੀਂ ਦੇਖ ਪਾਉਂਦੇ ਕਿ ਮੰਗਲਵਾਰ ਦੁਪਹਿਰ ਦੇ ਕੋਡਿੰਗ ਸੈਸ਼ਨ ਦੌਰਾਨ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਡਿਵੈਲਪਰ ਸਮਾਂ ਬਚਾਉਣ ਲਈ ਕਿਸੇ ਅਣ-ਸੈਂਸਰਡ (uncensored) ਬ੍ਰਾਊਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨ ਰਾਹੀਂ ਪ੍ਰੋਪਰਾਈਟਰੀ ਸੋਰਸ ਕੋਡ ਭੇਜ ਦਿੰਦਾ ਹੈ। ਫਰੇਮਵਰਕ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਕੰਮ ਟਰਮੀਨਲ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ API ਕਾਲਾਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
ਇਸਦਾ ਨਤੀਜਾ ਇੱਕ ਅਨੁਮਾਨਿਤ ਅੰਨ੍ਹੀ ਸਥਿਤੀ (blind spot) ਹੈ। ਲੀਡਰਸ਼ਿਪ ਨੂੰ ਵਿਸ਼ਵਾਸ ਹੁੰਦਾ ਹੈ ਕਿ AI ਦੀ ਵਰਤੋਂ ਨਿਯੰਤਰਿਤ ਹੈ ਕਿਉਂਕਿ ਨੀਤੀ ਅਜਿਹਾ ਕਹਿੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਕਾਰਜ ਪ੍ਰਣਾਲੀ (operations) ਇੱਕ ਵੱਖਰੀ ਕਹਾਣੀ ਦੱਸਦੀ ਹੈ। ਇਹ ਅੰਤਰ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਂਪਟ ਜਿਸ ਵਿੱਚ ਅਣ-ਮਾਸਕ ਕੀਤੇ ਸਿਹਤ ਰਿਕਾਰਡ ਜਾਂ ਅਣ-ਵਿਗਿਆਪਤ ਵਿੱਤੀ ਡੇਟਾ ਹੋਵੇ, ਇੱਕ ਕੰਪਲਾਇੰਸ ਉਲੰਘਣਾ, ਰੈਗੂਲੇਟਰੀ ਜਾਂਚ, ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਜਨਤਕ ਘਟਨਾ ਨੂੰ ਜਨਮ ਦੇ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਵੀ ਮੁਆਫੀ ਯਾਤਰਾ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਦੁਰਵਰਤੋਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਆਡਿਟ ਦੀ ਉਡੀਕ ਕਰਨਾ ਬਹੁਤ ਦੇਰ ਹੋ ਜਾਣਾ ਹੈ। ਅਸਲ ਗਵਰਨੈਂਸ ਲਈ ਸਿਰਫ਼ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ ਦੀ ਨਹੀਂ, ਸਗੋਂ ਆਪਸੀ ਕਿਰਿਆ (interaction) ਵਿੱਚ ਸਪਸ਼ਟਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਐਕਸੈਸ ਪਾਥ (Access Path) ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ
ਐਕਸੈਸ ਪਾਥ ਕੋਈ ਅਮੂਰਤ ਸੰਕਲਪ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਸਹੀ ਪਲ ਹੈ ਜਦੋਂ ਕੋਈ ਰਿਕਵੈਸਟ ਤੁਹਾਡੇ ਵਾਤਾਵਰਣ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦੀ ਹੈ ਅਤੇ ਇੱਕ AI ਮਾਡਲ ਵੱਲ ਜਾਂਦੀ ਹੈ। ਉਹ ਰਿਕਵੈਸਟ ਇੱਕ ਮਾਰਕੀਟਿੰਗ ਮੈਨੇਜਰ ਤੋਂ ਆ ਸਕਦੀ ਹੈ ਜੋ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵੈੱਬ ਇੰਟਰਫੇਸ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ, ਕਰਮਚਾਰੀਆਂ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਇੱਕ Slack ਬੋਟ, ਜਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਦਾ ਸਾਰ ਕੱਢਣ ਲਈ API ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੀ ਇੱਕ ਮਾਈਕਰੋਸਰਵਿਸ ਹੋ ਸਕਦੀ ਹੈ। ਹਰੇਕ ਪਾਥ ਦੇ ਆਪਣੇ ਜੋਖਮ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਹਰੇਕ ਨੂੰ ਆਪਣੇ ਗਾਰਡਰੇਲਜ਼ (guardrails) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇਸ ਕਿਨਾਰੇ 'ਤੇ ਕੰਟਰੋਲ ਪੁਆਇੰਟ ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਡੀ ਸੰਸਥਾ ਕੋਲ ਇੱਕ ਕਰਮਚਾਰੀ ਦੁਆਰਾ ਮਾਡਲ ਨੂੰ ਅੰਦਰੂਨੀ ਈਮੇਲ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਕਹਿਣ ਅਤੇ ਇੱਕ ਕਰਮਚਾਰੀ ਦੁਆਰਾ ਖਾਤਾ ਨੰਬਰਾਂ ਨਾਲ ਭਰਿਆ ਸਪ੍ਰੈਡਸ਼ੀਟ ਅਪਲੋਡ ਕਰਨ ਵਿਚਕਾਰ ਅੰਤਰ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। ਦੋਵੇਂ ਟ੍ਰੈਫਿਕ ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਹੀ ਅੱਗੇ ਵਧਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸ ਸੀਮਾ (boundary) 'ਤੇ ਕਬਜ਼ਾ ਨਹੀਂ ਕਰ ਲੈਂਦੇ, ਹਰ AI ਮਾਡਲ ਜੋ ਤੁਹਾਡੇ ਸਿੱਧੇ ਨਿਯੰਤਰਣ ਤੋਂ ਬਾਹਰ ਹੈ, ਅਸਲ ਵਿੱਚ ਇੱਕ ਹਨੇਰਾ ਗਲਿਆਰਾ ਹੈ ਜਿੱਥੇ ਡੇਟਾ ਬਿਨਾਂ ਕਿਸੇ ਦੇ ਨੋਟਿਸ ਕੀਤੇ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ।
ਨੌਂ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਦੇ ਜਵਾਬ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ
ਕਿਸੇ ਵੀ ਪ੍ਰੋਂਪਟ ਦੇ ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਨੌਂ ਵਿਸ਼ੇਸ਼ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਛਾਣ ਅਤੇ ਇਰਾਦੇ (identity and intent) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਰਿਕਵੈਸਟ ਕੌਣ ਭੇਜ ਰਿਹਾ ਹੈ? ਕਾਰੋਬਾਰੀ ਵਰਤੋਂ ਦਾ ਮਾਮਲਾ (business use case) ਕੀ ਹੈ? ਕਿਹੜਾ ਵਿਭਾਗ ਜਾਂ ਸਿਸਟਮ ਇਸਦਾ ਮਾਲਕ ਹੈ? ਇਹ ਤਿੰਨ ਇਹ ਸਥਾਪਤ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਕਿਰਿਆ ਜਾਇਜ਼ ਅਤੇ ਟ੍ਰੇਸੇਬਲ (traceable) ਹੈ।
ਅਗਲਾ ਕਦਮ ਡੇਟਾ ਅਤੇ ਮਾਡਲ ਦੀ ਸੁਰੱਖਿਆ ਹੈ। ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਕਿਹੜਾ ਡੇਟਾ ਜਾ ਰਿਹਾ ਹੈ? ਕਿਹੜਾ AI ਮਾਡਲ ਇਸ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰੇਗਾ? ਕੀ ਉਹ ਖਾਸ ਮਾਡਲ ਇਸ ਖਾਸ ਕੰਮ ਲਈ ਮਨਜ਼ੂਰ ਹੈ? ਕੀ ਤੁਹਾਨੂੰ ਆਪਣੇ ਵਾਤਾਵਰਣ ਤੋਂ ਬਾਹਰ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਮਾਸਕ ਜਾਂ ਬਲਾਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ?
ਅੰਤ ਵਿੱਚ ਕਾਰਜਸ਼ੀਲ ਜਵਾਬਦੇਹੀ (operational accountability) ਆਉਂਦੀ ਹੈ। ਕੀ ਤੁਸੀਂ ਐਕਸੈਸ ਨੂੰ ਰਿਕਾਰਡ ਕੀਤਾ