Local AI for regulated industries: HIPAA, GDPR, ITAR, CMMC, GLBA, NIS2

Regulated organizations face the same question with every new tool: where does the data go, and can we show it? A local inference system answers the first question by design. The model, the documents, and the analysis stay on hardware the organization controls, and the system can run with the network disabled.

The second question is answered with evidence. smolsi's compliance and assurance credentials include HIPAA, SOC 2, GDPR, ITAR, CMMC, GLBA, and NIS2. Supporting documentation and the applicable scope for a particular deployment are available during security review, under NDA. This guide explains how the two fit together and what to ask for.

The requirement behind each framework

The frameworks differ in detail, but each constrains data movement and demands accountability:

• HIPAA governs protected health information for hospital systems, clinical research organizations, and their vendors. Access control, audit logging, and minimum-necessary disclosure are central.
• SOC 2 is an assurance report on a service organization's controls. For a software vendor it is the common evidence that security, availability, and confidentiality controls exist and operate.
• GDPR governs personal data of people in the EU. Data residency and purpose limitation make a local deployment attractive, since personal data does not leave the controller's environment.
• ITAR restricts access to defense-related technical data to authorized persons, which in practice means data cannot flow to systems outside controlled jurisdiction.
• CMMC applies to the US defense industrial base and assesses how contractors protect controlled unclassified information.
• GLBA requires financial institutions to safeguard customer financial information.
• NIS2 sets cybersecurity and incident-reporting obligations for essential and important entities across the EU.

What a local deployment changes

A hosted AI service adds a processor outside your perimeter, and every framework above has something to say about that. A local deployment removes the question for the inference step:

• Residency. Documents are indexed and read where they already live. In an air-gapped deployment, source documents and analysis stay within the configured environment.
• Access. Deployment controls for access control and audit logging are configured around the organization's requirements rather than a provider's defaults.
• Isolation. The model, document index, and tools operate with the network disabled when required.
• Integrity. Production model directories carry byte-level manifests and release stamps, so a deployment can show which model was running.
• Ingestion safety. Documents are scanned for prompt injection on ingestion, with the verdict stored alongside the document.

What a security review should ask for

Credentials are a starting point. The review should establish scope:

1. Which controls apply to this deployment shape? A laptop for one analyst, a shared node for a team, and a private cluster have different boundaries.
2. What evidence exists, and for what period? Ask for the supporting documentation under NDA and check its scope against your environment.
3. How are models and updates admitted? Controlled transfer with verifiable manifests, or an open network path.
4. What is logged, and where do logs live? Audit logging is a deployment control; confirm its configuration meets your retention and access rules.
5. Who supports the system? One team evaluates the workflow, configures the system, and supports the deployment.

Do not accept a blanket "compliant" claim from any vendor, including us. Compliance requirements depend on the deployment, and the right answer is scoped evidence.

Where to start

Bring one workflow that touches regulated data. An engineer replies within one business day and scopes an evaluation around it, including the controls and documentation your review needs. Request an evaluation or schedule the call.