Clinical-grade AI for healthcare and health-tech.
Healthcare AI in the UAE is regulated by DHA in Dubai, DOH in Abu Dhabi, and MOHAP at the federal level, with requirements covering clinical decision support, patient data handling, and AI-assisted diagnosis or treatment tools. Steinn Labs builds AI systems for healthcare and health-tech companies, including multi-agent clinical decision support systems designed to meet regulatory and clinical-safety requirements, including HIPAA and FDA CDS classification considerations for US-market healthcare AI.
More fragmented than fintech. Here is the honest map.
Healthcare AI does not have one clean regulator story. UAE health authorities set the local frame, while US regimes like HIPAA and the FDA's CDS classification shape any product that intends to serve US patients or providers. Many UAE-based health-tech companies will touch both, which is why building with US-grade discipline from day one is a real commercial advantage, not scope creep.
Health authorities in Dubai, Abu Dhabi, and federally set expectations for AI tools used in clinical settings. Licensing, data handling, and clinical governance are the recurring themes. Public rulemaking is still forming, which makes intent and evidence of safe design the most important signals.
Applies whenever protected health information of US patients is handled, including by UAE-incorporated firms serving US providers or payers. Covers technical, physical, and administrative safeguards for data at rest and in transit, plus breach notification obligations.
The FDA distinguishes informational tools a clinician can independently evaluate from tools that drive specific clinical actions. Crossing that line typically brings a system under medical device regulation. The classification decision changes the entire build, evidence, and clearance path.
Relevant for AI systems inside telehealth workflows, particularly around controlled substance prescribing. Constrains what an AI can surface, recommend, or automate in a virtual care setting, and affects how the clinician-facing experience is designed.
Clinical safety is an architecture problem, not a policy document.
Doctrine and guideline grounding
Outputs are anchored to specific clinical guidelines, protocols, or institutional doctrine, not to a language model's general knowledge. Every recommendation traces back to the source it relied on.
Human-in-the-loop by design
Any diagnostic or treatment-adjacent output is surfaced as decision support for a licensed clinician. Sign-off gates, override flows, and clear system framing are part of the product, not settings.
Clinical audit trails
Every recommendation carries the who, what, and why: which model version, which sources, which inputs, and which clinician acted. Reviewable long after the shift ends.
Classification awareness
We know when a tool is drifting from informational into regulated CDS territory under FDA-style frameworks, and we design the boundary deliberately instead of discovering it during clearance.
Two shapes of engagement, depending on what you are building.
Doctrine-grounded copilot systems for clinicians.
Multi-agent systems that surface protocol-aligned recommendations to clinicians, with human sign-off gates, full audit trails, and awareness of where the tool sits on the CDS classification line. This is the shape of the Brite work.
Patient apps, provider tools, and clinical data platforms.
Broader health-tech product builds where AI is one part of a larger system. Patient-facing apps, provider workflow tools, and data platforms built with the same clinical-safety and regulatory discipline from day one.
A short engagement before you commit to a full build.
Many health-tech founders need answers on classification and compliance before spending on engineering. We offer this as a distinct, lightweight engagement drawn directly from the analysis we have done for live clinical products.
HIPAA readiness review
A structured look at how patient data flows through the proposed system, where the gaps are, and what the minimum viable path to HIPAA-grade controls looks like for your specific use case.
FDA CDS classification assessment
An analysis of where your tool sits on the informational versus regulated CDS line, what design choices push it in either direction, and the practical implications for your build and go-to-market.
State AI disclosure law review
For firms operating across US states, a review of the emerging patchwork of AI disclosure and consent rules that increasingly apply to healthcare AI in the consumer channel.
Brite: doctrine-grounded clinical AI in production.
Brite is a multi-agent clinical decision support system we built to surface protocol-aligned recommendations to clinicians. The architecture grounds every output in specific clinical doctrine, routes higher-risk outputs through explicit clinician sign-off, and captures a full audit trail behind every recommendation.
The compliance work behind Brite covered HIPAA controls, FDA Clinical Decision Support classification analysis, DEA telehealth constraints, and the emerging state-level AI disclosure rules. That combination of clinical architecture and regulatory depth is what we bring to every healthcare engagement.
Credentials that matter when a health-tech buyer runs diligence.
What AI regulations apply to healthcare in the UAE?+
Healthcare AI in the UAE is governed by the health authority the provider is licensed under. DHA covers Dubai, DOH covers Abu Dhabi, and MOHAP sets the federal baseline. Expectations cover licensing of health AI tools, patient data handling, clinical governance, and clinician oversight for anything that touches diagnosis or treatment. The public rulebook is thinner than in finance, which means intent matters: regulators want to see safe design, human accountability, and a clear paper trail before a tool goes live in a clinical setting.
Do AI clinical decision support tools need FDA approval?+
It depends on what the tool actually does. The FDA's Clinical Decision Support framework distinguishes between informational tools that a clinician can independently review and higher-risk tools that drive a specific clinical action. Systems in the second category are typically regulated as medical devices and require FDA clearance. Getting the classification right early is the single most important decision for a health-tech founder, because it changes the entire build, evidence, and go-to-market path.
What is the difference between an informational AI tool and a regulated clinical decision support system?+
An informational tool surfaces information, references, or summaries that a qualified clinician can independently evaluate before acting. A regulated CDS tool influences or directs a specific clinical decision in a way the clinician cannot practically verify from first principles. The dividing lines are the specificity of the recommendation, how much clinician judgement is preserved, and whether the reasoning is transparent. Most tools that end up as regulated devices got there by drifting across these lines during the build.
Is HIPAA compliance required for AI health-tech companies outside the US?+
HIPAA applies when protected health information of US patients is handled, regardless of where the company is based. A UAE-incorporated health-tech firm serving US providers, patients, or payers is in scope. Even for firms without US exposure today, building to HIPAA-grade controls from day one is often the right call, because the alternative is a costly retrofit the first time a US customer or investor runs due diligence.
Can AI be used for diagnosis or treatment recommendations under UAE law?+
AI can support clinicians in the UAE, but autonomous diagnosis or treatment is not the expectation. Regulators want a licensed clinician accountable for the decision, with the AI positioned as decision support. Practical requirements include human sign-off gates, clear documentation of what the system recommended and why, and controls on the data used to train and run the model. Framed correctly, this is not a blocker for real clinical products.
What is doctrine-grounded AI in healthcare?+
Doctrine grounding means the system's outputs are anchored to specific clinical guidelines, protocols, or institutional doctrine, not to a language model's general knowledge. Every recommendation can be traced back to the source material it relied on. This is the difference between a plausible-sounding answer and a clinically defensible one, and it is a design choice that has to be made at the architecture stage, not added later.