Treadstone Associates
Article · Engagement lifecycle

AI to set up a client portal for a new file

Portal creation, folder structure, permissions and the first document request are rules-based steps. Who is allowed in, and what the tool retains, are decisions a licensee makes.

Treadstone Associates · Updated 2026

Key takeaways

  • • Portal setup is a workflow problem before it is an AI problem — most of it is deterministic automation triggered by file opening.
  • • Rule 3.3-1 requires a lawyer to hold client information in strict confidence, which governs who gets portal access and on what terms.
  • • By-Law 7.1 requires an organisation client’s identity to be verified not later than thirty days after the relevant activities begin — a good thing for the system to track.
  • • Generative features belong on the edges: drafting the welcome message, summarising an upload, checking a request list for completeness.

The short answer

Most of what you want here is not artificial intelligence at all — it is workflow automation, and it is the cheaper and more reliable half of the answer. When a matter is opened, the system should create the portal, apply the folder structure for that matter type, set permissions from the contact record, issue the invitation, and queue the standard first document request. Those are deterministic steps with no judgment in them, and a rules engine executes them identically every time, which is exactly what you want from a control.

Where a generative model earns a place is at the edges: drafting the welcome message in the client’s language and reading level, summarising a long upload so the file handler knows what arrived, comparing what has been received against what was requested, and drafting the chase. Useful, but peripheral. If your portal setup is inconsistent today, the fix is the workflow, not the model.

What the platforms actually do

It is worth being precise about vendor capability rather than vague about it. Clio’s client portal software is described as secure client communication and document sharing with clients logging in to view documents, bills and dates; its workflow automation pages describe automating intake steps such as emails, appointments and tasks so a sequence fires without anyone remembering it. On the accounting side Karbon’s client portal describes personalised task lists, secure file sharing, e-signature collection and automated reminders that prompt clients when action is needed, with uploads landing against the right work item.

Read those as capability descriptions, which is what they are. What none of them can do is decide who should have access to a matter, and that is the decision that actually carries risk.

The confidentiality decision comes first

Rule 3.3-1 of the Law Society of Ontario’s Rules of Professional Conduct requires a lawyer at all times to hold in strict confidence all information concerning the business and affairs of the client acquired in the course of the professional relationship, and not to divulge it except as the rule allows. A portal is a disclosure mechanism. Every automated step that grants access is therefore a small confidentiality decision executed by a machine on rules you wrote, which is fine — provided you wrote them deliberately.

Three rules are worth making explicit before you automate anything. Who, other than the client, may be invited to a matter, and who approves that. What happens to access when a matter closes, or when a client’s representative leaves their organisation. And whether any content in the portal is ever routed through an external model for summarisation, because that is a transfer of client material to a third party and it should be a considered choice rather than a default setting.

Privilege is a related but separate question, and it behaves differently from confidentiality; our sister firm’s note on solicitor-client privilege in a CRA audit is a useful illustration of how the distinction bites in practice.

Identity, and the clock nobody tracks

File opening is also when client identification and verification obligations start running. By-Law 7.1 sets out what a licensee must obtain and when identity must be verified, including the requirement to verify an organisation’s identity immediately and, in all cases, not later than thirty days after first engaging in the activities described in the by-law.

This is a good example of automation adding real value quietly. A workflow that opens the portal can equally open the verification task, date it, and escalate it if the documents have not arrived. No model is required. What a model can do usefully is read what the client uploaded and tell the file handler whether it looks like the category of document that was requested — a triage step, not a verification decision.

Worked example: a five-lawyer firm standardising file opening

Illustrative. The firm opens files inconsistently: some clients get a portal, some get email attachments, folder names vary by assistant, and nobody can say from the system whether a client has actually logged in.

The rebuild is a checklist turned into a workflow. Matter opening triggers portal creation with a folder structure fixed per matter type. Permissions come from the contact record rather than from whoever set it up. The invitation and the first document request go out together, because a portal a client never enters is worse than email. A verification task is created with its own due date. A reminder sequence runs on the outstanding requests. And a weekly report lists matters where the portal was created but never accessed, which is the signal that a client needs a phone call rather than another automated nudge.

Only two generative steps are added. The welcome message is drafted from the matter record and reviewed once per matter type, not per client. And uploads are summarised for the file handler. Everything else is rules.

Where the client data goes

If you introduce a model that reads portal content, you have introduced a processor. The Office of the Privacy Commissioner’s principles for responsible, trustworthy and privacy-protective generative AI ask organisations to establish that the use is necessary and proportionate, to prefer de-identified or synthetic data where personal information is not required, to be open about collection and use, to maintain safeguards commensurate with sensitivity — including against prompt-injection attacks, which they name specifically — and to be able to demonstrate accountability for compliance.

For a law firm that translates into a short set of answerable questions. Where does the text go. Is it retained, and for how long. Is it used to improve a model beyond your instance. Who at the vendor can see it. Can you produce a record of what was sent. Settle those before the integration, because retrofitting an answer after a client asks is a poor position to be in.

Questions we get asked

Do we still need email?
Yes, and the portal will not eliminate it. What a portal does well is hold documents, requests and status in one place so the file record is complete. Treat email as the notification layer and the portal as the record.

Can AI decide who gets access?
No. It can apply the access rules you wrote and flag exceptions. The rules, and any exception, are a licensee’s decision.

What about clients who will not use it?
Some will not, and a firm that pretends otherwise ends up with two half-complete records. Keep a documented fallback path and make sure documents received by other means still land in the same file.

If you are looking at the wider file-opening sequence rather than the portal specifically, see AI for client onboarding at a Canadian firm. Intake, scheduling and front-desk workflow are a different discipline and they sit on the practice-owner page.

See where AI pays off first in your firm.

A 30-minute call is enough to tell you whether AI pays for itself here.