ਅੱਜ ਤੁਸੀਂ ਜੋ ਵੀ ਸਾਫਟਵੇਅਰ ਵਰਤਦੇ ਹੋ, ਉਹ ਇੱਕੋ ਇੱਕ ਅਨੁਮਾਨ 'ਤੇ ਬਣਿਆ ਹੋਇਆ ਹੈ। ਕੋਈ ਉਂਗਲਾਂ ਵਾਲਾ ਵਿਅਕਤੀ ਸਕ੍ਰੀਨ ਦੇ ਸਾਹਮਣੇ ਬੈਠਾ ਹੈ। ਬਟਨ ਇਰਾਦੇ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਵਿਜ਼ਾਰਡ (Wizards) ਗੁੰਝਲਦਾਰਤਾ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ। ਫਾਰਮ ਮਨੁੱਖੀ ਵਿਚਾਰਾਂ ਨੂੰ ਇੱਕ ਢਾਂਚਾ ਦਿੰਦੇ ਹਨ। ਇਹ ਆਰਕੀਟੈਕਚਰ ਦਹਾਕਿਆਂ ਤੋਂ ਪ੍ਰੋਡਕਟ ਡਿਜ਼ਾਈਨ ਨੂੰ ਚਲਾ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ ਹਾਲ ਹੀ ਤੱਕ, ਸਿਰਫ਼ ਇਨਸਾਨ ਹੀ ਕਲਿੱਕ ਕਰਦੇ ਸਨ।
ਉਹ ਅਨੁਮਾਨ ਹੁਣ ਟੁੱਟ ਚੁੱਕਾ ਹੈ। AI agents ਇੰਟਰਫੇਸ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹਦੇ। ਉਹਨਾਂ ਨੂੰ ਮਦਦਗਾਰ tooltips ਜਾਂ confirmation dialogs ਤੋਂ ਕੋਈ ਫਾਇਦਾ ਨਹੀਂ ਹੁੰਦਾ। ਜਦੋਂ ਕਿਸੇ ਖੁਦਮੁਖਤਿਆਰ (autonomous) ਸਿਸਟਮ ਨੂੰ ਕਿਸੇ ਯੂਜ਼ਰ ਦੀ ਤਰਫੋਂ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ chrome ਰਸਤੇ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਡਕਟ ਕਿਵੇਂ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਅਤੇ ਆਧੁਨਿਕ callers ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਇਸ ਵਿੱਚ ਇੱਕ ਵਧਦਾ ਹੋ ਰਿਹਾ ਅੰਤਰ ਦੇਖਣ ਨੂੰ ਮਿਲ ਰਿਹਾ ਹੈ।
ਕਲਿੱਕ ਪੈਰਾਡਾਈਮ (The Click Paradigm)
ਰਵਾਇਤੀ ਸਾਫਟਵੇਅਰ ਇੱਕ ਵਿਜ਼ੂਅਲ ਕੰਟਰੈਕਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਇਨਸਾਨ ਬਟਨ ਦੇਖਦਾ ਹੈ, ਲੇਬਲ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ਦਬਾਉਣਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਵਰਕਫਲੋਜ਼ (Workflows) ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਰੁਕਾਵਟਾਂ (friction) ਨਾਲ ਭਰਿਆ ਜਾਂਦਾ ਹੈ। ਮਲਟੀ-ਸਟੈਪ ਵਿਜ਼ਾਰਡ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਲੋਕਾਂ ਤੋਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਆ (guardrails) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Dropdowns ਅਤੇ radio buttons ਇਨਪੁਟ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਖੁੱਲ੍ਹਾ ਟੈਕਸਟ (freeform text) ਅਸ਼ਾਂਤੀ ਨੂੰ ਸੱਦਾ ਦਿੰਦਾ ਹੈ।
ਇਹ ਉਦੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਆਪਰੇਟਰ ਇੱਕ ਵਿਅਕਤੀ ਹੋਵੇ। ਪਰ ਜਦੋਂ ਆਪਰੇਟਰ ਇੱਕ agent ਹੋਵੇ, ਤਾਂ ਇਹ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਿਸੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਰੱਦ ਕਰਨ ਜਾਂ ਰਿਕਾਰਡ ਨੂੰ ਸੋਧਣ ਲਈ ਮਸ਼ੀਨ ਨੂੰ ਪੰਜ-ਸਟੈਪ ਵਿਜ਼ਾਰਡ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਉਸਨੂੰ ਇਸ ਗੱਲ ਦਾ ਸਪੱਸ਼ਟ ਬਿਆਨ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ (operations) ਉਪਲਬਧ ਹਨ ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਉਸਨੂੰ ਉਹਨਾਂ ਨੂੰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਜਦੋਂ ਟੀਮਾਂ ਇਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਸ਼ਾਰਟਕੱਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ।
ਪਹਿਲਾਂ, ਉਹ agent ਨੂੰ ਇੱਕ API key ਦੇ ਦਿੰਦੇ ਹਨ। ਦੂਜਾ, ਉਹ ਮੌਜੂਦਾ user interface ਨੂੰ ਇੱਕ chatbot ਦੇ ਅੰਦਰ ਲਪੇਟ ਦਿੰਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਪੂਰਾ ਹੋਣ ਦਾ ਨਾਮ ਦੇ ਦਿੰਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਤਰੀਕਾ ਅਸਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦਾ।
ਇੱਕ API key ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, “ਕੀ ਇਹ ਬੇਨਤੀ ਕਿਸੇ ਭਰੋਸੇਮੰਦ ਸਰੋਤ ਤੋਂ ਆਈ ਹੈ?” ਇਹ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਕਦੇ ਨਹੀਂ ਦਿੰਦੀ ਜੋ ਮਹੱਤਵਪੂਰਨ ਹੈ: “ਕੀ ਇਹ ਖਾਸ caller ਇਸ ਖਾਸ ਰਿਕਾਰਡ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ?” ਇੱਕ key ਇੱਕ skeleton key ਵਾਂਗ ਹੈ। ਇੱਕ ਵਾਰ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਰੋਤਾਂ ਅਤੇ ਸੰਦਰਭਾਂ (contexts) ਵਿੱਚ ਵਿਆਪਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਇਸਨੂੰ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਵਿਅਕਤੀਗਤ ਕਾਰਵਾਈਆਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਵਾਲੀ ਨੀਤੀ (policy) ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ।
ਇੱਕ GUI ਨੂੰ chatbot ਵਿੱਚ ਲਪੇਟਣਾ ਹੋਰ ਵੀ ਨਾਜ਼ੁਕ ਹੈ। Agent ਉਸ ਹਰ ਮਨੁੱਖ-ਕੇਂਦ੍ਰਿਤ ਅਨੁਮਾਨ ਨੂੰ ਅਪਣਾ ਲੈਂਦਾ ਹੈ ਜੋ ਇੰਟਰਫੇਸ ਵਿੱਚ ਮੌਜੂਦ ਹੈ। ਇਹ modals ਅਤੇ ਫਾਰਮਾਂ ਰਾਹੀਂ ਕਲਿੱਕਾਂ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ ਜੋ ਅੱਖਾਂ (eyeballs) ਲਈ ਬਣਾਏ ਗਏ ਹਨ, ਨਾ ਕਿ autonomous logic ਲਈ। Chatbot ਸ਼ਾਇਦ chrome ਵਿੱਚ ਸਫਲਤਾਪੂਰਵਕ ਨੈਵੀਗੇਟ ਕਰ ਲਵੇ, ਪਰ ਇਹ ਬਿਨਾਂ ਸਮਝੇ ਕਰਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ 'automation theater' (ਆਟੋਮੇਸ਼ਨ ਦਾ ਦਿਖਾਵਾ) ਹੈ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਅਜੇ ਵੀ ਇਸ ਬਾਰੇ ਕੋਈ ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ (machine-readable) ਸਮਝੌਤਾ ਨਹੀਂ ਹੈ ਕਿ ਕਿਸ ਚੀਜ਼ ਦੀ ਇਜਾਜ਼ਤ ਹੈ।
Agents ਨੂੰ ਮੇਨ ਡੋਰ ਦੀ ਇੱਕ ਹੋਰ ਚਾਬੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਉਹਨਾਂ ਨੂੰ gates ਦੀ ਲੋੜ ਹੈ।
Gates ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ
ਇੱਕ gate ਇੱਕ ਨਿਯੰਤਰਿਤ execution layer ਹੈ। ਕਿਸੇ credential 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਅਤੇ ਇਹ ਉਮੀਦ ਕਰਨ ਦੀ ਬਜਾਏ ਕਿ caller ਸਹੀ ਵਿਵਹਾਰ ਕਰੇਗਾ, gates ਵਾਲਾ ਸਿਸਟਮ ਹਰ ਬੇਨਤੀ ਦਾ ਘੋਸ਼ਿਤ ਨਿਯਮਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ। ਇਹ ਨਿਯਮ ਕਿਸੇ ਵੀ ਇੰਟਰਫੇਸ, ਮਨੁੱਖੀ ਜਾਂ ਹੋਰ, ਤੋਂ ਸੁਤੰਤਰ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਸਹੀ gate ਚਾਰ ਚੀਜ਼ਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਘੋਸ਼ਣਾ ਕਰਦਾ ਹੈ ਕਿ ਪ੍ਰੋਡਕਟ ਦੇ ਅੰਦਰ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਮੌਜੂਦ ਹਨ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੌਣ ਅਤੇ ਕਿਹੜੀਆਂ ਸ਼ਰਤਾਂ ਦੇ ਅਧੀਨ ਉਹਨਾਂ ਨੂੰ ਚਲਾ ਸਕਦਾ ਹੈ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਦੋਂ ਇੱਕ caller ਨੂੰ side effects ਪੈਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਪੱਸ਼ਟ ਸਹਿਮਤੀ ਦੀ ਮੰਗ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਹਰ ਫੈਸਲੇ ਨੂੰ ਇੱਕ ਸੰਰਚਿਤ, queryable ਟ੍ਰੇਲ ਵਿੱਚ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ।
ਇਹ ਰਵਾਇਤੀ access control ਤੋਂ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਹੈ। Role-based ਸਿਸਟਮ ਅਕਸਰ ਦਰਵਾਜ਼ੇ 'ਤੇ ਪੁੱਛਦੇ ਹਨ, “ਕੀ ਤੁਸੀਂ ਇੱਕ admin ਹੋ?” ਅਤੇ ਫਿਰ ਤੁਹਾਨੂੰ ਇਮਾਰਤ ਵਿੱਚ ਘੁੰਮਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਦਿੰਦੇ ਹਨ। Gates ਹਰ ਮੋੜ 'ਤੇ ਪੁੱਛਦੇ ਹਨ, “ਕੀ ਤੁਹਾਨੂੰ ਇਸ ਸਮੇਂ ਇਹ ਖਾਸ ਸਵਿੱਚ ਫਲਿੱਪ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ?” ਪਛਾਣ (Identity) ਵਿਵਹਾਰ ਦੇ ਅੱਗੇ ਦੂਜੇ ਨੰਬਰ 'ਤੇ ਆ ਜਾਂਦੀ ਹੈ। ਨੀਤੀ (Policy) ਕਾਰਵਾਈ ਦੇ ਨਾਲ ਚੱਲਦੀ ਹੈ।
ਇਸ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ, ਇੱਕ
ਕਿਸੇ ਵੀ ਕਾਲਰ (caller) ਨੇ ਮਾਸਟਰ API key ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ। ਕੋਈ ਬੈਕਡੋਰ ਨਹੀਂ ਸੀ, ਕੋਈ ਉੱਚੇ ਅਧਿਕਾਰ (elevated credential) ਨਹੀਂ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ ਪਾਲਿਸੀ ਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ ਹੋਵੇ। ਇਨਸਾਨ ਨੂੰ ਘੱਟ ਰੋਕ-ਟੋਕ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਨਾ ਪਿਆ ਕਿਉਂਕਿ ਉਸ ਕੋਲ ਪਾਸਵਰਡ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਸੀ। ਏਜੰਟ ਨੂੰ ਮਨਮਾਨਾ ਬਲਾਕ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਕਿਉਂਕਿ ਉਸ ਕੋਲ ਇਨਸਾਨੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਨਹੀਂ ਸੀ। ਗੇਟ ਨੇ ਕਾਰਵਾਈ, ਸੰਦਰਭ (context) ਅਤੇ ਨਿਯਮਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ। ਇਹ ਪੂਰੀ ਲੈਣ-ਦੇਣ ਸੀ।
ਨਤੀਜਾ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਸੀ ਜਿੱਥੇ ਇੱਕ ਨਵੇਂ ਕਾਲਰ, ਚਾਹੇ ਉਹ ਇਨਸਾਨ ਹੋਵੇ ਜਾਂ ਮਸ਼ੀਨ, ਨੂੰ ਜੋੜਨ ਲਈ ਐਕਸੈਸ ਲੌਜਿਕ (access logic) ਦੇ ਰੀਫੈਕਟਰੀੰਗ (refactoring) ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਤੁਸੀਂ ਪਾਲਿਸੀ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ। ਗੇਟ ਨੇ ਇਸ ਨੂੰ ਲਾਗੂ ਕੀਤਾ।
ਪ੍ਰੋਡਕਟ ਦੇ ਸਵਾਲ ਬਾਰੇ ਮੁੜ ਵਿਚਾਰ ਕਰਨਾ
ਜੇਕਰ ਤੁਹਾਡੀ ਟੀਮ ਇਸ ਸਮੇਂ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ ਕਿ ਇਨਸਾਨਾਂ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਪ੍ਰੋਡਕਟ ਵਿੱਚ AI agents ਨੂੰ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਵੇ, ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਗਲਤ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰ ਰਹੇ ਹੋ। ਟੀਮਾਂ ਅੰਤਰ-ਆਤਮਾ ਨਾਲ ਇਹ ਪੁੱਛਦੀਆਂ ਹਨ ਕਿ ਕੀ ਉਨ੍ਹਾਂ ਨੂੰ API ਐਕਸਪੋਜ਼ (expose) ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ ਉਨ੍ਹਾਂ ਨੂੰ ਇਹ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਉਨ੍ਹਾਂ ਕੋਲ ਹਰ ਕਾਲਰ ਲਈ ਇੱਕ ਗਵਰਨਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲੇਅਰ (governed execution layer) ਹੈ।
ਗੇਟ ਤੋਂ ਬਿਨਾਂ ਇੱਕ API ਸਿਰਫ਼ ਇੱਕ ਚੌੜਾ ਦਰਵਾਜ਼ਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀਆਂ ਅੰਦਰੂਨੀ ਪਾਲਿਸੀਆਂ ਸਿਰਫ਼ ਵਿਜ਼ਰਡ ਲੌਜਿਕ (wizard logic), ਫਾਰਮ ਵੈਲੀਡੇਸ਼ਨ (form validation), ਅਤੇ ਇਨਸਾਨਾਂ ਦੁਆਰਾ ਪੜ੍ਹਨਯੋਗ ਮਦਦਗਾਰ ਟੈਕਸਟ ਦੇ ਅੰਦਰ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕੋਈ ਵੀ ਐਂਡਪੁਆਇੰਟ (endpoint) ਖੁਦਮੁਖਤਿਆਰ ਕਾਲਰਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੋਵੇਗਾ। ਏਜੰਟ ਜਾਂ ਤਾਂ ਕਿਸੇ ਕੀ (key) ਰਾਹੀਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਭਰੋਸਾ ਪ੍ਰਾਪਤ ਕਰ ਲਵੇਗਾ ਜਾਂ ਚੈਟਬੋਟ ਵੈਪਰ (chatbot wrapper) ਰਾਹੀਂ ਕਮਜ਼ੋਰ ਪੁਤਲੀ ਨੱਚਣ ਵਰਗਾ ਕੰਮ ਕਰੇਗਾ।
ਪਹਿਲਾਂ ਗੇਟ ਬਣਾਉਣ ਦਾ ਮਤਲਬ ਹੈ ਆਪਣੇ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਹਰ ਅਰਥਪੂਰਨ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਘੋਸ਼ਿਤ ਆਪਰੇਸ਼ਨ (declared operation) ਵਜੋਂ ਸੂਚੀਬੱਧ ਕਰਨਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਪਰਮਿਸ਼ਨ ਚੈੱਕ ਨੂੰ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਤੋਂ ਵੱਖ ਕਰਨਾ ਤਾਂ ਜੋ ਇੱਕ Shell ਯੂਜ਼ਰ ਅਤੇ ਇੱਕ ਬਾਹਰੀ ਏਜੰਟ ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੇ ਰਨਟਾਈਮ ਇਨਫੋਰਸਮੈਂਟ (runtime enforcement) ਦਾ ਸਾਹਮਣਾ ਕਰਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਲਈ ਸਹਿਮਤੀ ਹੁੱਕ (consent hooks) ਨੂੰ ਲੋੜ ਪੈਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਜੋੜਨਾ, ਨਾ ਕਿ ਉਦੋਂ ਜਦੋਂ ਕੋਈ ਏਜੰਟ ਗਲਤ ਡੇਟਾਸੈੱਟ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਅਜਿਹੇ ਆਡਿਟ ਟ੍ਰੇਲ (audit trails) ਤਿਆਰ ਕਰਨਾ ਜਿਨ੍ਹਾਂ ਦੀ ਸੁਰੱਖਿਆ ਅਤੇ ਕੰਪਲਾਇੰਸ ਟੀਮਾਂ ਇਹ ਜਾਣੇ ਬਿਨਾਂ ਜਾਂਚ ਕਰ ਸਕਣ ਕਿ ਕਾਲਰ ਕਾਰਬਨ (ਇਨਸਾਨ) ਸੀ ਜਾਂ ਸਿਲੀਕਾਨ (ਮਸ਼ੀਨ)।
ਇਸ ਲਈ ਇੱਕ ਅਸਲ ਆਰਕੀਟੈਕਚਰਲ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਹੈ। ਮਨੁੱਖ-ਕੇਂਦ੍ਰਿਤ ਡਿਜ਼ਾਈਨ (Human-centric design) ਲੌਜਿਕ ਨੂੰ ਹਮਦਰਦੀ ਅਤੇ ਰੁਕਾਵਟਾਂ ਵਿੱਚ ਲਪੇਟਦਾ ਹੈ। ਏਜੰਟ-ਤਿਆਰ ਡਿਜ਼ਾਈਨ (Agent-ready design) ਸਪਸ਼ਟ, ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ ਇਕਰਾਰਨਾਮਿਆਂ (contracts) ਰਾਹੀਂ ਲੌਜਿਕ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ। ਇੰਟਰਫੇਸ ਪਾਲਿਸੀ ਬਣਨਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਮੈਨੀਫੈਸਟ (manifest) ਹੀ ਪਾਲਿਸੀ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇਹ ਤਬਦੀਲੀ ਇਨਸਾਨਾਂ ਨੂੰ ਬਦਲਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਇਹ ਮਾਨਣ ਬਾਰੇ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਾਫਟਵੇਅਰ ਕੋਲ ਹੁਣ ਇੱਕ ਤੋਂ ਵੱਧ ਕਿਸਮ ਦੇ ਕਾਲਰ ਹਨ। ਹਰ ਇੱਕ ਇੱਕੋ ਜਿਹੀ ਸਖ਼ਤੀ ਦਾ ਹੱਕਦਾਰ ਹੈ।
ਅਸਲ ਸਿੱਖਿਆ
ਕਲਿੱਕ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਨਿਯਮ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡਾ ਸਿਸਟਮ ਘੋਸ਼ਿਤ ਕਾਰਵਾਈਆਂ, ਸੰਦਰਭਿਕ ਇਜਾਜ਼ਤਾਂ (contextual permissions), ਸਹਿਮਤੀ ਚੈੱਕ, ਅਤੇ ਸਾਂਝੇ ਆਡਿਟ ਟ੍ਰੇਲ ਰਾਹੀਂ ਹਰ ਕਾਲਰ ਨੂੰ ਕੰਟਰੋਲ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਦੂਜੇ ਪਾਸੇ ਕੌਣ ਜਾਂ ਕੀ ਹੈ। ਇਨਸਾਨ ਹੋਵੇ ਜਾਂ ਏਜੰਟ, ਉਹ ਸਾਰੇ ਇੱਕੋ ਗੇਟ 'ਤੇ ਆਉਂਦੇ ਹਨ। ਪਹਿਲਾਂ ਗੇਟ ਬਣਾਓ। API ਸਿਰਫ਼ ਇੱਕ ਦਰਵਾਜ਼ਾ ਹੈ। ਪਾਲਿਸੀ ਹੀ ਉਹ ਹੈ ਜੋ ਕਮਰੇ ਨੂੰ ਸਹੀ ਸਥਿਤੀ ਵਿੱਚ ਰੱਖਦੀ ਹੈ।