Insight: Artificial Intelligence and Automation
Before the agents, the foundations.
A large organisation with a wide footprint, whose data grew the way most data grows: from on-premises file shares, into SharePoint, and along the way into Azure Files. Two principal stores on different technology stacks, reached by different paths, with permission models that were never the same as each other. This is precisely the estate where an enthusiastic artificial intelligence rollout does real damage, and it is a common one.
A worked programme rather than a named client engagement. The sequence matters more than the specific platforms; the same reasoning applies wherever data has accumulated across more than one system.
The Hazard
Three facts that combine badly
Each is well known on its own. Together they describe why adoption on an unprepared estate is a governance incident waiting to be scheduled.
Fact One
It inherits the user's access
An assistant reaches exactly what the person running it can reach. Straightforward enough as a principle, and entirely dependent on those permissions being correct, which after a decade of organic growth they will not be.
Fact Two
The user does not know what they should not see
Nobody holds a list of the things they were never meant to have access to. Where permissions have drifted, the person is unaware of it, so there is no intent involved and no reason for them to stop.
Fact Three
It moves faster than any person could
Someone might spend years never opening the folder they should not have been able to open. With the right prompt, an assistant traverses everything reachable in seconds and summarises it on request. The exposure was always there. Now it is trivial to reach.
And agents raise the stakes again
Direct use by one person carries a lower risk, though not a removed one. An agent is different: it is given data connections at the point it is created, it carries the access its creator granted, and it is then shared with other people. Whatever reach was available during construction becomes available to everyone the agent is published to. One misjudged connection becomes an organisation-wide exposure.
The Surface
Everything in scope, whether or not anyone listed it
Assessments concentrate on the obvious repository and miss the rest. Select any store to see what it contributes.
The exposure was always there. What changed is that it became easy to find.
A permission nobody noticed for ten years is a different proposition once something can read everything reachable and answer questions about it.
The Programme
Seven steps, in this order
None of this is exotic work. It is unglamorous, sequential, and it is the difference between a rollout that holds and one that has to be withdrawn.
01 / Consolidate
One store, one archive
Bring the data together and deal with the remainder
Active data moves into SharePoint so there is a single governed store rather than two with divergent models. Everything else is archived rather than deleted: historic material still has genuine reference value, particularly for agents, and discarding it trades one problem for another.
Access to the archive is then revoked and reseeded deliberately, with departmental champions approving requests rather than access being inherited from whatever it was before. Critically, the process includes revocation: grants that are issued and never withdrawn are how the original situation came about.
02 / Audit Mailboxes
Delegation as intended
Validate mailbox delegation and shared access
Mail is a data store, and it is routinely omitted from this kind of assessment. Delegation arrangements accumulate over years, whether someone covering a role, an assistant granted access, or a shared mailbox added to a team. Each is validated against what it should be today rather than what it was when it was set up.
03 / Audit Permissions
Know, validate, document
Establish who can reach what, and confirm it is correct
A full permission audit across the consolidated store: who holds access, how they obtained it, and whether it is still appropriate. The position is then documented, so there is a baseline rather than a memory.
A change process follows, because an audit alone buys about a year. Requests raised through a defined route, approved by a data owner, recorded and reviewed.
04 / Classify
Workshop the data types
Identify what the data is, then tag it accordingly
Run as workshops with the people who actually own the material, because no technology function can classify a business's data from the outside. What types exist, what sensitivity each carries, who owns it. Tags are then applied consistently. Everything after this step depends on it.
05 / Retain
Lifecycle, not deletion
Set retention against the classifications
Building on the classification workshops, each type receives a retention position defining its lifecycle. The principle here is deliberate: nothing is deleted automatically. Instead, material reaching the end of its useful life is flagged and archived, which keeps the active store clean without anyone having to trust a rule with irreversible consequences.
06 / Protect
Controls on what matters most
Apply data loss prevention to the sensitive classifications
With tags in place, the most sensitive categories can be identified and given policies of their own. The important shift is that access is no longer the only control: even where a person is legitimately permitted to open something, downloading it, sharing it externally or deleting it generates an alert.
That is what turns a permission model into something observable, and it is what gives an organisation a chance of noticing an incident while it is still happening.
07 / Govern
Decide what is permitted
Establish an artificial intelligence position for the organisation
A company-level decision about which platforms are supported, what use is permitted and what is not. Then policy and technical control that prevents use of anything outside that set, because otherwise staff adopt whatever they find, business data leaves through channels nobody sanctioned, and the drift begins immediately.
One platform limitation worth knowing about
Capabilities differ by integration, and the differences are not always obvious. Microsoft Copilot, without the appropriate connector configured, cannot reach Azure Files at all. In this estate that mattered considerably: an assistant would have appeared to work correctly while being blind to a substantial body of historic reference material. Establishing what each tool can genuinely see, rather than what it is assumed to see, is part of the assessment rather than a detail to discover later.
Then, The Adoption
With the foundation in place
Only now does the interesting part begin, and it begins narrow, deliberately.
Purpose-built, not general purpose
Identify where an agent would genuinely help, then build for that specifically. A human resources agent. A stock agent. A tender agent. Each configured against only the sources it requires, rather than one assistant pointed at everything.
Published narrowly
Each agent reaches only the people who need it. The human resources agent goes to that team, the stock agent to those preparing quotes, the tender agent to the executive group. Scope of publication is a control, and it is the one most often overlooked.
Then connected to one another
Once individual agents are proven, they can be integrated so one draws on another. This is where compounding value appears, and it is only safe because the underlying classification and permissions were settled first.
Then opened to the people using it
Ask users where else they see potential. Once someone has worked with a basic agent and seen what it does, they identify opportunities no strategy document would have surfaced, because they know their own process better than anyone reviewing it.
The Point
Three different things, frequently conflated
Generative assistants, agents and automation are not interchangeable. Generative tools and agents exist to support people, to find, summarise, draft and advise. Automation exists to process a defined goal reliably, without judgement. Choosing between them requires knowing which of those a given problem needs, and a great deal of disappointment comes from applying one where another was required.
What they share is the dependency described above. None of them is safe to deploy across an estate whose permissions nobody can state with confidence. The foundation is not preparation for the work. It is the work.