HIPAA-Compliant AI Agents for Hospitals: A Primer

The demo works. Scheduling moves faster. Intake feels less cumbersome. A prior-authorization packet that once took an employee half an hour comes together in minutes.

Then the compliance team asks two reasonable questions: Where does the protected health information go? And if an auditor reviews the system six months from now, who can account for every access event?

That conversation does not have to end the project. In fact, it is usually the point at which a promising experiment either becomes a production capability or remains a demo.

For HIPAA-compliant AI agents that handle patient data, the privacy documentation and acceptance evidence must move alongside the product—not trail behind it. A development partner should be able to show that path early, including an executed Business Associate Agreement before PHI reaches any sandbox{1}.

A working prototype in week one, with no commitment required, gives healthcare leaders a practical way to confirm that fit before approving a full build.

When a Useful Agent Is Still Waiting for Answers

Hospital operations teams encounter this situation all the time.

A revenue-cycle or patient-access group pilots an AI agent on a real workflow. It may schedule appointments and check eligibility, collect digital intake forms and route them into the EHR, or assemble prior-authorization packets for a human reviewer. The results on sample cases are encouraging, and the staff using it want to move forward.

Then the harder questions arrive. How will it connect to athenahealth, Epic, or Cerner? Where will PHI travel along the way? Which users and systems will be allowed to see it? If something goes wrong, will the audit trail be detailed enough to reconstruct what happened?

These questions should shape the Statement of Work before the schedule and budget are locked. Addressing them early leads to a far cleaner implementation: the workflows are specific, the integrations are named, and everyone knows what evidence must exist before go-live.

The leaders who successfully bring agents into production are not necessarily the most technical. They are usually the ones who define “done” clearly—what the agent will complete, what records it will leave behind, and who will be able to operate it after handoff.

What “HIPAA-Ready” Actually Means

“HIPAA-ready” should describe an operating model, not serve as a marketing label. A hospital should be able to ask straightforward questions about the agent and receive evidence-based answers.

Protected health information, or PHI, is identifiable patient information related to care or payment{2}. Covered entities such as hospitals and health systems share responsibility with their business associates—vendors that handle this data on their behalf{1}. A Business Associate Agreement, or BAA, spells out those responsibilities and must be in place before PHI enters a test or production environment{1}.

For an AI agent, that foundation should also include:

• Role-based access that limits people and systems to the information their work requires, in keeping with the minimum necessary standard{3}

• Encryption both while data is stored and while it moves between systems{4}

• Audit logs showing who accessed PHI, when the access occurred, and what happened next{4}

• Security testing in the production environment before launch

• Current SOC 2 Type II evidence that applies to the systems involved in the engagement{5}

These are not items to leave in a security appendix and revisit at the end. They belong in the acceptance criteria. The hospital should be able to see the controls working before it approves payment and go-live.

What This Looks Like in Scheduling, Intake, and Prior Auth

Compliance language can become abstract quickly. It is easier to evaluate an agent by looking at the actual work it performs.

Here is what three common hospital workflows can look like when operational needs and privacy requirements are addressed together.

Scheduling support

The agent confirms available appointment times, checks eligibility through approved interfaces, and writes the resulting status back to the EHR. It does not expose clinical notes that the scheduling role has no reason to see. Each PHI lookup is recorded, while exceptions—such as incomplete demographics or a coverage gap—go to an employee with the relevant context already assembled.

Intake support

The agent collects forms, checks that required fields are complete, and places structured information in the appropriate areas of Epic, Cerner, athenahealth, or NextGen. Its access stops at the intake data it needs. Clinical documentation remains behind the controls already used by clinical staff. The immediate operational benefit is simple: fewer incomplete charts on the day of the visit.

Prior-authorization support

The agent gathers the materials a reviewer would otherwise chase manually: payer requirements, supporting attachments, and ICD-10 coded documentation where needed{6}. A person still reviews and approves the submission. Meanwhile, the system records what it retrieved and attached, giving the revenue-cycle team a defensible history of how the packet was prepared.

