One governed path to every AI model.

Miso lets a health system decide which teams and vendors may use which models, for which purposes and data, and enforces those decisions on every request. Runs in your cloud. OpenAI-compatible. Every decision is logged.

Talk to usHow it works

Every new AI project should not need the same review from scratch.

A clinical team prototypes against OpenAI. A vendor arrives using Anthropic. Another department wants Bedrock. Privacy, Security, and Legal answer versions of the same questions each time, and the projects wait.

Miso turns those answers into routes: who may call which model, with what data, under which agreement. A route is approved once and enforced on every request after that.

One request, going through.

The developer makes a normal model call. Miso checks the caller, the purpose, the data, the model, and the agreement, then either sends the request or refuses it. Either way it keeps the evidence.

Synthetic examples. Model names illustrative.

Inbox Assistant (pilot)→Miso
Caller
unregistered key
Requested model
GPT-5, OpenAI direct
Agreement
none on file
Result
ROUTE DENIED · logged b7c2…04 · no data sent

For the teams that build

An approved path, in place of another review.

Once a route is approved, the team gets an endpoint and a key. They write ordinary model calls. Reading the BAA, deciding what PHI may be sent, and keeping the provider-specific controls current are Miso's job, done once per route.

For Privacy and Security

See what was approved, and what actually happened.

Every route ties a caller, a purpose, a data class, a provider, a model, an agreement, and a set of obligations to the traffic that used it. The record shows each request against the approval that covered it.

Fewer reasons to say no.

Today each new AI application brings its own questions about models, PHI, agreements, and data handling, and each application has to be trusted to implement the answers correctly. Miso moves those controls into one shared path, so an approval is reused rather than reconstructed, and Privacy can approve more because it no longer depends on every application getting the rules right.

Your AI vendors should not each bring their own AI stack.

Give an approved vendor a Miso endpoint. Their application uses the models and providers your health system has already approved, under your agreements and your controls. They never hold your provider credentials. You never take on another opaque AI dependency.

Make the vendor inherit your AI controls

vendor.ambient-scribe · encounter-note-draft · purpose: treatmentreceived

Patient Maria Alvarezname removed, DOB 03/14/1961age 65, MRN 44810-2mrn removed, presents with worsening dyspnea on exertion over two weeks. Reports orthopnea; denies chest pain. Started on 05/02/2026~4 months ago on furosemide 40 mg.

Modelazure openai · gpt @2026-07-10 · eastus2pinned for this vendor · BAA in force · zero retention
Vendor oweshuman review before usedisclose AI to patient
Recordhash 91d4…c2 ← prev 7c1e…a94 identifiers handled · values not stored · 412 ms · $0.0031
receivedidentifiers filteredrouted to pinned modelobligations returnedrecorded

Synthetic example.

An AI inventory built from actual use, not another questionnaire.

For the applications and vendors routed through Miso, the inventory updates itself from traffic: who is using which models, for what purpose, under which approvals. The privacy officer sees what needs a decision. A builder sees their own applications, spend, and denials.

Every view in the console

your cloud account
model providers ↗
the only thing outside
miso · policy · filter
postgres · records

Miso runs in your cloud account.

  • The gateway runs in your VPC
  • The policy and the audit records are in your Postgres
  • Provider credentials stay in your environment
  • Model traffic leaves only through routes your organization approved

One container and Postgres