Generative AI Is in Your EHR. Now What.

Generative AI in the EHR is already a risk issue, not a future project. If ambient note tools, chart summaries, or AI prompts are live in your system, you need to review them now for patient safety, HIPAA, vendor terms, and clinician sign-off.

A few facts make that plain:

• 62.6% of U.S. hospitals running Epic were using ambient documentation AI in a 2025 study
• One health system rolled out ambient listening to 4,000+ clinicians
• AI summarization research found about 1.5% hallucinations and 3.5% omissions
• Even a small error rate can affect many patients when these tools are used every day

Here’s the short version of what I’d do:

• Find every live AI feature in the EHR stack
• Sort each one by risk, especially for safety, PHI, security, and vendor exposure
• Set clear ownership across security, privacy, legal, IT, and clinical leaders
• Keep AI output as draft-only until a clinician reviews and signs off
• Test each workflow on its own, including data flow, logging, model behavior, and bias checks
• Update BAAs and contracts for training use, retention, sub-processors, and feature changes
• Watch post-go-live changes like model updates, incidents, and new data use

Put simply: AI in the EHR should be treated like a clinical risk, a privacy risk, and a cyber risk at the same time. The article argues for a clear path: inventory, governance, workflow review, contract fixes, and post-launch checks.

That is the core point of the piece, and it sets up the rest of the article.

1. Identify Which EHR AI Features Change Your Risk Profile

Ambient Documentation, Summarization, and Decision Support

Ambient documentation, chart summarization, and in-workflow decision support are the three EHR AI functions creating the most immediate risk.

Ambient clinical documentation listens during patient visits and drafts notes in real time. Chart summarization turns a patient’s history, medications, labs, and prior visits into a short overview. That can save time, but it can also hide details that still matter in the full chart. In-workflow decision support shows AI-generated suggestions, risk flags, or differential diagnoses right inside the clinical interface, often while a clinician is ordering or documenting.

These tools don’t all use PHI the same way. That’s why each one needs its own risk review. Start there. The differences between these workflows will show you which ones need a closer look first.

Once you know which features are live, classify each one by risk before clinicians start leaning on it.

Five Risk Categories to Assess First

After you inventory the active features, review each one across these five categories:

Clinical safety needs the closest review because even small error rates can pile up fast across many encounters.

Research on AI summarization accuracy found about a 1.5% hallucination rate and a 3.5% omission rate across nearly 13,000 clinician-annotated sentences.^[2] Those numbers may look small on paper. In practice, at scale, they matter.

One documented hallucination changed a patient’s aortic stenosis severity from moderate to severe, which could directly change clinical management.^[1] Omissions create their own chain reaction. If something drops out of the record once, it can get copied into later notes, used for billing, or passed into other predictive tools.

The U.S. Regulatory Baseline for AI in Healthcare

Several frameworks and rules should anchor both procurement and post-deployment oversight.

HIPAA’s Privacy and Security Rules set the floor for PHI handling, access controls, audit logging, and risk analysis. Those controls need updates when AI adds data flows such as audio transcripts and generated outputs.

ONC’s HTI-1 Final Rule adds a Decision Support Intervention (DSI) requirement at 45 CFR 170.315(b)(11). It makes predictive DSIs part of the certified EHR baseline as of January 1, 2025, and requires certified health IT developers to document risk analysis, mitigation, and governance for each predictive DSI they supply.^[3][4][5]

The NIST AI Risk Management Framework (AI RMF) gives organizations a practical structure - Govern, Map, Measure, Manage - for sorting features by risk level and setting up repeatable oversight processes.

The AMA’s AI Tool Evaluation Guide brings a clinical lens to the review. It recommends assessing each tool’s intended use, level of automation, data sources, validation evidence, and workflow fit before broad rollout.

Use these frameworks to rank AI-enabled workflows before clinicians rely on them. That baseline should shape governance, guardrails, and workflow-level review.

That classification sets the agenda for governance, guardrails, and workflow review.

2. Build AI Governance Before Clinicians Rely on the Output

Form a Cross-Functional AI Governance Committee

Once you know which AI features are live and how they’re classified by risk, the next issue is simple: who owns what? If no one does, teams start using AI without formal sign-off, and risk tends to surface late. Your inventory needs a clear owner.

The governance committee should include the CISO, CIO, privacy officer, compliance and legal counsel, clinical leadership (CMIO, CMO, nursing), health IT operations, and data and AI leads. Each group has a clear lane:

• The CISO handles security and incident response
• The privacy officer tracks PHI flow
• Clinical leaders define appropriate use and specialty-specific thresholds
• Data and AI leads watch performance and bias

This committee should register every AI system, approve deployment in stages, and own escalation.

A 2026 rollout across 12 hospitals and 1,800 medical staff worked because the committee could approve, monitor, and pause deployments.^[7]

Once ownership is clear, the next job is setting rules for how clinicians use the output.

Set Human-in-the-Loop and Documentation Guardrails

The AMA says any AI that affects patient care, clinical judgment, or the medical record needs documented, risk-based governance. And the clinician who signs the note owns the final record.

