This is the sixth post in the Honswer editorial series. The previous post, Five AI risks professional firms cannot ignore, named the five distinct risk categories AI introduces and the control that contains each one. This post examines the two with the sharpest regulatory consequences: data leakage and compliance exposure.
Compliance is a design requirement
Every managing partner of a regulated practice has had the same two-part conversation about AI. The first part is enthusiasm: a tool that drafts, summarizes, and researches in seconds is obviously useful. The second part is the brake. Nobody in the room can establish where client data would go, what obligations the vendor accepts, or how the firm would reconstruct an AI-assisted decision during an audit. The pilot stalls there, and the stall gets filed under prudence.
The uncertainty is reasonable. Lawyers hold confidential and privileged communications. Medical practices hold protected health information. Accountants work with sensitive financial records and, in some engagements, operate within formal financial-reporting controls. A useful tool can create regulatory exposure as soon as real client data enters it.
Telling staff to “be careful” does not resolve that uncertainty. A reliable control must operate under deadline pressure, apply consistently across users, and leave evidence that it ran. The practical question is how to build those properties into the system.
The compliance landscape in 60 seconds
Three recurring obligations shape AI use across law, medicine, and accounting.
For lawyers, the duties of confidentiality and competence apply when client information is entered into a generative AI tool. The risk depends on the information involved, the tool’s terms, its security, who can access the data, and whether the client has given informed consent where required. Attorney-client privilege adds another concern: disclosure outside the protected relationship can create waiver arguments, depending on the jurisdiction and circumstances. The American Bar Association’s Formal Opinion 512 directs lawyers to evaluate these issues before using client information with generative AI.
HIPAA applies to covered entities and their business associates when protected health information is created, received, maintained, or transmitted. A cloud provider processing electronic protected health information on behalf of a covered entity will generally be a business associate. The parties must enter into a compliant Business Associate Agreement, and the practice must still conduct its own risk analysis and apply appropriate safeguards. A BAA is necessary in that relationship, but it is not the whole compliance program.
Accounting obligations vary by engagement. Firms involved in public-company reporting and audits may need to preserve records, maintain defined controls, and show how material information was produced or reviewed. An AI-assisted process that affects financial reporting therefore needs clear ownership, validation, and documentation.
These regimes are not identical, but they raise the same operational questions:
- Where does the data go, and who can access it?
- What contractual and professional obligations apply?
- Can the firm reconstruct what happened?
Those questions provide a practical starting point for system design. They do not replace legal analysis for a specific practice, jurisdiction, or engagement.
Where firms are already exposed
Most exposure begins with ordinary convenience.
A paralegal pastes a client communication into a consumer chatbot to prepare a summary before a meeting. The output is useful, but nobody has reviewed the provider’s retention terms, training policy, subprocessors, or access controls. The firm can no longer explain with confidence how the information was handled.
A tax associate uploads a client’s return to a free online tool to check a calculation. The vendor has not been assessed, has no negotiated confidentiality obligation, and may have no duty to notify the firm after a security incident.
A medical office uses a general-purpose AI assistant to draft patient correspondence containing names and conditions. If the provider processes that information on the practice’s behalf without the required Business Associate Agreement and safeguards, the practice may have made an impermissible disclosure of protected health information.
A consulting team reuses a single AI workspace across competing engagements, so context from one client shapes the suggestions generated for another. No data left the building, and a confidentiality wall still came down inside it. Formal Opinion 512 identifies this exposure directly, warning that self-learning tools which retain what lawyers put into them raise the risk of improper disclosure across different client matters.
These are predictable actions by capable staff trying to complete real work. Training remains necessary, but a policy memo will always compete with speed and convenience. Technical controls should make the approved route easier to use and prevent sensitive data from reaching unapproved services.
The compliance-by-design architecture
Four components carry most of the operational weight.
Deployment and tenancy
The firm needs an approved environment with documented rules for data retention, model training, geographic processing, administrator access, and subprocessors. A private or dedicated deployment can provide stronger isolation and contractual control than a consumer service, but the label alone proves little. The firm must verify the configuration and the governing terms.
For a law firm, that assessment should cover professional confidentiality and any privilege implications. For a medical practice, it must include the required Business Associate Agreement when the provider handles protected health information. The deployment establishes the controlled boundary in which approved AI work can occur.
Data classification
Data should be classified when it enters the system. Categories might include privileged, confidential client, protected health information, financial, internal, and public. The classification then determines which services may process the data and what approval is required.
A medical practice, for example, can prevent information classified as protected health information from reaching any provider outside its approved list. The user does not need to remember the vendor matrix during every task because the boundary enforces it.
Deterministic compliance checks
Some obligations can be translated into rules that run on every transaction. This is Programmatic Intelligence, the deterministic layer described in AI alone is not a system, applied to compliance.
An accounting system can hold an AI-assisted output until cited figures reconcile with the source ledger and a designated reviewer approves the result. A legal system can block documents carrying a privileged classification from unapproved models. A medical system can remove direct identifiers before an appropriate secondary use.
The model handles the task that requires interpretation or generation. Code enforces the conditions that should not vary.
Audit logging
Every material AI-assisted action should create a usable record. Depending on the task, that record may include what triggered the action, which data sources were used, which model and version ran, which rules applied, what output was produced, and who reviewed or approved it.
Logging also requires judgment. A firm should not create a second uncontrolled repository of sensitive prompts and outputs in the name of compliance. Retention periods, access controls, and redaction rules must apply to the logs themselves.
Honswer’s General Counsel, Alvaro Ramirez Bonilla, describes the underlying problem this way:
“Almost every firm I talk to treats AI compliance as a policy problem. They write a memo, run a training, and ask people to be careful. That approach fails the moment it meets a deadline, and it fails silently, which is worse than failing loudly.”
Policy defines the obligation. Architecture makes the approved behavior repeatable and produces evidence that the controls operated.
Three questions to ask any AI vendor
The same principles provide a short test for products a practice is considering.
- Where does the data go, and who can access it? The vendor should identify where data is processed and stored, how long prompts and outputs are retained, whether they are used for model training, and which subprocessors can access them. A general assurance about “enterprise security” is not enough to assess exposure.
- Will the vendor accept the required contractual obligations? For protected health information, this generally includes a Business Associate Agreement. Other uses may require confidentiality, data-processing, breach-notification, deletion, or audit provisions. Product capability does not compensate for missing contractual protection, and this question ends more evaluations than any other.
- What evidence can the system produce? The firm should be able to determine what data the tool processed, what it generated, which version or configuration was used, and who approved any consequential output. The required detail will vary by task, but the vendor should support the firm’s recordkeeping obligations.
Vagueness on any of these points should delay adoption for regulated data until the gap is resolved.
What a defensible deployment looks like
A regulated practice should be able to name its approved AI environment, classify the data entering it, enforce rules at the system boundary, and produce a proportionate record of consequential actions. These controls allow the firm to use AI for real client work without relying on individual memory as its primary safeguard.
Privilege, HIPAA, and professional obligations are not reasons to keep AI at arm’s length. They are the design specification for how to bring it close. A practice that treats them as system requirements gets a clearer path to adoption and a stronger answer when a client, auditor, court, or regulator asks what happened.
The next post turns from protection to performance. Even a well-governed system produces poor work when the model receives the wrong context, whether too little or too much.
