A control framework tells you what to do. Whether your organization can actually do it is a question of people, ownership, and maturity, and the workforce now includes the agents acting on its behalf.
When we published Operationalizing Enterprise AI Security: An Open-Source Framework for AI Cyber Risk Management with Eric Cardinal of Delta Dental of California at SPIE, the central argument was that AI introduces a class of risk that existing cybersecurity programs were not designed to address. Prompt injection, data poisoning, model extraction, AI output liability, and agentic goal misalignment are not variations of known software vulnerabilities. They are properties of how AI systems learn, infer, and act. Managing them requires a specialized vocabulary, a structured risk catalog, and specific controls mapped to organizational owners.
That paper provided the operational layer: 112 security-oriented definitions, a taxonomy of 187 risks cross-mapped to MITRE ATLAS and the MIT AI Risk Repository, and more than 200 sub-controls across 25 domains. Reflecting on the engagement afterward, Eric captured the harder truth underneath the artifacts:
AI security gets plenty of attention, but attention is not the same thing as maturity.
A framework tells you what to do. It does not, by itself, tell you whether your organization is actually capable of doing it.
For healthcare risk and security leaders, that distinction is where the real work begins. This post extends the framework in the direction it points but does not fully cover: the human and organizational dimension of AI risk management, and why a control catalog only delivers value once it sits inside a workforce that can execute it.
Why healthcare raises the stakes
AI does not stay contained within a defined technology boundary. It surfaces in clinical decision support, claims and benefits adjudication, prior authorization, member and patient communication, revenue cycle operations, and the third-party integrations that connect all of them. Each of these touches either protected health information or a consequential decision about a person’s care or coverage. The blast radius of an AI failure in healthcare is therefore measured not only in records exposed but in decisions distorted.
Consider a prior-authorization agent trained on historical approval data. If that data is manipulated, or simply skewed, the agent can begin approving or denying requests according to a pattern no one intended, such as favoring a particular diagnostic code. No system is breached and no alert is triggered. The problem surfaces only later, in the aggregate, after a large number of decisions have already been made.
This is also where the limits of conventional security become visible. Traditional programs treat risk as a function of code, configuration, and access. They assume deterministic systems: the same input produces the same output. AI does not behave that way. A model produces outputs through statistical inference, so the same prompt can yield different answers. Behavior emerges from training data and design choices rather than fixed logic. And an attacker who never penetrates the network perimeter can still steer the model by crafting the content it consumes. A deployed model is simultaneously a data artifact and a running system, which means a single attack can constitute a data exposure, an intellectual property loss, and a regulatory violation at once.
The operational gap, and why ownership is the hard part
The most valuable early decision was to begin with language rather than technology. The engagement made this concrete: confusion up front usually turns into weak architecture later. When a security reviewer and a clinical informatics engineer mean different things by “guardrail,” the review produces findings the engineer cannot act on. When legal and engineering disagree on what counts as an “AI system” under an applicable regulation, compliance coverage becomes ambiguous. Shared definitions are not an academic exercise. They are the precondition for everything downstream.
But the framework’s deeper diagnostic value is a single question it forces every organization to answer. For each of the 25 control domains, from Secure Data Lifecycle to Incident Response and Forensics to the agentic domains governing tool use and human oversight: who owns this today? In most organizations, the honest answer is that no dedicated ownership exists. Unowned controls are unenforced controls, and in high-stakes deployments, unenforced controls translate directly to unmanaged risk.
This is why we frame the program around an AI Security Service Team that operates horizontally across the organization rather than as another narrow technical function. It is also where the framework runs into a problem it cannot solve on its own. Assigning a control domain to a named owner is necessary. But it assumes the people in that organization can reason about data provenance, model behavior, adversarial technique, and business impact in a single analytical frame. That combination does not map cleanly to existing security specializations. An organization that deploys the framework without also building that cross-disciplinary expertise will find its control domains formally assigned but operationally empty.
The workforce is now blended
There is a second reason the human dimension cannot be treated as an afterthought. The actors creating risk are no longer only people. They are increasingly the AI systems and agents that people delegate to.
The Living Security Human Risk Management Maturity Model, featured by Health-ISAC as its State of Human Cyber Risk Report, makes this case directly: cyber risk now lives in decisions, and those decisions are increasingly delegated to AI systems and autonomous agents operating at machine speed. The 2025 Verizon Data Breach Investigations Report attributes roughly 60% of breaches to a human element. The model also argues that agents inherit the same behaviors, biases, and mistakes as the humans who deploy them, but with far greater blast radius. This inheritance is not metaphorical. It occurs through the prompts that define an agent’s objectives, the data it is trained and grounded on, and the decisions delegated to it without human review. Each is a path by which a human assumption or error is reproduced, now at machine speed and scale. Managing cyber risk now means managing both people and the agents acting on their behalf.
This aligns with an observation made about the AI capability itself. The surrounding environment can be well secured while the model remains the wildcard. AI is goal-oriented and optimized for completion. It pushes toward satisfying requests and closing gaps even when context is incomplete or boundaries are weaker than they should be. That does not make it malicious. It means the system operates according to its design incentives, and those incentives concentrate risk wherever controls are weak, inconsistent, or too trusting. An agent finds the path of least resistance for the same structural reason a careless or rushed employee does.
The two views converge on the same operating principle. Defense in depth has to be real, layered, and deliberate, accounting for the infrastructure around the model, the data flowing into it, the outputs coming out of it, the users interacting with it, the systems connected to it, and the decisions made on its results. The control framework specifies the technical layers. The maturity model supplies what those layers depend on: visibility into who and what is acting on the organization’s behalf, and the ability to take targeted action when behavior drifts.
From framework to maturity
For a healthcare CIO or CISO, the practical synthesis is that two questions have to be answered together, not in sequence.
The first is technical and is what our framework addresses: which AI-specific risks apply to our deployments, which controls mitigate them, and who owns each control domain. The framework is published openly under a Creative Commons license precisely so that healthcare organizations can adapt it to their own technology stacks, risk appetites, and regulatory environments rather than starting from a blank page.
The second is organizational and is what the maturity model frames well: how visible is our workforce risk, including the risk delegated to AI and agents, and can we measurably reduce it over time. The maturity model’s progression from reactive compliance toward predictive, risk-informed operations is a useful mirror for AI governance specifically. An organization at its initial stage uses AI tools informally, with no inventory of AI systems or agents and no guardrails. A mature organization maintains a comprehensive inventory with defined owners, approved use cases, logging, and automated detection of risky activity. Neither question is sufficient alone. A control catalog without organizational maturity produces documentation rather than defense. Workforce visibility without a structured control framework produces awareness without a clear path to action. Healthcare organizations need both, and they need them oriented around the same blended workforce of people and agents.
Where to start
The most useful first move is also the least expensive. Inventory the AI systems and agents already operating in your environment and ask, for each of them, what data it relies on, what actions it can influence, and who is accountable when it fails. That exercise tends to surface both gaps at once: the control domains with no owner, and the delegated activity with no visibility.
The inventory also makes the harder problem more manageable. The cross-disciplinary expertise the framework requires cannot be acquired through a single hire or a one-time training effort. It develops over time, as named owners work through the specific risks of the systems they manage. Assigning ownership of individual systems is therefore not only a control measure; it is also how an organization builds that expertise.
Treating AI as an asset class with both traditional and genuinely new risks, governed through intentional and layered defense, is the disciplined path between panic and blind optimism. We built the open-source framework because the industry has not yet caught up to what enterprises deploying AI in consequential settings need today. Healthcare, given what is at stake in its decisions, has the least room to wait. If your organization is working through these questions, that is the conversation we want to have.
The framework is open source.
The AI Cyber Risk Framework is published under a Creative Commons license at github.com/FireMountainLabs/ai-cyber-risk-framework.