ਇੱਕ ਸਾਫ਼ ਦਰਸ਼: Satya Nadella ਨੇ Microsoft ਨੂੰ ਕਿਵੇਂ AI ਪਲੇਟਫਾਰਮ ਨੇਤਾ ਬਣਾਇਆ—ਕਲਾਉਡ-ਪਹਿਲਾਂ ਦਾਅ, OpenAI ਸਾਂਝ, Copilot, ਅਤੇ ਡਿਵੈਲਪਰ ਕੇਂਦਰਿਤ ਰਣਨੀਤੀ।

Microsoft ਨੇ ਕਿਸੇ ਇਕ ਮਾਡਲ ਜਾਂ ਚਮਕਦਾਰ ਡੈਮੋ ਨਾਲ "AI ਨਹੀਂ ਜੀਤਿਆ"। ਇਸ ਨੇ ਕੁਝ ਹੋਰ ਪੱਕਾ ਬਣਾਇਆ: ਇੱਕ ਐਸਾ AI ਪਲੇਟਫਾਰਮ ਜਿਸ 'ਤੇ ਹੋਰ ਕੰਪਨੀਆਂ ਤਿਆਰ ਕਰਦੀਆਂ ਹਨ, ਖਰੀਦਦੀਆਂ ਹਨ ਅਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀਆਂ ਹਨ। ਪਲੇਟਫਾਰਮ ਦੀ ਇਹ ਪੋਜ਼ੀਸ਼ਨ — ਕਿਸੇ ਇਕ ਉਤਪਾਦ ਨਾਲੋਂ ਵੱਧ — ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ ਕਿ Microsoft ਉਦਯੋਗੀ AI ਵਿੱਚ ਕੇਂਦਰੀ ਭਾਗੀਦਾਰ ਕਿਵੇਂ ਬਣਿਆ।
AI ਪਲੇਟਫਾਰਮ ਉਹ ਪੂਰਾ ਸਟੈਕ ਹੈ ਜੋ AI ਨੂੰ ਖੋਜ ਤੋਂ ਹਰ-ਰੋਜ਼ ਦੀ ਕੰਮਕਾਰਤਾ ਵਿੱਚ ਬਦਲਦਾ ਹੈ:
"ਯੁੱਧ" ਇਹ ਮੁਕਾਬਲਾ ਹੈ ਕਿ ਕਿਹੜੀ ਜਗ੍ਹਾ ਡਿਫਾਲਟ ਬਣੇਗੀ ਜਿੱਥੇ ਸੰਗਠਨ AI ਚਲਾਉਂਦੇ ਹਨ—ਇਸ ਨੂੰ ਪਹਿਲਾਂ ਦੇ ਪਲੇਟਫਾਰਮ-ਸ਼ਿਫਟਾਂ ਜਿਵੇਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਬ੍ਰਾਊਜ਼ਰ, ਮੋਬਾਈਲ ਅਤੇ ਕਲਾਉਡ ਨਾਲ ਤੁਲਨਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਤੁਸੀਂ ਦੇਖੋਗੇ Microsoft ਦੀ ਉਠਾਨ ਦੇ ਪਿੱਛੇ ਰਣਨੀਤੀ: ਕਿਵੇਂ ਕਲਾਉਡ ਬੁਨਿਆਦ ਬਣਿਆ, ਕਿਉਂ ਡਿਵੈਲਪਰ ਅਤੇ ਖੁੱਲ੍ਹਾ ਸਰੋਤ ਮਹੱਤਵਪੂਰਨ ਰਹੇ, OpenAI ਸਾਂਝ ਨੇ ਟਾਈਮਲਾਈਨ ਨੂੰ ਕਿਵੇਂ ਬਦਲਿਆ, Copilot ਕਿਵੇਂ ਇੱਕ ਵੰਡ ਇੰਜਣ ਬਣਿਆ, ਅਤੇ ਸਾਰੇ ਹੇਠਾਂ ਕਿਹੜੇ ਖਤਰੇ ਅਤੇ ਵਪਾਰ-ਅਦਾਨ-ਪ੍ਰਦਾਨ ਮੌਜੂਦ ਹਨ।
Satya Nadella ਤੋਂ ਪਹਿਲਾਂ, Microsoft ਨੂੰ ਅਕਸਰ Windows-ਪਹਿਲਾਂ ਕਹਿਆ ਜਾਂਦਾ ਸੀ। ਕੰਪਨੀ ਵੱਡੇ ਉਤਪਾਦ ਛੱਡਦੀ ਸੀ, ਪਰ ਕੇਂਦਰ ਸੋਚ PC ਉੱਪਰ ਸੀ: Windows ਦੀ ਰੱਖਿਆ, Office ਦੀ ਰੱਖਿਆ ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਸਹਾਇਕ ਸਮਝਿਆ ਜਾਂਦਾ ਸੀ। ਕਲਾਉਡ ਮੌਜੂਦ ਸੀ, ਪਰ ਲਹਿਰ ਇਕਸਾਰ ਨਹੀਂ ਲੱਗਦੀ ਸੀ ਅਤੇ ਅੰਦਰੂਨੀ ਪ੍ਰੇਰਨਾ ਲੰਬੇ ਸਮੇਂ ਵਾਲੀਆਂ ਪਲੇਟਫਾਰਮ ਸ਼ਰਤਾਂ ਨੂੰ ਹਮੇਸ਼ਾਂ ਬਹਾਲ ਨਹੀਂ ਕਰਦੀ ਸੀ।
ਨਾਡੇਲਾ ਦਾ ਪਿਛੋਕੜ ਇਸ ਰਵੈਏ ਨੂੰ ਥੱਲੇ ਕਰਦਾ ਸੀ। ਉਹ Microsoft ਦੇ ਸਰਵਰ ਅਤੇ ਉਦਯੋਗੀ ਪਾਸੇ ਤੋਂ ਉੱਠੇ, ਜਿੱਥੇ ਗਾਹਕ ਓਪਰੇਟਿੰਗ-ਸਿਸਟਮ ਦੀ ਰਾਜਨੀਤੀ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਉਪਟਾਈਮ, ਸਕੇਲ ਅਤੇ ਜਟਿਲਤਾ ਘਟਾਉਣ ਦੀ ਚਿੰਤਾ ਕਰਦੇ ਹਨ। ਇਹ ਤਜਰਬਾ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਕਲਾਉਡ-ਪਹਿਲਾਂ ਦ੍ਰਿਸ਼ਟੀ ਨੂੰ ਸੰਕੇਤ ਕਰਦਾ ਹੈ: ਇਕ ਉਹ ਬੁਨਿਆਦ ਬਣਾਓ ਜਿਸ 'ਤੇ ਲੋਕ ਭਰੋਸਾ ਕਰ ਸਕਣ, ਫਿਰ ਉਸ ਉੱਪਰ ਵੱਖ-ਵੱਖ ਅਨੁਭਵ ਖੜੇ ਹੋ ਸਕਣ।
ਨਾਡੇਲਾ ਨੇ ਸਿਰਫ਼ ਨਵੀਂ ਰਣਨੀਤੀ ਐਲਾਨ ਨਹੀਂ ਕੀਤੀ; ਉਸ ਨੇ ਕੰਪਨੀ ਲਈ ਨਵਾਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਧੱਕਿਆ।
"ਗ੍ਰੋਥ ਮਾਈਂਡਸੈਟ" ਇਕ ਨਾਰੇ ਤੋਂ ਵੱਧ ਬਣ ਗਿਆ। ਇਸ ਨੇ ਟੀਮਾਂ ਨੂੰ ਇਹ ਆਜ਼ਾਦੀ ਦਿੱਤੀ ਕਿ ਜੋ ਚੀਜ਼ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੀ, ਉਹ ਮਨਜ਼ੂਰ ਕੀਤੀ ਜਾਵੇ, ਜਨਤਕ ਤੌਰ 'ਤੇ ਸਿੱਖਿਆ ਜਾਵੇ ਅਤੇ ਦੋਹਰਾਉਂਦੇ ਸਮੇਂ ਵਿਚ ਬਹਿਸਾਂ ਨੂੰ ਜ਼ੀਰੋ-ਸਮ ਲੜਾਈ ਨਾ ਬਣਾਇਆ ਜਾਵੇ।
ਗਾਹਕ-ਕੇਂਦਰਤਾ ਉੱਤਰ-ਤਾਰਾ ਬਣੀ। ਸਵਾਲ ਹੁਣ "ਇਹ Windows ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ?" ਦੀ ਥਾਂ "ਗਾਹਕਾਂ ਨੂੰ ਆਧੁਨਿਕ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਅਤੇ ਚਲਾਉਣ ਲਈ ਕੀ ਚਾਹੀਦਾ ਹੈ?" ਹੋ ਗਿਆ। ਇਹ ਪਰਿਵਰਤਨ ਅੰਦਰੂਨੀ ਦਲੀਲਾਂ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਵਿਰਾਸਤੀ ਸਥਿਤੀ ਨਹੀਂ, ਪਰ ਉਪਯੋਗਿਤਾ ਜਿੱਤਦੀ ਹੈ।
ਸਿੱਖਣ-ਧਾਰ਼ਨਾ ਵਾਲਾ ਸੱਭਿਆਚਾਰ ਸਾਂਝਾਂ ਅਤੇ ਪਿਵਟਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਇਕ ਕੰਪਨੀ ਸੋਚਦੀ ਹੈ ਕਿ ਉਸਨੂੰ ਹਰ ਚੀਜ਼ ਖੁਦ ਹੀ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਉਹ ਹੌਲੀ ਚੱਲਦੀ ਹੈ। ਜਦੋਂ ਉਹ ਦੂਜਿਆਂ ਤੋਂ ਸਿੱਖਣ ਅਤੇ ਉਸ ਸਿੱਖੇ ਨੂੰ ਉਤਪਾਦ ਵਿੱਚ ਜੋੜਨ ਵਿੱਚ ਆਰਾਮਦਾਇਕ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਹ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧ ਸਕਦੀ ਹੈ।
ਇਹ ਸੱਭਿਆਚਾਰਕ ਰੀਸੈਟ Microsoft ਦੀਆਂ ਆਉਣ ਵਾਲੀਆਂ AI ਚਲਾਂ ਲਈ ਮੰਚ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਪਲੇਟਫਾਰਮ ਬਣਾਉਣਾ ਸਿਰਫ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੱਸਿਆ ਨਹੀਂ; ਇਹ ਇਕ ਸਹਿਮਤੀ ਦੀ ਸਮੱਸਿਆ ਵੀ ਹੈ। ਕਲਾਉਡ-ਪਹਿਲਾਂ ਢਾਂਚੇ ਨੇ ਉਤਪਾਦ ਲਾਈਨਾਂ ਵਿੱਚ ਟੀਮਾਂ ਨੂੰ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ, ਰੋਜ਼ਾਨਾ-ਲਾਭਾਂ ਦੇ ਬਦਲੇ ਛੋਟੇ ਸਮੇਂ ਦੇ ਸਹੂਲਤਾਂ ਪੈਣ ਅਤੇ ਲਗਾਤਾਰ ਬਿਹਤਰੀਆਂ ਭੇਜਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ।
ਉਹ ਖਾਸ ਗੱਲ ਇਹ ਸੀ ਕਿ ਨਿਰਮਾਤਾ-ਮਿੱਤਰ ਭਾਵ ਨੇ ਸਾਂਝਾਂ ਨੂੰ ਜੋੜਨ ਨੂੰ ਧਮਕੀ ਨਹੀਂ ਸਮਝਾਇਆ, ਜਿਸ ਨਾਲ ਤੇਜ਼ ਉਤਪਾਦ ਫੈਸਲੇ, ਜਲਦੀ ਮਾਰਕੀਟ ਵਿੱਚ ਜਾਣ ਦੀ ਕਾਬਲੀਅਤ ਅਤੇ ਵੱਡੇ ਦਾਅਵਾਂ ਲਗਾਉਣ ਦੀ ਹਿੰਮਤ ਆਈ—ਬਿਲਕੁਲ ਉਹੀ ਯਾਦਾਸ਼ਤ ਜਿਸ ਦੀ ਲੋੜ Microsoft ਨੂੰ ਜਦੋਂ ਜਨਰੇਟਿਵ AI ਤੇਜ਼ ਹੋਇਆ।
AI ਪਲੇਟਫਾਰਮ ਸਿਰਫ਼ ਮਾਡਲ ਗੁਣਵੱਤਾ 'ਤੇ ਨਹੀਂ ਜਿੱਤਦੇ। ਉਹ ਇਹ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ ਟੀਮਾਂ ਉਹਨਾਂ ਮਾਡਲਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਲਾਗਤ-ਅਨੁਕੂਲ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ ਕਲਾਉਡ ਸਕੇਲ ਹਰ "AI ਬ੍ਰੇਕਥਰੂ" ਦੇ ਥੱਲੇ ਰਹਿਣ ਵਾਲੀ ਬਿਨਾਂ-ਚਮਕ ਵਾਲੀ ਬੁਨਿਆਦ ਹੈ: ਟ੍ਰੇਨਿੰਗ, ਫਾਈਨ-ਟਿਊਨਿੰਗ, ਰੀਟਰੀਵਲ, ਨਿਗਰਾਨੀ ਅਤੇ ਸੁਰੱਖਿਆ—ਸਭ ਕੁਝ ਐਸੇ ਕੰਪੋਨੈਂਟਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਜ਼ਰੂਰਤ ਮੁਤਾਬਕ ਵਧ ਸਕਦੇ ਹਨ।
Microsoft ਦੀ ਰਣਨੀਤੀ ਇਹ ਸੀ ਕਿ Azure ਉਹ ਥਾਂ ਬਣੇ ਜਿੱਥੇ ਉਦਯੋਗ AI ਨੂੰ ਕਾਰਗਰ ਰੂਪ ਵਿੱਚ ਚਲਾ ਸਕਣ—ਸਿਰਫ਼ ਪ੍ਰਯੋਗ ਹੀ ਨਹੀਂ। ਇਸ ਦਾ ਮਤਲਬ ਉਹ ਗੁਣਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨਾ ਸੀ ਜੋ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਨੋਟ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਨਵੀਂ ਚੀਜ਼ ਦੀ ਚਮਕ ਮਿਟ ਜਾਂਦੀ ਹੈ:
ਅਮਲ ਵਿੱਚ, ਇਹ "AI ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ" ਨਹੀਂ ਹਨ, ਪਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਕੋਈ AI ਪਾਇਲਟ ਹਜ਼ਾਰਾਂ ਕਰਮਚਾਰੀਆਂ ਵੱਲੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੀ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਬਣੇਗਾ ਜਾਂ ਨਹੀਂ।
Azure ਨੇ ਦੋ ਪ੍ਰਜਵਲਿਤ ਲਾਭਾਂ ਦੇ ਆਸ-ਪਾਸ ਆਪਣੀ ਪੋਜ਼ੀਸ਼ਨ ਬਣਾਈ:
ਪਹਿਲਾਂ, ਹਾਈਬ੍ਰਿਡ ਅਤੇ ਬਹੁ-ਵਾਤਾਵਰਣ ਚਲਾਉਣਾ: ਕਈ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਹਰੇਕ ਚੀਜ਼ ਨੂੰ ਇੱਕ ਪਬਲਿਕ ਕਲਾਉਡ 'ਤੇ ਤੁਰੰਤ ਨਹੀਂ ਲਿਜਾ ਸਕਦੀਆਂ। ਆਨ-ਪ੍ਰੇਮ ਅਤੇ ਕਲਾਉਡ ਪਰਿਵਾਰਾਂ 'ਚ ਵਰਕਲੋਡ ਚਲਾਉਣ ਦੇ ਯੋਗ ਤਰੀਕੇ অফਰ ਕਰਨਾ AI ਅਪਣਾਉਣ ਲਈ ਰੁਕਾਵਟ ਘਟਾਉਂਦਾ ਹੈ।
ਦੂਜਾ, ਉਦਯੋਗੀ ਸਬੰਧ ਅਤੇ ਪ੍ਰੋਕਯੂਰਮੈਂਟ ਦੀ ਸਮਰੱਥਾ: Microsoft ਪਹਿਲਾਂ ਹੀ IT ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਡੂੰਘੀ ਪਹੁੰਚ ਰੱਖਦਾ ਸੀ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ AI ਪਲੇਟਫਾਰਮ ਦੇ ਫੈਸਲੇ ਅਕਸਰ ਸੁਰੱਖਿਆ ਟੀਮਾਂ, ਆਰਕਿਟੈਕਚਰ ਬੋਰਡਾਂ ਅਤੇ ਵੇਂਡਰ ਮੈਨੇਜਮੈਂਟ ਰਾਹੀਂ ਹੁੰਦੇ ਹਨ—ਕੇਵਲ ਡਿਵੈਲਪਰਾਂ ਰਾਹੀਂ ਨਹੀਂ।
ਇਸ ਨਾਲ ਇਹ ਪੱਕਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ Microsoft ਹੋਰਾਂ 'ਤੇ ਊਂਝ ਉਤਕ੍ਰਿਸ਼ਟ ਹੈ, ਪਰ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਉਂ Azure ਨੂੰ ਬੇਸ ਲੇਅਰ ਵਜੋਂ ਰਖਿਆ ਗਿਆ: ਜੇ ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਭਰੋਸੇਯੋਗ, ਸਕੇਲਯੋਗ ਅਤੇ ਗਵਰਨੇਬਲ ਹੈ, ਤਾਂ ਉਸ ਉੱਪਰ ਬਣਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ—ਮਾਡਲ, ਟੂਲਿੰਗ ਅਤੇ copilots—ਡੈਮੋ ਤੋਂ ਤੈਨਾਤ ਤਕ ਸਾਫ਼ ਰਸਤਾ ਪਾਉਂਦੀਆਂ ਹਨ।
Microsoft ਦੀ ਏਆਈ ਪਲੇਟਫਾਰਮ ਕਹਾਣੀ ਕੇਵਲ ਮਾਡਲਾਂ ਅਤੇ ਚਿਪਾਂ ਬਾਰੇ ਨਹੀਂ। ਇਹ ਉਸ ਲੋੜੇ ਵਿਚਕਾਰ ਭਰੋਸਾ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਬਾਰੇ ਵੀ ਹੈ ਜੋ ਹਰ ਰੋਜ਼ ਪਲੇਟਫਾਰਮ ਚੁਣਦੇ ਹਨ: ਡਿਵੈਲਪਰ। Satya Nadella ਦੇ ਅਧੀਨ, Microsoft ਨੇ ਖੁੱਲ੍ਹਾ ਸਰੋਤ ਨੂੰ "ਬਾਹਰ" ਨਹੀਂ ਸਮਝਿਆ, ਬਲਕਿ ਆਧੁਨਿਕ ਸਫ਼ਟਵੇਅਰ ਦੀ ਡਿਫਾਲਟ ਹਕੀਕਤ ਵਜੋਂ ਲਿਆ।
ਬਦਲਾਅ ਪ੍ਰાયੋਗਿਕ ਸੀ। ਕਲਾਉਡ ਅਪਣਾਉਣ ਬਹੁਤ ਵੱਧ ਰਿਹਾ ਸੀ, ਅਤੇ ਅਸਲ-ਦੁਨੀਆ ਦਰਜੇ ਦੇ ਵੱਡੇ ਹਿੱਸੇ Linux ਅਤੇ ਪ੍ਰਸਿੱਧ open-source ਸਟੈਕਾਂ 'ਤੇ ਚੱਲ ਰਹੇ ਸਨ। ਜੇ Azure ਇਹ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਉਹਨਾਂ ਵਰਕਲੋਡਾਂ ਦੀ ਜਗ੍ਹਾ ਬਣੇ, ਤਾਂ Azure ਨੂੰ ਉਨ੍ਹਾਂ ਟੀਮਾਂ ਲਈ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਪਇਆ।
"ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਥੇ ਮਿਲੋ ਜਿੱਥੇ ਉਹ ਹਨ" ਵਾਲੀ ਸੋਚ ਇੱਕ ਵਿਕਾਸ ਰਣਨੀਤੀ ਸੀ: ਜਿੰਨਾ ਆਸਾਨ ਤੁਹਾਡੀ ਪਲੇਟਫਾਰਮ 'ਤੇ ਮੌਜੂਦਾ ਟੂਲ, ਭਾਸ਼ਾ ਅਤੇ ਤੈਨਾਤੀ ਧਾਰਾਂ ਲਿਆਉਣਾ ਹੁੰਦਾ, ਉਨਾ ਹੀ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਕਿ ਟੀਮਅਗਲੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਉਸ 'ਤੇ ਅਦਾਲਤ ਕਰਨਗੀਆਂ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਉਹ ਅਗਲਾ ਪ੍ਰੋਜੈਕਟ AI ਜੁੜਿਆ ਹੋਵੇ।
ਦੋ ਚਲ-ਕਦਮਾਂ ਨੇ ਬਦਲਾਵ ਨੂੰ ਦਰਸ਼ਯੋਗ ਕੀਤਾ:
ਅਤੇ ਫਿਰ Linux on Azure—ਇੱਕ ਸਧਾਰਨ ਸੁਨੇਹਾ ਜਿਸ ਦੇ ਵੱਡੇ ਅਰਥ ਹਨ: ਤੁਹਾਨੂੰ Microsoft ਦੇ ਕਲਾਉਡ ਨੂੰ ਵਰਤਣ ਲਈ ਆਪਣਾ ਸਟੈਕ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਣਾ ਪੈਂਦਾ। ਆਪਣੇ ਕੰਟੇਨਰ, Kubernetes ਆਦਤਾਂ, CI/CD ਪਾਈਪਲਾਈਨ ਲਿਆਓ ਅਤੇ ਬਿਨਾਂ ਸਭਿਆਚਾਰਕ ਲੜਾਈ ਦੇ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰੋ।
ਸਮਾਂ ਦੇ ਨਾਲ, Microsoft ਦਾ ਬ੍ਰਾਂਡ "ਵੇਂਡਰ ਲਾਕ-ਇਨ ਖਤਰਾ" ਤੋਂ "ਭਰੋਸੇਯੋਗ ਪਲੇਟਫਾਰਮ ਪਾਰਟਨਰ" ਵਿੱਚ ਬਦਲਿਆ। ਇਹ ਭਰੋਸਾ AI ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਜਿੱਥੇ ਟੀਮਾਂ ਨੂੰ ਲਚੀਲਾਪਨ (ਖੁੱਲ੍ਹੇ ਮਾਡਲ, ਖੁੱਲ੍ਹੀ ਟੂਲਿੰਗ, ਪੋਰਟੇਬਲ ਸਕਿਲ) ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਵਾਲਾ ਸਹਿਯੋਗ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਡਿਵੈਲਪਰ ਯਕੀਨ ਕਰਦੇ ਹਨ ਕਿ ਇੱਕ ਪਲੇਟਫਾਰਮ ਉਹਨਾਂ ਦੀ ਹਕੀਕਤ ਨੂੰ ਅਨੁਕੂਲ ਕਰੇਗਾ—not ਬਦਲ ਦੇਵੇ—ਉਹ ਲੰਬੇ ਸਮੇਂ ਲਈ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਗੇ।
Microsoft ਦੀ OpenAI ਨਾਲ ਸਾਂਝ ਕੇਵਲ ਸਿਰਫ਼ ਇੱਕ ਸਿਰਲੇਖੀ ਨਿਵੇਸ਼ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਰਣਨੀਤਿਕ ਸ਼ਾਰਟਕਟ ਸੀ ਜਿਸ ਨਾਲ AI ਪਲੇਟਫਾਰਮ ਖੇਡ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ ਗਿਆ। ਸਾਲਾਂ ਤੱਕ frontier ਮਾਡਲ ਖੁਦ ਬਣਾਉਣ ਦੀ ਬਜੇ, Microsoft OpenAI ਦੀ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਰ ਰਹੀ ਸਮਰੱਥਾ ਨੂੰ Azure ਦੀ ਤਿਆਰ-ਪਹੁੰਚ ਸਮਰੱਥਾ ਨਾਲ ਜੋੜ ਸਕਦਾ ਸੀ।
ਉਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਤਿੰਨ-ਹਿੱਸਿਆਂ ਵਾਲਾ ਗਠਜੋੜ ਸੀ:
ਇਹ Microsoft ਨੂੰ ਇੱਕ "ਖਰੀਦੋ, ਬਣਾਓ, ਅਤੇ ਸਾਂਝ ਕਰੋ" ਦ੍ਰਿਸ਼ਟੀ ਸਹਾਇਕ ਬਣਾਉਂਦਾ: Microsoft ਮੁੱਢਲੇ ਪਲੇਟਫਾਰਮ ਸੇਵਾਵਾਂ (ਸੁਰੱਖਿਆ, ਪਛਾਣ, ਡੇਟਾ, ਪ੍ਰਬੰਧ) ਬਣਾਉਂਦਾ, frontier ਮਾਡਲ ਨਵੀਨਤਾ ਲਈ ਸਾਂਝ ਕਰਦਾ, ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਟੀਮਾਂ ਜਾਂ ਟੂਲਾਂ ਨੂੰ ਖਰੀਦਦਾ।
Microsoft ਨੇ Azure ਨੂੰ OpenAI ਮਾਡਲਾਂ ਦੇ ਹੋਸਟਿੰਗ ਅਤੇ ਡਿਲਿਵਰੀ ਲੇਅਰ ਵਜੋਂ ਰੱਖਿਆ—Azure OpenAI Service ਵਰਗੀਆਂ ਪੇਸ਼ਕਸ਼ਾਂ ਰਾਹੀਂ। ਸੋਚ ਸਧਾਰਨ ਹੈ: Azure ਉਹ ਕੰਪਿਊਟ, ਨੈਟਵਰਕਿੰਗ, ਅਤੇ ਆਪਰੇਸ਼ਨਲ ਕੰਟਰੋਲ ਦਿੰਦਾ ਜੋ ਉਦਯੋਗ ਉਮੀਦ ਕਰਦੇ ਹਨ (ਤैनਾਤੀ ਵਿਵਕਲਪ, ਨਿਗਰਾਨੀ, ਅਨੁਕੂਲਤਾ ਸਮਰਥਨ), ਜਦੋਂ ਕਿ OpenAI ਅਧਾਰਭੂਤ ਮਾਡਲ ਸਮਰੱਥਾ ਮੁਹੱਈਅ ਕਰਵਾਂਦਾ ਹੈ।
ਜਨਰਲ ਜਾਣਕਾਰੀ ਵਿੱਚ: Microsoft ਨੇ OpenAI ਮਾਡਲਾਂ ਨੂੰ Azure ਸੇਵਾਵਾਂ ਅਤੇ ਆਪਣੇ ਉਤਪਾਦਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ, ਅਤੇ Azure ਤੇ ਇਹ ਮਾਡਲ ਉਦਯੋਗਾਂ ਲਈ ਪ੍ਰਸਿੱਧ ਚੈਨਲ ਬਣ ਗਏ।
ਘੱਟ ਪ੍ਰਕਾਸ਼ਿਤ ਪਰ ਅਹਿਮ: ਅੰਦਰੂਨੀ ਆਰਥਿਕਤਾ, ਮਾਡਲ-ਟ੍ਰੇਨਿੰਗ ਅਲੋਕੇਸ਼ਨ, ਅਤੇ ਕਿਵੇਂ ਸਮਰੱਥਾ Microsoft ਦੇ ਉਤਪਾਦਾਂ ਅਤੇ ਤੀਜੀਆਂ ਪੱਖਾਂ ਵਿੱਚ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ—ਇਹ ਸਾਰੇ ਮਾਮਲੇ ਘੱਟ ਪੱਤਰਕਾਰਕ ਹਨ।
ਲਾਭ ਸਪਸ਼ਟ ਹੈ: Microsoft "ਸਭ ਤੋਂ ਉਪਲਬਧ ਮਾਡਲਾਂ" ਨੂੰ ਇੱਕ ਪਲੇਟਫਾਰਮ ਫਾਇਦੇ ਵਜੋਂ ਬਦਲ ਸਕਦਾ ਹੈ—APIs, ਟੂਲਿੰਗ, ਅਤੇ ਵੰਡ ਜੋ Azure ਨੂੰ ਉਦਯੋਗੀ AI ਅਪਣਾਉਣ ਲਈ ਡਿਫਾਲਟ ਰਸਤਾ ਬਣਾਉਂਦੇ ਹਨ।
ਖਤਰਾ ਨਿਰਭਰਤਾ ਹੈ: ਜੇ ਮਾਡਲ ਲੀਡਰਸ਼ਿਪ ਬਦਲੇ ਜਾਂ ਸਾਂਝ ਦੀਆਂ ਸ਼ਰਤਾਂ ਬਦਲਣ, ਤਾਂ Microsoft ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੋਏਗਾ ਕਿ ਉਹ ਪਲੇਟਫਾਰਮ ਸਟੈਕ ਦੇ ਕਾਫ਼ੀ ਹਿੱਸੇ (ਡੇਟਾ, ਡਿਵੈਲਪਰ ਵਰਕਫਲੋ, ਗਵਰਨੈਂਸ, ਅਤੇ ਢਾਂਚਾ) ਆਪਣੇ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਦਾ ਰਹੇ ਤਾਂ ਜੋ ਮੁਕਾਬਲਾ ਜਾਰੀ ਰਹੇ।
Microsoft ਦਾ ਫਾਇਦਾ ਸਿਰਫ਼ ਅੱਛੇ ਮਾਡਲਾਂ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਸੀ—ਉਸ ਨੇ ਉਹ ਮਾਡਲ ਅਜਿਹੇ ਪੈਕੇਜ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੇ ਜੋ ਉਦਯੋਗ ਸੱਚਮੁੱਚ ਖਰੀਦ, ਤੈਨਾਤ ਅਤੇ ਗਵਰਨ ਕਰ ਸਕਦੇ। ਸੋਚੋ "Azure OpenAI Service"-ਸਟਾਈਲ: ਜਾਣਿਆ-ਪਹਿਚਾਣ ਵਾਲੀ ਕਲਾਉਡ ਖਰੀਦਦਾਰੀ, ਟੇਨੈਂਟ-ਲੈਵਲ ਕੰਟਰੋਲ, ਅਤੇ ਤਾਕਤਵਰ ਮਾਡਲ APIs ਦੇ ਆਲੇ-ਦੁਆਲੇ ਓਪਰੇਸ਼ਨਲ ਗਾਰਡਰੇਲ।
ਉਦਯੋਗਾਂ ਨੂੰ ਕੇਵਲ ਚੈਟਬੋਟ ਨਹੀਂ ਚਾਹੀਦਾ। ਉਹ ਇੱਕ ਪੇਸ਼ਗੋਈਯੋਗ ਸੇਵਾ ਚਾਹੁੰਦੇ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਮਾਡਲ ਹੋਸਟਿੰਗ ਜੋ ਮੌਜੂਦਾ Azure ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਵਿੱਚ ਫਿਟ ਹੋਵੇ, ਨਾਲ ਹੀ ਵਿਹਾਰ ਨੂੰ ਟਿਊਨ ਕਰਨ ਦੇ ਵਿਕਲਪ (ਪ੍ਰੋੰਪਟ ਪੈਟਰਨ, ਰੀਟਰੀਵਲ ਸੈਟਅਪ, ਅਤੇ ਜਿੱਥੇ ਉਪਲਬਧ ਹੋਵੇ ਫਾਈਨ-ਟਿਊਨਿੰਗ) ਬਿਨਾਂ ਹਰ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਖੋਜ-ਕੋਸ਼ਿਸ਼ ਬਣਾਏ।
ਉਸ ਤੋਂ ਇਲਾਵਾ, ਮਾਡਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਜਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਹਨ ਉਹ ਬੜੀ ਜ਼ਰੂਰੀ ਹਨ:
ਨਤੀਜਾ: ਮਾਡਲ ਇੱਕ ਹੋਰ ਪ੍ਰਬੰਧਤ ਕਲਾਉਡ ਸਮਰੱਥਾ ਬਣ ਜਾਂਦੇ ਹਨ—ਇਕ ਐਸੀ ਚੀਜ਼ ਜੋ ਓਪਰੇਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਸਮਝ ਸਕਦੀਆਂ ਹਨ, ਨਾਹ ਕਿ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਪਵਾਦ।
Azure ਇੱਕ ਵਧੀਆ ਡਿਲਿਵਰੀ ਵਾਹਕ ਬਣਨ ਦਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਇਕੀਕਰਨ ਹੈ। ਪਛਾਣ ਅਤੇ ਪਹੁੰਚ Microsoft Entra (Azure AD ਸਮਝਾਵਾਂ) ਰਾਹੀਂ ਸੰਭਾਲੀ ਜਾ ਸਕਦੀ ਹੈ, ਜਿਹੜੀ AI ਦੀਆਂ ਆਗਿਆਵਾਂ ਨੂੰ ਮੌਜੂਦਾ ਭੂਮਿਕਾਵਾਂ, ਗਰੁੱਪਾਂ ਅਤੇ ਸ਼ਰਤੀ ਪਹੁੰਚ ਨੀਤੀਆਂ ਨਾਲ ਮਿਲਾਉਂਦੀ ਹੈ।
ਡੇਟਾ ਪਾਸੇ, ਉਦਯੋਗੀ AI ਕਦੇ ਵੀ ਸਿਰਫ਼ "ਮਾਡਲ-ਕੇਵਲ" ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਮਾਡਲ + ਤੁਹਾਡੇ ਦਸਤਾਵੇਜ਼ + ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ + ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਟੂਲ ਹਨ। Azure ਡੇਟਾ ਸੇਵਾਵਾਂ ਅਤੇ ਕਨੈਕਟਰ ਟੀਮਾਂ ਨੂੰ ਡੇਟਾ ਚਲਾਓਣ ਨੂੰ ਇਰਾਦੇਨੁਸਾਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ retrieval-augmented generation (RAG) ਵਰਗੀਆਂ ਪੈਟਰਨਾਂ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜਿੱਥੇ ਮਾਡਲ ਕੰਪਨੀ ਸਮਗਰੀ ਦਾ ਹਵਾਲਾ ਲੈਂਦਾ ਹੈ ਬਿਨਾਂ ਉਸਨੂੰ ਬੇਉਪਰਤੀ ਤਰੀਕੇ ਨਾਲ "ਟ੍ਰੇਨ" ਕੀਤੇ ਬਿਨਾਂ।
ਖਰੀਦਦਾਰ ਸਪਸ਼ਟ ਪਰਾਈਵੇਸੀ ਸੀਮਾਂ, ਅਨੁਕੂਲਤਾ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਅਤੇ ਭਰੋਸਯੋਗ ਓਪਰੇਸ਼ਨਲ ਸਹਿਯੋਗ ਨੂੰ ਲੱਭਦੇ ਹਨ। ਉਹ ਭਰੋਸਾ ਕਰਨਗੇ ਕਿ SLA ਅਤੇ ਸਮਰਥਨ ਰਾਹੀਂ ਉਠਾਉਣ ਦੇ ਰਾਹ ਹਨ—ਕਿਉਂਕਿ ਜਦ AI ਫਾਇਨੈਂਸ, ਕਸਟਮਰ ਸਰਵਿਸ ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਆਦਿ ਹੁੰਦਾ ਹੈ, "ਸਭ ਤੋਂ ਚੰਗੀ ਕੋਸ਼ਿਸ਼" ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦੀ।
Microsoft ਦਾ ਏਆਈ ਫਾਇਦਾ ਸਿਰਫ਼ ਮਾਡਲ ਗੁਣਵੱਤਾ ਨਹੀਂ ਸੀ—ਇਹ ਵੰਡ ਵੀ ਸੀ। Copilot ਨੂੰ ਆਪਣੇ ਉਤਪਾਦਾਂ ਦੇ ਊਪਰ ਇਕ "ਐਪ ਲੇਅਰ" ਵਜੋਂ ਦੇਖ ਕੇ, Microsoft ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਨੂੰ ਪਲੇਟਫਾਰਮ ਪੂਵਰਨ ਲਈ ਖਿੱਚ ਬਣਾਉਂਦਾ ਹੈ: ਵੱਧ ਪ੍ਰੋੰਪਟ, ਵੱਧ ਡੇਟਾ ਕਨੈਕਸ਼ਨ, ਅਤੇ Azure-ਹੋਸਟ ਕੀਤੀਆਂ ਏਆਈ ਸੇਵਾਵਾਂ ਲਈ ਵੱਧ ਮੰਗ।
Copilot ਇਕ ਇਕੱਲਾ ਉਤਪਾਦ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਲਗਾਤਾਰ ਤਜਰਬਾ ਹੈ ਜੋ ਉਸ ਥਾਂ ਤੇ ਆਉਂਦਾ ਹੈ ਜਿੱਥੇ ਕੰਮ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਉਪਭੋਗਤਾ ਸਮਰੀ, ਡਰਾਫਟ, ਕੋਡ ਸੁਝਾਅ ਜਾਂ ਡਾਟਾ ਦੀ ਵਿਆਖਿਆ ਮੰਗਦੇ ਹਨ, ਤਾਂ ਉਹ "ਇੱਕ ਏਆਈ ਟੂਲ ਦੀ ਕੋਸ਼ਿਸ਼" ਨਹੀਂ ਕਰ ਰਹੇ—ਉਹ ਆਪਣੀਆਂ ਪਹਿਲਾਂ ਦੀਆਂ ਭੁਗਤੀਆਂ ਤੋਂ ਵਧਾ ਰੁਪ ਵਿੱਚ ਟੂਲ ਦਾ ਇਸਤੇਮਾਲ ਕਰ ਰਹੇ ਹਨ।
Microsoft Copilot ਨੂੰ ਉਨ੍ਹਾਂ ਉੱਚ-ਫ੍ਰਿਕਵੈਂਸੀ ਸਤਹਾਂ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਕਈ ਸੰਸਥਾਵਾਂ ਮਿਆਰੀਕ੍ਰਿਤ ਹੁੰਦੀਆਂ ਹਨ:
ਵਿਸਥਾਰ ਦੇ ਵੇਰਵੇ ਘੱਟ ਮੱਤਵਪੂਰਨ ਹਨ, ਪਰ ਪੈਟਰਨ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ AI ਮੂਲ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਐਂਬੇਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਪਣਾਉਣ ਨੋਵਲਟੀ ਨਹੀਂ ਬਲਕਿ ਆਦਤ ਨਾਲ ਚੱਲਦਾ ਹੈ।
ਬੰਡਲਿੰਗ ਅਤੇ ਵਰਕਫਲੋ ਇਕੀਕਰਨ ਰੁਕਾਵਟ ਘਟਾਉਂਦੇ ਹਨ। ਪ੍ਰੋਕਯੂਰਮੈਂਟ ਅਸਾਨ ਹੁੰਦੀ ਹੈ, ਗਵਰਨੈਂਸ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਲੱਗ ਕਾਂਟੈਕਸਟ ’ਤੇ ਜਾਣ ਜਾਂ ਨਵੀਂ ਸਟੈਂਡਅਲੋਨ ਐਪ ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ। ਇਸ ਨਾਲ ਸੰਸਥਾਵਾਂ ਲਈ ਪ੍ਰਯੋਗ ਤੋਂ ਦੈਨੀਕ ਨਿਰਭਰਤਾ ਵੱਲ ਜਾਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ—ਬਿਲਕੁਲ ਓਥੇ ਜਿੱਥੇ ਪਲੇਟਫਾਰਮ ਦੀ ਮੰਗ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ।
ਵਿਆਪਕ ਵਰਤੋਂ ਫੀਡਬੈਕ ਲੂਪ ਬਣਾਉਂਦੀ ਹੈ। ਜਿਵੇਂ Copilot ਵੱਖ-ਵੱਖ ਸਨਾਰਿਓਜ਼ 'ਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, Microsoft ਦੇ ਪਾਸ ਇਹ ਜਾਣਕਾਰੀ ਆਉਂਦੀ ਹੈ ਕਿ ਲੋਕ ਕਿਸ ਨਾਲ ਸੰਘਰਸ਼ ਕਰਦੇ ਹਨ (ਹੈਲੂਸੀਨੇਸ਼ਨ, ਅਧਿਕਾਰ, ਹਵਾਲੇ ਦੀ ਲੋੜ, ਲੇਟੈਂਸੀ), ਫਿਰ ਉਹ ਪ੍ਰੋੰਪਟ, ਟੂਲਿੰਗ, ਗਾਰਡਰੇਲ ਅਤੇ ਐਡਮਿਨ ਕੰਟਰੋਲ ਸੁਧਾਰ ਸਕਦਾ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਫਲਾਈਵ੍ਹੀਲ ਹੈ: ਬਿਹਤਰ Copilot ਅਨੁਭਵ ਵਰਤੋਂ ਵਧਾਉਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਮੂਲ ਪਲੇਟਫਾਰਮ ਮਜ਼ਬੂਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਰੋਲਆਉਟ ਨੂੰ ਸਹੀ ਬਣਾਉਂਦਾ ਹੈ।
Microsoft ਦੀ ਏਆਈ ਪਲੇਟਫਾਰਮ ਰਣਨੀਤੀ ਸਿਰਫ਼ ਪੇਸ਼ੇਵਰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬਿਹਤਰ ਟੂਲ ਦੇਣ ਬਾਰੇ ਨਹੀਂ ਸੀ—ਇਹ ਸੰਸਥਾ ਵਿੱਚ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣ ਵਾਲਿਆਂ ਦੀ ਗਿਣਤੀ ਬਹੁਗੀਣੇ ਕਰਨ ਬਾਰੇ ਸੀ। Power Platform (Power Apps, Power Automate, Power BI, ਅਤੇ Copilot Studio) ਇੱਕ ਪੁਲ ਵਾਂਗ ਕੰਮ ਕਰਦੀ ਹੈ: ਕਾਰੋਬਾਰੀ ਟੀਮਾਂ low-code ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਜਦੋਂ ਕੰਮ ਨੂੰ ਡੂੰਘੀ ਕਸਟਮਾਈਜੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰਵੇਸ਼ ਕਰਦੀ ਹੈ।
Low-code ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਮਕਸਦ ਮੌਜੂਦਾ ਸਿਸਟਮਾਂ ਨੂੰ ਜੋੜਨਾ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਮਿਆਰੀਕ੍ਰਿਤ ਕਰਨਾ ਹੋਵੇ। ਪ੍ਰੀਬਿਲਟ ਕਨੈਕਟਰ, ਟੈਂਪਲੇਟ ਅਤੇ ਵਰਕਫਲੋ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧਣ ਦਿੰਦੇ ਹਨ, ਜਦਕਿ ਗਵਰਨੈਂਸ ਖਾਸੀਅਤਾਂ—ਜਿਵੇਂ environments, data loss prevention (DLP) ਨੀਤੀਆਂ, ਅਤੇ managed connectors—IT ਨੂੰ ਖਤਰਨਾਕ "ਸ਼ੈਡੋ ਐਪਸ" ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ।
ਇਹ ਜੋੜ ਬਹੁਤ ਮਤਲਬ ਰੱਖਦਾ ਹੈ: ਗਤੀ ਬਿਨਾਂ ਗਾਰਡਰੇਲ compliance ਮੁਸ਼ਕਿਲ ਪੈਦਾ ਕਰਦੀ ਹੈ; ਗਾਰਡਰੇਲ ਬਿਨਾਂ ਗਤੀ ਲੋਕਾਂ ਨੂੰ ਵਾਪਸ ਸਪ੍ਰੇਡਸ਼ੀਟ ਅਤੇ ਈਮੇਲ ਤੇ ਭੇਜ ਦਿੰਦੀ ਹੈ।
Low-code ਫਿੱਟ ਹੁੰਦਾ ਹੈ ਜਦੋਂ:
ਪ੍ਰੋ-ਕੋਡ 'ਤੇ ਜਾਣਾ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈ ਜਦ:
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ Microsoft ਇਨ੍ਹਾਂ ਦੁਨੀਆਂ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ: ਪੇਸ਼ੇਵਰ ਡਿਵੈਲਪਰ Power Platform ਨੂੰ ਕਸਟਮ APIs ਅਤੇ Azure ਸੇਵਾਵਾਂ ਨਾਲ ਵਧਾ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਇੱਕ ਤੁਰੰਤ ਜਿੱਤ ਪ੍ਰਬੰਧਯੋਗ ਸਿਸਟਮ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਸਕਦੀ ਹੈ।
ਬਿਲਡਰ ਆਧਾਰ ਵਧਾਉਣ ਵਾਲੀ ਉਹੀ ਰੁਝਾਨ ਨਵੇਂ "ਚੈਟ-ਟੂ-ਐਪ" ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਵੀ ਆਉਂਦੀ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, Koder.ai ਇੱਕ vibe-coding ਪਹੁੰਚ ਲੈਂਦਾ ਹੈ: ਟੀਮਾਂ ਚੈਟ ਇੰਟਰਫੇਸ ਵਿੱਚ ਜੋ ਚਾਹੁੰਦੇ ਹਨ ਉਹ ਵੇਰਵਾ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਵਾਸਤਵਿਕ ਐਪਲੀਕੇਸ਼ਨ (ਵੈੱਬ, ਬੈਕਐਂਡ, ਮੋਬਾਈਲ) ਤਿਆਰ ਅਤੇ ਦੁਹਰਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਯੋਜਨਾ ਮੋਡ, ਸનੈપਸ਼ੌਟ/ਰੋਲਬੈਕ, ਤੈਨਾਤ/ਹੋਸਟਿੰਗ, ਅਤੇ ਸਰੋਤ-ਕੋਡ ਐਕਸਪੋਰਟ ਵਰਗੇ ਵਿਕਲਪ ਹੁੰਦੇ ਹਨ। ਉਹ ਸੰਸਥਾਵਾਂ ਲਈ ਜੋ AI ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਤੈਅਤ ਅੰਦਰੂਨੀ ਟੂਲਜ਼ تک ਤੇਜ਼ੀ ਨਾਲ ਜਾਣਾ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਨਾਲ ਪਲੇਟਫਾਰਮ ਸਬਕ ਨੂੰ ਪੂਰਾ ਹੁੰਦਾ ਹੈ: ਰੁਕਾਵਟ ਘਟਾਓ, ਗਾਰਡਰੇਲ ਸਥਿਰ ਕਰੋ, ਅਤੇ ਸ਼ਿਪਿੰਗ ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਓ।
ਉਦਯੋਗੀ AI ਫੇਲ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਟੀਮਾਂ ਡੈਮੋ نہیں ਬਣਾਉਂਦੀਆਂ—ਉਹ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਕੋਲ ਤੈਨਾਤ ਮਨਜ਼ੂਰ ਕਰਨ ਲਈ ਰਸਤਾ ਨਹੀਂ ਹੁੰਦਾ। ਨਾਡੇਲਾ ਦੇ Microsoft ਨੇ "ਜਿੰਮੇਵਾਰ AI" ਨੂੰ ਨારા ਨਹੀਂ ਰਹਿਣ ਦਿਤਾ ਪਰ ਇੱਕ ਤੈਨਾਤਯੋਗ ਚੈੱਕਲਿਸਟ ਵਜੋਂ ਬਨਾ ਦਿੱਤਾ: ਸਪਸ਼ਟ ਨੀਤੀ, ਟੂਲਿੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ, ਅਤੇ ਦੁਹਰਾਊ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਬੈੱਕ ਕੀਤਾ।
ਅਮਲੀ ਪੱਧਰ 'ਤੇ ਇਹ ਤਿੰਨ ਚੀਜ਼ਾਂ ਇੱਕਠੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:
ਬਹੁਤ ਸਾਰੀਆਂ ਗਵਰਨੈਂਸ ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਜਾਣਪਹਚਾਨਕ ਸੈੱਟ 'ਤੇ ਮਿਲਦੀਆਂ ਹਨ:
ਜਦੋਂ ਕੰਟਰੋਲ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਬਣੇ ਹੋਂਦੇ ਹਨ, ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ: ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਵਾਂ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਪ੍ਰੋਕਯੋਰਮੈਂਟ ਕੋਲ ਘੱਟ ਅਣਜਾਣੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਉਤਪਾਦ ਮਾਲਿਕ ਨਿਰਭਰ ਹੋਕੇ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹਨ। ਨਤੀਜਾ ਘੱਟ ਸਮਾਂ ਛੇਤੀ ਪ੍ਰਵਾਨਗੀ ਲੈਣ ਵਿੱਚ ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਣਾਉਣ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਹ ਸੈੱਟ ਕਰ ਰਹੇ ਹੋ, ਤਾੰ ਇੱਕ ਸਧਾਰਨ ਚੈੱਕਲਿਸਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਦੁਹਰਾਓ: /blog/ai-governance-checklist. ਜੇ ਤੁਹਾਨੂੰ ਲਾਗਤ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਟਰੇਡ-ਆਫ਼ ਦੀ ਸਪਸ਼ਟ ਤਸਵੀਰ ਚਾਹੀਦੀ ਹੈ, ਵੇਖੋ: /pricing.
ਕਿਸੇ ਏਆਈ ਪਲੇਟਫਾਰਮ ਦੀ ਚੋਣ "ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਡਲ" ਲੱਭਣ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਫਿੱਟ ਬਾਰੇ ਹੁੰਦਾ ਹੈ: ਟੀਮਾਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਉਹ ਖੁਲ੍ਹੇ ਤੌਰ 'ਤੇ ਕਿੰਨੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ ਚਲਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ AI ਕਿਵੇਂ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਨਾਲ ਜੁੜਦਾ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਹ ਪਹਿਲਾਂ ਹੀ ਨਿਰਭਰ ਹਨ।
Microsoft ਦਾ ਫਾਇਦਾ ਵੰਡ ਅਤੇ ਇਕੀਕਰਨ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਸੰਸਥਾ ਪਹਿਲਾਂ ਹੀ Microsoft 365, Teams, Windows, ਅਤੇ GitHub ਵਿੱਚ ਜੀਉਂਦੀ ਹੈ, ਤਾਂ "ਪਾਇਲਟ" ਤੋਂ "ਲੋਕ ਸੱਚਮੁੱਚ ਵਰਤਣ" ਤਕ ਰਸਤਾ ਛੋਟਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਇੰਫ੍ਰਾਸਟ੍ਰਕਚਰ ਟੀਮਾਂ ਲਈ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜੋ ਪਛਾਣ, ਸੁਰੱਖਿਆ, ਨਿਗਰਾਨੀ ਅਤੇ ਤੈਨਾਤੀ ਲਈ ਇੱਕ ਜਗ੍ਹਾ ਚਾਹੁੰਦੀਆਂ ਹਨ।
Google ਅਕਸਰ ਉੱਪਯੋਗੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਪਹਿਲਾਂ ਹੀ Google ਡੇਟਾ ਸਟੈਕ (BigQuery, Vertex AI) 'ਚ ਗਹਿਰਾਈ ਨਾਲ ਹਨ ਜਾਂ ਉਹ cutting-edge ਮਾਡਲ ਰਿਸਰਚ ਅਤੇ ਡੇਟਾ-ਟੂ-ML ਵਰਕਫਲੋਜ਼ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ। ਤਬਦੀਲੀ ਖਰੀਦਦਾਰੀ ਦੇ ਪੈਟਰਨ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਅੰਗਾਂ ਵਿੱਚ Microsoft ਨਾਲ ਤੁਲਨਾ ਵਿੱਚ ਦਿਨ-ਪ੍ਰਤੀ ਦਿਨ ਦੀ ਪਹੁੰਚ ਘੱਟ ਹੋ ਸਕਦੀ ਹੈ।
AWS ਆਮ ਤੌਰ 'ਤੇ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਪ੍ਰਿਮਿਟਿਵਸ ਦੀ ਵਿਆਪਕਤਾ ਅਤੇ "ਆਪਣੇ ਢੰਗ ਨਾਲ ਬਣਾਓ" ਸਭਿਆਚਾਰ ਨਾਲ ਜਿੱਤਦਾ ਹੈ। ਜੇ ਟੀਮਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਮੋਡੀਊਲਿਟੀ ਚਾਹੁੰਦੀਆਂ ਹਨ—ਜਾਂ ਉਹ ਪਹਿਲਾਂ ਹੀ AWS ਨੈਟਵਰਕਿੰਗ, IAM ਪੈਟਰਨ, ਅਤੇ MLOps 'ਤੇ ਅਡਿੱਠ ਹਨ—AWS ਸਭ ਤੋਂ ਕੁਦਰਤੀ ਘਰ ਹੋ ਸਕਦਾ ਹੈ।
Microsoft ਉਸ ਜਗ੍ਹਾ 'ਤੇ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਹੈ ਜਿੱਥੇ AI ਨੂੰ ਮੌਜੂਦਾ ਉਦਯੋਗੀ ਸਾਫਟਵੇਅਰ ਅਤੇ ਵਰਕਫਲੋਜ਼ ਨਾਲ ਜੁੜਨਾ ਪੈਂਦਾ ਹੈ: ਪਛਾਣ (Entra), ਐਂਡਪੋਇੰਟ ਮੈਨੇਜਮੈਂਟ, Office ਦਸਤਾਵੇਜ਼, ਮੀਟਿੰਗਾਂ, ਈਮੇਲ, CRM/ERP ਕਨੈਕਸ਼ਨ, ਅਤੇ ਗਵਰਨੈਂਸ। ਦਬਾਅ ਵਾਲੀ ਗੱਲ ਲਾਗਤ ਅਤੇ ਜਟਿਲਤਾ ਹੈ: ਗਾਹਕ ਕਲਾਉਡਾਂ ਵਿੱਚ ਮੁੱਲ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਨੂੰ ਡਰ ਹੈ ਕਿ "ਸਭ ਤੋਂ ਵਧੀਆ ਅਨੁਭਵ" ਫੀਚਰ ਉਹਨਾਂ ਨੂੰ Microsoft ਸਟੈਕ ਵੱਲ ਵੱਧ ਵਾਤਾਂ ਲੈ ਜਾਣਗੇ।
ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਮਾਡਲ ਸਟੈਕਾਂ ਵੱਲੋਂ ਨਿਯੰਤਰਣ, ਕਸਟਮਾਈਜੇਸ਼ਨ, ਅਤੇ ਸਕੇਲ 'ਤੇ ਸੰਭਵ ਲਾਗਤ ਫਾਇਦੇ ਹੋ ਸਕਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਉਹ ਟੀਮਾਂ ਜਿੰਨ੍ਹਾਂ ਕੋਲ ਮਜ਼ਬੂਤ ML ਅਤੇ ਪਲੇਟਫਾਰਮ ਇੰਜੀਨੀਅਰਿੰਗ ਟੈਲੈਂਟ ਹੈ।
Microsoft ਦਾ ਫਾਇਦਾ ਪੈਕੇਜਿੰਗ ਹੈ: ਪ੍ਰਬੰਧਤ ਸੇਵਾਵਾਂ, ਸੁਰੱਖਿਆ ਦੀਆਂ ਡਿਫਾਲਟ, ਉਦਯੋਗੀ ਸਮਰਥਨ, ਅਤੇ ਜਾਣਪਹਚਾਣ ਵਾਲਾ ਐਡਮਿਨ ਅਨੁਭਵ। ਵਪਾਰ-ਬਦਲਾ ਇਹ ਹੈ ਕਿ ਖੁੱਲ੍ਹਾਪਣ ਅਤੇ ਲਾਕ-ਇਨ ਦੇ ਸੰਦੇਸ਼ ਹੋ ਸਕਦੇ ਹਨ; ਕੁਝ ਟੀਮਾਂ ਵਧੇਰੇ ਪੋਰਟੇਬਲ ਆਇਟਿਕੈਕਚਰ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ ਭਲੇ ਉਹ ਦੇਰ ਨਾਲ ਆਉਣ।
ਵਸਤੀ ਨਿਸ਼ਕਰਸ਼: ਜਦੋਂ ਅਪਣਾਉਣ ਅਤੇ ਇਕੀਕਰਨ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹੋਵੇ ਤਾਂ Microsoft ਮਜ਼ਬੂਤ ਫਿੱਟ ਹੈ; ਜੇ ਲਾਗਤ ਸੰਵੇਦਨਸ਼ੀਲਤਾ, ਪੋਰਟੇਬਿਲਿਟੀ ਜਾਂ ਕਸਟਮ ML ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰਾਥਮਿਕਤਾ ਹੋਵੇ ਤਾਂ ਹੋਰ ਵਿਕਲਪ ਮਿਹਤਰ ਹੋ ਸਕਦੇ ਹਨ।
Microsoft ਦਾ ਏਆਈ ਪਲੇਟਫਾਰਮ ਧੱਕਾ ਸ਼ਕਤੀਸ਼ালী ਹੈ, ਪਰ ਇਹ ਖਤਰੇ-ਮੁਕਤ ਨਹੀਂ। ਉਹੀ ਚੋਣਾਂ ਜੋ ਤਰੱਕੀ ਨੂੰ ਤੇਜ਼ ਕਰਦੀਆਂ—ਕਠੋਰ ਸਾਂਝ, ਵੱਡੇ ਢਾਂਚਾ ਦਾਅ, ਅਤੇ ਵਿਆਪਕ ਵੰਡ—ਅਜਿਹੇ ਪੱਛੇ ਦਬਾਅ ਬਣਾ ਸਕਦੀਆਂ ਹਨ ਜੋ ਅਪਣਾਉਣ ਨੂੰ ਧੀਮਾ ਕਰਦੇ ਹਨ ਜਾਂ ਪਿਵਟ ਲੈਣ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ।
OpenAI ਸਾਂਝ Microsoft ਨੂੰ frontier ਮਾਡਲਾਂ ਤੱਕ ਆਸਾਨੀ ਨਾਲ ਪਹੁੰਚ ਦਿੰਦੀ ਹੈ, ਪਰ ਇਹ ਕੇਂਦਰੀ ਕਰਕੇ ਇੱਕ ਤੀਸਰੇ ਪਾਸੇ 'ਤੇ ਨਿਰਭਰਤਾ ਪੈਦਾ ਕਰ ਦਿੰਦੀ ਹੈ। ਜੇ ਕੋਈ ਸਾਂਝੀਦਾਰ ਪ੍ਰਾਥਮਿਕਤਾ ਬਦਲੇ, ਪਹੁੰਚ ਸੀਮਤ ਕਰੇ, ਜਾਂ ਕਾਨੂੰਨੀ/ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਫਸ ਜਾਵੇ, ਤਾਂ Microsoft ਨੂੰ ਤਕਨੀਕੀ ਅਤੇ ਪ੍ਰਤਿਭਾਤਮਕ ਦੋਵਾਂ ਤਣਾਅ ਸਹਨ ਕਰਨੇ ਪੈ ਸਕਦੇ ਹਨ। ਭਾਵੇਂ ਵੀ ਅੰਦਰੂਨੀ ਮਾਡਲ ਕੰਮ ਅਤੇ ਕਈ ਮਾਡਲ ਵਿਕਲਪ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਗਾਹਕ fortfarande "Azure AI" ਨੂੰ ਇੱਕ ਛੋਟੇ ਨੈੱਟਵਰਕ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਸਮਝ ਸਕਦੇ ਹਨ।
ਟ੍ਰੇਨਿੰਗ ਦੇ ਸਿਰਲੇਖ ਧਿਆਨ ਖਿੱਚਦੇ ਹਨ, ਪਰ ਦਿਨ-ਪ੍ਰਤੀ ਦਿਨ ਖਰਚ ਇੰफਰੈਂਸ 'ਤੇ ਆਉਂਦਾ ਹੈ। ਕੰਪਿਊਟ ਉਪਲਬਧਤਾ, GPU ਸਪਲਾਈ, ਡੇਟਾ ਸੈਂਟਰ ਬਿਲਡਆਉਟ, ਅਤੇ ਊਰਜਾ ਸੀਮਾਵਾਂ ਬੋਤਲਨੇਕ ਬਣ ਸਕਦੀਆਂ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਮੰਗ ਛਕਦੀ ਹੈ। ਜੇ ਆਰਥਿਕਤਾ ਕਾਫੀ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਸੁਧਰੇਗੀ, ਉਦਯੋਗ ਵਰਤੋਂ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦੇ ਹਨ, ਤैनਾਤ ਨੂੰ ਕੁਝ ਪ੍ਰਵਾਹਾਂ ਤੱਕ ਘਟਾ ਸਕਦੇ ਹਨ, ਜਾਂ ਰੋਲਆਉਟ ਨੂੰ ਟਿਕਾਊ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਕੀਮਤ ਤੱਕ ਟਾਲ ਸਕਦੇ ਹਨ।
ਇੱਕ ਉੱਚ-ਪ੍ਰੋਫਾਈਲ ਘਟਨਾ—ਡੇਟਾ ਦਾ ਰਿਸਾਉਣਾ, ਪ੍ਰੋੰਪਟ ਇੰਜੈਕਸ਼ਨ ਕਾਰਨ ਨੁਕਸਾਨਦਾਇਕ ਨਤੀਜੇ, ਜਾਂ Copilot ਫੀਚਰ ਦਾ ਅਣਉਮੀਦ ਵਰਤਣ—ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਵੱਡੇ ਅੰਦਰੂਨੀ ਰੋਕ ਲਿਆ ਸਕਦੀ ਹੈ। ਇਹ ਘਟਨਾਵਾਂ ਸਿਰਫ਼ ਇੱਕ ਉਤਪਾਦ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦੀਆਂ; ਇਹ ਸੰਪੂਰਨ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਪ੍ਰੋਕਯੂਰਮੈਂਟ ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਕਿ ਕੰਟਰੋਲ, ਆਡਿਟਿੰਗ, ਅਤੇ ਮੁਆਵਜ਼ਾ ਸਾਬਤ ਨਹੀਂ ਹੋ ਜਾਂਦੇ।
AI ਨਿਯਮ ਅਤੇ ਕਾਪੀਰਾਈਟ ਨਿਯਮ ਖੇਤਰ ਅਨੁਸਾਰ ਬੇਰੂਪ ਹੋ ਰਹੇ ਹਨ। ਮਜ਼ਬੂਤ ਅਨੁਕੂਲਤਾ ਟੂਲਿੰਗ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਗਾਹਕ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ, ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਪ੍ਰੋਵੈਨੈਂਸ, ਅਤੇ ਮਨਜ਼ੂਰ ਵਰਤੋਂ 'ਤੇ ਸਪਸ਼ਟਤਾ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਅਣਨਿਸ਼ਚਿਤਤਾ ਖੁਦ ਬੋਰਡਰੂਮ ਫੈਸਲਿਆਂ ਵਿੱਚ ਖਤਰਾ ਬਣ ਜਾਂਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਨਿਯਮਤ ਉਦਯੋਗਾਂ ਲਈ।
Microsoft ਦੀ ਕਾਮਯਾਬੀ ਇਕ ਇਕੱਲੀ ਮਾਡਲ ਜਾਂ ਉਤਪਾਦ ਨਹੀਂ ਸੀ। ਇਹ ਇਕ ਦੁਹਰਾਊ ਪ੍ਰਣਾਲੀ ਸੀ: ਪਲੇਟਫਾਰਮ ਬਣਾਓ, ਵੰਡ ਕਮਾਓ, ਅਤੇ ਉਦਯੋਗਾਂ ਲਈ ਤੈਨਾਤਯੋਗ ਬਣਾਓ। ਹੋਰ ਟੀਮਾਂ ਬਿਨਾਂ Microsoft ਦੇ ਪੈਮਾਨੇ ਦੇ ਵੀ ਇਹ ਨਮੂਨਾ ਅਪਣਾਈ ਸਕਦੀਆਂ ਹਨ।
AI ਨੂੰ ਇੱਕ ਸਮਰੱਥਾ ਵਜੋਂ ਰਖੋ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਲਾਈਨ 'ਚ ਹਰ ਜਗ੍ਹਾ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ-ਵਾਰੀ "AI ਫੀਚਰ"। ਇਸ ਦਾ ਮਤਲਬ ਸਾਂਝੀ ਬੁਨਿਆਦਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਨਿਵੇਸ਼ ਕਰਨਾ: ਪਛਾਣ, ਬਿਲਿੰਗ, ਟੈਲੀਮੈਟਰੀ, ਡੇਟਾ ਕਨੈਕਟਰ, ਅਤੇ AI ਇੰਟਰਐਕਸ਼ਨਾਂ ਲਈ ਇੱਕ ਇਕਸਾਰ UI/UX।
Microsoft ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਵੰਡ ਨਾਲ ਯੂਟਿਲਿਟੀ ਜੋੜ ਕੇ ਕੀ ਹੁੰਦਾ ਹੈ। Copilot ਇਸ ਲਈ ਕਾਮਯਾਬ ਹੋਇਆ ਕਿ ਇਹ ਦੈਨਿਕ ਵਰਕਫਲੋਜ਼ ਦੇ ਅੰਦਰ ਜੀਉਂਦਾ। ਨਿਸ਼ਕਰਸ਼: AI ਨੂੰ ਉਹਥੇ ਰੱਖੋ ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਹੀ ਸਮਾਂ ਗੁਜ਼ਾਰਦੇ ਹਨ, ਫਿਰ ਇਸਨੂੰ ਮਾਪਯੋਗ ਬਣਾਓ (ਸਮਾਂ ਬਚਾਇਆ, ਗੁਣਵੱਤਾ ਸੁਧਾਰੀ, ਖਤਰਾ ਘਟਾਇਆ) ਤਾਂ ਜੋ ਇਹ ਬਜਟ ਸਮੀਖਿਆ 'ਚ ਬਚਕੇ ਰਹੇ।
ਅਖੀਰ ਵਿੱਚ, ਸਾਂਝਾਂ ਟਾਈਮਲਾਈਨ ਕੰਪ੍ਰੈੱਸ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਪਲੇਟਫਾਰਮ ਦਾਅ ਵਾਂਗ ਬਣਾਉ, ਨਾ ਕਿ ਸਿਰਫ਼ ਮਾਰਕੀਟਿੰਗ ਸੌਦਾ। ਸਪਸ਼ਟ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਬਾਹਰੀ ਰਿਸੋਰਸ 'ਤੇ ਨਿਰਭਰ ਹੋ ਰਹੇ ਹੋ (ਮਾਡਲ R&D) ਅਤੇ ਕੀ ਆਪਣੇ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਹੈ (ਡੇਟਾ ਪਹੁੰਚ, ਸੁਰੱਖਿਆ ਦ੍ਰਿਸ਼ਟੀ, ਗਾਹਕ ਭਰੋਸਾ, ਅਤੇ ਉਤਪਾਦ ਸਤਹ)।
ਇੱਕ AI ਪਲੇਟਫਾਰਮ ਉਹ ਪੂਰਾ ਸਟੈਕ ਹੈ ਜੋ AI ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੋਜ਼ਮਰਰਾ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਬਦਲਦਾ ਹੈ:
"ਯੁੱਧ" ਇਸ ਗੱਲ ਲਈ ਹੈ ਕਿ ਕੌਣ ਉਹ ਮੂਲ ਥਾਂ ਬਣਦਾ ਹੈ ਜਿੱਥੇ ਉਦਯੋਗ AI ਚਲਾਉਂਦੇ ਹਨ—ਜਿਵੇਂ ਪਹਿਲਾਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਬ੍ਰਾਊਜ਼ਰ, ਮੋਬਾਈਲ ਅਤੇ ਕਲਾਉਡ ਵਿੱਚ ਹੋਇਆ।
ਇਹ ਪੋਸਟ ਦਸ਼ਾਉਂਦੀ ਹੈ ਕਿ Microsoft ਦਾ ਫਾਇਦਾ ਇੱਕ ਪਲੇਟਫਾਰਮ ਪੋਜ਼ੀਸ਼ਨ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਇਕਲੌਤੇ ਮਾਡਲ ਤੋਂ:
ਇਹ ਸਾਰਾ ਮਿਲ ਕੇ ਉਹ ਕਾਰਨ ਬਣਦਾ ਹੈ ਕਿ ਉਦਯੋਗਿਕ AI ਵਰਕਫਲੋਜ਼ ਵਿੱਚ Microsoft ਨੂੰ ਬਦਲਣਾ ਮੁਸ਼ਕਿਲ ਹੁੰਦਾ ਹੈ।
ਇਸ ਲਈ ਕਿ ਉਦਯੋਗਿਕ AI ‘‘ਬੋਰਿੰਗ’’ ਮੰਗਾਂ 'ਤੇ ਠਹਿਰਦਾ ਹੈ:
Azure ਦੀ ਉਦਯੋਗ-ਤਿਆਰੀ ਇਸ ਗੱਲ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਪ੍ਰਾਇਗ ਨਾ ਰਹਿ ਕੇ ਪਾਇਲਟ ਸਿਸਟਮ ਵਾਸਤਵਿਕ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਬਣ ਸਕੇ।
ਪੋਸਟ ਇਸ ਤਰ੍ਹਾਂ ਜੋੜਦੀ ਹੈ:
ਇਹ ਗੁਣ ਲੰਮੇ ਸਮੇਂ ਲਈ ਪਲੇਟਫਾਰਮ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਆਪਸੀ ਮਿਲਾਪ ਅਤੇ ਉਪਲਬਧੀ ਦੀ ਲੋੜ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ।
ਇਸ ਨੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਰੁਕਾਵਟ ਘਟਾਈ:
ਜਿਵੇਂ ਉਦਯੋਗਿਕ ਟੀਮਾਂ ਲਈ ਵਿਸ਼ਵਾਸ ਬਣਿਆ, ਉਹ ਲੰਬੇ ਸਮੇਂ ਲਈ AI ਸਿਸਟਮ ਉਸੇ ਥਾਂ ਬਣਾਉਣ ਲਈ ਜ਼ਿਆਦਾ ਤਿਆਰ ਹੋਏ।
ਸਾਂਝ ਨੂੰ ਇੱਕ ਰਣਨੀਤਿਕ ਝਟਕਾ ਵਜੋਂ ਵੇਖਿਆ ਗਿਆ:
ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਇਹ ਨਿਰਭਰਤਾ ਬਣ ਸਕਦੀ ਹੈ: ਜੇ ਮਾਡਲ ਲੀਡਰਸ਼ਿਪ ਬਦਲੇ ਜਾਂ ਸਾਂਝ ਦੇ ਸ਼ਰਤ ਬਦਲਣ, ਤਾਂ Microsoft ਨੂੰ ਅਜੇ ਵੀ ਪਲੇਟਫਾਰਮ ਦੇ ਮੁੱਖ ਤੱਤ (ਡੇਟਾ, ਸੁਰੱਖਿਆ, ਟੂਲਿੰਗ, ਵਿੱਤ) ਆਪਣੇ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਣਾ ਹੋਏਗਾ।
ਉਦਯੋਗਾਂ ਨੂੰ ਕੇਵਲ ਕੱਚੇ ਮਾਡਲ API ਤੋਂ ਬਹੁਤ ਕੁਝ ਚਾਹੀਦਾ ਹੈ:
ਇਹ ਪੈਕਿੰਗ ਹੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਤਕਨੀਕੀ ਡੈਮੋ ਇੱਕ ਵਾਸਤਵਿਕ ਤੈਨਾਤਯੋਗ ਸੇਵਾ ਵਿੱਚ ਬਦਲਦੀ ਹੈ।
ਕਰਨੀਆਂ ਥਾਂ 'ਤੇ Copilot ਇੱਕ ਵੱਡਾ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ:
ਇਹ ਸਭ ਮਿਲ ਕੇ ਪਲੇਟਫਾਰਮ ਲਈ ਇਕ ਫਲਾਈਵ੍ਹੀਲ ਬਣਾਉਂਦਾ ਹੈ: ਬਿਹਤਰ تجربੇ ਵਧੇਰੇ ਵਰਤੋਂ ਲੈਕੇ ਆਉਂਦੇ ਹਨ, ਜੋ ਫਿਰ ਮੁੱਢਲੇ ਬੇਸ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ।
Power Platform (Power Apps, Power Automate, Power BI, Copilot Studio) ਦਾ ਮਕਸਦ ਹੇਠਾਂ ਦਿੱਖਦਾ ਹੈ:
ਸਰਗਰਮੀ ਨੂੰ ਤੁਰੰਤ ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰੀ ਅਤੇ ਓਪਰੇਸ਼ਨ ਘੱਟ-ਰੋਕ-ਟੋਕ ਵਾਲੇ ਬਣਾਓ:
ਫਿਰ ਐਸੇ ਪਾਇਲਟ ਚਲਾਓ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਤਿਆਰ ਹੋ ਕੇ ਉਤਰਨ ਦੇ ਯੋਗ ਹੋਣ—ਸਫਲਤਾ ਮੈਟਰਿਕ, ਥ੍ਰੈਟ ਮਾਡਲ, ਅਤੇ ਰੋਲਆਉਟ ਯੋਜਨਾ ਪਹਿਲਾਂ ਤੋਂ ਰੱਖੋ।
ਆਰੰਭਿਕ ਨਿੰਦਾਹੇਠ: /blog/ai-governance-checklist ਅਤੇ ਲਾਗਤ/ਓਪਰੇਸ਼ਨ ਟਰੇਡ-ਆਫ ਲਈ: /pricing
ਅਨੁਕੂਲਤਾਵਾਂ ਮੁੱਖ ਹਨ: ਤੇਜ਼ੀ ਨਾਲ ਤੈਅਤ ਹੋਣਾ, ਸੁਰੱਖਿਆ ਨਾਲ ਚਲਾਉਣਾ, ਅਤੇ ਮੌਜੂਦਾ ਸਿਸਟਮਾਂ ਨਾਲ ਜੁੜਨਾ।
ਅਮਲੀ ਨਤੀਜਾ: ਜਦੋਂ ਅਪਣਾਉਣ ਅਤੇ ਏਕੀਕਰਨ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ ਤਾਂ Microsoft ਮਹਾਨ ਫਿੱਟ ਹੈ; ਜੇ ਲਾਗਤ, ਪੋਰਟੇਬਿਲਿਟੀ ਜਾਂ bespoke ML ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰਾਇਰਿਟੀ ਹੋਵੇ ਤਾਂ ਹੋਰ ਵਿਕਲਪ ਬੇਤਰ ਹੋ ਸਕਦੇ ਹਨ।
ਕੁਝ ਮੁੱਖ ਖਤਰੇ ਅਤੇ ਟੈਨਸ਼ਨ ਹਨ:
ਦੂਹਰਾਊ ਪ੍ਰਣਾਲੀ ਬਣਾਓ: ਪਲੇਟਫਾਰਮ ਬਣਾਓ, ਵੰਡ ਲਈ ਮੋਹ ਪਾਓ, ਅਤੇ ਉਦਯੋਗਾਂ ਲਈ ਤੈਨਾਤਯੋਗ ਬਣਾਓ।
ਅਗਲਾ ਦੌਰ बहु-ਮਾਡਲ ਪੋਰਟਫੋਲੀਓ, ਏਜੰਟ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਐਨਟੀਗ੍ਰੇਸ਼ਨ ਵੱਲ ਜਾਵੇਗਾ—ਪਰ ਮੁੱਖ ਸਬਕ ਇੱਕੋ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ: AI ਨੂੰ ਤੈਨਾਤਯੋਗ ਬਣਾਓ—ਸੁਰੱਖਿਅਤ, ਗਵਰਨੇਬਲ, ਅਤੇ ਰੋਜ਼ਮਰਰਾ ਕੰਮ ਵਿੱਚ ਲੱਗਾ।
ਇਹ ਸਮੱਸਿਆਵਾਂ ਰਣਨੀਤੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕਈ ਵਾਰੀ ਪਿਵਟ ਲੈਣ ਜਾਂ ਸੁਧਾਰ ਕਰਨ ਲਈ ਦਬਾਅ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ।