How to Filter Personal Information in LLMs — A 4-Stage Design from Input to RAG, Output, and Logs

Connecting Large Language Models (LLMs) to business operations increases the pathways for personal information to enter. Users can directly input it into prompts, or it might already be included in training data or RAG documents. Problems also arise when the model combines search results, mixing personal information unrelated to the original query into the answer, or when operational logs become new personal information storage locations.

This problem isn’t solved by simply attaching a regular expression filter in front of the model. Personal information flows from data collection to input, search context, output, and logs. Conversely, indiscriminately blocking every sentence would lead to an increase in false positives, rendering the service unusable.

The realistic goal is not to promise ‘perfect detection,’ but to layer multiple detection methods to avoid missing high-risk information, and to consistently decide on blocking, masking, pseudonymization, or allowing based on business purpose and authority.

First, you need to map the flow of personal information

The typical paths for personal information in LLM services are as follows:

원본 문서·업무 데이터
        ↓
수집·전처리 → RAG 인덱스
        ↓           ↓
사용자 입력 → 검색·컨텍스트 구성 → LLM
                                  ↓
                              모델 출력
                                  ↓
                           사용자·외부 도구

각 구간의 요청·결과·정책 판단 → 감사 로그

The important point here is that the model itself should not be allowed to determine personal information access rights. A system prompt like ‘Do not mention personal information’ is merely a supplementary instruction, not a security boundary. OWASP also explains that sensitive information can be exposed through training data or user interactions, and system prompts alone are difficult to prevent circumvention.

Therefore, personal information control must be enforced outside the model.

A quick look at the 4-stage structure


Stage	Protected Object	Key Control	Representative Result

—	—	—	—
1. Collection/Preprocessing	Training data, documents, RAG originals	Regex/checksum, NER, context detection, sample review	Removal, masking, pseudonymization, isolation
2. User Input	Prompt, attached files, conversation history	Normalization, real-time PII detection, purpose-specific policies	Blocking, masking, tokenization, warning
3. RAG/Tools/Context	Search documents, secret information, external tools	Pre-search authorization check, minimal context, secret brokerage	Only authorized information passed to model
4. Output/Audit	Model response, execution arguments, operational logs	Output re-inspection, structure validation, secure logging	Leakage prevention, tracking/alerting

Each stage does not replace the others. Even if personal information is missed during preprocessing, it should be caught again at the input or output stage, and if a filter fails, RAG access control should prevent other users’ documents from being searched.

Stage 1: Reduce personal information during data collection and preprocessing

Reducing the amount of personal information from the moment training data or RAG knowledge bases are created is the most cost-effective approach. Once vectorized, not only the original text but also chunks, embeddings, metadata, caches, and backups must be cleaned together.

First Detection: Rules and Checksums

Values with relatively clear formats, such as resident registration numbers, phone numbers, emails, and credit card numbers, can quickly be identified as candidates using regular expressions. However, a matching number format doesn’t necessarily mean it’s an actual identification number, so where possible, validation methods like checksums, date validity, and prefix ranges should be applied together to reduce false positives.

Regular expressions alone often miss expressions like the following:

공일공-일이삼사-오육칠팔
홍 길 동의 메일은 hong (at) example (dot) com
매주 화요일 ○○병원 희귀질환 센터에 방문하는 팀장

Therefore, spaces, Unicode, delimiters, and known encodings should first be normalized, and regex results should be treated as one of several detection signals, not as a final judgment.

Second Detection: NER and Context

For information whose meaning changes depending on the context, such as names, locations, organizations, and medical information, Named Entity Recognition (NER) and surrounding words are analyzed together. Microsoft Presidio’s Analyzer also combines regular expressions, lists, checksums, rules, NER, and context, and can connect NLP engines like spaCy, Transformers, Stanza, or custom recognizers.

In a Korean environment, it’s necessary to validate Korean NER models and business-specific dictionaries rather than directly adopting generic English models. Values that are only identifiable within an organization, such as employee IDs, customer numbers, project codes, and branch names, are unknown to general-purpose tools, thus requiring custom recognizers.

Third Detection: Semantic-based models as auxiliary means

Sentences where identification risk is revealed only by combining multiple clues, such as “the only executive receiving specific treatment at the same hospital every week,” can use semantic-based classifiers or LLMs as auxiliary detectors. However, entrusting blocking decisions solely to an LLM-as-a-Judge can lead to non-deterministic outputs and susceptibility to prompt circumvention.

