Q: What does "AI security" actually mean for an ASC? How is it different from the cybersecurity center administrators already think about day to day?
Dr. Paul Alcock (PA): When people hear "AI security," they sometimes assume it is a completely new category of cybersecurity. It really isn't.
The traditional cybersecurity concerns are still there: Who has access? Is the data encrypted? Is the system patched? Can someone compromise it?
AI adds another layer because now we also have to ask: What information are we giving the AI? Where does that information go? Is it retained? Is it being used to train something? And what is the AI allowed to do with the information or systems it can access?
For an ASC, that becomes especially important because AI may touch patient information, clinical workflows, scheduling, billing, or financial information.
So I think of AI security as cybersecurity plus data governance plus responsible use. The technology may be new, but the objective is the same: protect the patient, protect the organization, and make sure we understand the risk we're accepting.
Q: Who should be part of the conversation when an ASC is evaluating a new AI tool, and what does each of those roles bring that the others might miss?
PA: One of the biggest mistakes would be treating AI as just an IT decision.
You want the person who owns the business or clinical process involved because they understand what problem we're actually trying to solve.
You want clinical leadership involved when the technology affects patient care because they understand where an incorrect recommendation or output could create risk.
You need privacy and compliance asking what information is being used and whether that use is appropriate.
Security and IT need to understand how the technology connects to the environment, who gets access, where the data goes, and what controls are in place.
And depending on the solution, legal and contracting should understand things like liability, data ownership, breach obligations, and what the vendor is allowed to do with your information.
Each group sees a different part of the risk. The goal isn't to create a huge approval committee. It's to make sure somebody is asking each of those questions before you put the technology into production.
Q: What does "data minimization" mean in practice for an AI tool used in an ASC, and why should that matter to an administrator who isn't a security expert?
PA: Data minimization is actually a very simple concept: don't give a system information it doesn't need.
If an AI tool is helping summarize an operative note, maybe it needs certain clinical information. That doesn't automatically mean it needs the patient's entire medical record, insurance information, Social Security number, billing history, and everything else we know about that patient.
The question should always be: What is the minimum amount of information required to accomplish this particular task?
And administrators should care because every additional piece of information you give a system becomes something you now have to protect.
If the vendor doesn't need it, don't send it.
That reduces privacy risk, reduces the impact of a potential breach, and generally makes the entire solution easier to govern. You don't have to be a security expert to apply that principle.
Q: What should a vendor be willing to explain about how their AI works and where patient and other sensitive data goes? What's a reasonable level of transparency to expect?
PA: I don't expect every AI vendor to hand over their source code or explain every mathematical detail of their model.
But they absolutely should be able to explain the data flow.
If I give you patient information, I want to know where it goes, where it is processed, where it is stored, how long you keep it, who can access it, and whether any other company receives it.
I also want to know whether our data is ever used to train or improve a model.
If they're using another AI provider underneath their product, such as a large language model provider, I want to know that too.
And then the normal healthcare security questions still apply: encryption, access controls, audit logging, incident response, vulnerability management, business associate agreements, and independent security assessments.
The vendor doesn't have to disclose their intellectual property. But "it's proprietary, trust us" is not an acceptable answer when patient data is involved.
Q: If you were coaching an ASC administrator through their first AI solution evaluation, what questions would you tell them to ask?
PA: I would actually keep the first conversation very simple.
Ask:
- What problem are we solving?
- What information does the AI need in order to solve it?
- Does any patient, employee, financial, or other sensitive information leave our environment?
- Where does that information go, and who else receives it?
- Is our information retained or used to train a model?
- What happens if the AI is wrong?
- Can a human review or override the result before something important happens?
- And finally, if something goes wrong, can we determine what happened?
Those questions will uncover a surprising amount of risk very quickly.
You can always get deeper technically later. But if a vendor struggles to clearly answer those basic questions, I would be very cautious about moving forward.
Q: What does a strong security posture look like for a company building AI products for healthcare, and how does SIS apply that internally?
PA: The first thing I look for is whether AI security is being treated as part of the company's overall security program rather than as a separate science project.
You still need strong identity management, encryption, vulnerability management, monitoring, incident response, secure software development, third-party risk management, and all of the fundamentals we already expect from a healthcare technology company.
Then you layer AI-specific controls on top.
At SIS, one of the principles we've adopted is that the level of control should increase with what the AI is capable of doing.
An AI tool that summarizes information is very different from an AI agent that can change data, communicate externally, or take an action inside a production system.
We look at things such as least-privilege access, unique identities for AI agents, audit logging, restrictions around sensitive data, human approval for consequential actions, and making sure AI tools only receive the information they actually need.
The objective is not to prevent people from using AI. It's to create a safe path for using it responsibly.
Q: How should an ASC weigh the operational or clinical benefits of an AI tool against the responsibility to protect patient and other sensitive data?
PA: I don't think those two things should be viewed as opposing goals.
There can be enormous value in AI for healthcare. If a technology can reduce administrative workload, improve documentation, help staff find information faster, or allow clinicians to spend more time with patients, we absolutely should explore that.
The question is whether the benefit justifies the risk and whether we can manage that risk appropriately.
Not every AI use case carries the same risk.
Using AI to help draft a scheduling reminder is very different from allowing AI to influence a clinical decision or autonomously change something in a patient's record.
So the higher the potential impact, the stronger the controls should be.
My philosophy is not "security says no to AI." It is: understand the use case, understand the data, understand what the AI can do, and put controls around it that are proportionate to the risk.
If we do that well, security actually becomes an enabler of AI adoption rather than an obstacle to it.