In each case, the workflow is not finished merely because the agent produces the right output. It is finished when the agent runs in an environment representative of the hospital’s infrastructure, the audit logs can be queried, and the clinical-operations team can accept the process without creating manual workarounds around it.

Request a week-one prototype for a focused piece of your scheduling, intake, or prior-authorization workflow. It is an opportunity to examine both the experience and the evidence trail before committing to a full build.

Five Questions Every HIPAA Agent Proposal Should Answer

A proposal does not need to be packed with jargon, but it does need to be specific. These five questions make a useful review framework. If one cannot be answered with evidence, the scope probably is not ready to lock.

1. What work will the agent actually complete?

The contract should identify the specific scheduling steps, intake fields, prior-authorization packets, integrations, and data flows included in the build. “Build an AI agent for revenue cycle” leaves far too much open to interpretation. Story-level deliverables, paired with a capped change-order process, help both sides handle new requests without quietly expanding the project.

2. What privacy and compliance evidence will the hospital receive?

The BAA should be executed before PHI enters the sandbox. Current attestations should apply to the systems being used, and each PHI flow should be limited to the information a given role genuinely needs.

3. How will production readiness be demonstrated?

The hospital should see the agent operate in a sandbox that reflects its environment. Before launch, the vendor should demonstrate access controls, encryption at rest and in transit, and usable audit logs for PHI access events{4}. Logging is part of a production-ready system, not an enhancement for a later phase.

4. Who carries the delivery risk?

The agreement should make clear who absorbs the cost if the project runs long and who is responsible for defects in the vendor’s work. With a locked, fixed-fee unosquare engagement, overrun costs remain with the builder when the scope was agreed and priced before development began.

5. What happens at handoff—or if the relationship ends?

The hospital should know exactly what it will receive: source code, deployment configurations, data exports, operating guides, and an agreed transition period. Long-term control of the system matters just as much as the agent’s initial performance.

How unosquare Delivers a HIPAA-Ready Hospital Agent

Those five questions are resolved before a fixed-fee agreement is signed. From there, the delivery rhythm is deliberately straightforward so hospital leaders can stay involved without having to manage the development team day to day.

During week one, Discovery, unosquare maps the chosen workflow, builds a working sandbox prototype, and prepares a priced draft Statement of Work with measurable acceptance criteria. The BAA is executed before PHI enters the discovery environment{1}. The hospital is not required to commit to the full project at this point.

Week two focuses on Solution Architecture. The team finalizes the technical design, EHR integration specifications, acceptance tests, audit trails, and data-flow maps. It also defines access rules role by role. Only then is the price locked and full development approved.

Across weeks three through eleven, the Build phase produces working software on a regular cadence. The team validates the named clinical-operations workflows, patient-access controls, and audit-log design against the agreed acceptance criteria. If the work on that locked scope takes longer than promised, unosquare absorbs the additional cost rather than passing it to the hospital.

Week twelve covers deployment and handoff. The hospital receives the source code, deployment configurations, operating documentation, and monitoring setup. Formal sign-off completes the transition, leaving the internal team able to run the system independently from day one.

Projects typically take 8–12 weeks and begin around $100K, with scope and pricing settled before full development starts. Deep integrations with athenahealth, Epic, or Cerner—as well as strict regional hosting or data-residency requirements—can increase the cost. The locked Statement of Work provides the final price.

When a Platform Is Enough—and When a Custom Build Makes Sense

Not every hospital workflow warrants a custom agent. Before choosing an approach, start with three questions.

Will the workflow handle PHI?

No-code and vendor-hosted agents, including platforms such as Hyro, can be a sensible option for patient-engagement use cases involving little or no sensitive data. Once PHI becomes part of the workflow, however, the expectations around accountability, auditability, and ownership become much more demanding.

How much integration does the workflow require?

A standard scheduling workflow that uses published APIs may fit a configurable platform backed by a strong BAA{7}. A workflow that reaches further into the EHR—pulling clinical documentation, ICD-10 coded records, care-coordination data, or eligibility information—will often call for a custom build.