Furthermore, sending original text to an external LLM to detect personal information can create a contradiction: personal information is transmitted externally before detection. If semantic-based detection is necessary, internal models or approved processing environments should be used, and results should be limited to structured labels like PERSON, MEDICAL_CONTEXT, HIGH_RISK for safety.

Fourth Validation: Human review of samples

The accuracy of automatic filters varies by document type and language. Before deployment, samples with and without personal information should be created to measure recall and precision, and during operation, authorized reviewers should check at least a minimum number of samples. The review screen should also avoid unconditionally exposing the entire original text, showing only necessary surrounding context.

More important than detection is ‘how to process it’

Actions taken after discovering personal information vary depending on the purpose of use.


Processing Method	Example	Suitable Situation	Caution

—	—	—	—
Block/Remove	Reject the request itself	High-risk values like passwords, API keys, resident registration numbers	Guide user on safe re-entry method
Masking	010-****-5678	When some information is needed for display or consultation context	Check for re-identifiability of remaining fragments
Categorization	Exact age → 40s	When precise values are unnecessary for statistics/analysis	Too fine-grained categories maintain identifiability
Pseudonymization/Tokenization	Name → PERSON_7F2A	When connectivity is needed within the same conversation/task	Mapping table stored in a separate vault outside the model
Allow	Customer inquiry by authorized agent	When legal basis and business purpose are clear	Apply minimal scope, expiration time, audit records

Microsoft Presidio Anonymizer provides operators like replace, redact, hash, mask, encrypt. However, the functions provided by a tool are separate from the policies an organization must choose. For example, one-way hashing can be re-identified if the range of candidate values is narrow, and pseudonymization is not the same as anonymization because a mapping table remains.

Is it safe to only leave the last four digits of a phone number?

Simply masking part of a number like 010-****-5678 does not automatically make it anonymous information. If affiliation, position, region, visit date, or incident circumstances are present in the same conversation, the remaining four digits can be combined to infer a specific individual.

“경기 남부 지점의 유일한 보안팀장”
+ “지난 화요일 ○○병원 방문”
+ “전화번호 끝 네 자리 5678”
= 결합했을 때 높아지는 재식별 가능성

Therefore, the masking scope should be determined not by a fixed pattern, but by the display screen, business purpose, co-exposed information, and the scope of accessors.

For simple statistics or LLM analysis, replace entirely with [Contact] or delete.
If the target needs to be linked within the same conversation, use a random token like PHONE_8F92.
If an agent needs to confirm contact information after identity verification, only display the necessary range on the screen, and separate full number lookup into a separate approval process.
For logs and analytical data, avoid leaving even the last four digits if possible.

The safest personal information is not information well-masked by a filter, but information that was never collected or transmitted to the model in the first place. Even when preparing for post-masking, input of unnecessary values like resident registration numbers and authentication information should be blocked on the input screen first.

Stage 2: Control user input before model invocation

In an operational environment, all prompts and attached files are untrusted inputs. The processing order can be structured as follows:

요청 인증
→ 텍스트·인코딩 정규화
→ 규칙·체크섬 탐지
→ NER·문맥 탐지
→ 테넌트·업무 목적별 정책 결정
→ 차단 또는 가명화
→ 승인된 모델 호출

OpenAI Guardrails’ Contains PII check can mask or block input personal information using Microsoft Presidio, and apply blocking policies at the output stage. AWS Bedrock Guardrails also provides features to detect and block or mask PII in input and model responses. While these managed features are useful, one should not assume ‘it’s set, so it’s done’ without validation tailored to the organization’s Korean data and identifiers.

Input length limits, file size limits, and request frequency limits are also necessary. These are controls to reduce cost spikes, resource exhaustion, and mass extraction attempts, not filters to solve personal information detection or prompt injection.

User experience is also important. Instead of simply throwing an error, it’s better to provide specific safe actions, such as:

주민등록번호로 보이는 값이 포함되어 요청을 전송하지 않았습니다.
해당 값을 삭제하거나 고객 참조번호로 바꾼 뒤 다시 시도해 주세요.

Stage 3: RAG checks permissions before searching

A common mistake in RAG is to search all documents and then instruct the model, ‘Do not answer content for which you do not have permission.’ Once the searched chunks are in the context, there is a possibility of exposure due to prompt injection or model errors.

Permission checks should occur before searching.

사용자 인증 정보
→ 테넌트·역할·문서 ACL 확인
→ 허용 범위로 검색 후보 제한
→ 관련 청크 검색
→ 필요한 최소 청크만 컨텍스트에 포함

