Confidentiality Obligations as an Architectural Constraint on AI Assistant Selection

For privacy-conscious professionals, AI assistant selection starts with confidentiality obligations. Consumer cloud tools are unsuitable for confidential client work, while managed enterprise tools can provide contractual protections and on-premises or privacy-by-architecture deployments can provide stronger proof of data control. AI assistant selection depends on whether the applicable duty accepts a vendor’s assurance or requires verifiable limits on where data goes and who can access it.

Why confidentiality obligations are not negotiable constraints that AI procurement must satisfy

Attorneys, clinicians, financial advisors, and businesses do not approach confidentiality as an optional service preference. Their duties arise from professional conduct rules, attorney-client privilege, healthcare law, financial recordkeeping requirements, contracts, and trade-secret law. Those duties constrain what a tool may do. An assistant that cannot accommodate them is incompatible with the work, however useful its answers or attractive its price.

Good intentions do not establish compliant data handling. A professional may take care when writing a prompt and still send protected information into a system that processes or keeps it in ways that breach a duty. Evaluation must account for what actually happens to the information under both the system’s design and its terms. Selection criteria therefore follow from the duty.

The regulatory framework that now gives confidentiality obligations specific teeth in AI contexts

ABA Formal Opinion 512 recommends getting informed client consent before putting confidential client information into a self-learning generative AI tool. The opinion is advisory. Its significance lies in connecting existing professional duties to a specific form of AI use, rather than treating an enterprise subscription as sufficient reassurance. A lawyer must look at both what the tool does and the terms under which information goes into it.

Legal uncertainty makes that examination more consequential. Heppner in S.D.N.Y. and Warner v. Gilbarco in E.D. Mich., issued on the same day in February 2026, disagreed on whether AI-assisted materials get work product protection. Both agreed that AI use does not support attorney-client privilege. The split resists a blanket answer about protection for AI-assisted work.

HIPAA requires a signed Business Associate Agreement for an AI tool processing Protected Health Information, which most consumer-tier tools cannot offer. SEC Rule 17a-4 and FINRA Rule 4511 impose retention and accessibility requirements on recorded client communications, while FINRA Rule 3110 addresses supervisory review separately. These obligations attach to AI-captured meeting content even when the firm did not intend to create a record. A generic compliance claim cannot answer these distinct requirements.

How the ordinary use of consumer AI assistants creates exposure without any user error

The exposure can begin with an entirely ordinary prompt. An employee types information into an assistant, receives a useful answer, and thereby places the information into provider-controlled processing that may include retention or training. No cyberattack is necessary for that sequence. The mismatch lies between what the tool is designed to do and what the professional is permitted to disclose.

Consumer-tier tools collect data and use it for training by default. Paying for ChatGPT Plus or Claude Pro does not provide the contractual training exclusions associated with team or enterprise subscriptions. Claude Pro’s August 2025 consumer terms update made training on by default, with an opt-out available. A setting is not a negotiated contractual protection.

In Samsung’s 2023 incident, engineers in its semiconductor division introduced proprietary source code, internal meeting notes, and confidential test sequences into ChatGPT through routine work tasks within weeks. Samsung had no shadow AI detection, data loss prevention, or audit trail at the time. The employees were not violating a known rule under the standards they were operating under. The missing boundary was architectural and policy-level.

Nor is the prompt the only possible disclosure point. AI systems can reveal confidential details from earlier exchanges or internal content they retrieve, including client names, private phrasing, and summaries of internal reports. Caution about what employees type cannot, by itself, govern what the assistant retrieves and returns.

Why contract terms alone do not resolve the gap — and what vendor agreements actually say about data use

Owning a record does not mean controlling every use of it. A customer may own a meeting transcript while the vendor retains a license to create analytics, generate aggregated datasets, develop models from the material, or retain de-identified information. Ownership and permitted use are separate contractual questions.

Terms covering “research,” “product improvement,” “analytics,” or “model development” can encompass content the customer assumes is protected. References to “anonymous,” “de-identified,” or “aggregated” data may also permit retention and commercial use of information about meeting frequency, participant interactions, and workflow patterns. Those patterns can reveal confidential business activity even if the transcript itself is not kept.

The review must also extend beyond the subscription period. A no-training commitment that does not survive termination may leave already-processed data without that protection, while an incomplete sub-processor list leaves uncertainty about which third parties received it. Legal, procurement, and privacy review therefore needs to establish training defaults, covered models, derived-data rights, and post-termination protections in the actual agreement. Contractual review is necessary, but it remains a different kind of evidence from architectural proof. A promise about processing is not a technical boundary that prevents it.

What AI assistant can handle sensitive client information — and what can each architecture guarantee?

Consumer cloud tiers provide the weakest confidentiality profile. Processing takes place on provider infrastructure under terms that default to collection and training use, without the contractual no-training commitments, signed data processing agreements, or Business Associate Agreements needed for protected professional work. Customers also lack audit logs of what was processed. These tiers are categorically incompatible with confidential client work under the obligations described here. Their usefulness does not cure those omissions.

