A clinic buys an AI note taker. The vendor offers a business associate agreement. A clinician then connects the transcript library to an AI chat app through MCP and asks it to summarize yesterday’s appointments.
The connection works. The answer looks useful. But one question remains: does the approved arrangement cover the place that just received the transcript?
That is easy to miss when each product is reviewed separately. A recorder, a connector and a chat app can each behave as designed while the combined workflow falls outside the organization’s approved use.
This article explains how to review that workflow. It is written for people choosing, building or administering AI note tools. Locus builds meeting-notes software; the principles here apply to any vendor. This is an educational guide, not a legal determination about a particular deployment.
THE CENTRAL IDEA
Approve a specific flow of information: the data, the people, the services, the account and the purpose.
01 / THE VOCABULARY
Five terms that answer different questions
- AI note taker
- Software that captures, transcribes, summarizes or searches conversations. These steps may happen on one device, across several services, or both. The product name alone does not describe the architecture.
- MCP
- The Model Context Protocol, an open standard that lets AI applications work with tools and information supplied by other systems. In this setting, a note app exposes a way to search or retrieve notes; an AI app uses that connection. MCP is a protocol, not a model, storage service or compliance certificate. MCP architecture →
- HIPAA
- The U.S. Health Insurance Portability and Accountability Act and its implementing rules. The Privacy Rule governs protected health information and its uses and disclosures. The Security Rule addresses safeguards for electronic PHI. HIPAA applies to covered entities and business associates, not automatically to every app that mentions health. HHS Privacy Rule summary →
- PHI
- Protected health information. In a HIPAA-regulated setting, identifiable health information can appear in an audio recording, transcript, summary or search result. Turning speech into text does not remove its sensitivity. What HIPAA protects →
- BAA
- A business associate agreement: a contract governing a business associate’s handling of PHI. A service that creates, receives, maintains or transmits PHI on behalf of a covered entity may be a business associate. Relevant subcontractors can also be business associates. The relationship and activity matter. HHS business associate guidance →
Outside HIPAA’s scope, information may still be sensitive and subject to other laws or contracts. Permission to record a conversation is also a separate question from permission to process or disclose its contents.
02 / THE WORKFLOW
Follow one transcript all the way through
Consider a fictional appointment note. A recorder captures the conversation. A transcription engine produces text. The note app stores it. Later, an AI app requests that text through the note app’s MCP server.
Here, “server” describes a role. It might be a process on the same laptop or a service on another machine. The AI app may then send the returned text to a local model or a remote model provider. The answer may become part of a saved chat, an export or another connected system.
Where the content can travel
Audio becomes searchable notes.
Each step can be local or hosted.
Local model or remote provider,
depending on the application and settings.
Check which copies exist and who controls them.
A read-only connection still moves information. It may prevent the AI app from changing the original note. It does not prevent that app from receiving a copy. Even a search tool can disclose sensitive snippets, titles or participant names.
This is why “the recording stays on my laptop” answers only part of the question. If retrieved text is sent to a remote model, the later step needs its own review. Equally, a cloud service can be part of a compliant arrangement when the applicable safeguards and agreements are in place. HHS permits cloud use under those conditions; local storage is not, by itself, a compliance verdict. HHS cloud guidance →
03 / PERMISSIONS & IDENTITY
A successful connection proves less than it appears to
Authentication checks an identity or credential. Authorization decides what that identity or credential may do. A consent screen is part of a permission process. None of these, on its own, establishes the legal terms governing the recipient’s use of a transcript.
For HTTP connections, MCP defines an authorization framework based on OAuth, a standard for granting access without sharing the user’s password. Local connections may use a different credential mechanism. The precise behavior depends on the implementation and transport. MCP authorization specification →
Four questions. Four kinds of evidence.
Who is connecting?
User, application and organization identity.
Evidence: validated credentials and account context.What may they read?
Records, tools and permitted actions.
Evidence: enforced access rules and negative tests.What is covered?
Service, account, purpose and contractual scope.
Evidence: applicable agreements and documented approval.What actually happened?
Retrieval, processing, storage and onward sharing.
Evidence: logs, configuration and recipient-side records.A recognizable client name or public client ID is not proof that the request came from the expected software process. MCP’s security guidance explicitly discusses this problem for local applications. A known vendor name also does not establish which subscription, organization or output workspace is involved. MCP security best practices →
That does not make verification impossible. A controlled integration can combine trusted identity evidence, organization policy and destination restrictions. But the evidence must match the claim. Proving which organization signed in does not necessarily prove where the resulting chat will be stored.
For a reviewer, a useful distinction is “approved by an administrator” versus “destination verified by the system.” The first records a decision. The second requires a technical mechanism. Ask the vendor which it can demonstrate.
04 / ASSURANCE
Read the scope behind the badge
Several useful forms of assurance appear together on vendor websites. They answer different questions.
| What you see | What it can tell you | What to inspect |
|---|---|---|
| “HIPAA compliant” | A claim about a service or arrangement. HHS does not certify or endorse particular products as HIPAA compliant. | The actual controls, supported use, contract and customer responsibilities. |
| A BAA | Binding obligations for a defined business associate relationship. | Legal parties, covered services, permitted uses, subcontractors, incident reporting and termination terms. |
| A SOC 2 report | An independent CPA examination of controls in a defined service organization system. Type 2 includes operating effectiveness over a specified period. | System boundary, period, exceptions and controls the customer must operate. |
| ISO/IEC 27001 certification | Certification of an information security management system against the standard, within a defined scope. | Certificate scope, legal entity, covered locations and services, issuer and validity. |
Sources: HHS cloud guidance, HHS BAA provisions, AICPA SOC services, AICPA report review checklist, ISO/IEC 27001.
Private HIPAA assessments and certification services exist. HHS does not recognize those certifications as removing legal obligations. HHS certification FAQ →
A security report or certificate can support due diligence. It does not establish that every product feature or connected AI service is covered by a BAA. A BAA, in turn, does not replace risk analysis or operational safeguards.
For the clinic in our example, the practical question is whether the recipient is acting as a business associate and whether the required agreement covers that use. The recorder’s BAA does not automatically extend to an independently chosen chat service. Nor can we assign all liability to either the clinician or the recorder vendor from the existence of an MCP button. Duties depend on the parties’ roles, conduct and agreements. HHS on business associate obligations →
05 / THE REVIEW
Review a working configuration
A useful review starts with one real task, such as “summarize this appointment for the care team.” The following is a practical review method, not a universal HIPAA checklist.
Draw the complete path.
Name the operator of every step: capture, transcription, storage, retrieval, model processing and saved output. Include diagnostic logs, backups and exports. Record the actual account and workspace, not just the vendor logo.
Match purpose and contracts to that path.
Identify the data involved, who needs it and why. Check the selected product, plan, features and subprocessors against the applicable agreements. Ask about training, retention, support access and deletion separately. “Not used for training” does not answer the other questions.
Limit access to the task.
Check whether the connection can read one note, a selected folder or every past and future meeting. Test search and listing tools as well as full-transcript retrieval. Use the narrowest workable scope.
Check who controls the connection.
Can an organization block unapproved destinations? Can staff override the setting? Can access be revoked centrally? A warning can explain a decision; it cannot enforce a restriction. Default-off settings and organization-wide controls may be sensible requirements for a deployment. They are not a universal MCP-specific mandate written into HIPAA.
Test with synthetic notes.
Create a fictional record with a distinctive phrase. Try an approved account, an unapproved account, a forbidden record and a revoked connection. Inspect available logs and destination history. A successful happy-path demo tells you little about denied access.
Keep an owner and a review date.
Record what was approved, by whom, under which settings and for which use. Revisit the decision when a vendor, model, feature, workspace or contract changes. An inventory should include unapproved connections too; listing one is not approval.
The Security Rule requires regulated entities to assess risks and apply appropriate safeguards. It includes access and audit controls, as well as administrative and physical protections. The six steps above translate that broader work into questions about an AI note workflow; they do not exhaust the rule. HHS Security Rule summary →
06 / AUDIT & INCIDENTS
Keep evidence, and understand its limits
For a retrieval event, useful evidence might include the user or credential, connection, time, requested operation, relevant record identifiers and allow-or-deny result. The exact fields depend on the architecture. A generic “tool succeeded” message may not answer whose information was returned.
Logs need their own access rules and retention policy. Avoid copying full transcripts into diagnostic logs merely to prove that a read occurred. Even identifiers and search terms can be sensitive.
A source-side log can show that content was returned to a credential or session. It generally cannot, by itself, establish which downstream model processed the content, how long a recipient kept it or whether every copy was deleted. Those questions require evidence from the recipient and the applicable contractual process.
through that connection.
It does not recall a transcript already returned.
Test revocation explicitly, including already-issued credentials. Separately establish how recipients handle existing chats, exports and backups. Deleting the source note and deleting downstream copies are different operations.
If an unexpected disclosure occurs, contain the affected path and preserve evidence for the organization’s incident process. Do not assume that a successful tool call proves a reportable breach, or that a technical mistake cannot be one. HHS describes when an impermissible use or disclosure is presumed to be a breach, the exceptions, and the documented risk assessment used to determine a low probability of compromise. HHS breach notification guidance →
07 / COMMON MISCONCEPTIONS
Six shortcuts that lead reviewers astray
- “The note taker is compliant, so every connected workflow is covered.”
- Review the recipient, account, purpose and contract at each handoff. An approved starting point does not establish an approved destination.
- “Read-only means nothing leaves.”
- Reading can return a copy. Source integrity and control over disclosure are different concerns.
- “The user clicked Allow, so the organization approved it.”
- A software permission prompt does not demonstrate organizational approval or establish a required contract.
- “Local is automatically compliant; cloud is automatically disallowed.”
- Location is one design choice. Assess the full workflow, device security, access, operators and applicable agreements.
- “No training means no storage.”
- Training use, chat history, operational logging and retention are separate issues. Ask for a separate answer to each.
- “We removed the names, so HIPAA no longer applies.”
- Other details can identify someone. HIPAA recognizes Expert Determination and Safe Harbor methods for de-identification; informal name removal alone does not establish either. HHS de-identification guidance →
08 / BEFORE THE NEXT CONNECTION
Ask for a diagram and a demonstration
For a concrete configuration review, see our practical Locus workflow guide, including storage, backups, MCP scope and a fictional test script.
Ask the vendor to trace one fictional note from capture to its final output. Have them show the exact account, the allowed scope, the receiving service, the relevant agreement and what happens after access is revoked.
Then record three things separately: what the system enforces, what the contract promises and what your organization has approved. That small discipline makes the next review clearer, and the next unexpected handoff easier to investigate.