Clean the Shared Drive Before You Connect AI Search

Tools & Technical Tutorials

4 October 2026 | By Ashley Marshall

The fastest way to make an AI assistant unreliable is to give it access to everything. Your shared drive needs decisions before it needs a connector.

A connector does not turn clutter into knowledge

Many AI search projects begin with a deceptively simple plan: connect Microsoft 365, Google Workspace or a network drive to an assistant and let staff ask questions. The connector may take hours to configure. The underlying information problem can take months to understand. A model cannot reliably distinguish an approved policy from an abandoned draft merely because both files are searchable. It sees content, metadata and permissions, not the organisational judgement that should decide which document is authoritative.

The latest GOV.UK guidance on using AI to manage shared drives describes legacy drives as one of government's largest unmanaged data estates. Some contain hundreds of millions of documents. The scale matters, but the pattern applies to a 50-person firm too: duplicates, uncommunicated drafts, departed-team folders and old customer records create competing versions of the truth. Retrieval can make that material easier to find without making it safer or more accurate.

This changes the first question leaders should ask. Do not start with, "Which AI search product should we buy?" Start with, "Which information should be available for which decisions?" Build an inventory of repositories, owners, age profiles, file types, permissions and obvious sensitivity. Identify the business processes the assistant will support. A sales proposal assistant needs a different evidence base from an HR policy assistant, and neither needs indiscriminate access to the whole file estate.

What this means in practice is a narrow first scope. Select one team, one document class and ten to twenty recurring questions. Name an accountable content owner. Exclude unknown and high-risk folders until they have been reviewed. A limited corpus that staff can trust creates more value than a universal search box that produces plausible answers from obsolete material.

Treat the file estate as a risk surface

Shared drives are not neutral storage. They are a live risk surface containing personal data, commercial terms, credentials, employee information and decisions whose context has disappeared. Connecting an AI assistant can expose those weaknesses because search becomes conversational. A user no longer needs to know a filename or folder path. They can ask a broad question and receive a synthesised answer assembled from several sources, including material they did not realise existed.

The National Cyber Security Centre's August 2026 advice recommends safeguards, sandboxing and active oversight for agentic systems. The same discipline belongs in enterprise search. Preserve source permissions, log retrieval events, restrict exports, and separate read-only search from tools that can move, edit or send documents. If the assistant can take actions, the content layer and the action layer need separate permissions. A poisoned or misleading document should not be able to trigger a consequential workflow.

Run a permissions review before indexing. Find folders with broad groups such as "Everyone" or inherited access that nobody can explain. Ring-fence HR, legal, finance and board areas. Check whether service accounts used for indexing have wider access than the staff who will query the assistant. Test the final user experience with accounts representing different roles, because a technically correct connector can still leak information through previews, summaries, citations or cached indexes.

Security teams should also create hostile test documents. Include a file containing instructions that try to redirect the assistant, a document with hidden or contradictory text, and an outdated policy presented as current. The NCSC's AI security guidance highlights prompt injection, hallucination and data poisoning as distinct risks. Testing them against your own corpus turns abstract warnings into observable controls.

Make retention and deletion decisions before indexing

The uncomfortable part of AI readiness is deletion. Organisations often retain files because storage feels cheap and nobody wants to make the wrong call. Yet retaining everything is not a safe default. Old personal data increases exposure, stale guidance degrades answers, and duplicate documents make retrieval less precise. The Information Commissioner's Office says organisations should erase or anonymise personal data when it is no longer needed, reducing the risk that it becomes irrelevant, excessive, inaccurate or out of date.

The government shared-drive guide offers a useful signal about the shape of a mature review: only a small proportion, estimated at 2 to 5 per cent in its public-records context, may have historical value requiring permanent preservation. That figure is not a deletion target for private businesses, but it challenges the assumption that every old file is equally valuable. Most organisations need explicit categories such as retain as authoritative, retain with restricted access, archive outside AI search, review with an owner, and dispose under an approved schedule.

Do not ask a model to make irreversible deletion decisions on its own. Use automation to profile age, duplicates, owners, file types and likely sensitivity, then route decisions to people who understand legal holds, contractual duties and operational value. Record the reason, approver and date for every bulk disposition. Where personal data is involved, involve the data protection lead early and complete a Data Protection Impact Assessment when the proposed processing is likely to create high risk.

What this means in practice is that the AI project needs records management expertise, not only IT delivery. Create a retention matrix before building the index. Block folders under litigation hold or active inquiry. Define how deleted content leaves both the source and any vector index, cache or evaluation dataset. The ICO's storage limitation guidance makes clear that retention needs justification and review, not habit.

Build an authority model the assistant can follow

Once the obvious clutter is reduced, the next job is to make authority visible. Staff often infer authority from context: a signed PDF beats a working note, the policy portal beats an email attachment, and the document owner can confirm the latest version. AI search needs those signals expressed in metadata and retrieval rules. Without them, a longer or more keyword-rich draft may outrank the short approved document.

Give every in-scope document a minimum metadata set: owner, business function, document type, approval status, effective date, review date, sensitivity and superseded-by reference. Where a platform supports content types or labels, use them consistently rather than relying on filenames. Mark authoritative sources and configure ranking to favour them. Exclude unapproved drafts from direct answers, or clearly label them as working material. If a policy expires, the retrieval layer should stop treating it as current even if the file remains available for audit purposes.

