LanternOpsField NotesManaged AI Teams
LanternOps Book a diagnosis →

← Field Notes

AI search over your file shares, without leaking the folders it shouldn't see

June 18, 2026 For Engineering, architecture, accounting, and professional firms with file shares and an aging DMS


The pitch is everywhere now: point AI at your network drives and finally search twenty years of files the way you search the web. It works in the demo. Then someone in the room asks the obvious question. When the assistant answers, does it know the HR folder, the partner comp file, and the sealed matter aren’t for everyone? Most of the time, nobody checked.

That question is the whole project. Settle it before you turn anything on.

Two ways “just point AI at the drive” goes wrong

The search is worse than you hoped. Files on a share are a pile, not a system. Twenty years of folders named by twenty different people, scanned PDFs with no text, the same project under three spellings. An AI that reads filenames and raw text gives you confident, plausible, wrong answers. It finds the 2019 version because it was named more clearly than the 2023 one. The demo searched a clean folder. Your drive is not a clean folder.

The search shows people things they could never open. This is the one that ends careers. On a Windows file server, who can open what is decided by NTFS and Active Directory permissions. The HR drive, the financials, the principals-only folder. Drop an AI index over the whole share and, unless you did something specific to stop it, that index has read everything. Now the assistant can quote a salary review to the person it’s about, because the model doesn’t know the folder was off limits. It was never told. Permissions live in the file system; the AI was pointed at the files.

Both failures come from the same mistake: treating “AI over file shares” as a tool you install instead of a system you operate.

The index is the asset, not the AI

If your firm has run a document management system for years, the part worth saving isn’t the software. It’s the index fields. The project number, the client, the document type, the date, the discipline. That structure is what made search work when it worked, and it’s why people tolerated the system they otherwise hated.

When a firm leaves an old DMS, the temptation is to dump the files onto a share and let AI sort it out. But the index fields are the real export. Carry them across, and AI fills the gaps where the metadata went patchy over the years. Throw them away, and you’ve asked the model to rebuild from filenames what people spent two decades recording on purpose. AI over a plain folder is a worse search than the system you just left. AI over a folder with a real index layer underneath is the search you always wanted.

So the order matters. Build the index layer first. Point the AI at that.

The one rule: it can only surface what the person could already open

Here is the rule that keeps an AI assistant out of trouble, written so a managing partner can hold the firm to it:

The assistant can never surface a document the person asking couldn’t open themselves.

Concretely, that means the search inherits your existing permissions instead of inventing its own. It mirrors the NTFS and Active Directory folder structure you already maintain. When someone in HR asks a question, they see HR results. When an engineer asks the same question, the HR documents aren’t in the answer, aren’t in a citation, aren’t hinted at. The permission model your firm already trusts becomes the permission model the AI obeys. You don’t manage a second set of rules, and you don’t hope the model behaves. The boundary is enforced before the model ever sees the document.

Most “point AI at your files” products gloss over this, or hand you an org-wide setting and call it governance. For a firm with HR records, client confidences, and partner-only material on the same server, org-wide is not a permission model. It’s the absence of one.

What good looks like

  • An index layer carried over from the old system and repaired, so search is accurate, not just fast.
  • Search results that respect NTFS and AD permissions, per person, every query.
  • A clear answer to “what can this assistant read, and on whose behalf,” in writing, before launch.
  • A human who owns the boundary and can show you, on demand, why a given person did or didn’t see a given file.
  • The whole thing scoped to one document workflow first, proven, then widened.

None of that is exotic. It’s the difference between buying a search box and operating a system that happens to use AI.

Start with one workflow

If your firm is leaving an old DMS, or just eyeing the file shares and wondering whether AI can finally make them searchable, the move isn’t to turn something on and see what happens. It’s to map the one document workflow that hurts most, decide what the assistant may read and on whose behalf, and prove it on that workflow before it touches the rest of the drive.

That’s the work we do in a workflow diagnosis. No tools installed, no data moved. We map how documents actually move through your firm, where the permission lines have to hold, and what an AI search would need to inherit to be both useful and safe. You walk out with the map whether or not you ever hire us.

Book a workflow diagnosis →

This is what a workflow diagnosis maps for your firm. No tools installed, no data moved.

Book a workflow diagnosis