When artificial intelligence began finding its way into everyday health decisions, a difficult question emerged alongside its extraordinary potential; and one we will recursively ask forever, Is it safe?
For those building at the intersection of healthcare and emerging technology, the question was neither theoretical nor easily answered. AI capabilities were advancing rapidly, while the standards, safeguards, and operational practices needed to responsibly deploy them were still taking shape.
ClaraWell, believes that progress did not require introducing every new capability at once. Often, the more responsible approach was to begin with something smaller, understand its limitations, and build deliberately from there.
This thinking helped shape the ClaraWell Health Network: a collection of public condition-specific applications that included health risk assessments combining AI capabilities with structured, rule-based evaluation. Each operated within defined boundaries under a shared intelligence and governance architecture.
What followed was a period of development, deployment, and observation. Our team deliberately made the decision to decommission the network.
This is a reflection on the decisions and engineering behind that work, the principles that informed it, and what we learned about building health AI responsibly.
A Technology Moving Faster Than Its Guardrails
The early expansion of generative artificial intelligence brought remarkable new capabilities into public view. For the first time, increasingly sophisticated language models were widely accessible, capable of interpreting questions, synthesizing information, and engaging in conversations that often appeared remarkably human.
In healthcare, the possibilities are significant, as are the uncertainties.
These systems could produce convincing explanations without reliably distinguishing established medical evidence from incorrect or incomplete information. Their conversational nature also introduced questions about trust, vulnerability, and the influence that seemingly authoritative responses might have on people seeking answers about their health.
For developers, the challenge extended beyond the capabilities of the models themselves. Privacy, informed consent, regulatory obligations, and the practical realities of operating across jurisdictions required careful consideration. Established healthcare responsibilities did not disappear simply because the underlying technology was new and transformative.
Early on, our team recognized a distinction between what emerging AI systems could demonstrate and what we could responsibly make available to the public.
We were also learning how large language models worked. We could not responsibly extend the technology beyond our own ability to understand its capabilities, limitations, and underlying behavior.
Our early development benefited from Microsoft for Startups, NVIDIA Inception, and the flexibility of OpenAI's platform to experiment with emerging AI capabilities. Particularly in early 2025, some experiments brought us close to red lines we had not yet fully understood. As new capabilities emerged, we reconsidered certain approaches, strengthened safeguards, and stepped back where necessary.
Rather than treating increasingly capable models as justification for increasingly unrestricted applications, we began exploring how narrow, structured experiences could introduce useful capabilities while maintaining clearer operational boundaries.
This approach was not without compromise. Restricting functionality could limit flexibility, personalization, and the breadth of experiences available to users. It could also constrain our organization's growth and reach. Yet those same constraints gave us a more deliberate starting point from which to evaluate and deploy emerging technology.
The question was not whether AI would become more capable. It was how responsibly we could introduce its capabilities while the technology, and our understanding of its risks, continued to evolve.
Small, by Design
No single approach could reasonably accommodate the diversity of human health concerns. We believe that introducing AI into healthcare requires more than an increasingly capable language model. It required an understanding of where the technology could be useful, where its limitations mattered, and specifically when its involvement should end. We continue to believe that.
We often described generative AI as a tunnel of intelligence. In healthcare, our responsibility was to understand how to close that tunnel completely before deciding what could safely pass through it to end users.
Rather than beginning with unrestricted capabilities and adding safeguards afterward, we worked backward to close the "tunnel of intelligence", selectively introducing boundaries and functionality we could understand and govern.
The ClaraWell Health Network was developed around this principle.
Rather than offering a single, unrestricted health AI experience, we introduced condition-specific risk assessments. Each application addressed a defined area of health, combining structured, rule-based evaluation with carefully bounded AI capabilities.
One example was FluRisk.com, an influenza-focused health assessment developed with input from our Medical Advisory Community. Like other applications in the network, it was designed around a specific health concern rather than an unrestricted medical conversation.
ClaraChat provided the conversational interface across these experiences, connecting users to the governed pathways of ClaraCortex. Applications such as FluRisk were also developed for English, French, and Spanish audiences, reflecting our intention to make these experiences accessible across languages.
Behind these experiences, we established two distinct engineering pathways: the General Pool and the Risk Pool. These were internal architectural concepts, not structures presented to users. During general conversation, rule-based linguistic recognition could identify opportunities to offer a structured risk assessment. The user's acceptance and informed consent then governed the transition between pathways.
The General Pool supported bounded generative AI interactions. The Risk Pool, by contrast, operated through a structured, rule-based assessment process. Generative AI was limited to delivering questions and adapting conversational language to predefined answer options. A separate, non-AI scoring model calculated the assessment risk score.
This separation was deliberate. We could use generative AI to make an assessment more accessible and conversational without allowing it to independently determine the underlying health-risk calculation.
This distinction was fundamental to our approach: conversational flexibility where appropriate; deterministic evaluation where necessary.
Through continued engineering and optimization, we reduced the model inference cost of an individual assessment to approximately $0.003. This demonstrated the potential for cost-effective, AI-assisted preliminary health screening at institutional scale.
We also made a deliberate architectural decision to operate without persistent conversational memory within each application and cross-network.
In a stateless interaction, information provided during one assessment was not automatically carried into subsequent assessments. This reduced dependencies on historical user context and supported a more limited approach to handling sensitive health information. This also prevented assessments from automatically accumulating into a longitudinal user health history.
There were practical consequences. Without persistent memory, our applications could not readily build longitudinal understanding, personalize experiences across visits, or provide the continuity of users increasingly expected from conversational AI.
These limitations were meaningful, particularly as competing AI experiences became more flexible and conversational.
Yet we believe that greater capability should not automatically require greater collection or retention of health information. Clear boundaries and deliberate data handling provided a responsible starting point for our early deployments.
Importantly, these applications were not independent systems operating under separate safety policies. They were distinct experiences connected through a common underlying architecture, designed to support consistent governance across the network.
That architecture was ClaraCortex (R) General, a shared middleware kernel developed to coordinate intelligence, enforce operational boundaries, and support governance across the entire ClaraWell Health Network concurrently.
One Network, Shared Responsibility
Although the ClaraWell Health Network presented several distinct health entry points, its applications operated through ClaraCortex (R) General, a shared middleware kernel designed to coordinate AI interactions and provide consistent governance across the network.
ClaraCortex brought together specialized service clusters responsible for maintaining clinical boundaries, enforcing conversational scope, identifying potentially unsafe interactions, and supporting jurisdiction-specific requirements. Additional services coordinated relationships between applications across the network.
Among these were specialized service clusters, such as Diagnosis Guard and Topic Scope Enforcer. These coordinated mechanisms helped distinguish general health information from diagnostic claims and maintain defined boundaries around the probabilistic nature of generative AI conversations.
Rather than relying exclusively on the language model to recognize its own limitations or attempt to "prompt" our way into complicit behaviors, these service clusters formed part of ClaraCortex's independent, mathematical & linguistic safeguards governing generative interactions.
These boundaries were designed to operate independently of the language model's own instructions. Rather than relying exclusively on a model to recognize when it was exceeding its responsibilities, ClaraCortex provided additional mechanisms for evaluating and constraining the behavior of generative inference.
Another important architectural achievement was what we described as the "double-drawstring bridge" approach to AI interactions.
Rather than concentrating safeguards exclusively on information entering a generative model, we established controls on both sides of the interaction and in between. Information entering the model passed through ClaraCortex's defined boundaries, while generated responses were evaluated against applicable constraints before reaching the user.
This allowed us to govern specifics within what the model received and what it may return.
Put simply, rather than building a separate safety and control system for every application, we built one shared foundation that each relied upon. This allowed us to manage common responsibilities in one place, introduce updates across the network, and respond decisively when unwanted behaviors were identified.
This architecture reflected a concern from the beginning; how do we continue to govern if we continue to increase the availability of applications? As the number of applications increased, independently maintaining safety policies, privacy protections, and operational controls for each deployment would introduce unnecessary complexity and opportunities for inconsistency.
However, centralization introduced responsibilities of its own. A common governance layer could improve consistency, but weaknesses within that layer could also affect the entire network of applications. Shared infrastructure was not, by itself, evidence that every deployment was operating appropriately.
To address this distinction, we developed complementary governance mechanisms.
The first was a Risk Registry, informed in part by our Medical Advisory Community. It provided a structured approach to identifying and classifying risks associated with operating health AI experiences, helping translate clinical and operational concerns into engineering considerations as well as a paneled approach to clinical risk assessments themselves.
Another example was an ongoing internal process known as System Accreditation.
Rather than granting permanent approval to the network as a whole, we evaluated individual deployments within their specific health contexts. Each application carried its operational boundaries and responsibilities within a larger system. This shared governance architecture could establish common standards, but it could not replace the responsibility to examine and conduct deployment-specific internal safety assessments individually.
These processes reflected a broader principle: the responsibilities associated with deploying health AI do not end when an application becomes available to the public.
Privacy, regulatory responsibilities, and safety required careful consideration, knowing that people from around the world could access our applications. We sought to maintain consistent safeguards across the network while accounting for the different obligations of each jurisdiction and deployment.
And as we continued operating the network, another question became increasingly important: how could we observe meaningful information without compromising the privacy boundaries we had worked to establish?
Health Signal Events
Operating health AI responsibly introduced a difficult contradiction. We needed to understand how our systems behaved in real-world conditions, yet we had deliberately designed our applications to minimize the collection and retention of personal information.
The ClaraWell Health Network operated without conventional user tracking, analytics scripts, or persistent conversational memory or the use of third-party applications. We avoided relying on cookies to follow individuals during or between cross network interactions. These decisions reflected our belief that seeking health information should not automatically require surrendering privacy.
But operating without conventional tracking did not eliminate our responsibility to observe.
An application could be technically available, respond to requests, and appear to function correctly while still behaving outside its intended boundaries. Traditional measures of software performance could not adequately answer every question relevant to responsible health AI.
This challenge contributed to the development of Health Signal Events, an approach to data science and structured observation designed around the particular safety and privacy responsibilities of health AI.
Is it Health?
Before a general Health Signal Event could be considered, we first needed to answer a more fundamental question: was the interaction actually about health?
Not every conversation involving generative AI, even within a health application, takes place in the context of health. People could, and did, use our applications to discuss current events, everyday questions, or even the score of a New York Yankees game. The latter was also one of our own test cases.
Rather than assigning that distinction to the conversational AI model, we developed an independent classification process using predefined linguistic rules, recognizable symptom patterns, and mathematical similarity measurements.
An interaction needed to cross a defined classification threshold before qualifying for further health-signal processing.
This distinction mattered. We did not believe every conversation should automatically become a health observation simply because it occurred within a health application.
By separating the recognition of health-related language from the generative model itself, we introduced another deliberate boundary between conversation, observation, and responsibility.
Observing the System
Behind the simplicity of these micro-applications was a considerably more involved observational architecture.
ClaraCortex used structured event models to distinguish between general health signals, the progression of risk assessments, and completed assessment results. Separate event pathways also addressed compliance-related and operational information.
These observations passed through a dedicated component known as the Bridge, a singular emission service that belonged in the middle of the "draw string" designed to separate the operation of health AI from the process of observing it.
The Bridge served as a unified emission boundary, forwarding structured events to dedicated infrastructure for health signals, compliance records, and operational information.
Importantly, the Bridge was observational rather than authoritative. It served as a dedicated boundary for recording and forwarding structured events without influencing the underlying assessment or its outcomes. Observation remained separate from the systems responsible for determining what happened next.
This separation was intentional. We wanted to understand how assessments progressed, how systems executed, and where unexpected behaviors might require attention, without relying on conventional mechanisms for following users within and across visits.
The approach was not without limitations. Structured assessment information could still be sensitive, and limiting what we observed also constrained what we could investigate afterward. Privacy remained an ongoing engineering responsibility, rather than a condition we could declare permanently achieved.
Early work on ClaraBrain also contributed to this architecture. Through a Health Domain Resolver, qualifying health observations could be mapped to established international health classifications, including ICD-11. This gave Health Signal Events a consistent classification structure beyond the language of an individual conversation, supporting more meaningful analysis across the network.
Health Signal Events and their variations formed part of a broader commitment to operational accountability. They provided a structured foundation for data science, examining system behavior, and supporting our risk governance and internal accreditation processes.
A Promising Future
No single garment fits the galaxy of health.
Human health is deeply individual. Circumstances, experiences, needs, and vulnerabilities differ, often in ways that cannot be adequately understood through a single assessment or conversation.
That diversity remains one of the most compelling challenges facing healthcare AI.
We are particularly interested in the development of more empathetic AI systems. Not systems that merely imitate human compassion, but those designed to recognize uncertainty, respect individual circumstances, and communicate with greater sensitivity to the people relying upon them throughout their health journeys. This includes empathy approaches we refer to as dual response pairing and intent mirrors.
We are developing how additional modalities, including safe conversational voice and visual interactions, might make health intelligence more accessible and intuitive. These capabilities introduce new possibilities for communication, particularly when written language alone cannot adequately serve an individual's needs.
Yet every additional modality introduces responsibilities of its own. Voice and visual information can be deeply personal, requiring careful consideration of consent, privacy, interpretation, and the boundaries of automated assistance.
Equally important is the development of stronger evidentiary systems.
Generative AI can produce remarkably convincing explanations, but convincing language is not a substitute for reliable evidence. We believe health intelligence must increasingly connect its responses to trustworthy sources, preserve the context of that evidence, and remain transparent about uncertainty and limitations.
Ultimately, the value of health AI must be measured not only by its capabilities or safeguards, but by the beneficial outcomes it can deliver for the people and communities it serves.
The lessons of the ClaraWell Health Network increasingly pointed us toward reusable infrastructure: systems capable of supporting different health experiences without requiring every application and future deployment to independently reconstruct the same foundations of safety, governance, and evidence.
Today, that work continues through advanced ClaraCortex kernels and the ClaraBrain platform, building on established foundations for evidence-grounded intelligence, responsible execution, and more adaptive human interactions. These systems represent a deliberate continuation of the engineering principles developed through the ClaraWell Health Network.
We remain confident in this direction, while recognizing that greater capability brings new responsibilities and that important questions about the future of health AI remain dynamic.
Our understanding will continue to evolve alongside technology.
The consequences of a technological decision rarely end with the system in which it was made. Some decisions disappear with their applications; others become foundations for systems not yet imagined. We cannot know precisely where health AI will lead, but we can take proactive responsibility for the conditions under which it develops.
We are particularly grateful to the members of our Medical Advisory Community, whose insight and generosity helped shape this work. Some have since become permanent members of our team, continuing a collaboration that began with the ClaraWell Health Network.
Our ambition is to bring responsible, evidence-grounded health AI to larger healthcare networks, using the foundations we have built to support deployment at scale.
So, is it safe?
We will continue to work to make it so.