This authority model also improves citations. Every answer should show the source title, location, effective date and a link the user is permitted to open. If the assistant cannot cite a current source, it should say that it does not have enough evidence. That refusal is a useful product behaviour, not a failure. It tells the organisation where information ownership is weak.

A common counterargument is that modern models can work out which document is best. Sometimes they can, but probability is not governance. Two nearly identical contracts may differ in one liability clause. A staff handbook from last year can sound more complete than the current update. Models optimise for a useful response, while the organisation remains responsible for the decision. Put deterministic filters around dates, approval states and access controls before asking the model to rank meaning. The best assistant combines machine retrieval with a human-defined content hierarchy.

Test real questions, not a polished demonstration

A demonstration normally uses clean questions whose answers are already known. Production users do the opposite. They use abbreviations, ask incomplete questions, combine several issues and assume local knowledge. Build a golden question set from actual work before rollout. Ask each participating team for examples of questions that consume time, cause rework or produce inconsistent answers. Include easy, ambiguous, sensitive and deliberately unanswerable cases.

For every question, define the expected source, acceptable answer elements, prohibited disclosures and the correct behaviour when evidence is missing. Measure retrieval precision, citation accuracy, permission enforcement and usefulness separately. A fluent answer with the wrong citation is not a partial success. Neither is a correct answer shown to the wrong user. Track results by question class so a strong average does not conceal failures in HR, finance or customer data.

The adoption context makes this urgent. The Office for National Statistics reported in July 2026 that 55 per cent of employees said they used AI for work or education, compared with 35 per cent of businesses reporting use of at least one AI technology. The gap suggests that individual use can outpace formal organisational visibility. A trustworthy internal search service can reduce uncontrolled workarounds, but only if it answers real questions better than copying documents into a public chatbot.

Run the test set before launch, after every material content change and after model, embedding or retrieval configuration updates. Sample live queries with appropriate privacy controls. Let users flag wrong, stale or over-broad answers in one click, then route each issue to either the product team or the content owner. The operating metric is not the number of indexed files. It is the proportion of important questions answered with current, permitted and traceable evidence.

Use a 30-day readiness sprint before procurement expands

You do not need a year-long information management programme before testing AI search. You do need enough discipline to avoid turning a pilot into an uncontrolled production service. A 30-day readiness sprint creates evidence quickly. In week one, choose one workflow, one repository and one accountable sponsor. Inventory the content, confirm user groups and capture twenty recurring questions. Record a baseline for the time staff spend finding or checking answers.

In week two, profile the repository. Identify duplicates, abandoned drafts, unknown owners, stale files and sensitive folders. Agree a retention and exclusion matrix with information governance, security and data protection colleagues. Fix the most serious permission problems first. Do not migrate everything merely to make the architecture look tidy. The aim is to create a defensible corpus for a defined business use.

In week three, add metadata and authority rules, then configure a read-only search pilot. Require citations and refusal when evidence is weak. Run the golden question set using several user roles. Log false answers, missed documents, permission failures and questions with no approved source. In week four, let a small group use the service on real work while content owners resolve defects. Compare answer time, escalation rates and user confidence with the baseline.

At the end, make a decision based on evidence. Expand only if permission tests pass, high-value questions have reliable sources, deletion propagates to indexes, and somebody owns ongoing content quality. Pause if the project depends on broad service-account access, undocumented exceptions or users spotting every mistake themselves. The lesson from current UK guidance is not that businesses should avoid AI search. It is that well-managed information is a prerequisite for safe value. Cleaning the drive is not preliminary housekeeping. It is the implementation work that determines whether the assistant becomes trusted infrastructure or another source of uncertainty.

Frequently Asked Questions

Should we clean every shared drive before piloting AI search?

No. Select one bounded repository linked to a useful workflow, clean it to an agreed standard and prove the controls. Use the evidence from that pilot to prioritise the next repository.

Can Microsoft Copilot or another enterprise tool respect existing permissions?

Many enterprise tools are designed to preserve source permissions, but that does not make the existing permissions correct. Test with representative user roles and check summaries, previews, citations and cached results.

Do we need a Data Protection Impact Assessment?

Complete a DPIA where the planned processing is likely to create high risk for individuals. Even where a formal DPIA is not mandatory, document the purpose, data flows, retention, access and mitigations.

What belongs in a golden question set?

Use real recurring questions, ambiguous wording, sensitive cases, outdated terminology and questions the assistant should refuse. Define the expected source and acceptable answer before testing.

Can AI decide which old files to delete?

Use AI to classify, cluster and flag likely duplicates or stale material, but keep irreversible deletion under an approved retention policy with accountable human review and legal-hold checks.

How many documents should the first pilot include?

There is no universal number. Scope by workflow and evidence quality, not volume. A few hundred governed documents can be more useful than millions of unreviewed files.

What should happen when the assistant cannot find an approved source?

It should say that evidence is insufficient, show any limited context clearly and route the gap to a content owner. It should not fill the gap with an uncited confident answer.

Which metrics show that AI search is working?

Track citation accuracy, permission failures, successful answers to high-value questions, time saved, escalation rates, stale-source incidents and the speed at which content defects are corrected.