A managing partner recently asked me: which AI chatbot should his firm buy? He is our happy customer and among the most forward-thinking lawyers I’ve met.

He is not the first senior lawyer to ask me this. White-collar workers all over the world have found AI chatbots useful, and legal work is no exception.

This is my practical view as at May 2026: a starting point, not a permanent ranking, because model quality, usage limits, features, and privacy terms can change quickly.

First, select the right product tier

Before comparing products, there is an important caveat: the relevant distinction is not simply free versus paid.

Some paid tiers are still consumer products, and may not give the firm the no-training commitment, admin controls, access controls, retention controls, and internal usage policy it needs.

The Law Society has already warned lawyers about publicly available AI tools that are not designed for business or enterprise use. I wrote about that recently.

That warning still applies here. If a firm is going to upload privileged, confidential, client, or opposing-counsel documents, it should not do that through unmanaged consumer accounts. It should use business or enterprise AI with the correct legal and operational safeguards, and review whether prompts, uploads, and outputs may be used for model training or service improvement.

This sounds tedious, but it is the price of taking professional obligations seriously.

Powerful, but not simple

AI chatbots are powerful, but not simple.

There are different underlying models, product interfaces, file-handling systems, project workspaces, connectors, memory features, and reasoning modes. Even within the same product, one model may behave differently from another. A newer model may be better at reasoning but worse at style. A faster model may be good enough for many tasks but less reliable for difficult ones.

That is why these tools work best with people who are motivated to experiment.

The user does not need to become a software engineer. But the user does need enough initiative to test different approaches, notice failure modes, and keep asking the tool to improve the answer.

Some lawyers will naturally push the tool hard. Others will try it once, get a bad answer, and give up. If the firm starts with the wrong product, the wrong tier, or the wrong use case, the risk is that people come away thinking AI is not useful, when the real problem was the setup.

Where AI chatbots are good

AI chatbots are strongest when the work is open-ended, ambiguous, and text-heavy.

They are good at reading, summarising, comparing, reorganising, and synthesising large amounts of material. They can help a lawyer test an argument, identify themes, produce a first-pass chronology, compare versions of a document, or work through research across many sources.

That does not mean the answer can be accepted blindly. It cannot. The lawyer still has to check the source material, exercise judgment, and verify the law.

But as a thinking partner for messy text work, the best AI chatbots are already useful.

I know litigators who use these tools to sift through large document sets, identify potentially relevant material, and work out where human attention should go first.

A friend goes further. When opposing counsels serve large document dumps at the last minute, in the name of their Kadar disclosure obligations, he can avoid turning the firm’s associates into an all-hands document review team. He uses AI not just to review the documents, but to help build custom visualisations from them. Those visualisations then help him decide which documents to single out in court during cross-examination.

That is the kind of use case where general AI starts to matter: not because it replaces legal judgment, but because it helps a lawyer find structure in material that would otherwise take far longer to work through.

For ambiguous work with a critically engaged user, these tools can be very good.

Where AI chatbots are weaker

AI chatbots are less convincing when the firm needs a repeatable workflow.

If the task is prescriptive, high-volume, and expected to produce consistent structured output every time, a blank chatbox is often the wrong interface. The user has to know what to ask, how to upload the context, how to constrain the answer, how to check the result, and what to do when the answer is subtly wrong.

That is a lot to ask of every lawyer, paralegal, and secretary in the firm.

This is where specialised legal software should earn its keep. It should absorb the prompting complexity into the workflow: what documents matter, what fields have to be extracted, what source links need to be preserved, what exceptions are common, and what format the lawyer needs at the end.

In other words, AI chatbots are excellent for open-ended thinking. They are less good for complex, repeatable workflows.

ChatGPT Business

ChatGPT Business is my default first recommendation for most law firms.

The model quality is strong, the interface is familiar, file handling is good, and Projects can be used as lightweight matter workspaces. A project can hold instructions, chats, and uploaded files, so the lawyer does not have to start from a blank context every time.

It also tends to be less frustrating for broad daily use because the usage limits are generally more forgiving than Claude’s. That matters if lawyers are asking many follow-up questions, testing, revising, uploading more material, and trying again.

For a controlled pilot, ChatGPT Business is probably the best default starting point.

Claude Team

Claude Team belongs on the same shortlist.

Many lawyers like Claude for reading, summarising, and drafting from long documents. Depending on the exact model, and these models change quickly, some users prefer Claude’s more conversational style and personality.

Claude Projects are also useful because they keep related chats, documents, and instructions together.

Claude also now has a Legal plugin, aimed mainly at in-house counsel use cases such as contract review, NDA triage, compliance workflows, legal briefings, and templated responses. Law firms would still need to test it carefully against their actual work, but it is another reason Claude is worth taking seriously.

