Every conversation about AI in eligibility operations eventually reaches the question that decides the procurement: where does the data go? The capabilities described across our guide to social services eligibility verification, document extraction, cross-system reconciliation, grounded case querying, all involve processing the most sensitive records a state holds. For many AI products on the market, the honest answer to "where does the data go" disqualifies them before the demo ends.
This article maps the three legal regimes that constrain AI architecture in health and human services, explains why external-API architectures usually fail review, and lays out the deployment models that pass, including when on-premises AI for government agencies is the only viable answer. It is written for the CIOs and security officers who have to sign the risk acceptance, and it assumes the question is not whether to use AI but how to use it inside the rules.
What an Eligibility Case File Actually Contains
Security architecture follows data classification, so start with what is in the file. An eligibility case aggregates Social Security numbers for every household member, income records and pay stubs, bank information, immigration documents, and, for Medicaid cases, health information. Through data matches, it also incorporates two categories with their own federal regimes: federal tax information returned from IRS data exchanges, and data received under Social Security Administration exchange agreements.
That aggregation is the point often missed in vendor conversations. A tool touching eligibility case files is not handling generic government records with names attached. It is handling one of the densest concentrations of regulated data categories in state government, and three distinct compliance frameworks attach to different layers of the same file.
The Three Regimes That Shape Architecture
HIPAA governs the health information in Medicaid cases. For AI processing, the practical requirements are familiar to any healthcare CIO: business associate agreements with any vendor whose systems touch protected health information, access controls and audit logging under the Security Rule, and minimum-necessary discipline in what any component can see.
IRS Publication 1075 governs federal tax information, and it is the regime that most often surprises AI vendors. FTI received through income verification matches carries safeguarding requirements that follow the data wherever it flows: restrictions on where it may be stored and processed, background investigation requirements for personnel with access, detailed audit and inspection obligations, and reporting duties. A cloud service that cannot demonstrate FTI-compliant handling cannot process case data containing FTI, whatever its other certifications. Some government cloud environments are built to support Publication 1075 workloads; general-purpose consumer AI endpoints are not.
SSA data-exchange agreements govern the identity and benefit data returned from Social Security matches. Each state's agreement carries use limitations, safeguarding duties, and the standing possibility of SSA security reviews. Disclosing exchanged data to a third-party service outside the agreement's terms is not a technicality; it jeopardizes the exchange the agency's automated verification depends on.
The federal payment-integrity analysis adds an operational reason to take documentation seriously: most Medicaid improper-payment dollars trace to missing or insufficient documentation of eligibility verification. A compliant AI layer, properly logged, strengthens exactly the documentation trail federal reviewers keep finding inadequate.
Why "Send It to an API" Usually Fails Review
The default architecture of consumer AI is an external endpoint: data leaves the requester's environment, is processed on shared infrastructure, and returns. Applied to eligibility data, this architecture accumulates disqualifying questions fast. Where, physically and jurisdictionally, was the FTI processed? Who at the provider can access prompts and stored inputs, and have they met Publication 1075 personnel requirements? Is the provider contractually a HIPAA business associate, and does the SSA agreement permit the disclosure at all? Is applicant data retained, and is it used to train models? Can the agency produce audit logs meeting each regime's standards?
Security reviews do not need to answer all of these to say no; any one suffices. And there is a second, subtler failure mode: shadow deployment. Where no sanctioned tool exists, staff facing crushing document workloads will eventually paste case content into whatever public assistant is at hand. The strongest argument for standing up a compliant AI capability quickly is that the realistic alternative is not the status quo. It is unsanctioned use of non-compliant tools, invisible to the CIO until it is an incident.
Deployment Models That Pass
Three architectures satisfy the regimes, in ascending order of control.
Government cloud deployment places the AI layer in cloud regions purpose-built for regulated public-sector workloads, including environments that support IRS 1075 requirements for FTI. The agency gets cloud economics and managed infrastructure while data remains inside a boundary designed for exactly this data. For most state HHS agencies this is the pragmatic default.
Private cloud or dedicated tenancy narrows the boundary further: the AI platform runs in the agency's own virtual environment, under the agency's identity, network, and key management. This suits states with established cloud landing zones and strict data-residency positions.
Fully on-premises deployment, with self-hosted language and vision models, keeps every byte inside agency-controlled facilities. No external inference calls, no data leaving the network. This is the architecture of last resort in cost terms and of first resort in control terms, appropriate where the state's posture or specific data categories demand it. It has become genuinely practical: modern document-extraction and retrieval systems, including VIDIZMO's AI Intelligence Hub, run with self-hosted models precisely so that agencies with air-gapped or on-premises requirements are not excluded from the capability. Deployment flexibility across all three models is worth treating as a hard requirement in procurement, because it preserves the agency's options as data classifications and postures evolve; the buyer's checklist makes it one.
Controls Beyond Location
Where the AI runs is necessary and insufficient. Five controls complete the picture, and each should be demonstrable in a review, not asserted in a slide.
Access Control That Mirrors the Case System
The AI layer must enforce the same authorizations as the systems it reads from, so a worker can never learn through a query what they could not open directly. In practice this means the layer consumes the agency's identity and role model rather than maintaining its own, and demonstrating it means logging in as a restricted role and watching the restriction hold.
Audit Logging of Every Interaction
Every query, extraction, flag, and answer should generate a log record: who asked, what was retrieved, what was returned. Retention of those logs follows the strictest applicable regime, since an FTI-bearing interaction inherits FTI audit obligations. The test is concrete: ask the vendor to produce the complete audit trail for a specific case interaction from a pilot, on request, without engineering effort.
Grounding With Citations
Every AI output must trace to the specific records and document fields behind it. Grounding serves accuracy, but in a government context it equally serves compliance: a cited answer is reviewable by a supervisor, an auditor, or a hearing officer, while an uncited one is unusable the moment anyone challenges it. The mechanics of citation-backed answers are described in natural-language case search.
No Training on Applicant Data
Applicant data must never improve anyone's model, and the commitment belongs in the contract, stated without qualification. Ambiguity here, such as carve-outs for "service improvement," is a red flag worth treating as disqualifying, because a training pipeline is a disclosure pathway no data-exchange agreement contemplates.
Retention Aligned to Case Records
Extracted data, embeddings, and query logs should follow the agency's case-record retention schedules, not a vendor's platform defaults. When a case record reaches disposition, everything the AI layer derived from it goes with it, and the vendor should be able to demonstrate the deletion, not merely promise it.
One more consideration belongs on the CIO's list: the funding path. Security architecture influences cost, and eligibility technology draws enhanced federal match only through an approved Advance Planning Document, which expects the security posture to be described. Building the compliance story and the funding story together, as covered in Is It APD-Fundable?, avoids discovering late that an architecture choice complicated the match.
The Bottom Line
AI in eligibility operations is constrained less by what models can do than by where data may lawfully go, and the three regimes governing case files reward one architectural instinct: keep the processing inside the boundary. Government cloud, private cloud, and on-premises deployment each accomplish that at different points on the control-cost curve, and the surrounding controls, access parity, audit trails, grounding, no-training terms, turn a permissible architecture into a defensible one. The capabilities all of this protects are laid out in the guide to social services eligibility verification.
