Private AI for healthcare: confidentiality, clarity, and control

When we were building Timberline, we conducted a research study with claims reviewers, revenue cycle professionals, and clinical nurses to understand where AI could help in their day-to-day work. A recurring theme was the need to make AI safe to use without adding complexity. If someone has to stop and ask, “Should I paste this document into my AI?”, the uncertainty gets in the way of the work.

That question deserves a clear answer. It should come from an organization’s evaluation of the service and the information it is allowed to process, rather than leaving each employee to work out the boundaries at the moment they need help.

Public AI services do not all handle data the same way. For example, OpenAI’s business-data commitments state that business data is not used to train models by default. But a training restriction is only one part of the evaluation. Healthcare organizations also need to understand processing, retention, access, and the terms that apply to the specific service they intend to use.

Timberline grew out of conversations in late 2025 and early 2026 with healthcare processors, third-party administrators, healthcare consultancies, and other organizations handling sensitive healthcare information. Sidechain heard recurring concerns about public AI services and contractual restrictions on AI use. Organizations wanted modern AI capabilities, but needed clear security and data-governance boundaries.

“Private AI” should make those boundaries understandable. Three ideas give the term practical meaning: confidentiality, clarity, and control.

Confidentiality: understand the customer boundary

Confidentiality begins with a concrete question: what separates one customer’s information and environment from another’s?

A description of a private workspace should explain the architecture behind that separation. Which components are customer-specific? Which underlying resources may be shared? What information does the organization need to assess whether the design meets its requirements?

Timberline uses a single-tenant, logically isolated application architecture for each customer environment. Customer separation includes customer-specific logical components: an application instance, database, and orchestration, along with network segmentation and dedicated encryption keys. The Timberline architecture overview describes these boundaries.

Underlying physical GPU, CPU, and RAM resources may be shared across logically isolated customer environments. Dedicated logical components should therefore not be interpreted as a promise of dedicated physical hardware.

That distinction belongs in the conversation from the beginning. If an organization has a requirement concerning physical resource allocation, it can identify that requirement explicitly and examine it against the proposed environment. The word “private” alone does not answer it.

Timberline is designed for sensitive healthcare workflows involving protected health information (PHI). That describes the product’s design posture; it does not establish a blanket regulatory-compliance guarantee or a determination about a particular customer’s deployment.

Clarity: know what happens to the information

Customer separation answers part of the question. Clarity also requires an account of processing, model usage, retention, and access.

Timberline uses private inference: production PHI is not sent to a public third-party hosted model API. Sidechain controls the infrastructure used for the Timberline environment, and customer information is not used to train models. Our explanation of private inference and public model APIs walks through why that processing path matters.

These are distinct statements. Where inference runs and whether data trains models address different questions. Neither statement, by itself, specifies a retention period or every condition under which information might be accessed.

A useful governance conversation asks:

• Where is information processed in the proposed deployment?
• What is retained, for how long, and under what agreed requirements?
• Who can access customer information, and for what purposes?
• How is model use defined, including restrictions on training?
• What documentation and contractual terms establish those boundaries?

Those questions help distinguish an established fact from an answer still needed for the deployment. For example, “not used to train models” should not be expanded into a claim that nothing is retained or that no person could ever access information.

In Timberline, chat retention is configurable through administrative controls. Expired or deleted conversations are purged with their attachments. Those capabilities should not be expanded into assumptions about backup deletion or every other category of retained information. The data and privacy overview provides context for evaluating information handling.

Optional features also belong in the discussion. Timberline’s governed web search is off by default and requires an administrator with a specific permission to enable it. Search is audited, fails closed, and removes identifying details from queries before they leave the environment. That outbound query path is an explicit exception to a blanket claim that information never leaves the environment.

Clarity means explaining both the standard processing path and its exceptions, and being precise about what is known and what still requires confirmation.

Control: connect the service to organizational requirements

Control concerns how the organization governs AI use within the service. Who should have access? What information may they use? What retention requirements apply? What approvals or contractual permissions are needed for the intended activity?

An architecture can inform these decisions. It cannot substitute for the organization’s judgment about its obligations or permissions. Sidechain’s customer conversations included concerns about contractual terms restricting or prohibiting AI use. A private environment should not be treated as automatic permission to use information governed by those terms.

Timberline supports sign-in through an organization’s SSO using OIDC, or password sign-in with authenticator-app MFA. Accounts are invitation-only. MFA is recommended by default for password sign-in, and administrators can require it. These options provide a starting point for examining how the service fits the organization’s access requirements.

Sidechain can enter into a Business Associate Agreement (BAA) directly with customers where applicable. Availability of a BAA does not mean one has been executed for a particular customer or that every proposed use has been approved. HHS guidance on cloud computing explains that a BAA is part of the requirements for using a cloud service with electronic PHI; organizations must also meet applicable HIPAA obligations, including risk analysis and risk management.

Control becomes concrete when the organization can connect the intended use, the service’s boundaries, and its own requirements. Unresolved questions should remain explicit before sensitive information is introduced.

Making private AI useful for healthcare teams

Timberline is a private AI workspace for healthcare operations that helps people research, synthesize information, analyze documents, and draft work product. Humans remain responsible for final review and decisions. Access to specific documents and systems, along with any integration requirements, must be established for each evaluation.

That is the connection between security and utility: an understood environment gives an organization a basis for evaluating useful assistance. It does not, on its own, establish measured productivity improvements or remove human responsibility.

The goal is to resolve the important questions before an employee needs to use the tool. Confidentiality gives the customer boundary substance. Clarity makes information handling understandable. Control connects the service to the organization’s decisions about acceptable use. Together, they make “private AI” a proposition that can be examined rather than a label that must be taken on trust.

This article is general information, not legal advice. Review specific agreements and deployments with your own counsel and compliance team.