government – Cody Sandahl

June 2 2026

Before You Approve AI in Healthcare or Government, Ask These 4 Questions

codysandahlArticles, Author, Tech Projects AI, government, healthcare

There are two unhelpful stories I frequently hear about AI in healthcare and government.

The first story is that this is easy. Buy a license. Turn it on. Tell everyone not to paste sensitive information into the chat box. Done.

The second story is that this is impossible. The regulations are too strict. The acronyms are too dense. Legal will say no. Security will say no. Better to wait.

Both stories miss the point.

Deploying AI in these environments is not like flipping on a new calendar app. It is more like renovating a hospital wing. You are not just picking the paint color. You are checking the locks, the badge access, the records room, the cameras, the policies, and who is allowed through which door.

That sounds heavy, but it should also be reassuring. This doesn’t require magic. It requires governance. And governance is something your organization already knows how to do.

Who This Article Is For

This article is written for healthcare executives, government agency leaders, and program managers who are being asked to approve, fund, or oversee AI initiatives. You do not need a technical background to use it. You need enough context to ask the right questions of the people who do.

TL;DR

The four questions you should ask your technical leaders:

Which AI tools have a signed BAA or FedRAMP authorization in place?
Which of our data is the AI actually able to access, and how is that controlled?
Where are the logs, and who reviews them?
What happens if an employee uses a non-approved AI tool with patient or citizen data?

If your team can answer all four clearly, you are probably in good shape. If the answers are vague or inconsistent, that is the gap to close before you go further.

Help Me With the Acronym Soup

Before going further, let’s translate the language that makes this conversation feel more intimidating than it needs to be.

PHI (Protected Health Information) is any data that can identify a patient and relates to their health: names tied to diagnoses, insurance records, test results, appointment histories. Federal law requires that PHI be handled with strict controls.

PII (Personally Identifiable Information) is the broader category: any data that could identify a specific person. Social Security numbers, addresses, government ID numbers. Both federal and state laws govern how PII can be stored and shared.

HIPAA (Health Insurance Portability and Accountability Act) is the federal law that sets the rules for how health information must be protected. If your organization touches patient data, HIPAA applies to you and to every vendor you share that data with.

A BAA (Business Associate Agreement) is a contract. When your organization shares PHI with a vendor (say, a cloud provider or an AI tool), HIPAA requires that vendor to sign a BAA promising to handle that data responsibly. No signed BAA means no legal basis for sharing PHI with that vendor. Full stop.

FedRAMP (Federal Risk and Authorization Management Program) is the federal government’s stamp of approval for cloud services. Think of it as a security audit that vendors go through so that government agencies don’t have to audit every vendor themselves.

Leaders do not need to become experts in every one of these terms. They just need to hold on to the question underneath all of them: can this vendor handle our information in a way that matches the seriousness of our environment?

“Just Tell People Not to Paste Sensitive Data In”

A lot of AI conversations start with the software equivalent of, “How hard could it be?”

Someone sees a polished demo. A chatbot summarizes documents in seconds. It all looks smooth, and the assumption becomes: if the tool is this easy to use, it must be easy to deploy safely.

That is like admiring a beautiful hotel lobby and assuming the building has no boiler room, security desk, or fire code to worry about.

A premium license does not turn AI into a compliant system. A BAA is not automatic. Government authorization is not automatic. And the phrase “enterprise AI” often hides an important follow-up question: enterprise version of which product, exactly, covering which features?

The deeper problem is what happens once you connect the tool to internal documents. That is where the “just be careful” approach fully breaks down.

Saying “the AI should not see sensitive information” after enabling document access is like handing a contractor a master key and then acting surprised when they can open the doors. The tool is designed to read the files it is given access to. That is the feature. The question is not whether the AI will see sensitive information. The question is whether it sees the right information, under the right permissions, with the right safeguards in place.

“AI Is Off the Table” Is Also Outdated

The opposite mistake is treating regulation as a permanent stop sign.

The major cloud providers have spent the last several years building real pathways for regulated AI. Microsoft, Google, and AWS now offer AI services that operate inside FedRAMP-authorized and HIPAA-eligible environments, with BAAs available, data kept out of model training by default, and audit logs your compliance team can actually use. This was not true three years ago. It is true now.

The right answer is no longer “AI is off the table.” The right answer is “show me the approved path.”

That is a much better question for leadership to ask. Not: “Can we use AI?” But: “Under what conditions can we use AI responsibly?”

Think of AI as a Very Fast New Employee