Managed enterprise cloud tiers offer a materially different arrangement. Major providers make contractual no-training commitments, data residency options, and Business Associate Agreements available at this level. Processing still occurs on the provider’s infrastructure. The confidentiality assurance therefore depends on contractual scope and vendor performance, including how sub-processors, derived data, and retention are handled.

HIPAA does not prohibit cloud processing, and a properly executed BAA can satisfy its requirement for the provider relationship. Mayo Clinic’s Med-PaLM 2 pilot illustrates cloud controls: it relied on Google Cloud’s customer data controls, including encryption and a promise not to train on patient data, to keep PHI under the institution’s control. Some healthcare organizations choose on-premises systems for their most sensitive PHI to gain additional certainty.

On-premises or private-cloud deployment offers a stronger boundary when inference, retrieval, and logging all run within infrastructure the organization controls. Under that configuration, no data leaves the perimeter for an external AI provider. The qualification is essential to the guarantee. A deployment label alone does not establish that every part of the workflow stays inside.

With on-premises deployment, the organization must pay for hardware, manage it, and keep the model infrastructure running. Closed-source models also create a requirement to protect model confidentiality against theft. The operational value of the strongest technical guarantee depends on whether the obligation requires that degree of certainty and whether the organization can sustain the system.

What a complete architectural evaluation actually requires — beyond the deployment model

Deployment determines the protection an implementation can potentially achieve. Audit logs that capture only prompts and responses are insufficient for most regulatory purposes. Vendor-controlled formats also limit audit independence if the organization cannot export, search, and present the records as evidence. Otherwise, a system may process information within an acceptable boundary without supporting the organization’s duty to demonstrate what happened.

Restricting who can open the assistant does not govern which internal sources it can query or which results it can return. Controls must operate at the user, data-source, and output levels. An authenticated employee should not thereby gain unrestricted access to internal knowledge. Contractual no-training guarantees, data isolation, and role-based access address different parts of that confidentiality boundary.

Agentic assistants widen the evaluation beyond model inference. An assistant may call external services, retain persistent memory, or chain actions across systems, multiplying the entities involved in processing organizational information. Which services receive data at runtime, and for what purpose? Questions about controller identity, the legal basis for purpose-unspecified persistent memory, and cross-border transfers then become part of the assessment.

The strongest objection — that governance and policy can substitute for architecture — and why it only partially holds

Governance, policy, and contractual controls can achieve equivalent legal compliance at lower cost for many regulated workloads. An enterprise cloud arrangement with a sound data processing agreement, role-based access, a BAA where required, and a zero-retention configuration may satisfy the same legal standard as on-premises deployment. GDPR and HIPAA compliance also depends heavily on configuration and governance. Architecture alone does not settle the issue.

A healthcare organization can use cloud processing even though it runs on the provider’s infrastructure. With a model inside the perimeter, the organization still needs to control employee access, retention, and permitted uses. Internal control can still be poorly exercised. The architectural argument is strongest when it identifies the required boundary.

Governance nevertheless has limits when the system permits the disclosure it is meant to prevent. Samsung’s experience involved non-malicious employees and no governance layer capable of catching the exposure before it occurred. It later banned tools, developed Gauss, and negotiated enterprise agreements for specific divisions. Policy needs technical support to become a dependable preventive control.

The remaining distinction is between legal assurance and demonstrable handling. A DPA may satisfy an applicable requirement, but it depends on the vendor honoring its commitments. Evidence that data never left controlled infrastructure establishes a different proposition. Architecture sets the upper bound of protection, while governance determines how much of it is realized. They are complements, with architecture becoming decisive where the obligation demands verifiable certainty.

How to apply the architectural framework to a real selection decision

First, the organization identifies the information the assistant will process, including privileged communications, PHI, regulated financial records, trade secrets, or general business information. ABA Formal Opinion 512, the HIPAA BAA requirement, SEC Rule 17a-4, and GDPR are not interchangeable tests. A failed confidentiality requirement makes later feature comparisons irrelevant.

Next comes the required level of certainty. Does the applicable obligation accept a contractual commitment, or must the organization demonstrate that data never left its perimeter? Where contractual assurance suffices, managed enterprise cloud remains a candidate. Where verifiable containment is required, only on-premises or privacy-by-architecture deployments that establish that boundary qualify. This decision narrows the field before capability and price enter the comparison.

Procurement should ask for a network-level architecture diagram that shows every external call at runtime and check the audit-log format, whether logs can be exported, whether storage is append-only, and whether retention can be configured. Contract review should examine named sub-processors, no-training scope, and post-termination data rights. The diagram and agreement answer different questions. Together, they show whether the proposed technical boundary and the uses allowed to the vendor meet the duty.

Finally, the chosen architecture needs a working governance layer. Role-based access, employee training, data loss prevention, and defined retention periods apply regardless of deployment model, with informed client consent obtained where required. These controls are more effective when the underlying system already limits exposure. For lawyers, accountants, and other privacy-conscious professionals, the best-fit assistant is therefore not simply one that promises not to train on their data. It is one whose complete data-handling arrangement matches the confidentiality duty they must uphold.