When large language model outputs influence operational or clinical decisions, human-in-the-loop oversight and clear data provenance should be part of the original design{8}{9}. Retrofitting those safeguards after launch is considerably more difficult.

What would an auditor expect to see?

If reviewers may need to reconstruct what the system did, when it acted, which data it accessed, and which controls were active, the logging architecture must exist from the beginning. Configurable platforms differ significantly in the level of detail they record and allow customers to export.

Use case	Recommended approach
Appointment scheduling or patient engagement, no PHI	No-code platform
Standard EHR API integration, moderate PHI	Configurable platform with BAA
Deep EHR integration, clinical documentation, audit mandates	Custom fixed-fee build
Revenue cycle management, strict data residency	Custom fixed-fee build

Is a HIPAA-Ready Agent Build Right for Your Hospital?

A fixed-fee HIPAA build tends to make sense when:

• A successful healthcare AI pilot cannot move into production until privacy and acceptance requirements are addressed

• Leadership has approved a specific AI capability and attached a delivery date to it

• The required EHR integration is too deep for a lightweight platform

• The organization wants to own the code and operate the system independently after launch

It may be more than the organization needs when:

• The workflow does not involve PHI

• An established vendor-hosted product already covers the use case under acceptable BAA terms

• The long-term plan is to build an internal healthcare AI engineering team

• The organization can keep a lower-risk workflow on an existing compliant platform

For healthcare organizations subject to both HIPAA and GDPR, an established vendor-hosted platform may also be sufficient for lower-risk workflows when its compliance certifications and contractual terms meet the organization’s requirements{10}.

The custom model is intended for health systems that need a clearly bounded deliverable, ownership of the finished product, and a production handoff without an open-ended consulting engagement.

Start with the BAA. Then Watch the Agent Work.

Before committing to a full HIPAA AI build, watch the agent handle a representative piece of a real workflow. Seeing it schedule an appointment, process an intake form, or assemble part of a prior-authorization packet will reveal more than another vendor presentation.

unosquare delivers that prototype in week one, with the BAA signed before PHI enters the environment. There is no commitment required at that stage.

References

1. U.S. Department of Health and Human Services. (2026). Business associates. HHS.gov. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html

2. U.S. Department of Health and Human Services. (n.d.). The HIPAA Privacy Rule. HHS.gov. https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html

3. U.S. Department of Health and Human Services. (n.d.). Minimum necessary requirement. HHS.gov. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

4. U.S. Department of Health and Human Services. (n.d.). Summary of the HIPAA Security Rule. HHS.gov. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html

5. AICPA & CIMA. (n.d.). System and organization controls: SOC suite of services. AICPA & CIMA. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services

6. Centers for Medicare & Medicaid Services. (n.d.). ICD-10. CMS.gov. https://www.cms.gov/medicare/coding-billing/icd-10-codes

7. Office of the National Coordinator for Health Information Technology. (n.d.). Standardized API for patient and population services. HealthIT.gov. https://www.healthit.gov/test-method/standardized-api-for-patient-and-population-services-acb-atl/

8. National Institute of Standards and Technology. (n.d.). AI RMF core. NIST AI Resource Center. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

9. World Health Organization. (2024). Ethics and governance of artificial intelligence for health: Guidance on large multi-modal models. WHO IRIS. https://iris.who.int/handle/10665/375579

10. European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679

Our Editorial Standards

unosquare is committed to publishing accurate, carefully researched information about B2B software delivery. Our editorial team reviews every article and relies on reputable sources, including industry analysts, standards bodies, academic institutions, peer-reviewed research, and established enterprise technology providers. References are checked for relevance and accessibility at the time of publication.

We work hard to keep this information accurate, but mistakes can happen, and guidance may change as delivery models, pricing benchmarks, and technology standards evolve. If you find an error or an outdated reference, please contact us so our team can review it.

Important Disclaimer

This article is provided for general informational and educational purposes. It is not legal, financial, or technical implementation advice and should not be treated as such. Consult qualified technology advisors, legal counsel, and other appropriate professionals before making decisions about software investments, vendors, or delivery models. unosquare assumes no liability for actions taken solely on the basis of the information presented here.