The main practical concern is usage limits. Heavy users may hit them more quickly than they expect, especially if they are doing long-document work.

So I would treat ChatGPT and Claude as roughly equal candidates, with ChatGPT probably the better default for broad firm-wide use because of usage headroom.

Microsoft 365 Copilot

I would be careful with Microsoft 365 Copilot.

On paper, it sounds like the obvious choice for many law firms. Most firms already use Microsoft 365. Copilot sits inside Word, Outlook, Teams, and the Microsoft ecosystem. Some firms may also be offered discounts or bundled pricing.

Many of my customers have tried it. The feedback has not been enthusiastic. Several have told me they are much happier using our product than trying to make Copilot do the same work.

That does not surprise me. Microsoft has often won by bundling middling products into software that companies already buy, then relying on distribution. It is not a new strategy. But convenience and bundling are not enough.

Beyond anecdotes, this recent piece has the receipts. The author gave Microsoft Copilot duplicate synthetic datasets that should not have supported meaningful group differences. Copilot nevertheless produced confident cultural explanations from noise.

That is exactly the kind of failure lawyers should worry about: not an obviously ridiculous answer, but a fluent answer that sounds analytical while inventing significance that is not really there. In this case, the same experiment was run on other leading models, and they did not fail in the same way.

But if the question is what I would recommend a law firm start with today, Microsoft 365 Copilot would not be my default.

The stakes are higher than they may seem.

If a firm’s first serious AI rollout is a mediocre tool, that can be worse than no rollout, because it teaches lawyers the wrong lesson: not that Copilot is weak, but that AI is overhyped.

Gemini

Gemini is credible if the firm is already Google Workspace-native.

Compared to ChatGPT and Claude, the perception is that Google Gemini is not as polished but rapidly catching up.

If the firm already works heavily in Google Drive, Gemini and NotebookLM may fit naturally into existing habits. But I would not switch a law firm to Google Workspace just to use Gemini.

Perplexity

Perplexity is useful for research, web search, and current-awareness work, especially where sourced answers about recent developments matter.

But I would treat it as a research add-on, not the firm’s main workspace for privileged matter documents.

If a firm wants to use Perplexity seriously, it should use the enterprise tier and review retention, training, and data-sharing terms carefully.

Beware account sharing

I know firms that reduce cost by buying one paid AI account and letting several lawyers or staff share it. I understand why. Some firms are rightly cost-conscious, especially if they are still testing whether these tools are worth paying for.

But for privileged or confidential legal work, I would be careful. I have written before about why seat-based pricing can create awkward incentives, but account sharing is not the right answer for confidential legal work.

Account sharing means weaker user accountability, weaker matter separation, harder offboarding, poorer auditability, and higher risk that confidential information is exposed to the wrong person.

A better low-cost approach is to buy a small number of seats for a controlled pilot, assign them to specific lawyers or staff, and restrict privileged-document uploads to approved business or enterprise workspaces only.

My practical recommendation

For most law firms, I would start with a controlled pilot of ChatGPT Business and Claude Team.

Give seats to people who are motivated to experiment, and test the tools on real but appropriate work: long-document review, chronology building, research synthesis, drafting, and internal knowledge work.

If the firm is already Google Workspace-native, test Gemini too. Use Perplexity as a research add-on if it fits. I would not lead with Microsoft 365 Copilot just because it is familiar, discounted, or bundled.

The AI wave is just beginning

I have no doubt that AI will transform white-collar work.

I have spoken to lawyers who can already tell when clients are using AI to help write emails. Sometimes that is useful. Sometimes it means the lawyer has to work through a great deal of confident, verbose slop before getting to the actual issue.

That is annoying, but it is also revealing. The wave is already reaching clients, opposing counsel, staff, and lawyers themselves. Law firms that adapt to this wave early will have an edge.

But adopting AI is not just about choosing a chatbot.

Chatbots are the most visible entry point. The deeper change is how legal work will be searched, reviewed, drafted, structured, checked, and managed.

This is why I liked the managing partner’s question. He was not asking whether a generic AI tool should replace the software his firm already uses. He was asking what else his team should have in its toolkit.

That is the right frame.

If a product is just a thin wrapper around a general AI model, it is vulnerable.

But if the product is built around actual legal workflows, jurisdiction-specific practice, firm templates, source-checking, structured outputs, and the way staff really work, then general AI is complementary.

That is the role I want Northbridge Lab to play for our customers. Not pretending every problem needs our software, and not pretending generic AI tools are irrelevant. The point is to partner with law firms to work out what belongs where.

For general AI chatbots, my answer today is simple: start with ChatGPT and Claude.

