Sovereign AI Compliance Architecture: CJIS, FedRAMP, and Air-Gapped

Designing an AI system to a named authorization is a different exercise from designing it securely. Security engineering asks what the sensible control is. Authorization work asks which catalogue applies, how you will evidence that each control operates, and where the line is drawn around the thing being authorized. Teams that treat those as one job build defensible systems that fail on documentation and boundary questions.

This article assumes the workload already belongs in infrastructure you control. If that is still open, running AI inside infrastructure you control works through the ladder from region pinning to full isolation.

Three requirements dominate US public sector AI procurement, and CJIS, FedRAMP and air-gap appear in the same RFP paragraph often enough that buyers read them as variations on one theme. One is a security policy, one is an authorization programme for cloud services, and the third is not a compliance regime at all. Which of them binds your system shapes everything downstream.

What each regime is and who it binds

The CJIS Security Policy binds the agency

The CJIS Security Policy, currently version 6.1 dated 06/25/2026, is issued by the FBI's Criminal Justice Information Services Division and sets minimum security requirements for any entity that accesses, stores, processes or transmits criminal justice information. The obligation belongs to the agency, and compliance is demonstrated through audit, usually involving the state's CJIS Systems Agency.

Controls reach a service provider by contract, through the CJIS Security Addendum, which the policy describes as "a uniform addendum to an agreement between the government agency and a private contractor, approved by the Director of the FBI, acting for the U.S. Attorney General". Suppliers are not certified. They are pulled inside the agency's own audit, because the policy requires that private contractors performing criminal justice functions "shall be subject to the same extent of audit review as are local user agencies". No body certifies vendors against the policy, so a claimed CJIS certification is marketing rather than fact. What a vendor can honestly offer is alignment with the policy and a signature on the addendum, which means CJIS requirements arrive as contract terms and operating constraints rather than as a product feature. What CJIS actually requires when AI touches criminal justice data covers the control areas that bite hardest on an AI pipeline.

What FedRAMP attaches to

FedRAMP is a programme under which cloud services used by US federal agencies are assessed and authorized. The authorization attaches to a service running in a defined environment, under a named operator, with a documented boundary, rather than to a software product in the abstract.

That distinction is the one most often lost in procurement, because the product name stays the same while the thing being authorized does not. The same application, deployed on different infrastructure and operated by different people, is a different service for authorization purposes. A vendor whose software runs inside somebody else's authorized environment sits in a different position from one whose own service carries an authorization, and both differ from a vendor that has aligned its engineering with the control catalogue without being assessed. Each of those positions is legitimate, and only some of them leave an agency with an authorization it can inherit.

Impact level matters as much as the programme name, since baselines scale with the categorization of the information handled. FedRAMP's Low, Moderate and High baselines are drawn from NIST SP 800-53 Rev. 5 and its companion SP 800-53B, so the control language an assessor uses is NIST's rather than the programme's.

Department of Defense work adds a second scale on top of those baselines, measured in impact levels that describe how sensitive the information is. The DoD Cloud Service Provider SRG defines Impact Level 5 as covering "nonpublic, unclassified NSS/NSI", meaning national security systems and national security information rather than simply higher-sensitivity controlled unclassified information, and sets the floor by reference: "per CNSSP 32, the minimum requirement for all unclassified NSS is equivalent to the FedRAMP High baseline with the additional overlays and NSS controls in CNSSI 1253 Appendix D." Impact Level 6 covers classified information up to SECRET, is reachable only "via one or more private SIPRNet connections or approved CNSSP-11 circuits", and requires infrastructure dedicated to the effect that such an offering "is not considered 'commercially available'". Conflating IL5 with classified work is the most common error in this area, and it changes both the control set and the procurement route. Establish which baseline applies before sizing anything.

Air-gap is an architecture, not a certification

An air-gapped environment has no network path to anything outside it. That is a design property, and it usually exists because the network's own accreditation forbids external connectivity rather than because a standard called for it. Procurement documents list it beside certifications all the same, in the same column, with the same yes or no box.

An honest answer to that box has a shape rather than a value, covering which functions still work, which change form, and which stop. Air-gapped AI and what still works with no internet at all goes through that inventory. Most enterprise software carries at least one quiet dependency on reaching its vendor, and licence validation is the classic one.

The authorization boundary is the concept that does the work

