Confidentiality is not a setting you toggle after the fact. It is where the system lives, who holds the keys, and what is written down before the first document is drafted.
Consider the shadow-AI pattern: an associate has a fact pattern to turn into a draft, reaches for a consumer tool, and pastes in the material. There may be no approved route for that work, no record of what was sent, and no agreed review step before the response returns to the matter file. The immediate drafting problem moves. The custody question does not.
Private AI for law firms starts with taking ownership of that route. Not just choosing a tool with reassuring language. The practice needs a system it controls, with a place for the source material, a record of the work, and an attorney responsible for the decisions.
Consumer tools can be useful. A prohibition can also be a reasonable part of firm policy. But a memo alone does not supply an approved place to do the work, and it does not show a supervising partner what happened outside that place. The practical question is how to give matter work a governed route the firm can inspect.
Governed AI, Not Shadow AI. That means the drafting process is attached to the practice's materials and permissions, rather than assembled anew in an individual account. A partner reviewing a document should be able to follow its preparation without asking the author to reconstruct a series of prompts from memory.
Ownership gives the policy something concrete to point to. The firm can say where matter work belongs, who can access it, and where review occurs. That does not remove the need for staff guidance or professional judgment. It makes the guidance usable during the work, instead of leaving it in a document separate from the decisions people make under pressure.
Your data stays yours. Never pooled, never resold, never used to train anything.
A firm needs more than a private place to store a draft. It needs to understand who prepared it, which materials informed it, and where an attorney accepted responsibility for the next step. Confidentiality and supervision belong in the same conversation, but they are not the same check.
The architecture is designed to support your obligations under ABA Model Rule 1.6(c), including reasonable efforts to prevent unauthorized disclosure or access, and supervision of AI-assisted work under ABA Formal Opinion 512. Those remain the firm's professional duties. A cloud project is not a legal conclusion about privilege, and a review record does not make that conclusion for you.
Attorney review gates are part of the design. The system prepares a draft from approved materials, records the work, and brings it to the attorney for review. The attorney decides whether the proposed wording is supported and suitable. The fact that text is well written does not establish that its use is sound.
Treatment checking has a separate boundary. The system never logs into or scripts against the research services the firm licenses. For load-bearing and first-use authorities, the attorney checks treatment in their own account; the system records the result and the attorney's confirmation. A primary-source check is not passed off as a treatment check, and the record should not invite that misunderstanding.
A replayable audit trail lets a reviewer follow the draft, review, and correction history. That is useful when responsibility moves between attorneys: the next reviewer can inspect the recorded work rather than rely on a recollection of what someone checked. It supports supervision without claiming to substitute for it.
Law firm AI data security also depends on the ordinary question of access. A person working on a document needs the permissions appropriate to that work, not automatic access to unrelated client material. Per-client isolation in retrieval applies that boundary when the system retrieves information, not merely when someone opens a folder.
For the drafting context around these controls, read the private operating system for law firms. The practical aim is a document process your attorneys can supervise: clear sources, visible unresolved material, and a recorded decision before work leaves.
A per-seat tool provides access under the product's terms and roadmap. Shared infrastructure does not tell you, by itself, whether a provider retains information or uses it for training; those are separate terms to check. The same applies to corrections and feedback. Ask whether they remain available to your firm, whether they contribute to the product, and what survives cancellation. A subscription can be useful without giving you ownership of the system. The important distinction is what the practice controls, not an assumption that every subscription handles data alike.
Your infrastructure. Your data. Your asset. The system runs in a cloud project your firm owns. You hold the administrative keys. Synapse Forge's access is granted by your firm and can be revoked by your firm at any time. Your corrections stay with your system. No pooled data. No per-seat rent. The only recurring cost is the optional care plan. Read the care plan terms for that continuing service, and the ownership overview for the wider principle. The firm keeps the system; care is a separate choice about tending it.
Ask a firm what it bought and the answer is often a model name. That is the wrong unit. The model drafts sentences. Everything that makes those sentences safe to rely on sits around it: what it is allowed to read, what it is allowed to send, and what checks the output before an attorney sees it.
A correctly built system holds the model at arm's length. Closed-circuit inputs: it reads approved records, templates, and sources inside the firm's project, and nothing else. Deterministic gates: a document type on the always-review list or a first-use authority goes to an attorney because a rule says so, not because the model reported that it felt confident. Verification that does not care whose model drafted the sentence: a citation is checked against the primary record the same way whichever model produced the draft.
Once the system is built that way, the model is swappable. Replace it and the inputs, the gates, and the checks stay exactly where they were. That is what makes the next decision the firm's to make.
Where inference runs is a custody decision. The standard build runs managed models inside the cloud project your firm owns, under zero-data-retention and no-training terms confirmed in writing. Open-weight models on compute the firm controls is where ownership ends up: no retention question, because there is no third party left to retain anything. It is also a real operating commitment. Someone runs the hardware. The cost is fixed on idle days. Rented frontier models are still stronger at open-ended work. So it is scoped on a firm's volume and mandate, not assumed; the standard build keeps that door open rather than walking through it for you.
The end state: open weights on compute the firm controls, with the same inputs, gates, and checks around them. The system does not change when you get there. Only the custody does.
Before live matter data enters the system, you receive three things in writing: the acceptance criteria, the data boundary, and a confirmation naming the models deployed and confirming the zero-data-retention and no-training terms in force for them.
The acceptance criteria describe what you will inspect before accepting the build. They turn a general promise about a system into work you can watch and assess. The document types, review steps, and expected behavior need to be understandable to the people who will use them. Acceptance is not a request to believe that an unseen technical test went well.
The data boundary describes where the work lives and where it does not. Read it alongside the practical workflow: where source material enters, where drafts are reviewed, and where diagnostics happen. Testing uses synthetic fixtures. If real content is needed to diagnose an issue, that work stays inside the firm's project rather than moving into a separate support workspace.
The confirmation answers retention and training separately. A promise not to train on information does not, on its own, answer whether that information is retained. The confirmation names the deployed models and confirms the terms and settings relevant to each. Synapse Forge supplies this confirmation, citing the published terms and the configured settings. It is not a promise that another company will author a bespoke document for your firm.
These written items should agree with each other. If a draft needs review, the acceptance criteria should make that review inspectable. If diagnostics stay in the firm's project, the data boundary should say so. If model processing is configured with zero-data-retention and no-training terms, the confirmation should address the deployed configuration rather than a product that is not being used.
Read how the system works alongside those commitments. The public explanation describes the method; the written items you receive describe your build. No real firm's acceptance criteria, data boundary, or confirmation is published here.
For the design in general terms, on a fictional firm, read the architecture boundary summary: where matter data enters, where it runs, who sees it, and what is verified before activation.
Sample · Illustrative. Whitfield & Marsh is a fictional nine-attorney employment firm built to show the deliverables start to finish. No client data, no client results.
Build Blueprint · Sample · Illustrative →
Use this fictional blueprint to inspect the form of a build description and the questions it makes possible. It is not a live deployment record or another firm's security documentation. The value of the sample is that you can read it critically before receiving the documents for your own practice.
The system runs in a cloud project your firm owns. Your data never sits on our infrastructure. Model processing is configured with zero-data-retention and contractual no-training terms, confirmed in writing. Your data stays yours: never pooled, never resold, never used to train anything. Law firms keep their obligations under ABA Model Rule 1.6(c) intact; the audit trail is designed to support supervision of AI-assisted work under ABA Formal Opinion 512.
The system is yours. It keeps running in your project; you keep every correction it has learned. Care covers monitoring, tuning, corrections, and law-change refreshes; it is optional and month to month.
That is a policy decision for the firm. What the system changes is that matter work has a governed place to go, with an audit trail, so the policy has something to point to.
Neither, by default. It runs in a cloud project your firm owns, with zero-data-retention and no-training terms in writing. Fully local hosting is a managed-infrastructure decision we scope separately when a firm's volume or mandate calls for it.
The audit maps where your matter work would live and where attorney review belongs. Thirty minutes. You leave knowing exactly where your data would live. Send your contact details and a brief workflow description; we reply to arrange the call. Your report arrives the same business day once the call and any agreed outstanding inputs are complete. No obligation to build.
Have your current tool list, team size, and top two repetitive workflows ready. Estimator results are helpful, not required. We confirm any missing inputs at the end of the call. Timing uses Eastern Time and business days, Monday-Friday excluding U.S. federal holidays. If both requirements are completed on a non-business day, delivery is the next business day.
See the document workflow for law firms.
You'll work directly with Matthew Samlal, the founder of Synapse Forge. No account managers, no handoffs.