MikeOSS went viral because of a simple claim.

Its creator, Will Chen, is a former Latham & Watkins associate who has branded MikeOSS as “the open source alternative to Harvey and Legora”. He said he had built the core web application of Harvey and Legora in two weeks, and was releasing it as open-source software.

That is a bold claim. Harvey and Legora are among the most talked-about legal AI companies in the world. Harvey was reportedly valued at US$11 billion. Legora has also raised at a multi-billion-dollar valuation and has reportedly crossed US$100 million in annual recurring revenue.

MikeOSS presents itself as an open-source alternative to both. Its visible feature set is familiar: an assistant, document projects, tabular review, and reusable workflows.

Open-source software is software where the source code is publicly available. That means people can inspect it, run it, modify it, and, depending on the licence, build on top of it. MikeOSS is released under the AGPL licence, which generally allows users to use, study, modify, and share the software, but may also require modified source code to be made available in some circumstances.

Whether MikeOSS is production-ready is a separate question. Rather, it accentuates what lawyers should have been asking when evaluating legal AI all along.

The token reseller critique

Chen’s criticism goes further. In a post describing his “token reseller theory”, he argues that Harvey and Legora are “essentially sales organisations that resell tokens”. Tokens are the units of text that AI model providers charge for when software sends information to a model and receives an answer back. In his view, Harvey and Legora “slap on a UI” that makes them look different from ChatGPT, but the core web-app features are essentially a chatbox, project uploads, tabular review, and workflows that are custom prompts.

That is a deliberately provocative framing, and Harvey and Legora are probably not losing sleep just yet.

MikeOSS may have reproduced the core visible features of those products, but it does not have the trappings of enterprise software: security reviews, procurement clearance, integrations, support, governance, training, auditability, and all the other things that make software acceptable inside a risk-sensitive law firm.

But the critique is still useful because it sharpens the buyer question: is this product adding real legal workflow value, or is it mostly a polished way to access the same underlying AI models through a legal-themed interface?

Lawyers already know AI can be useful

Many lawyers I speak to are already getting real value from ChatGPT, Claude, and Gemini. They use these tools to work through voluminous documents: finding relevant passages, summarising background facts, comparing documents, and testing their thinking.

And they get all this for tens of dollars a month.

There are a few reasons for that. AI companies are also subsidising usage to win market share. They are going after generic white-collar work at enormous scale, which is what they need to justify their valuations. Most importantly, this kind of work is what large language models are inherently good at: reading, summarising, comparing, reorganising, and drafting text.

That does not mean lawyers should be careless. As I have written previously, the exact product, tier, data-retention terms, and model-training terms matter. So does professional judgment: lawyers still have to read the source material, check the answer, and do their own legal research.

With those caveats, generic AI is already useful for a lot of legal work. The real question is what legal tech adds on top.

I think the answer has three layers.

Legal AI has three layers

When lawyers evaluate legal AI, they should separate the product into three layers: model access, generic wrapper, and practice fit.

Model access is the underlying AI intelligence from Claude, GPT, Gemini, or another large AI model. This layer is improving very quickly, and is increasingly available through many different providers. Responsible vendors still have to manage provider terms, data handling, retention, security, reliability, model selection, and the real cost of enterprise-grade usage.

The generic wrapper is the software interface placed around that model: the chatbox, document upload button, project folder, matter workspace, prompt library, reusable workflow button, or table that runs extraction across documents.

Practice fit is how well the product adapts to the actual legal work: the jurisdiction, practice area, document types, firm templates, house style, staff workflow, source-checking, and output format.

This distinction matters because vendors often blend all three together.

The product may look impressive because the model is impressive. It may feel polished because the wrapper is polished. But the question for the firm is whether the product actually fits the way the practice works.

That does not mean the wrapper is worthless. A good interface, good document handling, good citation design, and good collaboration features all matter.

But lawyers should be careful about paying enterprise prices for model access and generic wrapper alone. MikeOSS is a reminder that some of the visible interface layer may be easier to reproduce than buyers assumed.

In my humble opinion, the real value is in fit. That means knowing what has to be extracted, how it should be structured, what has to be checked, what source material must be linked, what exceptions are common, and what the lawyer needs to decide next.

That is much harder to commoditise than a chatbox, because it cannot be replicated by someone in San Francisco or Stockholm.

No chatbox here

A blank chatbox can be useful for exploration. It is less convincing as the centre of a production workflow.

This is partly a change-management problem. Even senior lawyers who are comfortable with technology tell me that prompting AI can be a pain. They do not necessarily want to learn a new technique just to get consistent results. That problem becomes larger when the users are secretaries, paralegals, and junior staff who may be less motivated to experiment with prompting.

