# Inference Analytics AI: full reference text > Inference Analytics is the company behind the InferAgents Suite, its flagship HIPAA-compliant agentic AI product for health systems. The suite has three parts: Dev Studio, the back end where engineering teams build agents; Inferch, the front-end application staff work in; and PayerAgents, for revenue cycle. None is sold as a separate product. This file contains the complete text of every reference page on https://www.inferenceanalytics.ai, generated from the same source as the pages themselves. Each section states its canonical URL and the date it was last reviewed. Entity structure: Inference Analytics is the company. InferAgents is the product. Dev Studio is the development interface of InferAgents, not a separate product. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/healthcare/hipaa-generative-ai Published: 2026-01-14 | Last reviewed: 2026-08-20 # HIPAA-compliant generative AI for the healthcare sector Generative AI is not HIPAA-compliant or non-compliant as a technology. Compliance is a property of the deployment: where protected health information travels, who can reach it, what is logged, and what contracts sit behind the model. This page sets out each control a health system should expect. **Direct answer:** Generative AI is HIPAA-compliant when protected health information stays inside a controlled boundary, every entity that can access PHI is covered by a business associate agreement, data is encrypted in transit and at rest, access is enforced per user and role, model providers receive only the minimum necessary data under contract, all access and generation is written to an immutable audit log, retention is defined and enforced, and a qualified human reviews any output that affects care. No model is compliant on its own. The platform around it is what makes the deployment compliant. ## What “HIPAA-compliant generative AI” means HIPAA does not name any technology. It regulates covered entities and their business associates, and it defines administrative, physical and technical safeguards for protected health information. A generative AI deployment inherits those obligations the moment PHI enters it. That distinction matters commercially. A vendor cannot truthfully say a model is HIPAA-compliant. What a vendor can say is that its platform implements the required safeguards, will sign a business associate agreement, and can evidence both. When you evaluate claims, the useful question is never "is your AI HIPAA-compliant?" but "which safeguards do you implement, and how would you evidence them in an audit?" | Term | What it means in an AI deployment | | --- | --- | | Protected health information (PHI) | Individually identifiable health information. In an AI system this includes prompts, retrieved context, generated output and logs, not just the source record. | | Business associate agreement (BAA) | The contract that makes a vendor accountable for PHI. Every party that can access PHI needs one, including any model provider reached through the platform. | | Minimum necessary | Only the data required for the task may be disclosed. In practice this shapes what retrieval returns and what is sent to a model. | | Audit controls | Hardware, software and procedural mechanisms that record and examine activity in systems containing PHI. For AI this means logging prompts, retrievals, model calls and outputs. | ## Where PHI travels, and where it must stop The single most important architectural decision is the location of the compliance boundary. In a well-built healthcare AI platform, PHI enters the boundary from the source systems, is processed inside it, and leaves it only under contract and only as much as the task requires. - Ingress. PHI arrives from the EHR, a data warehouse or a document store through an authenticated integration, carrying the requesting user's identity. - Retrieval. The platform selects the minimum necessary context for the task. This is where enterprise RAG design directly affects compliance posture, not just answer quality. - Model call. The assembled prompt goes to the selected model over an encrypted API connection, under a BAA, with provider-side training on the data contractually disabled. - Generation and return. Output returns into the boundary, is logged, and is shown only to users authorised for that patient or that workflow. - Retention. Prompts, context, outputs and logs are retained on a defined schedule and destroyed on it. > The failure mode to watch for: The most common compliance gap is not the model. It is the surrounding tooling. Copy-pasted PHI in a general-purpose chat assistant, an unlogged evaluation harness, or a prototype notebook that pulled real records all put PHI outside the boundary while the production system looks compliant. ## The control set a health system should require | Control | What good looks like | | --- | --- | | Encryption | TLS 1.2 or above in transit; AES-256 at rest, including vector stores, caches and logs. Vector embeddings derived from PHI are treated as PHI. | | Identity and access | SSO against the health system's identity provider, role-based access, and per-agent scoping so an agent can only reach the data its function requires. | | Model boundaries | Providers reached only at the API level under a BAA, with zero-retention or contractually disabled training on submitted data. | | Audit logging | Immutable, queryable logs of who asked what, which context was retrieved, which model answered, and what was returned, retained for the period compliance requires. | | Retention and deletion | Defined retention for prompts, outputs, embeddings and logs, with enforced deletion and a documented process for patient-driven requests. | | Human oversight | A named review step for any output that informs care, with the reviewing clinician recorded in the log. See our AI governance position. | | Subprocessors | A current, published list of every subprocessor that may touch PHI, with notice before it changes. | Inference Analytics implements this control set once, in the platform core, rather than per application. Every agent built in Dev Studio inherits it. Our full position, including certifications and data residency, is on the security, compliance and trust page. ## Retrieval and agents change the compliance surface A plain question-and-answer assistant has one PHI pathway. A retrieval-augmented system has several, and an agentic system has more still, because the agent chooses which tools to call and which data to fetch. The compliance surface grows with autonomy. - Retrieval creates derived copies of PHI in embeddings and caches. Both must sit inside the boundary and inherit its encryption, access control and retention. - Tool use means an agent can reach systems the original prompt never named. Scope each tool to the minimum necessary and log every invocation. - Memory persists PHI across sessions. Treat any memory store as a PHI repository with its own retention schedule. - Multi-step autonomy compounds error. Bound what an agent may do without a human in the loop, and see agentic AI for healthcare for where that line reasonably sits today. ## How to evaluate a vendor's claim Most procurement cycles stall because the questions are too general to disprove. These are specific enough to be answered, or conspicuously not answered. - Will you sign a BAA, and does it cover every subprocessor that can access PHI, including the model providers? - Is provider-side training on our submitted data contractually disabled, and can you show the clause? - Are embeddings and caches derived from PHI encrypted and retained under the same schedule as the source data? - Can you produce, for a named user and date range, every prompt, retrieval, model call and output? - What exactly can an agent do without human review, and where is that boundary configured? - Which certifications do you hold, what is their scope, and when were they last assessed? The full version of this checklist, covering governance, model flexibility, citation accuracy, integration and scalability as well as security, is in our vendor-neutral healthcare AI platform evaluation guide. ## Frequently asked questions **Is ChatGPT HIPAA compliant?** The consumer version of ChatGPT is not appropriate for protected health information: there is no business associate agreement covering consumer use, and PHI entered there leaves the health system's compliance boundary. Enterprise arrangements with model providers can be covered by a BAA, but compliance still depends on the surrounding deployment (access control, logging, retention and oversight), not on the model itself. **Can generative AI be used with PHI at all?** Yes. HIPAA permits the use of PHI for treatment, payment and healthcare operations, including through business associates under contract. Generative AI is not excluded. What is required is that the deployment implements the administrative, physical and technical safeguards HIPAA specifies, and that every party with access to PHI is covered by a business associate agreement. **Do we need a BAA with the model provider, or just the platform vendor?** With both, if the model provider can access PHI. A platform that sends prompts containing PHI to a third-party model is disclosing PHI to that provider, which makes the provider a business associate. Ask your platform vendor to show the chain of agreements rather than assuming their BAA covers it. **Are vector embeddings of clinical notes considered PHI?** Treat them as PHI. Embeddings are derived from identifiable health information and, in practice, information can be recovered or inferred from them. The defensible position is to hold vector stores inside the same compliance boundary as the source data, with the same encryption, access control and retention. **How is InferAgents HIPAA-compliant?** InferAgents implements the HIPAA safeguards once in its platform core, and every agent built on it inherits them: PHI stays inside the compliance boundary, model providers are reached only at the API level under a business associate agreement with training on submitted data disabled, access is governed per user, role and agent, and every prompt, retrieval, model call and output is written to an auditable log with a defined retention schedule. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/healthcare/agentic-ai Published: 2026-01-21 | Last reviewed: 2026-08-20 # Agentic AI for the healthcare sector The gap between what agentic AI is marketed as and what it reliably does inside a hospital is wide. This page describes what is genuinely working in production today, what still requires a human, and how to tell the two apart before you buy. **Direct answer:** Agentic AI in healthcare refers to AI systems that plan a sequence of steps, call tools and systems to gather information or take action, and work toward a goal rather than answering a single question. In health systems today it works reliably for bounded, well-instrumented tasks: payer-specific appeal drafting, CPT coding checks, surfacing protocol and tip-sheet guidance, supply chain reconciliation, and triaging documentation work. It does not reliably make autonomous clinical decisions, and responsible deployments keep a qualified human accountable for anything that affects care. ## What separates an agent from a chatbot A chatbot answers. An agent decides what to do next. The difference is not the model. It is whether the system has tools, state and a goal. | Capability | What it adds | | --- | --- | | Tool use | The system can call an API, query a database or write to another system, rather than only producing text. | | Planning | The system decomposes a goal into steps and chooses their order, instead of following a fixed script. | | State and memory | The system carries context across steps and sessions, so a long-running task survives interruption. | | Evaluation and retry | The system checks its own intermediate results and can retry or escalate when a step fails. | Every one of these expands the compliance surface as well as the capability. An agent that can call tools can reach data the original request never named, which is why tool scoping and logging matter more in agentic systems than in conversational ones. See HIPAA-compliant generative AI for the control set this requires. ## What is working in production today The pattern that works is narrow scope, rich instrumentation, and a clear human checkpoint. These are agent categories running inside health systems on the InferAgents platform now. ### Revenue cycle and billing Denial appeals are an unusually good fit: the policy is documented, the payer's requirements are specific, the source record is structured, and a human already reviews the output before submission. PayerAgents drafts payer-specific appeals against the clause a denial turned on, and checks CPT coding against current policy, with a billing specialist approving before anything leaves the health system. ### Clinical knowledge and protocol support Specialty agents surface guidance grounded in the health system's own protocols rather than generic literature. The Infectious Disease Agent is the clearest demonstration that the core generalises: the workflow is very different from billing, but the platform underneath is identical. ### EHR-adjacent guidance The Epic Tip Sheet Agent surfaces the right tip sheet inline, next to the work rather than in a separate portal. It sits alongside the system of record, never replacing it. This is a deliberate design constraint, because writing back into the EHR raises the stakes of an error by an order of magnitude. ### Operational and supply chain Reconciliation, exception triage and vendor-record cleanup are high-volume, low-ambiguity tasks with an existing audit trail. They are frequently the fastest route to a demonstrable result inside a health system, because nothing about them touches care delivery. ## Where the autonomy boundary sits Being precise about this is a commercial advantage, not a caveat. Health systems have been sold autonomy that did not exist, and buyers now discount vague claims heavily. | Appropriate for agent autonomy | Requires a human decision | | --- | --- | | Drafting a document a human will review and sign | Any diagnosis, or a recommendation presented as one | | Retrieving, summarising and citing internal guidance | Treatment selection, dosing, or changes to a care plan | | Checking a claim against documented payer policy | Final submission of a claim or appeal to a payer | | Flagging an exception or inconsistency for review | Closing or dismissing a clinical exception | | Reading from the EHR under scoped access | Writing to the patient record | > A working rule: If an error would reach a patient before a qualified human sees it, the step is not a candidate for autonomy. Everything else is a question of instrumentation and confidence, not principle. ## Governing agents once you have more than a few The first agent is a project. The fortieth is an estate. Health systems that do not plan for the second case end up with agents nobody owns, running against models nobody has reviewed, on data nobody has scoped. - Named ownership. Every agent has an accountable owner in the health system, not only in the vendor. - Scoped access. Each agent reaches the minimum data and tools its function requires, configured centrally rather than in the agent's own code. - Version and change control. Agents move through the same design, test, stage and ship lifecycle as any other clinical software. - Model review. The underlying model is a reviewable, swappable choice (see multi-model AI for why this matters at renewal time). - Continuous audit. Prompts, retrievals, tool calls and outputs are logged in one place across all agents, not per application. This is the reason InferAgents exists as a platform rather than a set of applications: the governance layer is the hard part, and it does not scale if it is rebuilt for every department. Our full position on oversight and permissions is on the AI governance page. ## Evidence from deployment More than 80 agents run on the InferAgents platform across clinical, revenue cycle, operational and IT-adjacent functions, serving over 3,000 active users and processing more than 200,000 queries since the June 2025 production launch. The platform is live inside University of Chicago Medicine and Mayo Clinic. > Scope of these figures: Figures are platform-wide totals across all deployments as of May 2026, measured from the June 2025 production launch. They describe adoption and usage, not clinical outcomes; we do not claim outcome effects that have not been independently studied. ## Frequently asked questions **What is agentic AI in healthcare?** Agentic AI in healthcare refers to AI systems that pursue a goal across multiple steps (planning what to do, calling tools and systems to gather information or take action, and checking their own intermediate results) rather than answering a single question. In health systems it is used for bounded tasks such as payer appeal drafting, CPT coding checks, surfacing internal protocol guidance and operational reconciliation. **How is an AI agent different from a chatbot?** A chatbot produces a response to a prompt. An agent has tools, state and a goal: it can call APIs, query systems, carry context across steps and retry or escalate when something fails. That extra capability also expands the compliance surface, because an agent can reach systems the original request never mentioned. **Can AI agents make clinical decisions autonomously?** No, and responsible deployments do not attempt it. Agents can draft, retrieve, summarise, check and flag; a qualified human remains accountable for diagnosis, treatment selection and any change to a care plan. A practical rule is that if an error would reach a patient before a clinician sees it, the step should not be autonomous. **What healthcare workflows are agents best suited to today?** Tasks that are bounded, well documented, already instrumented, and already reviewed by a human before they take effect. Revenue cycle appeals and coding checks, protocol and tip-sheet retrieval, documentation triage, and supply chain reconciliation are the categories currently working reliably in production. **How many agents can a health system realistically run?** More than most expect, provided governance is centralised. Over 80 agents run on the InferAgents platform today across clinical, billing, operational and IT functions. The limiting factor is rarely model capability. It is whether access scoping, change control, audit and ownership are handled by the platform rather than rebuilt per agent. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/healthcare/no-code-ai-agents Published: 2026-02-04 | Last reviewed: 2026-08-20 # No-code AI agents for the healthcare sector No-code agent building is real, and it is also frequently oversold. The useful question is not whether an agent can be built without code, but which parts of the work move to a clinical analyst and which stay with engineering, and whether the security model holds either way. **Direct answer:** No-code AI agents let a subject-matter expert configure an agent's instructions, knowledge sources, tools and review steps through a visual interface rather than by writing code. In healthcare this works well for agents built from capabilities the platform already exposes: retrieving internal guidance, drafting documents, checking records against documented policy. It does not remove engineering: integrations, access scoping, evaluation and production change control still require an engineering owner. The safe pattern is a no-code build surface on top of an engineered, centrally governed platform. ## What genuinely moves to no-code, and what does not Drawing this line precisely is what separates a no-code programme that scales from one that produces forty unmaintainable agents in a year. | A subject-matter expert can configure | An engineer still owns | | --- | --- | | The agent's task instructions and tone | Connecting a new source system or API for the first time | | Which approved knowledge sources it draws on | How those sources are indexed, chunked and secured | | Which of the platform's existing tools it may call | Building a new tool, and scoping what it can reach | | The review and escalation steps | Identity integration and role mapping | | Test cases drawn from real work | The evaluation harness those cases run in | | Requesting promotion to production | Change control, versioning and rollback | Read the right-hand column carefully: it is almost entirely security and lifecycle work. That is the argument for a platform rather than a standalone no-code tool. The engineering column is built once, centrally, and every no-code agent inherits it. ## Why healthcare raises the bar General-purpose no-code agent builders assume the builder may connect the agent to whatever data they can reach. In a health system that assumption is unsafe, because the builder's own access is frequently broader than the agent's should be. - Agent access is not builder access. An agent must be scoped to the minimum data its function requires, independently of the permissions of whoever configured it. - PHI leaves a trail the builder cannot see. Prompts, retrieved context and outputs all become records subject to retention and audit. See HIPAA-compliant generative AI. - Errors have a review obligation. A no-code agent that drafts clinical or billing content needs a defined human checkpoint before its output takes effect. - Estate risk compounds. Forty agents built by forty people, each with its own data reach, is a governance problem long before it is a cost problem. > The design rule: No-code should widen who can express a workflow, not widen what the platform will let an agent reach. Access scoping, logging and change control stay centralised and are never configurable from inside the no-code surface. ## How this works on InferAgents Dev Studio, the development interface of InferAgents, is where agents are built. It presents a configuration surface to subject-matter experts while the platform enforces the controls underneath. - Start from an approved template for the agent category (retrieval, drafting, checking or triage), each already carrying its review and logging behaviour. - Select knowledge sources from those an engineering team has already connected, indexed and secured. Nothing new is reachable by selection alone. - Choose tools from the platform catalogue. Each tool's data reach was scoped when it was built, not when it was selected. - Pick or inherit a model. Because the platform is model-agnostic, this is a configuration choice rather than an architectural one. - Test against real cases in the platform's evaluation harness, with results recorded. - Request promotion. An engineering owner approves the move to production, and the agent enters normal change control. The result at University of Chicago Medicine is that the health system's own IT organisation builds directly on the platform, with clinical and operational staff contributing the domain configuration rather than filing requirements and waiting. ## Questions to ask a no-code agent vendor - Can a builder grant an agent access to data the builder can reach but the agent should not? If yes, the security model is inverted. - Where is access scoping configured: in the agent, or centrally in the platform? - What happens between a no-code build and production? If the answer is "nothing", there is no change control. - Can we see, in one place, every agent in the estate, its owner, its data reach and its current model? - Can an agent built without code be evaluated with a repeatable test set before promotion? - If we change the underlying model, do no-code agents need rebuilding? These questions, alongside the security, governance, RAG and integration criteria, are consolidated in the healthcare AI platform evaluation guide. ## Frequently asked questions **What are no-code AI agents?** No-code AI agents are agents configured through a visual interface rather than by writing code. A subject-matter expert defines the agent's instructions, selects approved knowledge sources and tools, sets review steps and tests the result, while the underlying platform provides the integrations, security and lifecycle machinery. **Can clinical staff build their own AI agents?** They can configure them, which is the part that benefits most from domain expertise. What they should not control is what data an agent can reach, how sources are indexed and secured, or whether an agent reaches production. Those stay with an engineering owner, enforced by the platform rather than by policy alone. **Is no-code AI agent building secure enough for healthcare?** It is, provided the no-code surface cannot widen the platform's security boundary. Agent access scoping, audit logging, retention and change control must be enforced centrally and be unconfigurable from inside the build interface. If a builder can grant an agent access simply because they personally have it, the model is not safe for PHI. **Does no-code mean we do not need engineers?** No. It changes what engineers spend time on. Integrations, access scoping, tool development, evaluation harnesses and production change control remain engineering work. What no-code removes is engineering being the bottleneck for every wording change, knowledge-source swap or new variation of an existing agent pattern. **What is Dev Studio?** Dev Studio is the development interface of InferAgents: the environment inside the platform where agents are designed, tested and shipped. It is a component of InferAgents rather than a separate product, and it is not licensed or deployed independently. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/healthcare/enterprise-rag Published: 2026-02-18 | Last reviewed: 2026-08-20 # Enterprise RAG for hospitals and health systems Retrieval-augmented generation is how a health system gets answers grounded in its own protocols rather than the open internet. It is also where most healthcare AI projects quietly fail, because retrieval quality, not model quality, determines whether the answer is right. **Direct answer:** Enterprise RAG for a health system is a pipeline that finds the most relevant passages from the organisation's own approved knowledge, passes them to a language model as context, and returns an answer with citations back to the source. Done well it substantially reduces hallucination and makes answers checkable. Its hard parts are not the model: they are honouring each user's access permissions at retrieval time, chunking clinical documents without severing meaning, keeping the index current, and treating the vector store as a PHI repository. ## How RAG works, in the order it actually runs - Ingest. Approved sources (protocols, policies, formularies, tip sheets, payer rules) are collected with their metadata, ownership and effective dates. - Chunk. Documents are split into retrievable passages. This step decides answer quality more than any other, and clinical documents punish naive splitting. - Embed and index. Passages become vectors in a searchable store, alongside a keyword index. Access metadata travels with every chunk. - Retrieve. The user's question is used to find candidate passages, filtered, always, by what that specific user is permitted to see. - Rerank. Candidates are reordered by genuine relevance, which materially outperforms taking the top vector matches. - Generate. The model answers using only the retrieved context, and is instructed to say when the context does not contain the answer. - Cite. Every claim links back to the source passage, with its document, section and effective date. > Where projects fail: Almost never at step 6. The recurring failure points are chunking that severs a dosage from its condition, an index that has drifted months out of date, and retrieval that ignores who is asking. ## Permission-aware retrieval is not optional The most consequential design decision in healthcare RAG is that filtering must happen during retrieval, not after generation. A system that retrieves broadly and then tries to redact has already put the content into the model's context and, usually, into a log. - Access metadata on every chunk, mirroring the source system's permissions rather than a copy that drifts. - Filter at query time using the requesting user's identity, so two clinicians asking the same question can legitimately receive different results. - Re-check on refresh. When a source document's permissions change, the index must reflect it. Stale access metadata is a live disclosure risk. - Treat the vector store as PHI. Embeddings derived from clinical records inherit the encryption, retention and audit requirements of their source. See HIPAA-compliant generative AI. ## Chunking clinical documents Fixed-length chunking works acceptably on prose and badly on clinical material, where meaning is carried by structure: a dose belongs to a drug, which belongs to an indication, which belongs to a patient population. | Document type | What retrieval must preserve | | --- | --- | | Clinical protocols | The condition, population and exclusion criteria that qualify each step. A step retrieved without its exclusions is actively dangerous. | | Formulary and dosing | Drug, indication, dose, route and population as one unit, never split across chunks. | | Payer policy | The payer, plan, effective date and the specific criterion. Policies supersede one another, so dates are part of the meaning. | | Epic tip sheets | The workflow context and the version of the build the sheet describes. | | Committee minutes and memos | Status: proposed, approved, superseded. Retrieving a rejected proposal as current guidance is a classic failure. | In practice this means structure-aware chunking with generous overlap, metadata carried on every chunk, and a knowledge-graph layer for relationships that vector similarity cannot express, such as which policy supersedes which. ## Reducing hallucination, and measuring that you have RAG reduces hallucination; it does not eliminate it. A model given weak context will still produce a confident answer. The controls that matter are as much about measurement as about generation. - Grounded generation. Instruct the model to answer only from retrieved context and to state plainly when the answer is not present. - Mandatory citation. Every substantive claim carries a source link. An uncitable claim should not be displayed as an answer. - Abstention as a success state. "This is not covered in your approved sources" is a correct answer, and should be measured as one rather than counted as a failure. - Retrieval evaluation, separately from answer evaluation. Most quality problems are retrieval problems wearing a generation costume. - Freshness checks. Surface each source's effective date so a reader can see when guidance is stale even if it was retrieved correctly. ## RAG inside agents In an agentic system, retrieval stops being a single step and becomes a tool the agent may call repeatedly, with queries it composes itself. That is more capable and harder to govern. - Every retrieval call is logged with its query, its filters and what it returned, not just the final answer. - The agent's retrieval scope is bounded at configuration time, so it cannot widen its own reach mid-task. - Repeated retrieval is bounded, so a failing loop cannot pull large volumes of PHI into context. - Citations survive multi-step reasoning: the final output still points at source passages, not at the agent's own intermediate summary. See agentic AI for healthcare for how these bounds fit the broader autonomy question. ## Frequently asked questions **What is enterprise RAG?** Enterprise RAG is retrieval-augmented generation applied to an organisation's own knowledge. Rather than relying on what a model learned in training, the system retrieves relevant passages from approved internal sources, passes them to the model as context, and returns an answer citing those sources. In a hospital that means answers grounded in the organisation's own protocols, formulary and payer rules. **Does RAG stop AI hallucination?** It reduces hallucination substantially but does not eliminate it. A model given poor or irrelevant retrieved context can still generate a confident, wrong answer. The controls that make RAG dependable are grounded generation prompts, mandatory citations, treating abstention as a correct outcome, and evaluating retrieval quality separately from answer quality. **Is a vector database secure enough for PHI?** A vector store holding embeddings derived from clinical records should be treated as a PHI repository: encrypted at rest, inside the same compliance boundary as the source data, subject to the same retention schedule, and filtered by the requesting user's permissions at query time rather than after generation. **Do we need a knowledge graph as well as a vector database?** For clinical knowledge, usually yes. Vector similarity finds passages that resemble the question, but it cannot express relationships such as which policy supersedes another, which protocol applies to which population, or which tip sheet matches the current EHR build. A graph layer carries those relationships; the vector index handles semantic recall. **How do we keep the index current?** Treat freshness as a monitored property, not a migration task. Sources are re-ingested on a schedule tied to how often they change, permission metadata is re-checked on every refresh, each chunk carries an effective date that is surfaced with the answer, and superseded documents are marked rather than silently deleted so a citation to old guidance still resolves. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/healthcare/multi-model-ai Published: 2026-03-04 | Last reviewed: 2026-08-20 # Multi-model AI for the healthcare sector The best model for a clinical summarisation task is not the best model for structured extraction, and neither is guaranteed to be the best a year from now. Health systems that hard-wired one provider in 2023 have spent 2025 and 2026 paying to undo it. **Direct answer:** Multi-model AI means an architecture where the underlying language model is a configuration choice rather than a structural dependency. A model-agnostic platform exposes stable internal interfaces for prompting, retrieval, tool use, governance and logging, and connects to OpenAI, Anthropic, Google or a health system's own internal models only at the API level. This lets an organisation route different tasks to different models, adopt better models as they appear, keep sensitive work on internal models, and change providers without rebuilding its agents. ## Four reasons single-model architectures age badly - Task fit varies. Long-document clinical summarisation, structured extraction from scanned forms, and multi-step tool use have genuinely different leaders, and the ranking changes with each model generation. - Cost varies by an order of magnitude. High-volume, low-complexity work (classification, routing, extraction) does not need a frontier model. Routing it to a smaller one is frequently the single largest cost lever available. - Some data should not leave. A health system may reasonably decide certain workloads run only on internal or self-hosted models, regardless of the contractual protections around external providers. - Providers change. Pricing, terms, deprecation schedules and availability all move. An architecture that assumes one provider converts every one of those into a project. > The procurement consequence: Model-agnostic architecture is a negotiating position as much as an engineering one. A health system that can move workloads between providers in a configuration change is a different counterparty at renewal than one that cannot. ## What model-agnostic actually requires Nearly every vendor claims to be model-agnostic. Most mean they have an adapter for more than one provider, which is the easy part. Portability is decided by everything built on top of that adapter. | Layer | What portability requires | | --- | --- | | Prompting | Prompts held as versioned platform assets with per-model variants, not embedded in application code against one provider's quirks. | | Tool and function calling | One internal tool definition, translated per provider. Otherwise every tool is rewritten per model. | | Retrieval | Retrieval that is provider-independent, so the RAG layer does not have to be rebuilt when the model changes. | | Governance and audit | One audit schema across providers, so a compliance query spans the whole estate rather than one model's logs. | | Evaluation | A shared test set that can be run against any candidate model, which is what makes switching a measured decision rather than a leap. | | Cost and usage accounting | Normalised token and cost reporting per user, team and agent across providers. | The test is simple: can you change the model behind a production agent, run your evaluation set, and promote or roll back, without touching the agent's definition? If not, the architecture is multi-provider, not model-agnostic. ## Routing work to the right model Once models are interchangeable, routing becomes a live operational decision rather than an architectural commitment. - By capability. Multi-step agentic work to models that are strong at tool use; high-volume extraction to smaller, cheaper models. - By sensitivity. Workloads a health system prefers to keep in-house routed to internal or self-hosted models, enforced by policy rather than convention. - By cost ceiling. Per-agent and per-team budgets that route or throttle when a threshold is reached. - By availability. Automatic failover when a provider degrades, so an agent in a clinical workflow does not simply stop. ## How this works on InferAgents InferAgents connects to model providers only at the API level. Agents are built against the platform's own interfaces, so the model is selected per agent, or changed for an existing one, as configuration. - OpenAI, Anthropic and Google models alongside a health system's internal or self-hosted models. - Per-agent model selection, with a documented default and the ability to override. - One evaluation harness that runs the same test set against any candidate model before promotion. - Unified token, cost and usage accounting per user, team and agent across every provider. - One audit log schema regardless of which model answered. This is also why more than 80 agents run on one core rather than one stack per department: the expensive, reusable work sits in the platform, and the model stays a swappable component. See the InferAgents platform. ## Frequently asked questions **What is multi-model AI?** Multi-model AI is an approach where an organisation runs workloads across several underlying language models rather than committing to one. Different tasks are routed to whichever model fits best on capability, cost or data-sensitivity grounds, and models can be changed as better options appear without rebuilding the applications on top. **What does model-agnostic mean in practice?** It means the underlying model is a configuration choice, not a structural dependency. Concretely: prompts, tool definitions, retrieval, governance, audit and evaluation all live in the platform rather than being written against one provider's API, so you can change the model behind a production agent, run your evaluation set and promote or roll back without editing the agent. **Should a health system use OpenAI, Anthropic or Google?** The premise is the weak part of the question. Task fit, pricing and capability all change with each model generation, so committing to one provider is the risk. The more durable decision is to build on a platform that lets you use all of them, keep certain workloads on internal models, and change your mind later at configuration cost rather than project cost. **Can we run our own internal models alongside commercial ones?** Yes, and many health systems should. A model-agnostic platform treats an internal or self-hosted model as another provider behind the same interfaces, which lets an organisation keep specific workloads in-house on policy grounds while using commercial models where they perform better. **How do we avoid AI vendor lock-in?** Keep the reusable assets (prompts, tool definitions, retrieval, evaluation sets, audit schema and governance) in a layer you control, and connect to model providers only at the API level. Then test portability rather than assuming it: change the model behind a real agent, run your evaluation set and see what breaks. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/resources/healthcare-ai-evaluation-guide Published: 2026-03-18 | Last reviewed: 2026-08-20 # Healthcare AI platform evaluation guide A checklist you can use against any vendor, including us. Each question is written to be answerable, and to make a non-answer visible. Take it into your next three vendor calls and compare. **Direct answer:** Evaluate a healthcare AI platform across ten dimensions: security and HIPAA safeguards; business associate agreements and subprocessors; data handling and retention; governance and human oversight; model flexibility and portability; retrieval quality and citation accuracy; agent capability and autonomy boundaries; integration with the EHR and identity systems; evidence of production deployment at comparable organisations; and total cost including the internal engineering effort required. The strongest signal in any evaluation is whether a vendor answers precisely or reframes the question. ## How to use this guide Send the questions in advance, ask for written answers, and score consistency between the written answer and what you hear on the call. Vagueness that survives a written request is the finding. - Score each dimension out of five, and weight security, governance and integration highest. Those are the ones that block deployment, not the ones that impress in a demo. - Require evidence, not assertion. "We are HIPAA-compliant" is a claim. A BAA, a subprocessor list and a sample audit export are evidence. - Ask the same questions of every vendor, including incumbents and internal build proposals. - Record what was not answered. In our experience this column predicts implementation pain better than any score. ## 1. Security, HIPAA and business associate agreements - Will you sign a BAA? Does it cover every subprocessor that can access PHI, including model providers? - Publish your current subprocessor list. What notice do we get before it changes? - Is provider-side training on our submitted data contractually disabled? Show the clause. - How is data encrypted in transit and at rest, including vector stores, caches and logs? - Which certifications do you hold, what is their scope, and when were they last assessed? - Where does our data physically reside, and can we constrain residency? Background on what each of these controls is doing: HIPAA-compliant generative AI. Our own answers: security, compliance and trust. ## 2. Data handling, retention and audit - What exactly is retained (prompts, retrieved context, outputs, embeddings, logs), and for how long? - Can you produce, for a named user and date range, every prompt, retrieval, model call and output? - How do you handle a patient-driven deletion request that touches derived data such as embeddings? - On termination, what is returned, what is destroyed, and on what timeline? - Are audit logs immutable, and who inside your organisation can read our data? ## 3. Governance and human oversight - Where is the human review step configured, and can it be removed by a non-engineer? - How is an agent's data access scoped, and is it independent of the builder's own permissions? - Can we see every agent in the estate, its owner, its data reach and its current model, in one view? - What change control governs the move from build to production? - How are model changes reviewed and recorded? Our position: AI governance. Context on why scoping must be central: no-code AI agents. ## 4. Model flexibility and portability - Which providers do you support today, and can we use our own internal or self-hosted models? - Can we change the model behind a production agent without editing the agent? Demonstrate it. - Where do prompts and tool definitions live: in the platform, or written against one provider's API? - Do you provide normalised cost and token accounting across providers? - If we leave, what do we take with us: prompts, tool definitions, evaluation sets, logs? What a credible answer looks like: multi-model AI for healthcare. ## 5. Retrieval quality and citation accuracy - Is retrieval filtered by the requesting user's permissions at query time, or is content filtered after generation? - How are clinical documents chunked, and how do you keep a dose attached to its indication? - Does every substantive claim in an answer carry a citation to a source passage with an effective date? - How does the system behave when the answer is not in the approved sources? - How do you evaluate retrieval quality separately from answer quality? - How often is the index refreshed, and how are permission changes propagated? Detail on each: enterprise RAG for hospitals and health systems. ## 6. Agent capability and autonomy - What can an agent do without human review, and where is that boundary configured? - Can agents write to the EHR? If so, under what controls, and should they? - How are agent tool calls logged, and can a failing loop be bounded? - Show us three agents running in production at a comparable organisation, and what they do. - How many agents does your largest customer run, and who maintains them? A grounded view of what is realistic: agentic AI for the healthcare sector. ## 7. Integration, identity and scalability - How do you integrate with Epic or our EHR, and what is read versus written? - Do you support SSO against our identity provider, with role mapping? - What does the first integration take in our engineering hours, honestly? - How does the tenth department differ from the first in effort? - What is your uptime commitment, and what happens to an in-workflow agent when a model provider degrades? ## 8. Evidence, references and total cost - Name production deployments at organisations comparable to ours, and let us speak to them unaccompanied. - How long from contract to first agent in production at those sites? - What did the customer's own team have to build? - Distinguish licence cost from model consumption cost from our internal engineering cost. - What has a customer asked you for that you could not deliver? > The most useful question on this page: Ask the last one. A vendor that cannot name a limitation either does not know their product or is not being straight with you, and both are expensive to discover after signing. ## Frequently asked questions **How should a health system evaluate an AI platform?** Across ten dimensions: security and HIPAA safeguards, BAAs and subprocessors, data handling and retention, governance and human oversight, model flexibility, retrieval and citation accuracy, agent autonomy boundaries, integration with the EHR and identity systems, evidence of comparable production deployments, and total cost including internal engineering effort. Send the questions in writing, ask every vendor the same set, and record what goes unanswered. **What are the biggest mistakes in healthcare AI procurement?** Evaluating on demo quality rather than governance; accepting "we are HIPAA-compliant" without asking which safeguards and what evidence; ignoring the internal engineering cost, which frequently exceeds the licence; and committing to a single model provider, which converts every future pricing or capability change into a migration project. **Should we build our own healthcare AI platform instead of buying?** Building the agent logic is not the hard part; building the compliance boundary, access scoping, audit, evaluation harness and change control is, and it has to exist before the first agent ships. A reasonable test is to scope that platform work honestly, in engineer-months, and compare it against a vendor that already has it in production, then decide whether it is differentiating work for your organisation. **Is this guide biased toward Inference Analytics?** The criteria are written to be answerable by any vendor, and several would be uncomfortable for us to answer badly, particularly those on limitations, portability and what a customer's own team must build. Use it against us alongside everyone else. Where we state our own position, it is linked and labelled as ours. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/security Published: 2026-01-07 | Last reviewed: 2026-08-20 # Security, compliance and trust Our security position, stated specifically enough to be checked. Where a control is implemented, we say how. Where a review is in progress, we say that too rather than implying more than we can evidence. **Direct answer:** Inference Analytics operates InferAgents as a HIPAA-compliant platform and signs business associate agreements with covered entities. Protected health information stays inside the platform's compliance boundary; model providers are reached only at the API level under a BAA with training on submitted data contractually disabled; data is encrypted in transit with TLS 1.2 or above and at rest with AES-256, including vector stores, caches and logs; access is enforced through the health system's identity provider with role-based and per-agent scoping; and every prompt, retrieval, model call and output is written to an immutable audit log under a defined retention schedule. ## HIPAA position and business associate agreements Inference Analytics acts as a business associate to the covered entities it serves. We sign a BAA before any protected health information enters the platform, and our agreements extend to the subprocessors that can access PHI, including model providers reached through the platform. - A BAA is executed before production access is granted, not after a pilot has already handled real data. - Model providers are covered by agreements that contractually disable training on data submitted through the platform. - The minimum necessary standard is applied at retrieval time, so a model receives only the context the task requires. - We do not use customer PHI to train or improve models, our own or anyone else's. > What we do not claim: No AI model is HIPAA-compliant in itself. What is compliant, or not, is the deployment around it. We describe the safeguards we implement and will evidence them; we do not describe any model as compliant. ## Encryption and data protection | Control | Implementation | | --- | --- | | In transit | TLS 1.2 or above for all connections, including to model provider APIs. | | At rest | AES-256 for primary stores, vector stores, caches, backups and logs. | | Derived data | Embeddings generated from PHI are treated as PHI and inherit the same encryption, access control and retention as their source. | | Key management | Managed keys with documented rotation; keys are not shared across tenants. | | Isolation | Customer data is logically isolated per tenant; no cross-tenant retrieval is possible. | ## Identity, access and agent scoping Access is governed on two independent axes: what a person may see, and what an agent may reach. The second is not derived from the first, which is what stops a broadly privileged builder from creating a broadly privileged agent. - Single sign-on against the health system's identity provider, with role mapping maintained in that system rather than duplicated in ours. - Role-based access control for platform functions, including who may promote an agent to production. - Per-agent data scoping, configured centrally, restricting each agent to the minimum data and tools its function requires. - Permission-aware retrieval, filtering at query time by the requesting user's entitlements rather than redacting after generation. - Separation of duties between building an agent and approving its release. Why the second axis matters in practice: no-code AI agents for healthcare. ## Audit logging and retention - Every prompt, retrieval, tool call, model call and output is logged with the requesting identity and timestamp. - Logs are immutable and queryable, and can be exported for a named user and date range for compliance review. - Retention schedules are defined per data class (prompts, outputs, embeddings, logs) and enforced automatically rather than by process. - Deletion requests, including those touching derived data such as embeddings, follow a documented procedure with a completion record. - On termination, customer data is returned in an agreed format and destroyed on a contractual timeline. ## Data residency and subprocessors Data residency is agreed per deployment and recorded in the contract. We maintain a current subprocessor list covering every party that can access customer data, and provide advance notice of changes to it. > Requesting current documentation: Our subprocessor list, current certification scope and assessment dates, security architecture overview and standard BAA are provided under NDA during evaluation. Request them through the contact page and name the documents you need for your review. ## Human oversight Security controls bound what a system can reach. Oversight bounds what it can do unreviewed. Both are required, and we treat the second as a compliance control rather than a product preference. - Agents do not make clinical decisions. Outputs that inform care are reviewed by a qualified human, and that reviewer is recorded. - The review requirement is configured centrally and cannot be removed from inside the agent build interface. - Agents do not write to the patient record; they work alongside the system of record. - Every autonomy boundary is a configuration with an owner and a change history. The full position, including how models are selected and reviewed: AI governance. ## Frequently asked questions **Is Inference Analytics HIPAA compliant?** Inference Analytics operates as a business associate and implements the HIPAA administrative, physical and technical safeguards in the InferAgents platform core: PHI remains inside the compliance boundary, model providers are reached only at the API level under a BAA with training on submitted data disabled, data is encrypted in transit and at rest, access is enforced per user and per agent, and all activity is written to an immutable audit log. We sign a BAA before any PHI enters the platform. **Will you sign a business associate agreement?** Yes, and we execute it before production access is granted rather than after a pilot has handled real data. Our agreements extend to subprocessors that can access PHI, including the model providers reached through the platform. **Do you train models on our data?** No. We do not use customer protected health information to train or improve any model, ours or a provider's. Provider-side training on data submitted through the platform is contractually disabled, and we will show you the clause during evaluation. **Where is our data stored?** Data residency is agreed per deployment and recorded in the contract. Customer data is logically isolated per tenant, encrypted at rest with AES-256, and no cross-tenant retrieval is possible. Specific regions and hosting details are provided during evaluation. **Can we audit what the AI did?** Yes. Every prompt, retrieval, tool call, model call and output is logged with the requesting identity and timestamp, in an immutable and queryable store. For a named user and date range you can export the complete record, including which context was retrieved and which model answered. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/ai-governance Published: 2026-01-07 | Last reviewed: 2026-08-20 # Our AI governance position Governance is the product, not the paperwork around it. This page states how models are chosen and reviewed, where human judgement is required, how agent permissions work, and what we decline to build. **Direct answer:** Inference Analytics governs AI through controls built into the InferAgents platform rather than through policy alone: models are a reviewable, swappable configuration with a recorded change history; a qualified human remains accountable for any output that affects care, and that review step is configured centrally and cannot be removed by an agent builder; each agent's data and tool reach is scoped independently of its builder's own permissions; every prompt, retrieval, tool call and output is auditable; and agents are promoted to production through change control with a named owner. We do not build agents that make autonomous clinical decisions or write to the patient record. ## Five principles, each with a control behind it A principle that is not enforced by the platform is a preference. Each of these maps to something a customer can inspect. | Principle | The control that enforces it | | --- | --- | | A qualified human is accountable for care decisions | Review steps are configured centrally per agent category and cannot be removed from the build interface. | | An agent reaches only what its function requires | Per-agent data and tool scoping, set independently of the builder's own permissions. | | The model is a reviewable choice | Model selection is configuration with a recorded change history and a re-run of the evaluation set before promotion. | | Everything is reconstructable after the fact | Immutable logs of prompts, retrievals, tool calls, model calls and outputs, exportable per user and date range. | | Nothing reaches production unreviewed | Change control with separation of duties between building an agent and approving its release. | ## Where human judgement is required We draw this line publicly because health systems have been sold autonomy that did not exist, and because a vague line is unenforceable. - Clinical decisions. Diagnosis, treatment selection, dosing and changes to a care plan are human decisions. Agents may retrieve, summarise, draft and flag. - External submission. An agent may draft a payer appeal; a person submits it. - The patient record. Agents read under scoped access; they do not write to the EHR. - Closing exceptions. An agent may raise a flag; dismissing it is a human act with an identity attached. Where the boundary reasonably sits across workflow types: agentic AI for the healthcare sector. ## Model selection and review Because the platform is model-agnostic, which model answers is a governed decision rather than an architectural fact, and a governed decision has to be recorded. - Candidate assessment. A new model is assessed against the same evaluation set used for the agents that might adopt it. - Scoped introduction. It becomes available to selected agent categories, not to the whole estate at once. - Recorded change. Changing the model behind a production agent is a change-controlled action with an owner, a reason and a timestamp. - Rollback. The prior configuration remains available, so reverting is an action rather than a project. - Sensitivity routing. Workloads a health system designates as internal-only run on internal or self-hosted models, enforced by policy configuration. ## Agent permissions The most common governance failure we see in health systems is agents inheriting their builder's access. A senior analyst with broad entitlements builds an agent, and the agent quietly acquires the same reach for every user who invokes it. - Agent scope is defined centrally, by an engineering owner, and is not editable from the build interface. - Retrieval is filtered at query time by the entitlements of the person asking, not the person who built the agent. - Each tool's reach is fixed when the tool is created, so selecting it in an agent cannot widen it. - An agent cannot expand its own scope during a task, however it plans. - The whole estate (every agent, its owner, its data reach, its model) is visible in one view. ## What we will not build Stating this is commercially useful. It is also the fastest way for a prospective customer to work out whether we are describing a real system. - Agents that issue diagnoses or treatment recommendations without a qualified human in the loop. - Agents that write to the patient record. - Deployments where PHI leaves the compliance boundary to a provider not covered by a business associate agreement. - Configurations that let an agent builder widen the agent's data reach beyond what an engineering owner has scoped. - Claims of clinical outcome improvements we have not independently evidenced. > On our own claims: The adoption figures we publish (active users, queries processed, agents live) are platform-wide usage totals as of May 2026, measured from the June 2025 production launch. They evidence adoption, not clinical effect, and we describe them that way deliberately. ## Frequently asked questions **How does Inference Analytics govern AI?** Through controls built into the platform rather than policy alone: centrally configured human review steps that an agent builder cannot remove, per-agent data and tool scoping set independently of the builder's permissions, model selection as change-controlled configuration with recorded history and rollback, immutable audit logs across all agents, and separation of duties between building an agent and approving its release to production. **Do your AI agents make clinical decisions?** No. Agents retrieve, summarise, draft, check and flag. Diagnosis, treatment selection, dosing and changes to a care plan remain human decisions, and outputs that inform care are reviewed by a qualified person whose identity is recorded in the audit log. **Can an AI agent access more data than the person using it?** Not on our platform. Retrieval is filtered at query time by the entitlements of the person asking, and an agent's overall scope is set centrally by an engineering owner rather than inherited from whoever configured it. An agent also cannot widen its own scope during a task. **How do you decide which AI model to use?** A candidate model is assessed against the same evaluation set as the agents that might adopt it, introduced to selected agent categories rather than the whole estate, and adopted through a change-controlled action with a named owner and a recorded reason. The prior configuration stays available so rollback is an action rather than a project. **What will Inference Analytics not build?** Agents that diagnose or recommend treatment without a human in the loop; agents that write to the patient record; deployments where PHI reaches a provider not covered by a business associate agreement; configurations that let a builder widen an agent's data reach past what an engineering owner scoped; and claims of clinical outcome improvement we have not independently evidenced. --- ## The InferAgents Suite The flagship product of Inference Analytics, and its only top-level product. Three parts, one HIPAA-compliant core, deployed in the health system's own cloud. ### Dev Studio: Back end Domain: inferagents.ai For: Health-system IT, informatics and engineering teams The back end: build RAG agents visually, ship them through a full lifecycle, and govern tokens across every model. Includes: Visual development studio for RAG agents; API and token management across models; Software development lifecycle for agents: design, test, stage, ship; Quota optimisation and administration Page: https://www.inferenceanalytics.ai/dev-studio ### Inferch: Front end Domain: inferch.ai For: Clinical and operational staff across the health system The front end: enterprise chat across several models at once, with memory and a supervisor that verifies the answer. Includes: Analytics suite for Tableau and other analytics AI orchestration and visualisation; PPT generation, modification and enhancement agent; Memory management across sessions; Model fusion, with several models answering and one verified result Page: https://www.inferenceanalytics.ai/inferch ### PayerAgents: Revenue cycle Domain: payeragents.ai For: Revenue cycle and billing teams, and US private practices Denial and appeal automation, and CPT coding, against payer policy libraries tracked daily. Includes: Denial management and drafted appeals; CPT coding support; Payer policy libraries tracked daily Page: https://www.inferenceanalytics.ai/payeragents --- Source: https://www.inferenceanalytics.ai/company Published: 2026-01-07 | Last reviewed: 2026-09-23 # Building Healthcare AI from First Principles **Direct answer:** Inference Analytics is building the next generation of healthcare AI from first principles. Our suite of AI platforms and applications is already in use across major academic medical systems by more than 3,000 users, supporting physicians and researchers, infection control teams, revenue cycle operations, and other high-stakes healthcare workflows. Healthcare doesn't need another AI feature bolted onto legacy infrastructure. It needs AI designed from the ground up for sensitive data, complex workflows, high-stakes decisions, and strict compliance. Our mission is to put intelligent, agentic AI directly in the hands of clinicians, administrators, researchers, and healthcare leaders, helping them automate complex work, improve productivity, and make better-informed decisions. Across our technology suite, we combine model-agnostic AI infrastructure, agentic orchestration, healthcare-specific applications, and intelligent user experiences. Our architecture works across both the back-end systems healthcare runs on and the front-end applications clinicians and staff use every day. Rather than forcing every problem through a single model or approach, we match the right models, agents, and inference strategies to each workflow, optimizing for accuracy, performance, token efficiency, and cost. The result is practical enterprise AI built for environments where security, reliability, and trust matter. We were building healthcare generative AI before it became mainstream. Our work in AI-powered clinical text generation began in 2019, years before ChatGPT brought generative AI into the mainstream, and led to published IEEE research on generating clinical text from radiology reports. That foundation continues to shape our approach today: building AI around the realities of healthcare, rather than adapting healthcare to fit AI.