Can software clear a conflict check on its own?

No, and you should be wary of anything that presents itself as doing so. Whether a match creates a conflict depends on facts that are rarely in any system: what a client told you in a first meeting, what confidential information survives a closed matter, whether an informed consent would be reasonable to seek. Software can find the match and hand it over with the evidence. The call is a person's.

What is the most dangerous failure in an automated conflict check?

A confident empty result. 'No conflicts found' reads as an all-clear, when it may only mean the search never reached the archived matters, or the party was entered under a trading name. Any automated check should state its own scope on the face of the result: which systems were searched, which were not, and as at what date.

Is this worth doing in a firm of five people?

Work out the arithmetic before deciding. Count the checks you run in a month, multiply by the minutes each one honestly takes including the chasing, and price that at the cost of the person doing it. Then count how many were run after the work had already started. The second number usually decides it, because that is the exposure, not the time.

What an automation can and cannot do in a conflict check

Why does the search half fail so often?

Because a firm's memory is scattered, and a manual check only reaches the parts someone remembers to look in.

The practice management system holds the open matters. The ledger holds everyone ever invoiced, including the ones who never became a file. The inbox holds the enquiry politely declined two years ago, which is often the one that matters. Then there are the pre-migration files that only exist as PDFs in a folder, the referral spreadsheet, and the partner who once had a coffee about a matter and never wrote it down.

Names make it worse. A company is searched under its trading name and stored under its legal one. A trust appears under the trustee. A person married, or anglicised a given name, or gave you initials. A subsidiary shares nothing textual with its parent. Human searchers compensate for some of this and quietly miss the rest, and they miss more when they are busy, which is exactly when intake volume rises.

None of that is a judgement problem. It is a coverage problem, and coverage is machine work.

What can an automation actually do?

Six things, all of them mechanical, and all of them things a person currently does badly under time pressure.

Collect the parties properly at intake. Not just the client. The other side, their advisers, the related entities the client has declared, the directors, the trustee and beneficiaries where relevant. A structured intake step makes this a form field rather than a memory test.
Normalise the names. Strip the entity suffixes, capture the company number alongside the name, hold known aliases and former names against the same record, and search all of them rather than the one that was typed.
Search every system the firm holds. Matters, contacts, the ledger, closed files, the archive, and the mailbox if your obligations and your privacy position allow it. The point is not that it searches better than a person, but that it searches all of them every time, including the ones nobody remembers.
Rank rather than filter. Show exact matches first, then close ones, then weak ones, and never silently discard the tail. Where the cut-off sits is a decision, so it belongs to a person, not a threshold buried in a script.
Write the record. Date, who ran it, which systems were searched, which terms were used, what came back, who reviewed it and what they decided. Most firms can describe their conflict process better than they can evidence any single instance of it.
Re-run itself when the facts change. Parties get added mid-matter, opponents get acquired, a new client arrives whose interests collide with an existing one. A check is a snapshot, and the snapshot goes stale. Re-running on change is trivial for a machine and never happens by hand.

Note what all six have in common. Each one is fully determined by information already sitting in a system.

What must it never do?

The line is not "AI is risky". The line is that some steps depend on facts that exist only in a person's head or judgement, and those steps cannot be delegated to something that cannot know them.

It must not clear a check. No status field that flips to approved without a named person putting themselves behind it.
It must not decide two matters are unrelated. That assessment often turns on what was actually discussed, not on what was recorded.
It must not weigh confidential information from a closed file. Duties can outlive the retainer, and only the person who holds the knowledge knows what is in it.
It must not judge whether consent or an information barrier is appropriate. That is a professional and sometimes a regulatory call, and in some situations no arrangement makes the work acceptable.
It must not talk to the client about any of it. No automated "we've checked and we're fine to proceed" email. The reply to a conflict question is drafted by a person, or it is not sent.

The simple test: if answering the step requires knowing something that was never written down, a person does it.

Where does an automated check quietly go wrong?

The failure people expect is a wrong match. The failure that actually hurts is a confident empty result.

"No conflicts found" is read as an all-clear. It might instead mean the archive was never connected, the entity was entered under a trading name, the integration silently stopped returning results in March, or the party was added to the matter after the check ran. An automation that produces a clean answer from an incomplete search manufactures confidence that nobody had before, which is worse than the honest uncertainty it replaced.

Design against it directly. Every result states its own scope on its face: systems searched, systems not searched, terms used, as at what date and time. If a data source fails, the run fails loudly rather than returning nothing. Someone checks monthly that each connection still returns results, using a known name that should always match. It is the same discipline as any build people come to rely on, and the same reason to know how it behaves when it breaks before you need to.

The other quiet problem is legacy data. Most firms have a cut-off date before which the records are not searchable. That is fine, as long as the output says so and everyone knows the older years remain a human memory exercise.

What does a sensible build look like?

Small, in that order, and none of it starts with software.

Write down what a conflict means in your practice. One page. What you search, what counts as a match, who decides, what gets recorded. Most firms have never written this, and no automation can be built on top of an undocumented rule.
Fix the intake capture first. If the parties are not collected in a structured form, everything downstream is guessing. This step alone improves manual checks.
Connect one system, then a second. Start with the two that hold the most history, usually matters and the ledger. Prove the search works before adding the harder sources.
Make the output a review sheet, not a verdict. Ranked candidates, the evidence, the scope statement, and a place for a person to record the decision and their reasoning.
Log every run. The record is half the value. It is what you produce when an insurer, a regulator or a client asks how the check was done.
Test it against your own history. Run it over a handful of past matters where you know a conflict existed. If it does not surface them, you have found the gap before it finds you.

What to do next

Take the last ten checks your firm ran and reconstruct each one on paper: which systems were actually searched, by whom, and what evidence survives that it happened. That exercise takes an hour and tells you which of the two halves is your real problem. If the answer is coverage and record-keeping, the search half is worth building and the arithmetic in the FAQ above will tell you how quickly it pays for itself.

If the answer is that the judgement sits with the wrong person or arrives too late, no automation fixes that. Shift takes the same position on any risk workflow: automate the assembly, hand the decision to a person, and make sure the record proves which was which.