Generative AI that runs inside your own network

The compliance question is a network question

Every mainstream AI design tool is a public website. To use one, your team uploads the asset to a third party's infrastructure. That might be a patient photograph, an unreleased product render, a technical drawing. There it is processed by models you do not control, retained under a policy you did not write, and handled by subprocessors you did not select.

For most companies that is a procurement conversation. For a hospital marketing team, a broker-dealer, an agency on a federal contract or a defense supplier, it is a control failure, and no amount of vendor assurance changes where the bytes went.

Meraqi is built to run on either side of that boundary. Deployed to your intranet, the models, the rendering pipeline, your designs and everything they produce all sit inside your own perimeter. There is no upload step, no third-party model API call, and no telemetry carrying content out.

How deployment maps to obligations

This describes what the architecture provides. It is not a claim of certification. See what we don't claim below.

Healthcare and life sciences

Hospital and health-system marketing teams, and pharmaceutical and device companies, make patient stories, campaigns and promotional pieces from material that can carry protected health information or unreleased product data.

Financial services

Banks, credit unions and broker-dealers make campaigns, product announcements and client communications, and the brief often travels with customer information or figures that are not public yet.

Government and defense

Agencies, defense suppliers and federal contractors make briefings, recruiting material and public-affairs creative, sometimes from controlled technical data.

Every sector

Two questions come up wherever the work is regulated, where the data sits and whether it trains anyone's model.

Two places it can run

There is no third option and no confusing middle tier. Either the content travels to us or it does not, and that single fact is what your assessor actually cares about.

We do not currently run private instances for individual customers. We are still a small company, and running, monitoring and sustaining a private instance for each customer is a commitment we will not make until we can keep it. If you need your own instance, it runs on your network.

Air-gapped deployments arrive on a drive

Most software expects to reach the internet at some point while it installs, for a package, a container image or a model download. Inside an enclave each of those becomes a firewall exception to request or a file to carry across by hand, and finding them all is where the time goes. An air-gapped Meraqi makes none of those requests. It ships on physical media carrying the platform, the model weights and everything needed to stand it up inside the enclave. Nothing is pulled from a public container registry or a model hub, nothing phones home afterwards, and no step quietly assumes a connection.

Inspected before it comes inside

Physical delivery also lets your security team check exactly what is entering the perimeter before any of it runs. The media can go through your own intake process first, whether that means hashing it, scanning it for malware or examining it on an isolated machine. Because nothing can be fetched from outside afterwards, what you inspected is exactly what runs, and it stays that way until you install the next release. Every release is signed and carries a software bill of materials (coming soon).

Air-gapped delivery is built to order as part of an enterprise engagement rather than a download you configure yourself, because every enclave has its own rules about media, and pretending otherwise would waste your time and ours. Verification, government furnished media, and re-imaging before the boundary are all things we agree with you up front.

Updates arrive the same way, on your schedule, and they update the software, not your data.

Everything that happens in Meraqi stays in Meraqi

Containment is only half the requirement. The other half is being able to prove it. An auditor does not accept an architecture diagram as evidence, and neither does an incident review at two in the morning.

Every action taken in the system is written to an append-only audit record that lives on your deployment alongside everything else, so your audit trail is not sitting in a vendor's database behind a support ticket.

Every user has their own design library, and nothing is overwritten

Each user works in a library of their own, holding every design they have made and everything it produced, images and video alike, with every version of each. Users do not see one another's work unless it has been deliberately shared. That is how minimum necessary access under HIPAA, need to know handling for controlled information, and information barriers between deal teams get enforced rather than merely intended.

Versions accumulate instead of replacing one another. The design that was live last March is still there exactly as it was, which is the difference between answering a complaint and reconstructing an answer to one. Offboarding a user, placing a legal hold and satisfying an erasure request all operate against that boundary rather than as a search across shared storage you then have to prove was exhaustive.

Lineage runs in both directions

Events on their own tell you what happened. Lineage tells you what it touched. Every design records the assets it was built from and the outputs it went on to produce, so the chain running from source material through generation to export is one connected record rather than a scatter of unrelated log lines.

That makes the expensive question cheap. If a source file turns out to have carried protected health information, or a licensed image is withdrawn, or legal pulls a campaign after it has shipped, you can ask what else is downstream of this one file and get a complete answer. Ask a public design website the same question and there is no answer available at any price, because it never recorded which upload fed which output.

The record is yours

Audit records and lineage live on your deployment, queryable there, under your retention. Nothing is sampled, summarized or held back behind a higher pricing tier, which is the usual way audit data becomes an upsell.

Built on open models, not an API wrapper

Meraqi runs open-weight models on its own inference stack. That matters for three reasons beyond privacy.

• No dependency on a third-party API. Your creative pipeline cannot be broken by someone else's rate limit, deprecation notice or price change.
• Auditability. You can name the model, the version and the license under which it is used, which is the first question any serious procurement review asks.
• Output is editable, not final. Meraqi produces multi-layer images you can open and change, not flat images you have to regenerate. In a regulated setting that matters more than elsewhere, because legal review marks up copy and you need to change that line without re-rolling the whole design.

Questions we get asked

HIPAA and healthcare marketing, what Meraqi is and is not certified for, air-gapped generation, how the software reaches an enclave with no network and whether your security team can inspect it first, proving that content never left, what ITAR and CMMC mean for a defense contractor, whether FedRAMP applies inside a government environment, and marketing review at banks, broker-dealers and pharmaceutical companies. Those answers sit with the rest of them on the FAQ page, along with the audit trail, per-user isolation and lineage, which work the same way wherever Meraqi runs.