An authorization boundary is the set of components, people and processes the authorization covers. Everything that stores, processes or transmits the protected data sits inside it. Everything else is either an external interconnection with its own agreement, or a leased service whose authorization you inherit and document.

Draw it before the component diagram, because it decides what has to be assessed, what has to be evidenced and what you are on the hook to operate. Inside it sit compute and storage, the application and its data stores, the management plane, the logging pipeline, backup copies, the build and deployment path, and the identity system if you run one. Backups and build systems are the two people leave out, and both either hold protected data or can inject code that touches it.

Inheritance is the other half of the boundary, and it settles which controls you have to implement yourself. Deploy onto an authorized platform and you take some controls from it, typically the physical and environmental ones, while owning the rest. What goes wrong is rarely the inheritance itself but the absence of a written split saying which party does what. An assessor asks, for each control, who implements it, and "the platform handles that" is not an answer unless the platform's documentation says so and your architecture uses the feature.

What an external call does to the boundary

The boundary follows the data rather than the equipment, which is the sentence worth carrying out of this section. A single outbound API call to a hosted model takes protected content across the line, because the prompt carries that content inside it. Running retrieval locally does not change that, since passages assembled into a prompt and sent to a hosted endpoint have left the boundary as completely as if somebody had emailed them out. The diagram can look sovereign at the storage layer while the data flow says otherwise, and assessors read the data flow.

Once that call exists there are only four ways the design can be settled, and three of them leave you with a system you can defend. The hosted service can be brought in as an inherited authorization, which requires it to be authorized at the level your system needs and covered by the appropriate agreement. The data can be prevented from reaching it, which means self-hosting the model. The call can be restricted to non-protected content, which is hard to enforce once users can type into a box. Otherwise the boundary has been breached and the design does not hold.

The same test applies to routes that are easier to overlook, because anything carrying content out counts whether or not it looks like an AI feature. Embedding generation against a hosted endpoint sends the source text, and crash reporting can carry fragments of whatever was in memory. Model updates run inward rather than outward, which makes them a supply chain question rather than a confidentiality one, and they still belong on the diagram. Geography is a separate axis again, since a boundary drawn around infrastructure in your own country leaves open which legal systems can compel its operator. Data residency and jurisdiction for AI separates the two.

Turning control families into architecture decisions

The catalogues differ in detail, but the families that force architecture are broadly the same, and it helps to work from the actual identifiers because that is the vocabulary an assessor writes findings in. NIST SP 800-53 Rev. 5 organizes its catalogue into 20 families, and the CJIS Security Policy uses the same identifiers, which is why a control mapping between the two is possible at all. The five below are where AI systems most often need an architecture decision rather than a policy statement.

Identity and access control

This family forces the identity provider integration and the authorization model, which means federating to the agency's identity provider rather than keeping local accounts, meeting whatever multi-factor bar the regime sets, and automating deprovisioning so a departure is not a ticket somebody forgets.

The AI-specific part is retrieval. A system that indexes everything and answers using a service account has built a permissions bypass with a chat interface on the front. The fix belongs at ingestion, because the access metadata you need at query time is only available when the document is read. Two designs work. Filter results at query time against the calling user's entitlements, carrying the source system's access rules into the index and keeping them synchronized. Or partition indexes by access boundary, so a user only queries a corpus they are cleared for. Partitioning is easier to evidence and duplicates content, while query-time filtering is more efficient and rests on your synchronization being correct. Agents and scheduled workflows need their own least-privileged identities, so their actions stay attributable.

Audit and accountability

This family forces the logging architecture, its protection and its retention. AU-12 requires the system to "provide audit record generation capability for the event types the system is capable of auditing", and AU-10 goes further, requiring "irrefutable evidence that an individual (or process acting on behalf of an individual) has performed" a defined action. That parenthesis is the whole AI problem in eight words, because in an agent workflow the process acting on behalf of an individual is where most of the actions happen. You have to define what counts as an auditable event, where records go, how they resist modification, how long they persist, and who reviews them. Under CJIS the retention floor is AU-11's "minimum of one (1) year", extended wherever legal or investigative need applies.

For an AI system the list of events you have to record is longer than people expect, because one user action reaches many records at once. A retrieval is an access event against every document it returned rather than a single event for the query. An inference is a processing event on that content, and embedding generation is a copy operation on the source. If the log records that a user asked a question but not which documents were surfaced, you cannot answer the question an auditor asks, and in a criminal justice context you cannot answer the one defence counsel asks either. Retention pushes toward append-only or write-once storage, since a log that could have been edited proves less than one that could not, and clock synchronization matters because ordering is most of what a log is for once an incident is reconstructed.