In general business, ‘security trimming’ using document/row-level ACLs, tenant keys, security classification metadata, and search filters can be applied. In environments with strong regulatory boundaries or where data from different customers must never be mixed, physical separation of indexes, databases, accounts, or VPCs can be added. Replicating vector DBs for every user group is not the only answer.

API keys, database passwords, and OAuth tokens should not be placed in prompts or RAG documents. Secret values should be stored in secret stores like Secrets Manager or Vault, and referenced only at execution time by a tool broker. KMS or HSM primarily manage the keys that encrypt this data and storage.

Provide the model with a restricted tool interface instead of the secret itself.

나쁜 예: 프롬프트에 운영 DB 비밀번호 삽입

좋은 예: LLM이 `lookup_customer(reference_id)` 요청
       → 도구 브로커가 사용자 권한과 인자를 검사
       → 비밀 저장소에서 자격증명을 일시 참조
       → 필요한 필드만 반환

If the original text needs to be shown again later

Simple masking is an operation to obscure the display format and is not a function to restore the original. If the original text needs to be shown again later to an authorized user, reversible tokenization or a separate encrypted original storage must be designed. In this case, the restoration logic should not be entrusted to the LLM or prompt.

The safe flow is as follows:

1. 원본 전화번호 수집
2. 무작위 토큰 발급: PHONE_8F92
3. LLM·대화 DB에는 토큰만 저장
4. 원본↔토큰 매핑은 별도 보안 저장소에 암호화
5. 사용자가 원문 조회 요청
6. 애플리케이션이 세션·소유권·권한·재인증 확인
7. 미들웨어가 필요한 순간에만 복원
8. LLM을 거치지 않고 승인된 UI에 직접 렌더링
9. 조회 사실을 원문 없이 감사 로그에 기록

Component responsibilities must also be clear.


Component	Role to Play	Permissions Not to Have

—	—	—
LLM	Understand the intent “contact confirmation request”	Access original mapping DB / decryption key
Application	Session, ownership, business purpose, policy check	Unlimited bulk lookup of originals
Token Vault	Secure mapping of tokens and originals	Direct interaction with users
KMS/HSM	Control creation/use of storage encryption keys	Transmit personal information to prompt
Approved UI	Display for minimum time to verified user	Store original text in response cache / analysis logs
Audit System	Record inquirer, time, reason, policy result	Record restored personal information original text

Re-identification requests apply stronger controls than general lookups. Do not rely solely on login sessions; require MFA or recent re-authentication based on risk level, and verify not only RBAC but also data ownership and business purpose. Apply short expiration times, one-time permissions, call frequency limits, and bulk lookup blocking to restoration APIs.

Storage should be encrypted with approved cryptographic algorithms, and keys controlled by KMS or HSM. Simply stating ‘AES-256 was used’ does not guarantee safety. If the application role can freely decrypt all keys and data, the separation effect disappears, so key usage policies and service roles must be restricted together.

Audit logs should record user ID, session or request ID, lookup time, pseudonymized target identifier, lookup reason, allow/deny result, and policy version. The restored phone number itself or decryption key should not be recorded. These events can be sent to a SIEM to trigger alerts for lookups at unusual times, repeated lookups in a short period, or lookups of multiple customers.

Stage 4: Output and logs as the last line of defense

The model’s raw output must be re-examined before being delivered to users or external systems. Information not found in the input may be generated from RAG documents or model memory.

At the output stage, one of the following options is chosen by jointly considering the personal information type, requester’s authority, and response purpose.

안전함        → 전달
일부 노출 가능 → 마스킹 후 전달
고위험 정보    → 전체 차단 및 안전한 대체 문구
판단 불확실    → 사람의 승인 대기

Code, SQL, HTML, and tool call arguments require schema validation, allowlists, escaping, and sandboxing, separate from personal information filters. Deleting personal information does not make command execution safe.

It is better to leave the following information in audit logs instead of the original text:

{
  "request_id": "req_7f2a",
  "actor_id": "pseudonymous-user-42",
  "detected_types": ["PHONE_NUMBER", "PERSON"],
  "detected_count": 2,
  "action": "MASK",
  "policy_version": "pii-policy-2026-07",
  "model_route": "internal-model",
  "timestamp": "2026-07-30T10:15:00+09:00"
}

The original text of detected phone numbers or names is not recorded here. If limited original text retention is absolutely necessary for incident investigation, a separate encrypted storage, strict access control, short retention periods, and access audits must be applied.