The better approach is usually to absorb that complexity into the software. The AI should sit inside the workflow, not become the workflow itself.

The user should see the matter, the documents, the extracted facts, the missing information, the source links, the calculations, and the next decision. The product should narrow the task and make adoption easier, not ask every user to become a prompt engineer.

That is also why I think legal tech companies should be careful about building features that lawyers can already get from ChatGPT or Claude. If it is not sufficiently differentiated, it is probably not worth building.

This has affected how we work with firms at Northbridge Lab. We are looking for partners, not just customers.

We bring a core AI engine, but we do not treat the product as one-size-fits-all. We adapt it to the firm’s domain, workflows, templates, and preferred outputs. The point is not to give the firm another chatbox. It is to make AI fit the way the firm already works.

The real lesson from MikeOSS

MikeOSS does not mean every law firm should operate its own legal AI platform. It also does not mean Harvey or Legora are worthless.

But it should make lawyers less impressed by generic AI wrappers.

If a product mainly gives you another place to upload documents, ask questions, and receive fluent answers, the bar should be high. General AI tools already do a lot of that surprisingly well, and they do it at a price that dedicated legal tech vendors will find hard to match.

The harder work is making AI useful inside the actual practice.

That means understanding the documents, the bottlenecks, the judgment calls, the source-checking, the staff who will use the system, and the format in which the lawyer needs the answer. It also means understanding the firm’s style: how it drafts, how it reviews, how it wants outputs presented, and what its clients expect.

That kind of fit cannot be solved by a generic prompt written for a global market. It has to be worked out with the firm and then embedded into the software.

That is where we are trying to compete at Northbridge Lab.

Not by giving firms another chatbox, but by adapting a core AI engine to specific Singapore legal workflows and firm-specific ways of working. The aim is to make AI feel like part of the work rather than another tool people have to learn.

So if you are evaluating legal AI, ask a more uncomfortable question: could ChatGPT or Claude do this in 18 months?

If the answer is yes, you may just be paying a huge markup for a temporary wrapper sitting directly in the path of OpenAI and Anthropic.

If the answer is no because the product understands your practice, your documents, your templates, your staff, and your way of working, that is different.

That is where legal AI becomes useful software.

Most conversations about legal AI focus on capability. Can it draft, summarise, extract information, or search effectively?

Those questions matter. But firms should also ask a more commercial question: what behaviour does the vendor’s pricing model encourage?

AI accentuates these tensions. If software can take over more tasks, law firm owners should be thinking harder about how to run leaner, more productive teams.

Thus, software pricing becomes a question of incentive design.

The problem with seats

Seat-based pricing is familiar. Practice management systems, case management systems, document tools, and even many recent AI products like Harvey and Legora have a significant seat-based component.

The problem is that seat-based pricing sits awkwardly with AI.

If the vendor makes more money mainly when the firm adds users, the vendor benefits when headcount grows. But better software should often do the opposite: help the same team do more, or help a smaller team handle work that previously required more people.

It also discourages proper usage. The best software system is one where everyone who needs it can log in: lawyers, paralegals, and secretaries. That is how the whole firm becomes more productive.

If every login costs more, firms may start rationing access. Some may reuse accounts across multiple people. The vendor then has to police usage, creating a pointless cat-and-mouse game.

That is bad for productivity, auditability, and security.

The one-off build trap

There is another common model: a large upfront project.

Sometimes this is encouraged by subsidies or grants. Subsidies can be helpful. They lower the barrier to adoption and make it easier for firms to try new technology. If a subsidy only applies for one or two years, both buyer and vendor may be tempted to front-load as much cost as possible into a large bill. The firm pays less out of pocket. The vendor gets paid early.

Sometimes this is how many business owners think about cost. A one-off project fee can feel easier to accept than an ongoing subscription.

But upfront projects can distort incentives. The problem is that software does not stop needing work after the invoice is paid.

Legal practice changes. Staff change. Templates change. Court processes change. Firm preferences change. Once software is used on real matters, people discover edge cases and requirements that nobody could have fully specified upfront.

AI makes this more acute. It is cheaper than before to generate software features, but it is not simple to operate software responsibly. Models launch, improve, and deprecate quickly. Providers change pricing. Capabilities shift. What was the best setup six months ago may not be the best setup today.

Someone still has to manage security, uptime, data handling, provider changes, model behaviour, user feedback, workflow adjustments, and support. That work does not fit a one-off project model very well.

I have spoken to many law firms that had built a one-off software project. Later, when they wanted changes, the problems began.

The original developer may have moved on. The person who understood the system may no longer be available. The vendor may not be interested because the profitable part of the project is already over. Or the firm may be quoted a very high amount for a very small change because it has no easy alternative.