That’s why AI-generated notes should stay drafts only. Clinicians need to review them, edit them, and attest to their accuracy before anything enters the legal medical record. That step isn’t red tape. It matters in day-to-day care. A large content analysis of 314 AI-generated note sections across 33 specialties and 73 clinicians found substantial edits to AI drafts,^[6] which shows that review is a required step, not a box-checking exercise.

Don’t let AI finalize diagnoses, place orders, send patient messages, or update problem lists without clinician confirmation. AI-generated outputs should also be clearly labeled in the EHR.

Some workflows need even tighter controls. In behavioral health, substance use, and reproductive health, state privacy and consent rules may place extra limits on transcription and summarization.

Use Censinet as the Operating Layer for AI Governance

Censinet RiskOps™ can act as a central hub for AI policies, risk assessments, and task routing. In plain terms, it helps turn committee decisions into action across the teams that need to carry them out.

Censinet AI routes key findings to the right stakeholders: security concerns to the CISO’s team, PHI handling issues to the privacy officer, and clinical workflow changes to clinical leadership. It sends each issue to the right owner and keeps a documented trail. An AI risk dashboard shows active features, open risks, and remediation status.

Just as important, Censinet AI uses a human-in-the-loop model with configurable rules, required approvals, and documented sign-offs. That means the platform supports the same oversight standard your clinical guardrails require.

Once those controls are in place, each AI-enabled workflow still needs a structured risk assessment.

AI in Healthcare: Hidden Cybersecurity Risks

sbb-itb-535baee

3. Run a Structured Risk Assessment for Each AI-Enabled Workflow

Once governance is in place, each AI workflow needs a standard technical review. And each one needs its own review. You can’t lump them together. A note-writing tool, a triage assistant, and a coding helper may all sit inside the same EHR, but they don’t carry the same risk.

That’s the point of a structured assessment: it turns policy into a clear pass-or-fail check for each workflow.

Assess Data Flows, Security Controls, and Model Behavior

Start by mapping every data element the AI feature touches. For ambient documentation, that includes visit audio, real-time transcription, prompts, outputs, logs, and stored artifacts in the EHR or vendor cloud. Each element should be classified, tagged with a retention period, and checked for encryption status and access permissions. You also need to map what leaves the EHR, what stays internal, and where the vendor can reuse it.

Then review the security controls. Focus on the basics first, then go deeper:

• TLS encryption for API calls to external AI services
• Encryption at rest for audio files and transcripts
• MFA and RBAC for both EHR access and vendor configuration portals
• Logging that captures prompts, outputs, model version, and configuration changes, not just standard access events

HIPAA's Security Rule requirements for access control, audit controls, integrity, and transmission security apply to these data streams.^{[10][11][12][13]}

After that, test model behavior. Look for hallucinations, omissions, and bias. In plain English: does the tool make things up, miss key facts, or perform worse for some patient groups than others? Check for invented details, missed allergies or abnormal labs, and uneven performance across race, age, gender, and language. Vendors should provide validation reports with the methodology, datasets, and performance metrics they used. If the model struggles with fragmented notes or specialty-specific terminology, that should be documented and shared with clinicians before go-live.

Traditional EHR Review vs. AI-Enabled EHR Review

AI-enabled workflows need a separate assessment track.

That table shows the shift pretty clearly. A standard EHR review usually asks, “Did the feature work as designed?” An AI review has to ask more: What data did it touch? How was it trained? How often does it fail? Who checks the output before it affects care?

ONC's HTI-1 Final Rule requires certified health IT to support 31 source attributes for predictive DSIs, including purpose, input features, fairness processes, validation, performance metrics, and update schedules.^[9] Your assessment process needs to confirm that those disclosures exist and that your team has reviewed them.

These differences shape the vendor questions and contract terms that come next.

Use Censinet to Standardize AI and Vendor Risk Assessments

Doing this by hand across many AI features and vendors gets messy fast. Censinet RiskOps™ includes AI-specific questionnaires that cover data flows, encryption, access controls, model training and validation, bias testing, incident response, and sub-processor management. The goal is simple: collect the evidence your governance committee actually needs.

Censinet AI™ then summarizes vendor responses and flags high-risk areas, missing controls, and residual risks. It also records fourth-party exposures such as cloud hosts, model APIs, and analytics services behind the product. PHI risk doesn’t stop with the main vendor.

Those risk summaries feed mitigation planning and reassessment. Store evidence in one place so reassessment stays repeatable after updates.

Use those findings to guide vendor due diligence, contract language, and post-go-live monitoring.

4. Tighten Vendor Due Diligence, Contracts, and Ongoing Monitoring

Most AI risk shows up through vendor updates, not brand-new purchases. An EHR release can switch on new generative features before your security or compliance teams have reviewed them. When that happens, the job changes. It’s no longer just about listing features. It’s about checking whether the vendor’s controls line up with how data actually moves through the workflow.

Once you’ve assessed each AI workflow, your vendor terms need to match that reality.