Even when using managed guardrails, log settings must be checked separately. AWS documentation warns that Guardrails’ masking is not automatically applied to model call logs, meaning original requests may be stored in CloudWatch Logs or S3, and detected original text may also be included in tracing information. In other words, what is masked on screen is not the same as what is removed from logs.

Practical policies should vary by data type


Data Type	Default Policy	Exception Conditions

—	—	—
Passwords, API keys, session tokens	Immediate blocking, security alert	None
Resident registration numbers, passport numbers, accounts, cards	Block external model transmission, minimize even internally	Explicit legal basis and approved dedicated tasks
Phone numbers, emails, addresses	Masking or tokenization	When purpose is clear, e.g., agent confirming identity
Names, titles, organizations	Assess risk of combination with context	If public business information and necessary for purpose
Medical, biometric, location, behavioral information	Classify as high-risk, prioritize internal processing	Enhanced consent, authorization, audit system
Employee ID, customer number, project code	Apply organization-specific recognizers and policies	Approved internal tasks

Even the same name carries different risks depending on whether it’s a representative’s name in a public press release or a patient’s name in a private consultation record. Instead of simply judging ‘is it PII or not,’ the policy engine should also consider data sensitivity, purpose of use, requester’s authority, transmission target, and retention period.

Metrics to measure before operation

Personal information filters should be evaluated by their performance and failure modes, not just their installation status.

High-risk recall: How well it doesn’t miss actual resident registration numbers, account secrets, etc.
Precision: How often it doesn’t incorrectly block normal business sentences.
Performance by language/expression: Is performance maintained for Korean, English, spacing variations, Unicode, and image OCR?
Evasion resistance: Are policies maintained even with split input, encoding, role-playing, and indirect prompt injection?
Processing delay: Impact of input and output checks on service delay.
Policy results: Blocking, masking, allowing rates, and user retry rates.
Residual leakage rate: Percentage of personal information remaining in final responses or logs from red team datasets.

If detection rules or models are changed during operation, they must be re-measured with the same regression test set. This is why the detection model version and policy version are recorded in audit logs.

It’s safer to start small with the introduction order

First, list data flows and storage locations.
Block high-risk items first, such as passwords, tokens, and unique identifiers.
Create evaluation datasets with Korean documents and organization-specific identifiers.
Link the same policy ID to collection, input, RAG, output, and logs.
Design masking/pseudonymization exceptions by measuring the impact of blocking on operations.
Regularly perform red team and regression tests.
Verify deletion procedures for original text, caches, indexes, and backups whose retention periods have ended.

Points to check when applying domestic guidelines

Domestic official documents consistently emphasize lifecycle-wide risk management and data minimization. The Personal Information Protection Commission’s 2025 “Guidelines for Personal Information Processing for Generative AI Development and Utilization” presents considerations for each stage, from purpose setting to data preprocessing, access control, input/output filtering, pre-deployment testing, and continuous management. The 2026 user guide advises checking business data and third-party information before inputting it, and reviewing conversation storage, learning utilization, and external service permissions.

The PIPC’s AI Privacy Risk Management Model describes an approach that identifies the type and use case of AI, measures the likelihood and severity of risks, and selects measures proportionate to the risk. Not all example measures in the guidelines are equally mandatory for all services. Actual legal obligations, retention periods, international transfers, and pseudonymized information processing should be separately reviewed based on the organization’s processing purpose and applicable laws.

From a technical security perspective, KISA’s “Artificial Intelligence (AI) Security Guide” and “AI Security Threat Response Manual,” and the National Intelligence Service’s “AI Security Guidebook for National and Public Institutions” can be referenced together. Environments dealing with public institutions or confidential/sensitive data may require stronger approvals, network segmentation, and data classification controls than general consumer services.

Conclusion

LLM personal information protection is not about installing a single product. It’s a continuous system that reduces personal information during data collection, controls input before model invocation, prevents RAG from searching unauthorized documents, and re-examines final output and logs.

Regular expressions are fast but miss context, NER is flexible but has false positives and negatives, and semantic-based models can understand complex clues but themselves pose new processing risks. Therefore, multiple detection signals should be combined, but the final action should be decided by an external policy engine and authorization system, not the model.

The core principle is simple:

First, remove personal information that does not need to be transmitted to the model, pseudonymize necessary information to a minimum, restrict search and tool execution by user permissions, and re-check output and logs.

Applying this principle consistently across all 4 stages ensures that personal information filters function as actual security controls, not just simple string replacement features.