AI and automation
AI
Artificial Intelligence
Artificial Intelligence, in the context most relevant to a Microsoft cloud estate, refers to software systems that perform tasks which have traditionally required human judgement: understanding natural language, recognising patterns in data, generating text or images, or making predictions and recommendations.
Why AI matters in a Microsoft estate
AI matters when teams want AI support without losing control of identity, data, approvals, and audit evidence. In the EfficientEther portfolio, AI terms usually connect to governed workflows, Copilot readiness, or agentic packaging where humans still review important outputs.
How AI shows up in practice
These systems generally work by having been trained on large datasets, rather than by following explicitly hand-coded rules for every scenario. The term spans a wide range of underlying techniques, from long-established machine learning models used for anomaly detection and forecasting to the large language models now embedded across Microsoft 365 through Copilot. It is worth being precise about which is meant in a given conversation, since "AI" is applied loosely enough in vendor marketing that it can refer to anything from a simple rules-based automation rebranded as AI to a genuinely capable generative model.
In the Microsoft ecosystem specifically, AI now shows up in three broad, distinct layers that IT teams end up managing separately. Built-in AI features are embedded in existing products, such as Defender's anomaly detection, Purview's data classification, or Viva Insights' pattern analysis, and mostly operate invisibly as part of a feature an organisation is already licensed for. Assistant and copilot experiences, principally Microsoft 365 Copilot, sit directly in the Office apps and Teams and are consumed conversationally by end users. Platform-level AI services, delivered through Azure AI Foundry, are where organisations build custom applications, agents, or integrations against foundation models rather than consuming a pre-built product.
Each of these layers carries genuinely different governance, cost, and data-handling implications, which is where a lot of AI adoption in Microsoft estates goes wrong in practice. Enabling a built-in AI feature is usually just a licensing and configuration decision. Adopting Copilot, by contrast, means accounting for what data it can see across a tenant's existing, and often over-permissive, SharePoint, OneDrive, and Teams permissions, since Copilot answers strictly within the existing access a user already has. Years of permission sprawl that were low-risk when the practical cost of finding an over-shared file was a manual search become immediately higher-risk once a copilot can synthesise and surface content a user technically had access to but was never realistically going to find.
Cost is a similarly layered problem. Built-in AI features are typically bundled into existing licensing, Copilot is a discrete per-user monthly add-on cost that needs active usage review to justify against adoption, and Azure AI Foundry usage is consumption-based against tokens processed. That means a custom AI application's running cost is much harder to forecast and cap than a fixed per-seat licence, and organisations building on it without token usage monitoring and budget alerts in place are exposed to genuinely unpredictable monthly spend in a way traditional Microsoft 365 licensing never was.