Personally Identifiable Information (PII) is any data that can identify a specific individual, including a name, government ID number, financial account number, or geolocation. Protected Health Information (PHI) is a defined subset regulated under HIPAA: individually identifiable health information, whether held on paper or in electronic form. The distinction matters in an AI deployment because the controls a system needs depend on which data class it touches, and the two classes often travel together in real workflows.
The practical rule for both is the same: a model or an AI agent that reads PII or PHI must do so inside a boundary the organization controls, under access rules that limit who can trigger that read, and with a record of what was accessed and by whom. The risk is not that a model is inaccurate; it is that a sensitive data class reaches a place, or a provider, where the organization has no control and no audit trail.
PII is defined broadly and appears in nearly every business process. A credit union's loan application, an insurer's claims file, and a bank's customer profile all carry PII, and the exposure from leaking it is a data-breach notification obligation plus regulatory scrutiny. PHI carries an additional layer: it is individually identifiable health data, and HIPAA attaches specific obligations, including business associate agreements for any vendor that handles it and the minimum necessary standard for access.
In an AI environment the handling difference shows up in the access policy. A role that summarizes a financial document may legitimately reference PII. A role that touches PHI needs a tighter scope, a documented business purpose, and a business associate agreement covering the AI vendor. The system must know which class it is processing so it can apply the right rule.
The failure mode is data egress. A staff member pastes a patient note or a customer account statement into a public model, and that PII or PHI leaves the environment under a third party's terms, with no boundary and no audit trail the organization can point to. The fix is to route all AI traffic through a controlled layer that identifies the data class, enforces the access rule, and blocks egress outside the permitted boundary. When the model runs on the customer's infrastructure and the gateway enforces the boundary, the sensitive data never leaves the environment at all.
Shakudo's AI Gateway enforces the boundary around PII and PHI at the point where AI requests would leave the environment. Role-based access controls define which users can reference which data class, and Data Loss Prevention rules block or redact sensitive fields before a request reaches a model. Every access is logged with the user, the role, and the data class, so the audit trail a HIPAA or NCUA review expects is produced as part of normal operation. Because the gateway and the models run inside the customer's infrastructure, the regulated data stays inside the boundary the framework requires.
PII is any data that identifies a person and appears in most business systems. PHI is PII combined with health information, and it is regulated specifically under HIPAA. All PHI is PII, but not all PII is PHI. The controls for PHI are stricter because HIPAA adds business associate agreements and the minimum necessary access standard on top of general data-protection duties.
Sending PII to a public model under a third party's terms is the kind of data exposure that triggers breach-notification analysis, because the data left the organization's control. A governed deployment avoids this by keeping the model and the data inside the customer's boundary, so the egress that would trigger the breach does not occur. The distinction is between PII leaving the environment and PII being processed inside it under control.
HIPAA's minimum necessary standard requires access to PHI to be limited to what the task actually needs. For an AI workflow, that means a role that only needs to summarize a claim should not have access to the full patient record. Role-based access control enforces the limit: each role references the data class and fields its task requires, and the gateway enforces the restriction on every request.
