Blog
Should we connect an AI tool to our document management system?
Sometimes, but not first. A connection removes copying and uploading, and it also widens what the tool can reach, so permissions become the thing keeping you safe. Most small firms learn more by starting matter by matter.
Alesis · · 5 min read
Sometimes, but rarely as the first step. Connecting an AI tool to your document management system removes a lot of copying and uploading, and it also widens what the tool can reach in one go, which makes your permissions model the thing that keeps you safe. Most firms of four to fifty fee earners learn more, faster, by working matter by matter first and considering a connection once they know what they actually use the tool for.
What a connection actually means
"Integration" covers several different arrangements, and they carry different risk. Before anyone agrees to anything, establish which one is on the table.
- Read on request. The tool fetches named documents or a named matter folder when a fee earner asks for them, and nothing else moves.
- Bulk indexing. The tool copies or indexes the whole document store, or large parts of it, so it can search across everything.
- Write back. The tool saves drafts, notes or summaries into the file.
- Sign-on only. Staff log in with their existing firm credentials and no documents move at all. This is the lightest option and is often confused with the others.
A fee earner asking for a connection usually means the first of these. A supplier demonstration often shows the second. They are not the same conversation, and the second is the one that needs your compliance officer in the room.
Permissions are the hard part
Most document management systems were set up years ago and have been added to since. Permissions drift. Old matters sit in folders nobody has reviewed. Former colleagues' areas are still there. Information barriers were built for a world in which a person had to know a document existed before they could open it.
A search tool that reaches across the whole store removes that friction. If the tool does not reproduce your permissions exactly, a fee earner can be shown a document they were never meant to see, and they will not know it was a barrier breach because the result simply appeared in a list.
So ask, and get the answer in writing:
- Does the tool inherit permissions from the document management system, or does it keep its own separate list?
- If permissions change in the source system, how quickly does the tool reflect that? Immediately, overnight, or only when someone reindexes?
- What happens to a document already indexed when its permissions are tightened or it is moved behind a barrier?
- Can an administrator in the tool see content they could not see in the source system?
- What is logged, and can you produce a record of who asked what and what was returned?
If a supplier cannot answer the first three precisely, the connection is not ready for your client files, whatever the demonstration looked like.
The questions that follow from scope
A connection changes several things you have already thought about in another context, so revisit them rather than assuming the earlier answers hold.
Data protection. Widening the scope of processing is usually the point at which a data protection impact assessment becomes necessary, if you have not already done one. Record where the data goes, who can reach it, and on what legal basis.
Client terms and undertakings. Some client care letters, panel agreements and outsourcing arrangements limit where files may be held or who may access them. A bulk index of your whole store touches every matter at once, including those with the tightest terms.
Retention. Your document management system has a retention schedule. Does the tool's index follow it? If a file is destroyed under your policy, does the index still hold the content or a summary of it?
Leavers. Removing someone's document management access is routine. Removing their access to a connected tool, and to any conversations they created, needs to be on the same checklist.
Why starting narrow usually works better
There is a practical argument as well as a risk argument. Firms often find that the work they want help with is matter-shaped: get on top of this bundle, check these figures, pull the dates out of this correspondence. For that, giving the tool the papers for one matter is quick, and it has a useful side effect. You see exactly what the tool was working from, so when an answer looks wrong you can tell immediately whether the problem is the tool or the file.
A broad connection hides that. If an answer is thin, you do not know whether the document was missing, unindexed, unreadable or simply not reached. Diagnosing that across a whole store is slow, and it is the stage at which firms quietly stop using the tool.
Start narrow, use it for three months on real matters, and you will know whether a connection is worth the procurement effort. You will also know what to specify, which is a much stronger position to negotiate from.
Where Alesis fits
Alesis is used through the web browser, with one conversation for a matter, so the scope of each conversation is the papers you give it. It answers questions about the matter from those papers and names the page each answer came from, and if the papers do not say, it says so. Inside a firm, people see only the matters they are on, and seniority alone grants no view. Your information is held in the UK, processed only in the UK and the EU, kept apart from every other firm, and never used to train anything for anyone else.