System and communications protection

This family forces the encryption and segmentation design, because it governs what may cross each interface and in what form. SC-7 requires you to "monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces", and AC-4 requires enforcement of "approved authorizations for controlling the flow of information within the system and between connected systems", which is the control an assessor will point at when they find an inference node calling out. Validated cryptography in transit and at rest is the visible part, and under CJIS that means FIPS 140-3 modules with a symmetric key of at least 256-bit strength, with FIPS 140-2 certificates unacceptable after 21 September 2026. Key custody decides what the encryption is worth and is a separate decision from algorithm strength.

The AI-specific part is that GPU inference nodes belong in the data tier even though they are bought as compute. They hold decrypted content in memory and routinely write it to local scratch as model caches, extracted frames and temporary audio files. They are also, in most estates, the least hardened machines on the network, because they were specified by whoever needed the GPUs rather than by whoever owns the data. Segment them as you would a database tier, control what they persist, and bring their scratch volumes under the same encryption and sanitization rules as primary storage. Traffic between the application, the retrieval layer and the inference service needs authentication and encryption too.

Personnel security

This family forces decisions about who operates the system and where those people sit, and it reshapes vendor relationships more often than any other. Under CJIS, PS-3 requires state-of-residency and national fingerprint-based record checks, denies access outright where "a felony conviction of any kind exists", and obliges the agency to maintain a list of everyone authorized unescorted access to unencrypted CJI. That requirement reaches vendor engineers who can reach production, and the support model becomes an architecture question rather than a commercial one.

There is a documented way out of that screening burden, and it turns entirely on who holds the encryption keys. The policy's own infrastructure-as-a-service example concludes that where the agency "maintains sole access to the encryption keys" and provider personnel therefore have no ability "to view, modify, or make use of unencrypted CJI", no fingerprint-based background checks are required for that provider's staff. Key custody is therefore the lever that moves an entire population of vendor personnel out of scope.

A support model that requires a vendor engineer to log into production puts that engineer, and the vendor's screening process, inside your scope. A model where your own staff operate the system and vendor involvement arrives as artefacts passing through your review keeps the scope small. If the regime is strict, design for the second from the start, because retrofitting it means renegotiating support rather than reconfiguring software.

Configuration management

This family forces the update path, which is the control most often discovered late because nothing in a demonstration depends on it. CM-3 requires you to "determine and document the types of changes to the system that are configuration-controlled" and to review each proposed change "with explicit consideration for security and privacy impact analyses", while SI-2 requires installing security-relevant updates within an organization-defined period. In a connected environment that route is a pipeline. In a disconnected one it is a physical media process with scanning, hash verification, documented approval and a rollback position, and the period you defined under SI-2 is the number you will be measured against.

Models belong in this family, and that is where most AI deployments have a hole. Swapping model weights changes system behaviour more than a typical code change does, so it warrants the same change control. Two further controls apply and are almost never cited in AI system security plans. SR-4 requires you to "document, monitor, and maintain valid provenance" of system components and associated data, which covers where a set of weights came from. SI-7 requires integrity verification tools "to detect unauthorized changes" to software, firmware and information, which is the control that makes checksum verification of a model artefact a requirement rather than a good habit.

Where AI creates gaps the control catalogues did not anticipate

Four gaps come up repeatedly, and none is hard to close if you find it before the assessor does.

A set of model weights is a configuration item and a piece of third-party software at the same time, so it needs the controls that apply to both. A model pulled from a public hub arrived through a supply chain you did not audit, in a serialization format that has historically been able to carry executable code. Pin versions, verify checksums, host an internal registry rather than fetching at runtime, and record provenance and hash in the inventory.

The vector index holds derived copies of controlled data, so it carries the classification of its sources, with the encryption, access control, backup coverage and disposal planning that implies. Deletion is where this breaks. Removing a document from the source system does not remove its vectors unless the pipeline explicitly does so, which turns a routine records disposition or a privacy erasure request into an unhandled case.

Prompt and completion logs are a controlled data store, because their contents include quoted passages from the source material and inherit its classification, retention rules and access restrictions. Routing them to an external observability platform moves controlled data outside the boundary in the most easily overlooked way available.

