An office team uses AI-powered cloud tools to manage data, collaboration, analytics, and cybersecurity.
Glen Maguire, founder of Matrix AI Consulting, argues in an IT Brief Australia opinion piece that AI is not the next cloud. He says the business should spread AI use widely, but IT should keep hold of the foundations. For Windows and Microsoft 365 administrators, the argument is worth testing against the evidence. It is an opinion piece, not an advisory, so the framing and the seven recommendations below are the author's. The statistics come from other organisations, and I note where each one needs care.

An office team uses AI-powered cloud tools to manage data, collaboration, analytics, and cybersecurity. The core argument​

Maguire says earlier technologies such as the web, mobile, cloud and analytics followed one arc. IT evaluated and secured them, then they became strategic and ownership spread to marketing, operations and the executive team. That worked because a built and secured website or CRM could run day to day without putting the organisation at risk.

He says AI will try the same path, and that this is a mistake. His reasons:

  • It acts, not just informs. An agent with credentials can retrieve records, update systems and contact customers.
  • It sees what you give it access to. Years of loose permissions become visible quickly.
  • It arrives as a feature update inside CRM, HR, finance and collaboration tools, so no single department sees all of it.
  • It drifts. Models change and outputs vary, so it needs continuous testing rather than one-off implementation.
  • It changes roles and skills, not just tools.

His conclusion is that AI's use should spread, but its foundations should not outgrow IT.

What the numbers actually say​

Several statistics carry the argument. Each has limits that are easy to lose in a short opinion column.

Agent adoption versus governance. Deloitte's 2026 State of AI in the Enterprise report, published 12 February 2026, found 69% of Australian organisations now use agentic AI. It also found only 22% of Australian companies report a highly advanced model for agent governance. The survey covered over 3,000 director to C-suite-level leaders, so it reports what leaders said. It is not a count of production deployments, and it does not mean the other 78% have no governance.

Shadow AI. Microsoft and LinkedIn's 2024 Work Trend Index found 75% of global knowledge workers using generative AI. The 78% "bring your own AI" figure applies to AI users, not to all workers. The survey was run by Edelman Data & Intelligence among 31,000 knowledge workers across 31 markets between 15 February and 28 March 2024. That is global data from 2024, not an Australian or current measurement.

Breaches and access controls. IBM's 2025 Cost of a Data Breach report is based on 600 organisations globally from March 2024 through February 2025. It found 13% reported breaches of AI models or applications, and 97% of those lacked AI access controls. The separate 63% figure covers all breached organisations that lacked an AI governance policy or were still developing one. The two numbers use different populations, so they should not be merged.

IBM also found organisations with high levels of shadow AI saw an average of $670,000 in higher breach costs. That is an association, not proof that shadow AI alone caused the difference.

Workforce. Randstad Australia's Workmonitor Pulse found 32% of Australian workers are worried about AI-driven job loss. It also found 48% of workers say they have been trained on AI tools, against 56% of employers who say their workforce has. That is a perception gap between two surveyed groups. It does not measure the quality of the training.

One figure I could not confirm. Maguire attributes to Gartner a finding that only 4% of CIOs had explicit plans to redesign roles for a human-agent workforce, and that those that did were 2.4 times more likely to be high AI performers. I could not verify those numbers or the method behind them. Treat them as the author's claim.

Why this matters on the Microsoft stack​

Maguire's Copilot point is the most practical one for Windows and Microsoft 365 shops. Microsoft's own documentation makes the same case. The Microsoft Learn oversharing blueprint says oversharing is one of the most common risks organisations hit when deploying Microsoft 365 Copilot, because Copilot surfaces information users already have permission to see.

So Copilot does not break your permissions. It makes the existing mess easy to search. Microsoft's blueprint names common causes: site privacy settings that grant access to everyone in the organisation, and broken permission inheritance. It recommends a phased Pilot, Deploy, Operate approach.

