How to connect AI to your law firm software through an interface

Most law firms meet AI in a chat window first. Someone copies a passage, pastes it in, reads the answer, and decides what to keep. Every input is a separate human decision.

An interface changes that. When an AI tool reaches your practice management software through an API, or through the Model Context Protocol (MCP, an open standard for connecting models to tools and data), nobody pastes anything. The tool reads what its configuration allows it to read. That one configuration decides for every file at once.

This piece walks through what that shift means in practice and which decisions to make before the connection goes live. Not legal advice. Whether a given setup meets German attorney service-provider rules (BRAO §43e) and professional secrecy is for counsel to decide. For the overall chain of selection, written agreement, configuration and human review, start with how German attorney service-provider rules apply to AI tools in a law firm.

What changes from chat window to interface

Three things shift when the connection is technical rather than manual.

1. The decision moves from the person to the configuration. In a chat window, a lawyer decides each time what leaves the firm. With an interface, that decision is made once, when someone sets scopes and permissions. A loose setting applies to every matter the tool can see.
2. The volume of reachable data grows. A chat window only sees what someone pastes. An interface can see everything its credentials allow: documents, metadata, deadlines, correspondence. Reach is no longer limited by effort.
3. Writing becomes possible. A chat window gives text back to a person. An interface can, if allowed, create entries, change deadlines, file documents or send messages. That is where the stakes rise most.

So the useful question is less "is this tool allowed?" and more "what is this tool allowed to touch, and what may it change?"

Read-only by default

Start every connection read-only. The tool may read the objects it needs and nothing else, and it may not create, change or delete anything in the practice management software.

Read-only is not a final state. It is the starting point that lets the firm see what the tool actually requests and returns before anyone grants more. Write access, if it ever comes, is a separate decision for a named action, not a side effect of the first setup.

Scope by object class, not by "all files"

Practice management software holds different kinds of objects, and they deserve different answers. Before connecting, list the object classes and decide for each one:

• Matter metadata: file number, matter type, responsible lawyer, status.
• Deadlines and dates.
• Documents: pleadings, contracts, internal memos.
• Correspondence: email, letters, notes on calls.
• Client and opposing-party data: names, addresses, identifiers.
• Billing and time records.

For each class, write down: may the tool read it, in which matters, in full or in excerpt, and why the task needs it. A tool that drafts deadline overviews may need dates and file numbers, but not the full correspondence. Narrow scopes are easier to explain to counsel, to clients and to your own team.

Know who sits behind the endpoint

An interface sends data to a provider's endpoint, and that provider often relies on further subprocessors for hosting, model inference or logging. Before going live, record who the provider is, where requests and logs are processed, and which subprocessors are involved.

Then make sure the written agreement with the provider says how you are told about changes to subprocessors before they take effect, and what you can do if you object. A configuration that was reviewed once can change underneath you if a provider swaps a subprocessor. The hub piece covers the agreement itself; here the point is that the interface makes this list operational, not theoretical.

Log every request and every result

With a chat window, the record is usually the person's memory. With an interface, the firm can and should keep a log: which tool requested which object, from which matter, at what time, under which user or service account, and what came back.

The log is what lets the firm answer later questions with facts: what did the tool see in this matter, and who triggered it? Decide in advance who reviews the log, how long it is kept, and who may read it, since the log itself contains matter information.

Human approval before any write

If the firm later allows the tool to write, keep a person in front of every write. The tool proposes; a lawyer or authorised staff member reviews and releases, or refuses. Nothing lands in the practice management software, a deadline calendar or an outgoing message without that release, and the release is logged next to the proposal.

This is the same pattern as retrieval with approval: the model prepares, the person decides, and the decision stays traceable.

A short checklist before you connect

1. Name the task the tool is for.
2. List the object classes it needs, per task, and leave everything else out.
3. Set the connection to read-only.
4. Record the provider, processing locations and subprocessors.
5. Check how the agreement handles subprocessor change notices.
6. Turn on request and result logging, and assign a reviewer.
7. Decide whether any write is needed. If yes, define the single action and put human approval in front of it.
8. Take the documented setup to counsel before going live.

FAQ

Does an interface make AI use in a law firm allowed? No setup is allowed or not allowed by its technology alone. An interface changes where the decisions sit and makes them easier to document. Whether the setup meets professional rules is for counsel to assess. Not legal advice.

Is MCP different from a normal API here? For these decisions, no. MCP is one standard way to connect a model to tools and data. Scopes, logging, subprocessors and approval matter the same way.

Can we start with write access if the tool only creates drafts? A draft stored in the practice management software is still a write. Start read-only, and treat even draft creation as a defined action with human release.

How we build this at AETOP

We build agents on Spectacle along the same lines: read-only first, scoped to the objects a task needs, every request logged, and a person who releases before anything changes. The aim is time back for the people who still do this coordination by hand, without moving the decision away from them. Approval-gated actions are on our roadmap and not bookable yet; we will not describe them as live before they are. If you want to talk through your own setup, see Spectacle.

Not legal advice. This article describes operational practice and does not replace review by counsel.