Does an AI model automatically train on every prompt it receives?

No. Generating a response and updating a model's trained parameters are different processes. However, the application or provider may still log, retain, review, or reuse data according to its product settings, contract, and policy.

Can healthcare employees use personal AI accounts for work?

Employees should not enter PHI or other sensitive organizational data into unapproved personal AI accounts. Healthcare organizations should provide approved tools, written policies, training, access controls, and appropriate vendor agreements for authorized use cases.

Does zero data retention make an AI workflow HIPAA compliant?

Not by itself. Retention is one control within a larger system. A healthcare organization still needs to assess data flows, vendor roles, contracts, access, authentication, logging, incident response, downstream integrations, and its own storage practices.

Are locally hosted open models always safer than cloud models?

Local hosting can keep data within an organization's environment, but it also makes the organization responsible for securing the infrastructure, model supply chain, access, patching, monitoring, backups, and physical systems. The safer option depends on the complete architecture and the use case.

AI and Cybersecurity: Is It Safe for Healthcare?

A practical guide to AI privacy, data retention, enterprise controls, local models, and safer adoption for healthcare organizations.

AI and Cybersecurity: Is It Safe?

Watch on YouTube

The first privacy question is not "How do embeddings work?"

In this episode of the AI and Healthcare Podcast, recorded May 19, 2026, Dr. Joseph Yoon and Noah Vandal begin inside the model. They discuss how a language model turns text into numerical representations, uses layers of learned weights and attention to process context, and then converts its internal output back into language. That explanation is useful because it separates two ideas that are often blended together: **processing information** and **storing information**. During inference, a language model receives input and calculates a response. That does not mean the model is rewriting its trained parameters around one user's prompt in real time. But the model is rarely the whole product. A consumer or enterprise AI application may also include chat history, user profiles, memory, safety logs, analytics, connected tools, and databases. Those surrounding systems determine whether information is retained, where it goes, who can retrieve it, and whether it appears again in a future conversation. For a clinic or health system, that distinction changes the security review. Understanding embeddings may help explain the technology, but the operational questions are more direct: - What data will staff enter? - Which systems and subprocessors will receive it? - Where will it be stored, and for how long? - Who can access the prompts, responses, logs, and linked records? - Will any data be used to improve a provider's services or models? - What happens when a user deletes a chat or an administrator closes an account? The answer cannot come from a general statement that "the AI does not remember." It has to come from the actual product configuration, architecture, policy, and contract.

Why personal AI accounts create a shadow-AI problem

The episode opens with a blunt warning: healthcare employees should not use personal consumer AI accounts for sensitive work. The deeper lesson is that prohibition alone is often not enough. If staff find AI useful and the organization offers no approved alternative, some employees will still use whatever account is convenient. That creates shadow AI: organizational work moving through tools that security, compliance, and IT teams cannot configure, monitor, or govern. A safer policy pairs boundaries with a usable path. Healthcare organizations should define approved use cases, provide managed accounts or approved applications, train staff on what may be entered, and make the secure option easier to use than the workaround. Access should be role-based, and higher-risk workflows should have additional review. This is not unique to AI. It is a familiar security principle applied to a new interface: unmanaged tools create unmanaged data flows.

What zero data retention does—and does not—solve

Zero data retention, often shortened to ZDR, generally describes an arrangement in which a provider does not retain eligible request and response content after processing. It can reduce the amount of sensitive data held outside the healthcare organization's own systems. That can be valuable, but ZDR is not a magic compliance switch. Its meaning and coverage depend on the provider, product, endpoint, feature, and contract. Some capabilities may require temporary state or may not be eligible. Abuse monitoring, account metadata, tool calls, third-party integrations, and the healthcare organization's own logs or databases may follow different rules. The more useful question is not simply, "Do you offer ZDR?" It is, "Can we draw the complete data-flow diagram for this exact workflow and document the retention and access rules at every step?" For regulated healthcare use, teams should also determine whether a vendor will act as a business associate when required, whether an appropriate business associate agreement is in place, and whether the implementation fits the agreement's covered services. HHS guidance emphasizes risk analysis, access management, workforce training, security incident procedures, and periodic evaluation. An AI vendor setting does not replace those responsibilities.

Enterprise cloud AI and local models solve different problems

The conversation compares two broad deployment paths. An enterprise cloud service can offer strong models, managed infrastructure, administrative controls, contractual terms, and configurable retention. This is often the most practical route for smaller organizations, but it still requires careful vendor and feature review. A locally hosted model can keep inference within infrastructure controlled by the health system. Research highlighted by Harvard Medical School also suggests that open models can be competitive with proprietary systems on some defined clinical reasoning benchmarks. That makes local deployment a real option for certain institutions and tasks. Local does not automatically mean secure, however. A self-hosted system still has administrators, credentials, endpoints, storage, backups, dependencies, model files, and physical hardware. It needs patching, monitoring, network controls, supply-chain review, and an incident response plan. Disconnecting a system from the public internet may reduce remote exposure, but it does not eliminate insider risk, removable media, configuration errors, compromised updates, or unsafe outputs. The right choice is therefore not "open is safe" or "enterprise is safe." It is the architecture that gives the organization appropriate performance, control, accountability, and operational capacity for a clearly bounded use case.

A practical checklist for safer healthcare AI adoption

Before deploying an AI workflow that may touch patient or operational data, a clinic or health system should be able to answer the following: 1. **Use case:** What specific task is the system allowed to perform, and what is outside its scope? 2. **Data classification:** Will it receive PHI, personal data, credentials, financial data, or confidential business information? 3. **Data flow:** Which models, vendors, integrations, logs, and storage systems receive each category of data? 4. **Contracts:** Are the necessary service terms, retention commitments, and business associate agreements in place for the actual features being used? 5. **Access:** How are users authenticated, authorized, provisioned, and removed? 6. **Retention:** What is stored by each party, for how long, and through what deletion process? 7. **Human oversight:** Which outputs require review, and how does the system escalate uncertainty or possible harm? 8. **Monitoring:** Can the organization audit use, investigate incidents, and detect policy violations? 9. **Evaluation:** Has the workflow been tested for accuracy, privacy leakage, prompt injection, unsafe behavior, and failure modes? 10. **Change management:** Who reevaluates the system when the model, vendor, feature set, or use case changes? This aligns with the broader direction of NIST's AI Risk Management Framework: govern the system, map its context and risks, measure how it behaves, and manage the risks over time.

AI is also changing the threat environment

The episode closes with a second cybersecurity question. AI is not only something organizations must secure; it can also accelerate vulnerability research, code analysis, phishing, social engineering, and other offensive or defensive activities. That does not invalidate existing security practice. It raises the value of doing the basics consistently: timely patching, least-privilege access, strong authentication, secure software development, tested backups, vendor management, monitoring, and practiced incident response. NIST notes that many risks around AI systems overlap with the confidentiality, integrity, and availability risks that security teams already manage. The durable takeaway is that healthcare organizations should not treat AI privacy as a property of the model alone. Safety comes from the whole system: people, policies, contracts, infrastructure, data flows, monitoring, and the discipline to keep reassessing them as the technology changes.