Responsible AI inHealthcare: How WeBuild AI ThatClinicians Can Trust
Trust in clinical software is not earned by a statement of values. It is earned by being specific about where the software stops, who decides, and what can be reconstructed afterwards if someone asks how an entry got into a patient's chart or onto a claim.
So this page describes mechanisms, not intentions.
The rule behind everything
Every Kratu AI agent prepares the work. A person makes the decision.
One rule governs all four agents, and everything else on this page is a consequence of it. AI assembles, drafts, scores and suggests. It does not diagnose, prescribe, code, submit or write off. Those remain acts performed by a named person who can be asked why.
Kratu AI preparesAutonomous Substrate
Assembles, drafts, scores, suggests
- 01Organizes what a patient wrote into agenda items
- 02Drafts documentation on your clinical template
- 03Surfaces gaps, diagnoses and referrals from the record
- 04Extracts billing rules from payer policy documents
- 05Recommends codes with the rule behind each one
- 06Scores claims and accounts for risk
- 07Drafts an appeal letter
Stage 1: Pre-ExecutionZero Autonomous Commit
Irreversible Human Gate
Decisions are gated by named credentials
Your team decidesCredentialed Human
Reviews, edits, approves, acts
The patient edits their own agenda before sending it- The clinician edits and approves every note
- The clinician confirms each insight before it reaches the chart
- A reviewer approves low-confidence policy values
- A coder accepts or rejects each recommended code
- A biller decides to escalate, appeal or write off
- A person sends the claim, the order and the prescription
Stage 2: Execution & Record EntryAuthenticated Clinician Only
If an AI output reached a patient record or a payer without someone choosing it, that would be a defect, not a feature.
Clinical
Responsible AI principles for clinical documentation and insights
These govern Visit Prep and Kratu Co-Pilot — everything that touches a patient, a clinician or the medical record.
1AI does not practise medicine
An agent may organize what a patient said, or point out that a recorded condition never reached the problem list. It does not conclude what is wrong with anyone.
How it is enforcedEnforcement architectureVisit Prep structures the patient's own words into agenda items and is constrained from diagnosing, prioritizing items clinically or suggesting conditions. Co-Pilot Insights presents findings as flagged for the clinician to consider rather than concluded, and names the source each one came from.
Applies to: Visit Prep, Kratu Co-Pilot
2Nothing enters the record without a clinician
The review step is not a formality bolted onto a finished action. It is the point at which the action happens at all.
How it is enforcedEnforcement architectureDraft documentation is reviewed and edited before approval. Approving a note does not send orders, prescriptions or referrals — it brings the identified items forward for the clinician to select, and selected items are created but remain unsent until a separate sending step. Insight recommendations open the record for the clinician to update and confirm; nothing is added until they do.
Applies to: Kratu Co-Pilot
3The clinician controls what is captured
In behavioral health and addiction treatment, a patient may disclose something they do not want recorded, or ask for capture to stop entirely. That has to be possible in the moment, without leaving the encounter.
How it is enforcedEnforcement architectureRecording, pause and stop controls stay with the clinician throughout the encounter, in view rather than buried in a settings screen. The transcript builds visibly, so what has been captured is never a matter of trust.
Applies to: Kratu Co-Pilot
4The software adapts to your clinical practice, not the reverse
An AI that only produces one note format quietly pushes every organization toward documenting the same way. That is a clinical decision being made by a vendor.
How it is enforcedEnforcement architectureDocumentation follows the clinical templates configured for your organization during implementation, beyond SOAP notes to the templates your teams already use. The clinician selects the template for the encounter.
Applies to: Kratu Co-Pilot
5Patient identity is verified before any information appears
A link convenient enough that patients actually use it must not also be a link that shows a stranger someone's chart.
How it is enforcedEnforcement architectureThe patient enters name and date of birth, which is matched against the patient and the upcoming appointment. A one-time passcode is sent to the phone number already on record, and no patient information is displayed until that passcode is verified.
Applies to: Visit Prep
Revenue
Responsible AI principles for coding, claims and the revenue cycle
These govern Payor Policy Intelligence and the A/R Agent — everything that touches a code, a claim or a payer. Coding carries billing and licensing consequences, so the bar here is different from a recommendation engine.
Swimlane 01Deterministic Checks vs Probabilistic Uncertainty
1A certainty and a likelihood are never blended
A rule that failed and a risk that is elevated are different kinds of statement. Averaging them into one confident number is how a biller gets talked past a hard failure.
How it is enforcedDeterministic checks — utilization limits, provider credentialing, payer identifier validity, prior authorization — produce a pass or fail against a cited rule and are shown separately from probabilistic risk signals. A deterministic failure is always surfaced as a rejection reason and is never overridden by a favourable score.
Applies to: Payor Policy Intelligence
2Uncertainty is surfaced, never smoothed over
Extraction from a document is not uniformly reliable. A system that hides that fact is the one that quietly corrupts your payer configuration.
How it is enforcedEvery extracted value carries a confidence score. High-confidence values are applied, medium-confidence values are held for a reviewer to approve, and low-confidence values are not written at all — a task is created and routed to your queue. A field with no matching content in the policy is returned as unmapped rather than guessed.
Applies to: Payor Policy Intelligence
Swimlane 02Organization Policy Thresholds vs Score Prioritization
3The thresholds are yours, not the model's
Where the line falls between "apply this automatically" and "a person should look at this" is a policy decision belonging to your compliance team.
How it is enforcedConfidence routing is configuration rather than model behaviour. Your organization sets the thresholds that decide what is applied, what is reviewed and what is held.
Applies to: Payor Policy Intelligence
4A score ranks the work; it does not do the work
Prioritization and action are separate. Telling a team which accounts deserve today's attention is useful. Deciding to write one off is not the software's call.
How it is enforcedAccounts and claims arrive scored and banded, with the figures behind the score on screen to be checked. Whether a high-risk band means escalation, a phone call or a payment plan is decided by your team. Appeal letters are drafted for review, edit and export — not filed.
Applies to: A/R Agent
Swimlane 03Execution Authorization vs Longitudinal Accuracy Verification
5No code is committed and no claim is sent by AI
Under-coding leaks revenue and over-coding creates audit exposure. Neither risk should be taken on a clinician's behalf.
How it is enforcedRecommended codes are presented with their rationale and confidence, and a user adds the ones they accept — individually or in a batch. Nothing is auto-committed. Claims are generated in draft and scored; submitting one remains a deliberate, separate action.
Applies to: Payor Policy Intelligence
6Predictions are measured against what actually happened
A model's accuracy is a claim about the world, and claims about the world should be checked rather than asserted.
How it is enforcedReal payer outcomes — accepted or denied, and the payer's own reason codes — are captured and linked back to the original prediction, so predicted acceptance can be compared against actual acceptance over time.
Applies to: Payor Policy Intelligence, A/R Agent
Audit
Making every AI output explainable after the fact
The question that matters is not whether the AI was right. It is whether, months later, someone can reconstruct why a code, a diagnosis or a policy value is on the record — and who agreed to it.
Audit Ledger Governance Protocol
Every Kratu AI inference binds historical parameters, source token anchors, and the signing staff member's credentials directly to the resulting database row.
| What was produced | What is retained with it |
|---|---|
| A recommended code | The rationale, the confidence score, and whether it was AI suggested or manually entered — kept with the record, not only displayed at the time. |
| An extracted billing rule | A reference to the passage of the payer's document it was read from, so the value can be checked against the original. |
| A clinical insight | The source it was drawn from — today's documentation, a previous encounter, results on file. |
| A claim prediction | The score, the reasons and the recommendations, retained alongside the claim rather than overwritten by the next run. |
| An approved note | The clinician who reviewed and approved it, and the items they selected afterwards. |
Data
How we handle patient data and AI training
The shortest section on this page, because the answer is short.
Not used for training
Patient data is not used to train AI.
Strict Boundary
Inside the systems you already run
Every agent works within Elixir, on the records your organization already holds, rather than moving patient data into a separate product.
Zero External Export
Shown only after verification
In patient-facing flows, no protected health information is displayed until the patient's identity has been verified.
Pre-Verification Gate
Questions answered specifically
Retention, access scope and processing questions are answered against your agreement and configuration, not with a general statement.
Contractual Specificity
Evaluation Aid
Questions to ask any healthcare AI vendor, including us
If you are evaluating clinical or revenue cycle AI, these are the questions that separate a governed system from a demo. Ask them of every vendor on your list. We would rather you asked them than took this page on faith.
Evaluation Point 01Execution Surface
What exactly happens when a clinician clicks approve?
Is anything transmitted, or only created? Ask them to name each object and its resulting status. Vague answers here are the ones that surprise you in production.
Evaluation Point 02Autonomous Writes
Can the AI write to the record without a person?
If the answer is "only in certain cases," ask which cases, who configured them, and whether the configuration is visible to your compliance team.
Evaluation Point 03Confidence Thresholds
What happens when the model is not confident?
Is uncertainty surfaced at all? Is there a threshold below which output is withheld rather than shown with a caveat? Who sets it?
Evaluation Point 04Provenance & Source
Can you show me the source behind one recommendation?
Pick a code, a rule or an insight in the demo and ask where it came from. The answer should be immediate and specific.
Evaluation Point 05Logic Separation
Is a rule failure ever outweighed by a good score?
Ask how deterministic checks and probabilistic risk are combined. If they are blended into a single number, ask what happens to a hard failure.
Evaluation Point 06Data Rights
Is our patient data used to train your models?
Ask for it in writing, and ask whether the answer differs for de-identified data, for aggregate statistics, or for prompts sent at inference time.
Evaluation Point 07Real-world Benchmark
How is accuracy measured, not asserted?
Ask what outcome the vendor compares predictions against, over what period, and whether you will be able to see that comparison for your own organization.
Evaluation Point 08Boundary Definition
What does the AI refuse to do?
A vendor who cannot name a limit has not thought about one. The answer tells you more than any capability list.
Boundaries
What we do not claim
Responsible AI pages are usually a list of things a vendor is good at. These are the things we are not, stated here so nobody discovers them during an implementation.
Kratu AI is not a clinical decision maker
It does not diagnose, prescribe or determine medical necessity. Clinical judgement remains with the clinician, and the software is designed so that it cannot appear otherwise.
Non-claim 01
It does not remove the coder or the biller
It reduces the typing and the searching. Someone still accepts the code, works the denial and decides whether to appeal.
Non-claim 02
It is not a compliance guarantee
Correct configuration, current payer policies and your own review processes still determine compliance. The software supports that work; it does not certify it.
Non-claim 03
A confidence score is not a promise
It expresses how strongly the system supports a suggestion, not how likely a payer or reviewer is to agree. Scores rank work; they do not settle questions.
Non-claim 04
Answers
Frequently asked questions about responsible AI at Elixir
The questions clinical, compliance and IT leaders ask most often.
Does Kratu AI make clinical decisions?
No. It does not diagnose, prescribe or determine medical necessity. Agents organize, draft, surface and score. Clinical judgement remains with the clinician.
Can AI write to a patient record without a person?
No. Draft documentation is reviewed and edited before approval, and insight recommendations open the record for the clinician to update and confirm. Nothing is added until they confirm it.
Is patient data used to train AI?
No. Patient data is not used to train AI.
What happens when the AI is not confident?
Uncertainty is surfaced rather than hidden. Medium-confidence values are held for a reviewer to approve, and low-confidence values are not written at all — a task is routed to your queue instead.
Can an AI-generated output be explained months later?
Yes. Recommendations retain their source — the rationale and confidence behind a code, the policy passage a rule was read from, the reasons behind a claim score — kept with the record rather than only shown at the time.
Does a good risk score ever override a failed rule check?
No. Deterministic checks produce a pass or fail against a cited rule, and a failure is always surfaced as a rejection reason regardless of the probabilistic score.
Can a clinician stop the AI capturing a conversation?
Yes. Recording, pause and stop controls stay with the clinician throughout the encounter.
Does responsible AI mean the AI does less?
It means the AI does the preparation and a person makes the decision. That boundary is what makes the output usable in a record that has to withstand review.
See it rather than read it
Ask us the hard questions on a live record
Bring your compliance lead. Pick any recommendation in the demo and ask where it came from, what happens on approval, and what is retained afterwards.