This is not always bad faith. Often the commercial model was wrong from the start. A one-time payment rewards delivery of the first version. It does not necessarily reward responsiveness, maintenance, careful operations, or continued improvement.

Subscription pricing, done carefully

The better alternative is usually some form of usage-based subscription pricing. It avoids the worst problem of one-off builds because the vendor has to keep earning the customer’s business over time.

But care is still required.

A larger firm may have more matters, more documents, and more AI usage. It may extract more value and impose higher operating costs. So it is not obvious that a five-person firm and a fifty-person firm should always pay the same amount.

The principle is simple: pricing should track value.

This is especially true for AI software because usage has real marginal cost. The current AI build-out dominating the news relies on expensive chips, dedicated data centres, and huge amounts of electricity. These are passed on to operators of AI software as token costs.

That points toward usage-based pricing. But usage is hard to define well. The software operator needs enough predictability to cover costs. The buyer needs something understandable, budgetable, and not full of hidden surprises.

In practice, this becomes an ongoing conversation with customers. Different firms need different things. Some need a narrower workflow at a lower price point. Others need heavier AI processing, more document volume, or more firm-specific configuration.

That is the direction we are taking: modular pricing based on what the firm actually needs, with sensible volume caps. It is less tidy than a per-seat table, but it is more honest. The aim is to customise enough to make the software work without pricing in a way that makes the firm use it badly.

What buyers should ask

When evaluating legal software, law firms should ask what the pricing model rewards.

For example:

• Does pricing reward the vendor for helping us become more efficient?

• Does pricing track value and cost, or mainly tax headcount?

• Can the whole team use the system properly?

• What happens after the first version is delivered?

• What happens when our requirements, AI providers, or model capabilities change?

These are pricing questions, but they also tell you what kind of relationship you are buying.

Our incentives

At Northbridge Lab, we have absorbed a substantial amount of upfront development cost, which is now well into mid six-figure territory.

This is the bet we are making: that the verticals we’ve picked are large enough and the problems common enough for us to absorb the upfront development cost and recover it through subscription revenue over time. But that is exactly why the incentives are aligned: we only win if the software keeps being useful.

We charge a monthly subscription because we want to keep improving the software as firms use it. We do not want every useful improvement to become a separate mini-procurement exercise. If the product is not useful, customers will not keep paying. If workflows are awkward, we have a reason to fix them. If the AI landscape changes, we have a reason to keep evaluating the setup.

Clients sometimes ask why our products cost more than, say, something from Microsoft. The answer is partly scale. Microsoft can spread development cost across a global customer base. We cannot.

But the tradeoff is fit. Generic software is cheaper because it is not built around your practice area, your jurisdiction, your documents, or your workflow.

Clients who work with us will tell you that we are responsive to changes, including firm-specific workflow changes. Good luck getting Microsoft to adjust Copilot for your firm.

That fit is why I am confident specialised software can make a real difference to staffing pressure. The point is not to add another tool to the pile. It is to remove enough manual work that the same team can handle more, or that the firm can grow without headcount growing at the same rate.

That is what aligned incentives mean to me: not a one-off build, not a tax on logins, but software that has to keep earning its place.

AI should help law firms become leaner and more productive.

The software vendor’s incentives should point in the same direction.

Many lawyers instinctively prefer local, on-prem systems over the cloud. That instinct is understandable. A server in the office can feel more tangible, more controllable, and somehow safer.

It is often paired with another misconception: law firms are not allowed to use the cloud.

That is not what the Law Society says.

In its Guidance Note 3.4.1 on cloud computing, the Law Society says something quite clear: provided the relevant issues are properly addressed, it has no objection to the use of cloud services. (Amusingly, if you look closely at the link above, the PDF itself is hosted on Amazon Web Services, the pioneer of cloud services.)

That is an important distinction.

The guidance is not saying, “never use the cloud”. It is saying: understand the risks, choose your provider carefully, and put the right contractual and operational safeguards in place.

That matters because the real comparison is often not just about what is allowed. It is about what is cheaper, easier to maintain, easier to change.

Why the guidance sees value in the cloud

It is also fairly direct about the benefits.

Lawyers can work remotely from anywhere with an internet connection. Firms can reduce document-management costs. Because many cloud services are sold on a subscription basis, the cost is spread out rather than paid upfront in one large lump. For smaller firms, cloud services can make it easier to handle large volumes of documents even when support staff and office space are limited.

Furthermore, the guidance says cloud services may provide a level of IT security that meets or exceeds on-premises solutions. It even notes that, depending on a firm’s current practices, “storing documents on the cloud could be more secure than storing them on internal servers or as hardcopies”.