Output that changes between runs complicates test evidence, because an assessor expects a test to give the same result twice and the same prompt can produce different text on consecutive runs. Test the controls rather than the prose. Whether an unauthorized user can retrieve a restricted document is deterministic, as are whether the access log fires, whether a human review gate blocks progression, and whether citations resolve to real sources. Keep a fixed evaluation set for output quality, and record which model version produced the run.

What an assessor expects to see

Documentation quality decides more assessments than control quality does. Five artefacts carry most of the weight.

Architecture and data flow diagrams that show every egress, drawn around the data rather than the org chart. Every route out belongs on them, including telemetry, licence validation, model and container updates, name resolution and time synchronization. A diagram with no arrows crossing the boundary invites the question of how the system gets patched.

A component inventory that includes the AI pieces, meaning models and their versions, embedding models, the vector store, GPU nodes, message brokers, and any runtime that executes generated code. An inventory that stops at the application tier will be treated as incomplete.

Evidence that the controls operate rather than evidence that they exist on paper. A policy stating that access is reviewed quarterly is design evidence, while the last four review records, with names, dates and the accounts removed, is operating evidence. Build the system so that producing log extracts, change tickets and test records is a query rather than a project.

A written account of how updates enter the boundary, naming who approves an artefact, what is scanned, and what happens when a change is reversed. In a disconnected environment this doubles as the model update process.

A control responsibility matrix stating, for every control, whether the customer, the hosting platform or the software vendor implements it. Where a system inherits controls from an authorized platform, that document is what makes the inheritance real rather than assumed.

How the three regimes differ in what they demand

Read across the rows rather than down the columns, because the rows are where the regimes diverge. An architecture meeting a strict reading of the CJIS Security Policy is not thereby positioned for federal authorization, which additionally requires an assessed boundary and an evidence package. Deploying into an authorized cloud environment does nothing about the personnel screening a criminal justice agency will require of anyone who can reach its data.

Where VIDIZMO fits

This is a VIDIZMO publication, so here is where the platform stands against the regimes above.

VIDIZMO's processes and software are aligned with NIST SP 800-53, and the platform is deployable on FedRAMP High-authorized infrastructure, either Project Hosts' FedRAMP-authorized environment, which covers both infrastructure and application-level authorization and does not require agency sponsorship, or Microsoft Azure Government with agency sponsorship. VIDIZMO does not hold its own FedRAMP authorization. Azure Government holds FedRAMP High authorization and supports NIST SP 800-53, FIPS 140-3, CJIS, IL4/IL5 and IRS 1075. IL4 and IL5 workloads are supported via Azure Government.

VIDIZMO is CJIS Security Policy-aligned, and consistent with how the policy allocates responsibility, the agency holds the CJIS compliance obligation and VIDIZMO's controls support it.

VIDIZMO is ISO/IEC 27001:2022 certified under certificate RA-2507091, and that is the only third-party certification VIDIZMO holds. SOC 2 Type II belongs to the Azure infrastructure and is not a VIDIZMO audit. Encryption uses FIPS 140-3 validated cryptographic modules on supported infrastructure, feature-aligned to FIPS 200, with no FIPS certification.

Against the audit family described earlier, audit logs sit in append-only tamper-evident Azure SQL ledger tables archived under locked time-based WORM retention, and can be streamed to customer systems by webhook. In air-gapped deployments all AI processing runs locally on self-hosted models, and the workflow designer behaves identically with no dependency on external APIs.

The decisions that are expensive to change later

Some of the above can be added in the month before an assessment. Most cannot.

The boundary comes first, because every other decision rests on it, and redrawing it after an assessment means reassessing whatever moved. Draw it around the data rather than around the systems you happen to own.

The identity model comes second, specifically the decision to capture source access rules at ingestion. Retrofitting permission-aware retrieval onto an index built without it is a rebuild rather than a change, because the metadata that would make it possible was discarded when the content was read.

The logging schema comes third, since logs you did not write cannot be reconstructed and the events you decide are not worth capturing are reliably the ones an incident will need.

After those, the update path, because a disconnected environment designed on an assumption of connectivity is hard to repair once running, and the deletion path through the vector index. Model selection ought to be cheap to revisit, and it is cheap precisely when the architecture treats the model as a configuration item rather than a foundation.