Here is the clearest way to hold all of this in your head at once.

AI is like a very fast new employee. It can read quickly. Write quickly. Summarize quickly. Find patterns quickly. But it has no instinct for what is legally restricted, politically sensitive, or operationally off-limits unless someone builds those boundaries around it.

So the real job is not deciding whether to hire the employee. The real job is deciding which rooms they can enter, which files they can open, whether they are supervised, what gets recorded, and what kind of work they are allowed to do on their own.

That is why this is neither easy nor impossible. It is manageable, but only for organizations willing to manage it.

The Questions That Separate a Strategy from an Accident

The most effective leaders in this space are not the ones who memorize every compliance term. They are the ones who keep the conversation honest. They know the difference between a demo and an operating model. They know that if a team cannot explain the data boundary in plain language, the design is probably not mature enough yet.

Green-light uses that organizations are doing responsibly right now: searching internal policy documents, drafting patient education materials with human review before anything goes out, summarizing internal memos inside a covered environment.

Red-light uses that require much more caution: fully automated clinical decisions, benefits eligibility determinations without human review, any system where nobody is sure which data the AI is actually reading.

When evaluating any AI initiative, a leader can ask four plain questions of their IT and legal teams:

Which AI tools have a signed BAA or FedRAMP authorization in place?
Which of our data is the AI actually able to access, and how is that controlled?
Where are the logs, and who reviews them?
What happens if an employee uses a non-approved AI tool with patient or citizen data?

These are not technical questions. They are management questions. And they are often the difference between an AI strategy and an AI accident.

If your team can answer all four clearly, you are probably in good shape. If the answers are vague or inconsistent, that is the real risk, not AI itself.

AI in regulated environments is a bounded-yes problem. The boundary is the work. And the organizations that get there first are the ones willing to ask the right questions now.

Provider Comparison Table (illustrative, May 2026)

Provider	Healthcare path	Government path	Gotchas	Best fit when…
Microsoft	Azure OpenAI is available through Microsoft’s HIPAA / BAA framework for eligible services, and Microsoft 365 Copilot can fit into the same broader compliance story for covered tenants.	Azure OpenAI is available in Azure Government with strong federal authorization pathways, including FedRAMP High and DoD environments.	Not every feature is covered, and compliance is not “on” just because you bought an enterprise license.	Best when an organization already lives in Microsoft 365 and wants AI to stay inside an environment their teams already govern.
OpenAI	BAAs are available for certain API, enterprise, and healthcare offerings.	OpenAI now has a government story as well, including FedRAMP Moderate offerings and ChatGPT Gov patterns.	Public ChatGPT is not the same as a governed enterprise deployment, and feature scope matters.	Best when organizations want a strong front-end experience but are willing to be disciplined about contracts, features, and access boundaries.
AWS	AWS supports HIPAA through its BAA plus HIPAA-eligible services such as Bedrock, HealthLake, and Comprehend Medical.	AWS GovCloud and Bedrock now offer a real path for FedRAMP High and IL4 / IL5 use cases.	“HIPAA-eligible” still requires the customer to design and govern the environment correctly.	Best for organizations that want maximum control and are comfortable building a governed AI environment in the cloud.
Google	Google Cloud and Workspace now have meaningful HIPAA-covered paths for Vertex AI, Gemini in Workspace, and healthcare-focused cloud services.	Google also has a growing government story through Assured Workloads and FedRAMP-authorized AI services.	Consumer Gemini, AI Studio, NotebookLM, and some Gemini surfaces are not the same as compliant enterprise or government deployments.	Best for organizations already standardized on Google Workspace or Google Cloud that want AI close to their documents and collaboration tools.
Anthropic	Anthropic offers BAA-ready paths for some enterprise and API customers, and Claude can also sit inside cloud-provider compliance boundaries through Bedrock and Vertex AI.	Claude is also available through approved government-oriented cloud environments such as AWS GovCloud and Vertex AI.	The direct consumer experience is not the same thing as a covered regulated deployment.	Best when organizations want Claude’s model quality but prefer to consume it through AWS or Google’s compliance boundary.

Note: This is a high-level snapshot, not a compliance determination. Coverage, authorizations, and feature scope vary by product and deployment model, and should be validated directly with the vendor before any regulated use.

Sources

Note: Sources were compiled using AI-assisted research and then manually checked for link accuracy, title accuracy, and general relevance. Official vendor documentation was prioritized where available. Because product scope, authorizations, and terms can change, readers should confirm current details directly with the vendor before making compliance or procurement decisions.