That warning matters. Many lawyers still assume that “local server” means safer and “cloud” means risky. But the guidance specifically cautions lawyers “not to overestimate the risk of unfamiliar technologies and underestimate the risk of existing methods of work”.

The box in the office

Recently, a lawyer told me about his firm’s local server setup.

It had been set up by an external IT provider at a pretty price. But when it was first installed, it had apparently been placed in a cabinet with poor airflow and inadequate heat dissipation.

People came into the office one morning and smelled burnt plastic.

It turned out that the setup had no offsite backup at all. If it had failed, the firm could have lost a very large amount of data.

That story stuck with me because it captures something lawyers often overlook: running your own infrastructure is not just a compliance question. It is an operational one.

Someone has to set it up, maintain it, back it up, and think about hardware failure, fire, theft, access control, recovery, and continuity.

In many small and mid-sized firms, that “someone” is a contractor, an office manager, or simply a setup that nobody has revisited in years.

To be fair, lawyers get into legal practice to practise law, not to become amateur infrastructure engineers. IT resilience is often not what they are most worried about, until the day it becomes the only thing that matters.

The Law Society guidance also makes this point indirectly when it says physical documents and documents stored on internal servers may be lost through theft or fire, and that cloud backups could be a lifesaver in such situations.

If your server is sitting in one office, then your resilience may be sitting in one office too.

What about ransomware?

This is usually the point where someone says: yes, but what about ransomware?

That is a fair concern. But ransomware is not a problem unique to the cloud. It is a backup, recovery, and resilience problem.

If a firm has proper backups and tested recovery procedures, ransomware is far less existential because the data can be restored. If it does not, then “we are on-prem” is not much comfort.

Public reporting on a 2024 ransomware incident affecting a Singapore law firm does not clearly disclose whether the affected system was cloud-hosted or on-premises. But one widely reported clue was the incident involved an ESXi virtualisation platform, which usually points to a self-managed virtual server environment rather than a pure cloud-native SaaS setup like Microsoft 365, OneDrive, or the products we build at Northbridge Lab.

So I would be careful about treating ransomware as an argument against the cloud.

The real cost of staying physical

Some lawyers still pine for the days when everything was simpler and all documents were physical. However, this has its own costs.

One managing partner told me he pays about $5,000 a month in warehouse fees just to store physical files.

That is before you count the time spent retrieving documents, moving boxes around, scanning old files, or dealing with the fact that paper is not searchable.

Lawyers already know file retention is part of the job. It does not mean the files have to stay in paper form.

The Law Society’s Practice Direction 3.12.1 on Storage and Destruction of Documents says that, as a general rule, firms should retain closed files for at least 6 years after the matter is wholly completed, then review whether longer retention is appropriate. For conveyancing files, it gives the same 6-year period from completion of the transaction.

It also makes two practical points relevant to digitisation: a shorter storage period may be agreed with the client if considered carefully, and original documents should not be destroyed without the owner’s prior consent.

Separately, the Law Society’s cloud guidance points to section 70E of the Legal Profession Act as an example of a 5-year retention obligation in the anti-money laundering context, read together with the Legal Profession (Prevention of Money Laundering and Financing of Terrorism) Rules 2015 and the Legal Profession Act, section 70E.

But the broader commercial point remains: if you are required to retain documents, it does not follow that you should retain them in the least searchable, least flexible, and most operationally expensive format.

Who do you trust to run it?

At some point, this becomes a question of trust.

Do you trust a small Singapore IT vendor to run the server in your office, or do you trust Microsoft and AWS to run the underlying infrastructure?

If you build on AWS or Microsoft properly, you are building on infrastructure run by trillion-dollar companies that harden their systems against sophisticated, nation-state level attacks, including nation-state level threats.

Of course, that does not mean everything built on the cloud is secure. Many so-called cloud incidents are really configuration failures by the developer: exposed storage, bad permissions, weak key management, poor monitoring.

That is exactly the distinction that matters. I previously worked on data policy in the Prime Minister’s Office. A big part of the job was encouraging government agencies to move to the cloud because even the Singapore government recognised the security and cost advantages of doing so.

The issue is not whether something is in “the cloud”. The issue is whether the people setting it up actually know what they are doing.

This is what I tell my clients: if my house burns down, the software should continue to run, and you should not lose your data.

Where the upside begins

The real prize is not just cutting costs. It is what happens once the files are digital.

Cloud and digitisation are the prelude. AI is where the real upside is.

Once documents are scanned, stored, and searchable, the practice starts to change. You can work from anywhere. Your team can find things quickly. And AI can read the material, extract from it, and turn piles of paper into something you can actually work with.

That is not just efficiency. It is unlocking new capability. Documents that were previously trapped in a file room become searchable, analysable, and usable.