Ask Vendors the Right Questions About AI Data and Controls

Use your workflow inventory to ask direct questions about how the vendor handles data, where inference happens, and who can access it. You want clear answers on a few points:

• Whether PHI, prompts, outputs, or derived data are used to train or improve any model, including third-party models
• Whether tenant-level opt-out or zero-retention processing is available, so PHI is not stored beyond brief use
• Which sub-processors touch the data
• Whether release notes and rollback thresholds exist for model updates ^{[14][19][22][8][4][17][23]}

If a vendor can’t explain this in plain terms, that’s a warning sign.

Update BAAs and Contracts to Cover AI-Specific Use Cases

Those answers should show up in the BAA and order form before clinical use starts. In many cases, an existing BAA does not address AI-specific data use, retention, or release control.

Update it to cover four areas. First, confirm that your organization controls all PHI and AI-generated clinical content, with no vendor ownership rights ^[14][16]. Second, clearly block generalized model training unless you give prior written consent. Third, set maximum retention periods for prompts, outputs, and logs, and require documented deletion processes ^{[17][18][19][20]}. Fourth, require opt-in, not opt-out, for any new AI feature that changes PHI processing or clinical workflows ^[16][21].

It also helps to add AI-specific liability carve-outs for vendor-controlled failures. On top of that, require vendor indemnification for regulatory actions tied to vendor-controlled AI components.

Monitor AI Features After Go-Live, Not Just at Procurement

Contracts matter, but they don’t do much on their own. You still need to watch what changes after go-live. Procurement approval is not the end of review. It’s the start of ongoing oversight.

Track model version changes, new feature rollouts, reported incidents, correction rates, and security findings tied to AI endpoints ^[15]. Set reassessment triggers for a major model update, a reported incident, a new sub-processor, or a big change in how the feature processes PHI.

Censinet can centralize vendor risk records, evidence, and follow-up actions, so your team isn’t starting over every time a vendor ships a new AI capability.

Conclusion: Treat EHR-Embedded Generative AI as a Managed Clinical and Cyber Risk

Generative AI is already built into your EHR and showing up inside day-to-day clinical workflows. At this point, the main issue isn't adoption. It's unmanaged dependence.

These tools affect how clinicians document care and act on patient data. That brings clinical, privacy, security, and third-party risk that old-school procurement reviews often miss.

Once you see the risk clearly, the next step is pretty plain: governance, review, and monitoring. The governance committee should own approval, escalation, and reassessment. That setup helps keep clinical use in line with your risk tolerance as features shift over time.

That said, governance on paper isn't enough. Vendor terms need to line up with it. Contract language should reflect the same data-flow map used in the risk assessment. A BAA that skips PHI retention, model retraining, prompt logging, or deletion does not protect the organization. Procurement sign-off is not the finish line - it's the starting point for monitoring tied to clear reassessment triggers. Censinet RiskOps™ supports this model by centralizing AI risk records, routing findings to the right governance stakeholders, and maintaining continuous oversight across the vendor lifecycle.

Even with strong contracts in place, the workflow still relies on human review. No AI-generated content should enter the legal record without clinician sign-off. AI can draft or summarize, but clinicians need to treat it as input, not fact.

Safe EHR AI adoption is an operating discipline. The groups that handle it well will be the ones that moved with care - putting governance, controls, and monitoring in place before AI changed the workflow.

FAQs

How do we find every AI feature already active in our EHR?

Move past one-off manual reviews and treat this as a continuous discovery process.

Start with a broad AI inventory. Use network discovery and team surveys to spot features employees may not even realize use AI, including tools built into clinical documentation or decision support workflows.

Then keep watching for drift. Monitor vendor data access patterns for unexpected changes. Ask users to self-report unauthorized applications. And scan your SaaS and EHR app environments for tools that slipped past standard procurement.

Who should approve AI-generated content before it enters the medical record?

Clinicians should explicitly sign off on every AI-generated note before it’s finalized or added to the medical record. Simply letting it pass through isn’t enough. That kind of passive acceptance can increase legal exposure and put patient safety at risk.

This step needs to be built into the vendor’s workflow from the start, with audit trails that show the clinician reviewed and approved the content. That extra layer of oversight can help limit automation bias and reduce the risk of patient harm.

What contract terms matter most for EHR AI vendors?

The most important terms should deal with AI-specific risk, not just the usual software language.

Before you share any PHI, require a Business Associate Agreement (BAA). Also state, in plain terms, that your data cannot be used to train or fine-tune models unless you give written authorization.

It also helps to spell out who is responsible for AI-related errors. Add audit rights for AI-specific records, require advance notice before model updates or retraining, and set clear terms for data ownership and portability.

Related Blog Posts

• The Invisible Threat: How AI Amplifies Risk in Ways We Never Imagined
• Clinical Intelligence: Using AI to Improve Patient Care While Managing Risk
• The New Front Line in Healthcare Cybersecurity Is AI Governance
• Healthcare AI Is Expanding Fast but Governance Still Lags Behind