The tooling is there. According to Microsoft's blueprint and Microsoft's Tech Community post:

  • Permission State Reports in SharePoint Advanced Management cover broken inheritance, public links and excessive group access.
  • Site Access Reviews prompt site owners to clean up permissions.
  • Restricted Content Discovery can block an entire site from Copilot or agent processing regardless of access permissions.

Restricted Content Discovery hides content from Copilot. It does not fix the permissions underneath. A guide summarising Microsoft's documentation makes the same point about Restricted SharePoint Search, saying it is not a security boundary and does not change any permissions. Use these controls as containment while you remediate, not as the fix.

One licensing note: a third-party summary of Microsoft's documentation says assigning at least one Copilot licence gives SharePoint administrators SharePoint Advanced Management features. Check your own tenant's entitlements before planning around that.

The "anyone can build" problem​

The author's second theme is that plain-English agent builders let a marketer or finance analyst produce something that looks production-ready by lunchtime. His examples of what can go wrong are an app that stores customer data in the wrong place, connects with a person's own credentials, or exposes information publicly.

His dot-com comparison is anecdotal: hacked sites with no patching owner, and domains registered to individual staff. It is credible but unmeasured. The risk is plausible, and it matches what admins already see with personal-credential connections and orphaned automations. The answer he proposes is not to ban building. He wants:

  • approved platforms with data rules built in
  • every app and agent registered to the organisation, not an individual
  • a named business owner for each
  • IT review before anything touches customers or core systems

His seven moves, and how to read them​

These are recommendations, not a standard.

  1. Set guardrails early. That covers identity and permissions for agents, approved tools and privacy obligations. He cites the New Zealand Privacy Commissioner and Australia's OAIC. Both regulators tie their guidance to personal information. The OAIC's advice not to enter personal information into public AI tools is best-practice guidance, not a blanket legal ban.
  2. Make the approved path the easy path. If sanctioned tools are slower than free ones, shadow AI wins.
  3. Run a cross-functional AI group with HR, risk, legal and finance, convened by IT.
  4. Lead change with HR. He uses Prosci's ADKAR model: Awareness, Desire, Knowledge, Ability and Reinforcement. Prosci describes it as a model for individual change, not a complete change management methodology.
  5. Plan for learning and resistance over months, not a launch-day session.
  6. Measure value in business terms, not licence counts.
  7. Build capability inside IT and offer it to the business.

A balanced view​

The author has an obvious vantage point. He runs an AI consultancy, and his advice favours IT-led governance and structured change programmes. That does not make it wrong, but it is not a neutral position.

There is a fair counterargument. Heavy IT gatekeeping is exactly what drives shadow IT. His own second move, a fast route for business-led pilots, concedes this. The workable model is probably federated: business units own use cases, and IT owns identity, data, platform and monitoring. That is close to what he recommends once the rhetoric is stripped away.

A practical checklist for admins​

If you run a Microsoft 365 tenant, the argument reduces to a few actions:

  • Run permission and oversharing reports before widening Copilot licences.
  • Contain your highest-risk sites while you fix permissions.
  • Keep an inventory of agents and low-code apps, each with a named owner.
  • Review which credentials agents and connectors use.
  • Define where an agent must stop and escalate to a human.
  • Monitor after deployment instead of relying on one-time approval.

The takeaway is that AI governance is mostly identity, permissions and ownership, which are old problems. The difference is that an agent can now act on those problems at machine speed.

 

References

  1. AI isn't the next cloud. Don't let it outgrow IT - IT Brief Australia IT Brief Australia 2026-11-03T03:43:00+00:00
  2. 4 Actions CIOs Must Take to Redesign Human-AI Agent Work for AI Value gartner.com
  3. microsoft-365-docs/copilot/microsoft-365-copilot-blueprint-oversharing.md at public · MicrosoftDocs/microsoft-365-docs · GitHub github.com