> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beyondguard.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Protection: PII, PHI, and CII Operations

> Detect and mask personal, health, and critical-infrastructure data on both input and output — with custom PII types and a Python custom-code editor.

BeyondGuard's data-protection modules detect and mask sensitive information in both user inputs and model outputs, enforcing regulatory compliance (GDPR/KVKK, HIPAA) across every AI interaction. Each operates **bidirectionally** — on the way in and the way out.

## PII Operations

The **PII Operations** module detects, masks, and — when necessary — blocks personally identifiable information in inputs and outputs. You choose which PII types are actively monitored and define a separate processing policy for each.

* **Input** — a user's submission of personal data can be blocked or anonymized.
* **Output** — the model is prevented from returning PII, or the data is anonymized.

Detected types include name, address, phone number, national ID (TCKN), card numbers, IBAN, and email.

### Custom PII

Beyond the default types, you can define **Custom PII** elements for your own requirements — internal data formats, sensitive numbers, or unique data types that organizational policy requires you to protect — and have them monitored automatically.

### Custom code editor

For advanced cases, PII Operations includes a built-in **Custom Code Editor**. You can add Python-based custom validation, masking, or detection logic tailored to your business rules, test it instantly, and — once enabled for a PII type — have the system run it automatically.

## PHI Operations

**PHI Operations** detects protected health information and controls it under the relevant regulations. It ensures the system never discloses Personal Health Information — names, diagnoses, treatment dates, prescriptions, identification numbers, or clinical data.

* **Input** — sensitive health data is prevented from being sent to the model.
* **Output** — the model is prevented from producing or disclosing PHI.

<Note>
  HIPAA (the U.S. Health Insurance Portability and Accountability Act) requires strict technical and administrative controls to prevent unauthorized access to, disclosure, or transfer of PHI. PHI Operations is designed to help meet those obligations.
</Note>

## CII Operations

**CII Operations** regulates the flow of **critical infrastructure information**. It automatically identifies operational processes, service-continuity details, infrastructure dependencies, technical topologies, and other strategically important information, and restricts the processing of such content under your security standards.

* **Input** — critical infrastructure information is not sent to the model.
* **Output** — the model does not reproduce or disclose such information.

This is an important line of defense for sectors requiring high security — energy, finance, defense, and public institutions — preserving operational integrity and preventing the unintended modeling of sensitive operational data.

## Related

<CardGroup cols={2}>
  <Card title="Secondary Model Routing" icon="route" href="/platform/secondary-model-routing">
    Route PII/PHI to a local model so it never leaves your walls.
  </Card>

  <Card title="Controls Catalog" icon="list-check" href="/concepts/controls-catalog">
    BG-02, BG-20, and BG-24 in detail.
  </Card>

  <Card title="Proxies & Endpoints" icon="arrow-right-arrow-left" href="/platform/proxies">
    Enable these modules on an endpoint.
  </Card>

  <Card title="Compliance" icon="scale-balanced" href="/guides/compliance">
    Map these controls to regulatory obligations.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.