Do I need to tidy up my files before we use AI?
Less than you'd think — but there is something else that needs sorting first, and it's the step almost everyone skips on the way to switching the thing on.
Picture the first week. Someone in your office connects one of these tools to the company file store, which is the entire point of connecting it, and asks a perfectly reasonable question: what did we agree about the restructure? It answers thoroughly and with references, including the part drawn from a draft list of roles that had been sitting in a folder somebody shared with the whole company back in 2019 and never thought about again.
Nothing malfunctioned there; every step of it worked exactly as designed, which is the problem.
AI doesn't break your permissions, it reads them
This is the part worth understanding before anything else, because it changes what you're actually fixing.
For the most part, these tools don't get their own key to the building. They connect through a person's account and they reach what that person could already reach, and nothing more. Microsoft says it plainly in their own deployment guidance for Copilot: it works by "grounding responses in the data users already have permission to access". Tools like Claude and Cowork generally behave the same way when you connect them to a file store, because they're authenticating as the person using them.
Two exceptions are worth knowing about, because they're the ones that bite. An agent set up to run on its own schedule can be given access in its own right rather than borrowing somebody's, and a connector can be configured to make an entire source visible to everyone in the business regardless of who could see it where it came from. Both of those make getting permissions right more important rather than less, so if anyone sets one up, that's the moment to ask whose access it is using.
So the uncomfortable conclusion is that the tool didn't expose anything. Your permissions did. That draft list of roles was readable by everyone in the business on Tuesday, before anyone had heard of AI, and it was readable on Wednesday too. The only thing that changed was how easy it became to stumble across.
Why it only becomes a problem now
Because until recently, bad permissions were protected by bad search.
To find something in a shared drive, you had to know it existed, roughly what it was called, and roughly where somebody had put it. That's a genuine barrier, and most businesses have been quietly relying on it for twenty years without ever deciding to. Obscurity was doing the work that access control was supposed to be doing.
Now you ask a question in ordinary English and something goes and looks — across every folder, every attachment, every document nobody has opened since 2021 — and reads all of it, in seconds, without needing to know what any of it was called. Every "just share it with everyone for now, we'll sort it later" from the last decade is suddenly load-bearing.
For what it's worth, the regulator's numbers point the same way: the OAIC recorded 1,205 data breach notifications in 2025, the highest since the scheme began in 2018, and of the 532 reported in the first half of that year, human error accounted for 37% — up from 29% in the period before. Most of that isn't hacking. It's ordinary people, and ordinary settings, doing ordinary things.
Permissions first. Tidiness second
Here's where I'd push back on the way this usually gets sold to you.
You will be told that you need to get your data in order before you can use AI — a proper taxonomy, consistent naming, everything filed where it belongs. It's usually said by someone who would be delighted to spend six months helping you do it, and it is mostly not true. You can get real value out of these tools with a file store that is a bit of a mess, because the tool is far better at coping with mess than any of us are.
Permissions are different, and they are not optional. Get them wrong and the failure isn't a worse answer, it's the wrong person reading the redundancy list, or the salary spreadsheet, or the legal advice, or a client file they had no business seeing. One of those is an inconvenience you can improve over time. The other is a conversation with a staff member, a client or a regulator that you cannot take back.
It helps that the two jobs fail in completely different directions. If your quoting templates are scattered across four folders under six different names, the worst case is that you get a mediocre answer and go and find the right file yourself, the way you always have. If your payroll folder is readable by the whole company, the worst case is considerably harder to walk back.
So separate the two jobs, and don't let the big one delay the urgent one. Messy and correctly permissioned is a perfectly good place to start. Tidy and wide open is not.
Go wide and flat
If you are going to change anything structural, this is the change worth making, and it's smaller than a reorganisation.
Most businesses build downwards: a drive, then a folder, then a folder inside that one, then eleven more, and somewhere seven levels down is the thing you were looking for — with somebody's one-off permission change applied halfway down the tree, years ago, for a reason nobody now remembers. Nobody can see who has access to what, because working it out means opening every level and checking each one by hand, which is why nobody ever does.
The alternative is to go sideways instead. Use separate document libraries or sites for each body of work, keep them shallow, and let the library itself be the boundary — so access is a property of the library rather than something buried in a tree. Inside it, sort things with metadata and saved views (by client, by year, by status) rather than by burrowing further down. You get the same organisation without the nesting, and you can answer "who can see this?" by looking at one list.
This isn't me being opinionated; it's what Microsoft has recommended for years. Their guidance for SharePoint is to break permission inheritance "as infrequently as possible", and to put content that needs different permissions into its own document library or site rather than carving exceptions out of a shared one. That particular page documents their on-premises server product rather than the cloud version, but the reasoning transfers directly and the cloud tooling is built around the same idea.
In a contracting business that might mean a library for jobs, one for plant and compliance, one for the accounts, and a separate one for HR that only three people can open; in a practice it might be client matters, the practice's own administration, and a partners' library. The point is not the particular split, it's that each one has a door you can point at, and the sensitive material sits behind a different door rather than deeper inside the same room.
The real benefit for a business your size is that this is achievable in an afternoon or two. You are not reclassifying twenty years of documents; you are deciding which handful of things need their own front door, and then giving them one.
What to do before you switch anything on
Six things, and none of them needs a consultant to start.
Write down what must not be broadly readable. Payroll and HR files, anything about individuals, board or partner material, legal advice, and anything a client contract obliges you to keep restricted. It's a short list in most businesses, and it's the whole job.
Find out who can currently reach each of those. Not who uses them — who can. That distinction is the entire exercise, and the answer is usually worse than anyone expects.
Give the sensitive things their own home — a separate library or site with its own access list, rather than a locked folder sitting inside a general one. Exceptions carved out of shared spaces are what stop being true over time.
Deal with the broad sharing links. Anything shared with everyone in the organisation, or with a link that works for anyone who has it, is the first place to look. If you hold Microsoft 365 Copilot licences or the SharePoint Advanced Management add-on, the admin centre has reports built for this, including one showing the sites where content was shared with your whole organisation over the past month. Without either, you're checking by hand, which is slower and still worth doing.
Give every area an owner. One named person who decides who gets access. Permissions rot when they belong to everybody.
Then start small. Two or three people, one part of the business, before anyone talks about a rollout.
The test that actually tells you
Do this before anyone else gets access, and it takes about twenty minutes.
Connect the tool for two or three people at different levels of the business, and then be deliberately nosy with it. Ask it what's in the payroll file. Ask what the leadership team discussed last quarter. Ask what a named person earns, what's in their file, what the plans are for their department. Ask it to find anything marked confidential.
Whatever comes back is what any member of staff could have found the moment you switched it on, so you would much rather find out now, with three people watching, than in six weeks from someone who wasn't meant to see it. Write down every hit, fix the access behind it, and run the same questions again.
It's a crude test, and it works better than any audit report, because it asks the question the way your staff will actually ask it.
Sorting out who can see what is not glamorous and it's the thing that most often gets skipped, because it sits between IT and management and nobody quite owns it. An AI Readiness Day is a day in your business doing exactly this kind of groundwork — where AI fits and where it should stay out, what your staff can use and on which data, who signs off, and a costed roadmap of what's worth building once the guardrails are in place. $3,500 + GST, with a credit towards a larger project if you commission one within 30 days.
Sources, checked 22 September 2026: Microsoft Learn — foundational deployment guidance for securing and governing Copilot, guidance on fine-grained permissions in SharePoint, and getting ready for Copilot with SharePoint Advanced Management. OAIC — Notifiable Data Breaches statistics for 2025 (published 6 July 2026) and for January to June 2025 (published 4 November 2025). General information only, not legal advice.
