[Yandex Cloud documentation](../../index.md) > [Security in Yandex Cloud](../index.md) > Security standard for implementing and operating AI systems in Yandex Cloud, version 1.0.0 > Compliance and processing of personal and regulated data

# Compliance and processing of personal and regulated data

{#compliance-pii}

This section sets out technical requirements for implementing an **approved** legal and compliance approach for an AI scenario. It does not define the lawful basis for data processing, allowed recipients, retention period, or legal status of cross-border transfer.

The Yandex Cloud features and tools, including region selection, encryption, [DSPM](../../security-deck/concepts/dspm.md), [IAM](../../iam/index.md), and audit logs serve strictly as technical controls; they do not replace a review of a specific workflow by your organization’s authorized legal or compliance teams.

Throughout this section, regulated data refers to any personal data, trade secrets, banking secrets, payment details, or any other categories subject to special processing rules under the applicable law, agreement, or internal policy.

## Legal approach and placement {#legal-placement}

### Approved processing admissibility {#approved-processing-admissibility}

{#ai-comply1-id}

Requirement ID: `AI-COMPLY1`

{#ai-comply1-risk}

**Risk**

Running AI scenarios without established legal, organizational, and technical requirements for personal data or other regulated data processing may lead to regulatory violations, breaches of contractual obligations, or internal policy non-compliance.

{#ai-comply1-requirement}

**Requirement**

Prior to feeding regulated data into a model, RAG database, vector index, log, backup, external API, or any other component, the authorized party must define, document, and agree upon the following:

* Goal, lawful basis, and allowed processing operations.
* Categories of subjects, data categories, and minimum required fields.
* Roles of the organization, Yandex Cloud, external providers, operators, and other recipients.
* Allowed processing and storage locations, localization rules, and cross-border transfer requirements.
* Data processing delegation terms, applicable contractual obligations, and subcontractor involvement.
* Time frames for storing, deleting, destroying, archiving, and backing up data.
* Requirements for data protection and logging, incident response, and fulfilling data subjects’ rights.
* Features of data used for training, fine-tuning, assessing, and using a model as well as building a RAG database.

This baseline must be linked to a versioned processing card detailing the goal, data classes, source, operations, exact Yandex Cloud resources and region, model and provider, recipients, storage details, technical measures, and the approving authority. This card must map to data flows defined under `AI-SDLC1`. For a production processing scenario, the `N/A` result is prohibited.

{#ai-comply1-implementation}

**Implementation**

As a data controller hosting personal data in Yandex Cloud, the customer delegates data processing to the provider under the applicable agreement terms. Information on the Yandex Cloud measures and certifications is available in its [compliance documents](../conform.md); however, this does not replace the assessment of the customer’s specific system. The configuration of Yandex Cloud services does not translate into a legal approach. Configuration proves that controls are in place but does not establish the lawful basis.

{#ai-comply1-recommendation}

**Recommendation**

Conduct privacy and compliance assessments prior to connecting a model, external API, or RAG system. These assessments must also be performed prior to model training or fine-tuning, and ahead of any major updates to the data, recipients, region, endpoint, or architecture.

{#ai-comply1-manual-check}

**Manual check**

1. Map the approved baseline to the actual fields, subjects, models, logs, indexes, and recipients.
1. Verify that each type of regulated data, each scenario, and each recipient is covered by the baseline.
1. Do not allow the processing of undocumented data types or transfers to unauthorized recipients prior to revising and approving the baseline.
1. Select an actual resource, log, or request field and trace it to the approved processing card. An expired baseline means failure.

{#ai-comply1-artifacts}

**Artifact**

* Approved legal and compliance approach.
* AI scenario registry.
* Data flow diagram.
* Architecture description.
* List of processors and recipients.
* Agreement references.
* Baseline revision records.
* IDs of data flows and resources.
* Examples of traces without real personal data.

### Placement restrictions are implemented in the architecture {#placement-restrictions-enforced-in-architecture}

{#ai-comply2-id}

Requirement ID: `AI-COMPLY2`

{#ai-comply2-risk}

**Risk**

Hosting personal data or any other regulated data in components that fail to meet the localization, region, protection, or retention requirements, creates a risk of unauthorized processing and unaccounted data copies.

{#ai-comply2-requirement}

**Requirement**

The organization must create and maintain an up-to-date lifecycle map for regulated data within the AI workflow: ingestion, transfer, storage, backup, caching, logging, indexing, vectorization, inference, training, fine-tuning, maintenance, and deletion.

For each component processing regulated data, explicitly define:

* Permissible use and data category.
* Cloud, folder, region, availability zone, or external location.
* Resource owner and data owner.
* Backup retention period and methods for storage, deletion, destruction, and control.
* Applicable protection measures.
* Incoming and outgoing data flows, including external endpoints.

Inventory must track each copy of data, including exports. Approved services and regions must be enforced proactively via the resource creation and release policy.

{#ai-comply2-implementation}

**Implementation**

A Yandex Cloud region is a geographical area that groups availability zones. It has its own structure and services. Selecting a region does not prove legal compliance and does not describe data transfer to external systems. You cannot assume where data is processed by simply looking at resource folder. If using an external provider, you must obtain their official written records of processing locations.

{#ai-comply2-recommendation}

**Recommendation**

Ensure that the component registry encompasses, at minimum: [Object Storage](../../storage/index.md), [Yandex Managed Service for PostgreSQL](../../managed-postgresql/index.md), or any other databases, VM disks, queues, caches, [Cloud Logging](../../logging/index.md), [Audit Trails](../../audit-trails/index.md), RAG indexes, vector databases, observability tools, administrator workstations, and external AI APIs.

{#ai-comply2-check}

**Check**

1. Trace a synthetic regulated object from the ingestion point to all its copies and recipients.
1. For each cloud resource, cross-reference its region and actual location against the approved decision.
1. Check backups, logs, indexes, caches, and work data for unaccounted copies.
1. Any unaccounted copy, external route, or region change must block modification deployment until the approval is renewed.
1. In case of a negative test, deployment or export to a prohibited branch must be blocked.

{#ai-comply2-artifacts}

**Artifact**

* Data flow map.
* Component registry.
* Yandex Cloud resource inventory.
* Region and folder configuration.
* Retention polices.
* Deletion evidence.
* Architecture review results.
* Resource exports.
* Migration or deletion record.

## External recipients and cross-border flows {#external-recipients}

### Transfer to external recipients is allowed and limited {#external-recipient-transfer-allowed-limited}

{#ai-comply3-id}

Requirement ID: `AI-COMPLY3`

{#ai-comply3-risk}

**Risk**

Sending personal data or any other confidential information to an external model, API, SaaS tool, or third-party provider without a compliance review may lead to a violation of legal requirements, contractual obligations, and organization policies.

{#ai-comply3-requirement}

**Requirement**

Before sending data, the organization must document the following for each external recipient:

* Recipient, their jurisdiction, and allowed subcontractors.
* Purpose, categories, composition, and maximum allowed amount of data.
* Allowed endpoints, domain names, IP addresses, and the sending workload identity.
* Data processing, storage, and backup region, if defined by the provider.
* Terms for data processing delegation, cross-border transfer, retention, deletion, and processing termination.
* Validity period of the decision and events requiring its review.

An application or centralized AI gateway must only send approved data to a trusted endpoint. Changing a recipient, endpoint, processing region, included fields, provider terms, or subcontractor requires a new check.

{#ai-comply3-implementation}

**Implementation**

[VPC route tables](../../vpc/concepts/routing.md) allow routing subnet traffic through a specified `next hop` but do not confirm transfer legitimacy and do not support content filtering or recipient control at the application layer.

{#ai-comply3-recommendation}

**Recommendation**

Implement a centralized AI integration layer to handle workload authentication, recipient whitelisting, field minimization, PII masking, request metadata logging, and blocking of unapproved directions. Do not write the full contents of regulated requests and responses into technical logs without a reason and extra security measures in place.

{#ai-comply3-check}

**Check**

1. Cross-reference the approved registry of external recipients with the configurations of applications, DNS, TLS connections, VPC routes, and outgoing network traces.
1. Run a test allowed transfer of data to an approved endpoint.
1. Try to send a restricted field or route a request to an unapproved endpoint.
1. The unauthorized transfer must be stopped before the data leaves the trusted perimeter.
1. The request redirect attempt to an unapproved address must be blocked, and the denied call must not appear in the outgoing traffic log or provider traces.

{#ai-comply3-artifacts}

**Artifact**

* Data transfer evaluation.
* Registry of recipients and endpoints.
* Contractual documents or references to them.
* AI gateway configuration.
* Network policies.
* Block logs and test results.
* Secret ID.
* Provider evidence.

### Cross-border flow is allowed by a separate decision {#cross-border-flow-allowed-by-separate-decision}

{#ai-comply4-id}

Requirement ID: `AI-COMPLY4`

{#ai-comply4-applicability}

**Scope**

The requirement applies if data, a backup, log, model request, model results, or any other component of the workflow may cross a boundary defined by applicable law or an internal placement policy.

{#ai-comply4-risk}

**Risk**

Cross-border transfer carried out without complying with applicable procedures, notifications, or contractual or organizational requirements may result in a law violation and regulatory action.

{#ai-comply4-requirement}

**Requirement**

Prior to the initiation of a cross-border flow, authorized representatives of the organization responsible for legal matters or compliance must determine and approve the following:

* Occurrence of a cross-border transfer in a specific scenario.
* Countries, recipients, subcontractors, and end points.
* Categories, composition, target, and legal basis of the transfer.
* Applicable prohibitions, restrictions, approvals, notifications, and contractual terms.
* Requirements for protection, retention periods, deletion, and implementation of subject permissions.
* The decision's validity period and the events requiring its re-evaluation.

The technical team must follow the authorized representatives' decision and align it with the resources, routes, and endpoint from `AI-COMPLY2` and `AI-COMPLY3`. The presence of TLS, the choice of region, or a contract not reviewed by authorized representatives does not in itself constitute confirmation of legal admissibility.

For each flow, the following are specified: sender and recipient, data fields and data class, source and target locations, transport, storage and onward transmission, and solution ID. Allowlists for recipients and destinations with a default-deny policy are applied during resource creation and to outbound traffic; unknown or modified endpoints, regions, or recipients are blocked.

An internal flow across the border does not, in itself, constitute a legal conclusion regarding a cross-border transfer.

{#ai-comply4-check}

**Check**

1. Select one outbound data flow and map the country, recipient, data categories, endpoint, subcontractors, and timeframe against the current solution.
1. Verify that changing the supplier region, destination, subcontractor, or data composition blocks the flow until a new decision is made, if the previous decision does not cover the change.
1. Make sure the cross-border flow details are aligned with the architecture map and the recipient registry.
1. If the processing location or subsequent recipient is unknown, the flow halts until reputable information is received; no assumptions are made.

{#ai-comply4-artifacts}

**Artifact**

* Legal and compliance assessment.
* Confirmation of required procedures.
* Register of cross-border flows.
* Architectural schema.
* Endpoint configuration and changelog.
* Registry of flows with solution IDs.
* Failure of an unknown line.

## Anonymization, pseudonymization, and personal data masking {#deidentification-masking}

Regulated data transformation reduces identifying information provided to a model or external component down to an absolute minimum required by a scenario. The transformation method is selected based on whether you need to preserve structure, relations between records, and ability to recover values, and whether there is risk of re-identification.

Below is a technical glossary of terms used throughout the standard. It does not constitute a legal definition or replace an assessment by duly authorized officers.

* **Masking**: Concealing or replacing a part of a value, e.g., `+7 *** ***-12-34` or `[USER_NAME]`. The format or some part of the value may remain as is.
* **Pseudonymization**: Replacing a value with an alias or code. Reverse transformation is possible if you have access to the key, mapping table, or detokenization service.
* **Tokenization**: Replacing a value with a token, usually when an application needs to restore the value after processing by a model.
* **Hashing**: Deriving a calculated value; its resilience depends on the entropy of the source data, salt, secret, and risk of brute-force attacks.
* **Aggregation**: Replacing detailed data with grouped or statistical values.
* **Anonymization**: Transformation that provides no standard way to recover the identity from the transmitted dataset; its sufficiency is evaluated for the specific dataset and risk of re-identification through linkage attacks.

### Protective transformation takes place before the trust boundary {#protective-transform-before-trust-boundary}

{#ai-comply-pii1-id}

Requirement ID: `AI-COMPLY-PII1`

{#ai-comply-pii1-risk}

**Risk**

Transmitting personal data to an LLM or external AI service when such data is not required to perform the task at hand increases the risk of a data breach and non-compliance with data processing requirements.

{#ai-comply-pii1-requirement}

**Requirement**

If the approved solution requires transformation, the organization must perform PII detection and transformation before transferring data to a segment of the model, cloud, or external environment that is not authorized to view the original values.

For each scenario, the following must be defined:

* Data fields and categories subject to discovery and transformation.
* Algorithm, execution point, and policy version.
* Reversibility eligibility.
* Keys, mapping tables, and the detokenization sequence.
* Subjects with the permission to reverse conversion.
* Safe behavior in the event of a converter error or unavailability.

If recovery is not required, methods that are irreversible, or practically irreversible for the given scenario, are employed. If recovery is necessary, pseudonymization or tokenization is allowed, provided that the recovery is performed within the organization's controlled environment.

If the model requires only statistical properties, aggregation or other forms of detail reduction are applied. Hashing is only allowed after assessing the risk of brute-force attacks, matching, and re-identification.

The converter is placed before the first prohibited boundary; minimization is performed first, followed by the selected transformation, and the validator rejects any remaining prohibited fields.

{#ai-comply-pii1-implementation}

**Implementation**

You can use [Lockbox](../../lockbox/index.md) to store secrets and [KMS](../../kms/operations/index.md) to manage encryption keys; the choice and integration of these tools must align with the approved architecture. KMS and DSPM protect keys and mapping tables, but encryption in itself is not anonymization; KMS, KMS, and guardrails do not constitute a transformation in themselves.

{#ai-comply-pii1-recommendation}

**Recommendation**

Use semantically meaningful tokens, such as `[USER_NAME]`, `[PHONE]`, and `[ORDER_ID]`, provided they preserve the query's meaning and do not reveal the original value.

{#ai-comply-pii1-check}

**Check**

1. Using a synthetic record, trace the source field, transformation result, model request, and logs.
1. Confirm that the initial value does not cross the established confidence limit.
1. Make sure the reverse transformation is only available to an authorized subject and logged without recording the original value.
1. Provide an input containing a prohibited residual field and simulate converter unavailability: a subsequent outbound call must not take place.
1. Verify the absence of initial values ​​outside the boundaries by checking the logs and traces.

{#ai-comply-pii1-artifacts}

**Artifact**

* Transformation policies.
* Gateway or application configuration.
* Registry of tokens and keys without value disclosure.
* Test results.
* Access control model.
* Transformation type and version.
* Confirmation of the absence of data outside the boundaries.

### Personal data detection tools match data and risk {#pii-detection-tools-match-data-and-risk}

{#ai-comply-pii4-id}

Requirement ID: `AI-COMPLY-PII4`

{#ai-comply-pii4-risk}

**Risk**

Inadequate personal data detection tools may leak sensitive data when sending requests to LLMs, or capture such data in indexes, logs, and other storage locations.

{#ai-comply-pii4-requirement}

**Requirement**

The organization must use data discovery tools aligned with the data composition and risk level: rules, regular expressions, dictionaries, NER models, classifiers, DLP/DSPM tools, AI gateways, or special tokenization services.

These discovery tools must support:

* Tracking of false positives and false negatives.
* Rule versioning and controlled configuration modification.
* Test suites featuring multilingual, structured, and nested inputs.
* Monitoring of errors, bypasses, and unknown field types.
* Regular quality checks using representative synthetic or allowed test data.

Misses and false triggers must be evaluated separately by data class, language, format, and path. Policy and legal approach owners must approve the acceptable result; the general threshold is not defined. A critical miss must must trigger a fail-safe state or route the stream to quarantine. If a detector is not declared, this requirement may be considered `N/A`, but the `AI-COMPLY-PII1` and `AI-COMPLY-PII3` requirements remain applicable.

{#ai-comply-pii4-implementation}

**Implementation**

The DSPM module in Security Deck is designed to discover sensitive information in supported sources. Use its results for data detection and control but do not treat them as a replacement for data transformation inside model queries.

{#ai-comply-pii4-recommendation}

**Recommendation**

Include non-standard wording, transliteration, nested payloads, JSON, CSV, documents, OCR texts, prompt injections, and intentionally corrupted inputs in test suites.

{#ai-comply-pii4-check}

**Check**

1. Run a test suite on synthetic data for all supported personal data categories.
1. Document the precision, recall, or any other quality metric approved for this specific scenario.
1. Make sure that changes to a rule, classifier, or model undergo the change approval procedure.
1. Confirm that an unknown or unrecognized field type does not trigger an uncontrolled transfer of the original value.
1. Known positive and negative examples must be run upon each significant detector change.

{#ai-comply-pii4-artifacts}

**Artifact**

* DSPM, DLP, gateway, and classifier configurations.
* Rule versions.
* Test suites.
* Quality assessment results.
* Requests and change logs.
* Test suite management rules.
* Detector versions.

### Transformation is controlled and not bypassed on error {#transform-controlled-not-bypassed-on-error}

{#ai-comply-pii3-id}

Requirement ID: `AI-COMPLY-PII3`

{#ai-comply-pii3-applicability}

**Scope**

The requirement applies if one of the following is implemented for the scenario: software-based masking, tokenization, pseudonymization, detokenization, or another protective transformation.

{#ai-comply-pii3-risk}

**Risk**

Unauthorized de-anonymization, substitution of rules, key compromise, or emergency bypass of the transformation process can lead to disclosure of regulated data.

{#ai-comply-pii3-requirement}

**Requirement**

Access to modifying algorithms and rules, reading verification records, using keys and mapping tables, and performing reverse transformation must be granted based on the principles of least privilege and separation of duties.

A masking, tokenization, pseudonymization, detokenization event or another protective transformation is generated by an application or transformation component. Cloud Logging only accepts this event. Audit Trails records published cloud operations but does not acknowledge the execution of each individual application-level transformation operation. For each forward and inverse transformation operation, the following must be recorded:

* Time and technical request ID.
* Component, service account, or user.
* ID and version of the applied rule.
* Type of operation and technical result.
* Indication of an error, failure, or explicitly permitted exception.

Source personal data, keys, and mapping tables must not be included in logs without separate justification, approval, and protective measures.

A parser error, unknown field, corrupted input, or converter unavailability must not result in the model's source data being sent to an external recipient or a technical log; acceptable failure behavior is defined alongside the processing policy. Any subsequent call to a model, RAG, tool, or log must only receive the converter's typed, successful output; a bypass, timeout, exception, or invalid result will block the call.

Read permissions for the logs in Cloud Logging and Audit Trails must also be restricted.

{#ai-comply-pii3-recommendation}

**Recommendation**

Export required audit events to Yandex SIEM, set retention periods for records, protect it against unauthorized alteration, and regularly review access to it. Yandex Cloud documentation also recommends analyzing Cloud Logging and Audit Trails when investigating a compromise of secrets.

{#ai-comply-pii3-check}

**Check**

1. Perform a successful transformation using synthetic data and check how the following are handled: input with an unknown field, a corrupted object, and converter unavailability.
1. Verify the failure before crossing the trust boundary in all error scenarios.
1. Check for an attempted bypass via an alternative API, queue, log, or administrative interface.
1. Verify the denial of the reverse transformation to an unauthorized subject.
1. Confirm that the evidence contains time, component, rule version, operation type, and error or bypass indicator – without source values, keys, or mapping tables.
1. Make sure the subject who modifies the rule does not get the permission to perform detokenization and modify or read evidence without a separate, approved exception at the same time.

{#ai-comply-pii3-artifacts}

**Artifact**

* IAM policies and role models.
* Audit Trails and Cloud Logging configuration.
* Transformation logs.
* Rejection logs.
* Fault tolerance test results.
* Rules for storage and access to evidence.
* Event schema.
* Unavailability and bypass tests.