That is why I think cloud, digitisation, and AI are mutually reinforcing.

That is also why our own software is cloud-first. The basic idea is simple: scan in your documents, store them properly, and let software extract and structure the information so it becomes genuinely usable.

Share

What comes next

The legal industry has already lived through several major technology shifts: first the PC, then email, then the cloud.

Now it is AI.

In a sense, none of this is new. Legal practice today would be completely different without word processing, email, or even Zoom. Each shift raises the baseline expectation for competent practice. We are only at the beginning of the same shift in the AI era.

But that is the thing about rising baselines: you do not really get to opt out.

That is why I do not think this is just a story about storage, or compliance, or where the server sits. I am interested in helping firms take the next step in how legal work gets done.

With the advent of AI, the question is no longer whether law firms are allowed to use the cloud. It is whether they can afford not to.

On 2 April 2026, the Law Society circulated an advisory on the use of publicly available AI tools.

One of my clients sent it to me the same day. There was, in his words, a “lively debate” among the partners of his firm about whether AI tools were safe to use at all.

That reaction is understandable.

For many lawyers, “AI” still means a public chatbot.

But there is a difference between the product and the technology.

A public chatbot is a product, with its own terms, retention settings, and data handling rules.

The underlying model is the technology, and that same technology can also sit inside a very different enterprise product.

This distinction lies at the heart of the Law Society’s advisory. It is warning against using publicly available AI tools that are not designed for business or enterprise use, and the professional risks that come with using them for legal work.

That warning is timely and should be taken seriously.

Why the concern is real

Large language models today are trained on huge amounts of data, publicly available and otherwise.

The business model matters too.

Better models attract more usage, and more usage helps improve the product further. That is one reason consumer AI products are often priced so aggressively.

That concern has become harder to ignore because of The New York Times lawsuit against OpenAI (1, 2).

Whatever one thinks about the merits, the allegation that caught public attention was simple: with the right prompting, the model could reproduce substantial snippets of New York Times articles.

That is the nightmare scenario.

Not just that the provider stores your prompt, but that confidential facts, commercially sensitive material, privileged analysis, or your firm’s own advice end up in systems you cannot meaningfully audit.

That would be bad enough for any business. For legal practice, it is much worse.

The Law Society’s advisory therefore says something important in plain terms: if you are using publicly available AI tools, you should not upload privileged, proprietary, confidential, or personal data, and you should be very careful about whether those tools retain inputs or use them for model training.

But for lawyers, the issue is broader than model training alone.

The real question is whether the tool is on consumer or enterprise terms, whether there are contractual and operational safeguards comparable to the protection required under the PDPA, what the retention defaults are, what admin and audit controls exist, and whether those protections apply to the exact tier your staff are actually using.

The real problem is often the wrong product, on the wrong tier, under the wrong terms.

Microsoft Copilot is a good example of how misleading branding can be. “Copilot” sounds like one product, but in practice it hides several different privacy regimes: consumer Copilot, home Microsoft 365 Copilot features, and Microsoft 365 Copilot under a work account (1, 2, 3). Those are not the same thing. Some consumer-facing Copilot usage may still involve model training unless the user opts out, conversation history saved for up to 18 months, and automated or human review in some cases (1, 4). Lawyers should not assume that a familiar Microsoft brand automatically means enterprise-grade protections. The exact product and terms matter.

There is also a practical problem.

As I wrote in an earlier piece, generic public AI tools are often not a good fit for legal teams. Clients tell me it is hard enough to get staff to learn prompting well, and those techniques change as models change.

What lawyers should actually check

If your firm is evaluating any AI tool for legal work, the key questions are:

• Is this a consumer tier or a true business / enterprise tier?

• Will prompts, uploads, and outputs be used for model training or service improvement?

• What are the retention and deletion defaults?

• Are there contractual and operational safeguards comparable to the protection required under the PDPA?

• What admin, access-control, audit, and security settings exist, and do they apply to the exact workflow your staff will actually use?

But that does not mean the answer is to avoid AI altogether.

The underlying technology is not the problem. The real issue is whether the software is built and contracted for enterprise use.

Share

What we do differently

At Northbridge Lab, we do not rely on unmanaged consumer AI accounts. We use reputable enterprise AI providers, with contractual commitments that the data we send will not be used to train their models.

We also care about the rest of the picture: retention, provider choice, security posture, and how the system is deployed inside a legal workflow.

I spend a lot of time evaluating providers because model quality changes quickly, and the best practical setup is not static. That is also why our software has meaningful operational cost. Consumer AI is often subsidised; enterprise API access is not.

The goal is simple: get the benefits of the best available models without exposing customer data to the risks that come with unmanaged public tools.

