AI and automation, adopted safely and put to real work

The right starting point depends on the work. Copilot is usually the sensible first option for general Microsoft 365 productivity, document support, meeting support, search and summarisation, but only after permissions and data exposure are understood. Automation is usually the better first step when the problem is a repeatable process: intake, approvals, reporting, notifications, handovers, document routing or exception handling.

A custom AI application or private AI pathway earns its place when the use case needs a controlled experience, a specific data source, stronger containment, integration with a business system, or a workflow Copilot cannot safely or clearly support. The decision should follow the work, the data and the risk, not the licence.

Copilot works inside Microsoft 365 and respects existing permissions, which means the readiness question is mostly about the environment around it. Before rollout, it is important to review SharePoint, Teams, OneDrive, external sharing, sensitive content, labels, permissions, audit visibility and the users included in the first pilot.

A good rollout should start with a defined pilot and a clear allow-list, not a tenant-wide switch. The licence is the easy part. Access, data readiness, user guidance, support ownership and monitoring are the work that make Copilot safe enough to scale.

Copilot can be safe when Microsoft 365 is properly governed. It operates within the Microsoft 365 service boundary, respects existing permissions and can be supported by audit, compliance and information protection controls.

The practical risk is usually internal oversharing. Copilot may surface files, chats or documents that users already had access to but may not have found manually. That makes permissions, information architecture, external sharing, labelling and audit visibility important before rollout. The tool is not the whole risk. The surrounding Microsoft 365 governance model is what determines whether the rollout is controlled.

OpenClaw or another private AI option should be considered when the use case involves sensitive information, stricter data boundaries, self-hosting requirements, privacy concerns, or a need to avoid sending data into general-purpose AI tools.

Private AI is not automatically the right answer for every use case. For general productivity, Copilot may be more practical because it sits inside Microsoft 365 and respects existing controls. For contained use cases involving sensitive data, internal knowledge retrieval, controlled assistants or more deliberate data boundaries, OpenClaw may be a better fit. The decision should be based on the data, the workflow, the users and the support model.

Automation is usually the better starting point when the work is repeatable and structured. Examples include request intake, approvals, reporting packs, notifications, exception handling, handovers, evidence capture and document routing. These problems usually need a better workflow before they need intelligence.

AI is useful where the work involves interpreting, summarising, classifying, drafting, searching or triaging information. Many good solutions use both, but adding AI to a messy manual process often creates faster output inside a process that still has no structure. The strongest approach is often to fix the workflow first, then add AI where it clearly improves the result.

Power Platform is used to build structured internal applications, workflow automation and reporting improvements inside the Microsoft ecosystem. Power Apps can provide the user interface, Power Automate can handle workflow and integration, Dataverse can provide the data layer, and Power BI can support reporting where required.

The platform is strongest when the process is internal, structured, permission-aware and connected to Microsoft 365 or business systems. It still needs engineering discipline: environment strategy, solution packaging, DLP policies, data modelling, testing, documentation and support ownership. Low-code should not mean unmanaged.

The first use case should be frequent, visible, painful and contained. It should solve a real operational problem without becoming a whole transformation programme. Strong candidates include request intake, approval workflows, reporting packs, document handling, knowledge retrieval, service-desk triage, finance administration and compliance evidence capture.

The first project should also teach the organisation how future AI and automation work will be governed. That means deciding who owns the workflow, what data it touches, where human approval is required, how exceptions are handled, how it will be supported and how success will be measured.

OT changes the risk profile. In business IT, automation usually affects documents, approvals, reporting, service workflows or Microsoft 365 processes. In OT or OT-adjacent environments, the work may touch operational systems, site processes, sensitive operational data, access boundaries or security constraints that need stronger control.

AI and automation should not be introduced into operational environments as a generic productivity experiment. The use case should be reviewed against safety, availability, segmentation, identity, access, logging, vendor support and operational impact.

In many cases, the right starting point is better reporting, workflow, evidence capture, documentation, knowledge retrieval or controlled decision support around the operational environment. Where Fortinet-led security conversations are already happening, AI and automation decisions should also consider segmentation, access boundaries, logging, vendor support and the security model around operational systems.