That is also why I care about using reputable providers rather than chasing every new model release. In legal work, trust, contractual protection, and predictable handling of data arguably matter even more than raw model capability.

No tradeoff between compliance and performance

I previously worked on data policy in the Prime Minister’s Office and built software in GovTech, including systems that handled sensitive personal information of Singaporeans.

So this is not something I treat casually. Clients pay us to get the job done, but to get it done in a way that is responsible, compliant, and fit for legal work.

If you are curious about our compliance posture, feel free to reach out and I can send you our compliance and assurance note. It maps the product against:

• Law Society of Singapore, Guidance Note 3.4.1 “Cloud Computing”

• PDPC’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act

• Supreme Court’s Guide on the Use of Generative Artificial Intelligence Tools by Court Users

• Ministry of Law’s Guide for Using Generative AI in the Legal Sector

• MAS Guidelines on Outsourcing (Financial Institutions other than Banks)

• MAS Consultation Paper on Proposed Guidelines on Third-Party Risk Management

Just as importantly, the software also has to actually work.

Firms should not have to choose between performance and responsible deployment.

On 4 March, I held an event at SMU for more than 30 Personal Injury and Property Damage (PIPD) lawyers on what AI can do for their practice.

Two things stood out.

First, there is real interest in what AI can do for legal work today.

Second, many firms still do not realise how much useful work AI can already do for them.

What I learnt from the event

One of the clearest lessons was that even within PIPD, firms can have very different needs.

PD-heavy practices often face a high-volume, lower-margin operational problem. Each matter may pay less, so teams are understandably more price-sensitive. For these firms, the goal is to manage deadlines and make sure matters do not stagnate because of admin burden or handoff issues.

For those firms, the immediate value may come from tighter operational workflows rather than the most sophisticated features.

PI-heavy practices can look quite different. They often need much more powerful tooling around medical expenses and income documentation.

In one customer matter, there were around 600 physiotherapy invoices spanning six years, and our AI had no issue compiling everything into a clean Excel sheet in 15 minutes. That is a very different problem from simply keeping a high volume of smaller matters moving.

These differences lead to different priorities, buying decisions, and software needs. As a software maker, it is our job to cater to them.

Modular options are possible

This is why I do not think one-size-fits-all product packaging makes sense in the age of AI.

Some firms need a more scoped-down product at a lower price point, focused on the operational issues that matter most. Others need a fuller deployment across multiple workflows.

That also means pricing should not be one-size-fits-all. A firm using a more scoped-down workflow should not be forced into the same pricing structure as a firm using heavier drafting and compilation features at scale.

This matters especially for AI software because, unlike traditional software, it can carry meaningful operating costs. Volume matters. Complexity matters. The right commercial model should reflect that.

One consistent piece of feedback from clients is that they value how responsive we are in customising the software to their needs. That includes workflow changes, scoping decisions, and firm-specific templates that preserve their house style and secret sauce.

Put differently, we are putting the service back into Software-as-a-Service.

In some cases, the right answer is bespoke software built around a specific firm’s needs. If firms have different bottlenecks, they should not be forced into the same product shape.

This is not theoretical

Since the SMU event, we have signed multiple customers.

Those customers have different profiles and are using the software in different ways. Among them:

• One is a PD-heavy firm using a more limited feature set focused on the operational issues that matter most.

• Another is using multiple workflows and asking for more advanced features, including conflict searches and interest calculations.

That matters because it shows this is not only for firms with the largest budgets or the most standardised operations.

We have also built bespoke software for some customers where that made more sense than trying to force a standard package onto a non-standard workflow.

Why generic and imported tools often miss the mark

If there is already this much variation even within PIPD, it should not be surprising that generic AI tools and legal tech built for other markets often miss the mark.

Tools like ChatGPT and Gemini can be useful, but they are generic by design. Overseas legal tech products may be impressive, but they are often built around different legal workflows, client expectations, and market realities.

Neither is the same thing as software built for a specific area of practice, in a specific jurisdiction, with the actual workflow of a Singapore firm in mind.

If you are evaluating AI for your firm, do not assume the only options are:

• a generic AI tool like ChatGPT or Gemini

• an overseas legal tech product that was not built for your practice or the Singapore market

• a large, expensive all-or-nothing software rollout

• doing nothing and waiting

In my experience, the best way to build software that actually works is incrementally. Get a useful system into the hands of users, see where it helps, collect feedback, and iterate from there.

That is usually far better than trying to design a large, expensive all-or-nothing rollout upfront.

The better question is not “should we buy AI?” It is: where is the operational pain in our practice, and what is the smallest useful system, built for our actual workflow, that would move the needle?

If you are thinking about that question for your own firm, feel free to contact me at warren@northbridgelab.com.