Hướng dẫn về API ẩn PII (2026): So sánh AWS, Google Cloud, Azure và Presidio cho ứng dụng LLM
API ẩn PII nhận văn bản, tìm dữ liệu cá nhân như tên, email, số điện thoại, số thẻ và số giấy tờ định danh do cơ quan nhà nước cấp, rồi trả về vị trí của dữ liệu đó hoặc bản sao văn bản đã che, thay thế hoặc mã hóa dữ liệu bằng token. Với các nhóm phát triển sản phẩm AI, nhiệm vụ chính là loại bỏ hoặc thay dữ liệu cá nhân bằng định danh giả trước khi prompt, tài liệu và nhật ký được gửi đến LLM của bên thứ ba. Bốn lựa chọn được các nhóm cân nhắc nhiều nhất là Amazon Comprehend DetectPiiEntities, Google Cloud Sensitive Data Protection (trước đây là Cloud DLP), tính năng phát hiện PII của Azure Language và Microsoft Presidio mã nguồn mở.
Hướng dẫn này so sánh các lựa chọn về endpoint, xác thực, ngôn ngữ hỗ trợ, đơn vị tính phí và định dạng đầu ra, kèm các ví dụ có thể chạy được bằng dữ liệu giả lập. Bài viết cũng trình bày kết quả phát hiện thực tế từ một lần kiểm thử Presidio cục bộ, bao gồm những trường hợp bỏ sót và nhận diện nhầm mà bạn cần tính đến. Tất cả thông tin về nhà cung cấp đã được đối chiếu với tài liệu chính thức vào ngày 27 tháng 10 năm 2026.
Flatkey không cung cấp sẵn API ẩn PII. Các cách triển khai dưới đây chạy trong dịch vụ của bạn trước khi yêu cầu được gửi qua bất kỳ cổng truy cập mô hình nào, bao gồm Flatkey. Về khía cạnh chính sách của cùng vấn đề này, hãy đọc hướng dẫn chính sách ẩn dữ liệu cho API AI của chúng tôi.
Ẩn dữ liệu, che ký tự, phát hiện thực thể và token hóa khác nhau thế nào?
| Kỹ thuật | Kết quả trả về | Có thể khôi phục? | Trường hợp sử dụng phổ biến |
|---|---|---|---|
| Phát hiện thực thể | Loại thực thể, điểm tin cậy và vị trí ký tự | Không áp dụng (không thay đổi văn bản) | Quyết định cách xử lý từng thực thể; kiểm tra dữ liệu đang được truyền đi |
| Ẩn dữ liệu | Văn bản đã loại bỏ PII hoặc thay bằng nhãn như [PERSON_1] |
Không | Prompt gửi đến LLM bên ngoài, nhật ký, phân tích dữ liệu |
| Che ký tự | Văn bản có các ký tự được che, chẳng hạn ***********1111 |
Không | Màn hình hỗ trợ khách hàng cần hiển thị một phần giá trị |
| Token hóa / dùng định danh giả | Văn bản có PII được thay bằng token nhất quán hoặc giá trị được mã hóa | Có, nếu có khóa hoặc bảng tra cứu | Quy trình LLM cần đưa giá trị thật trở lại câu trả lời |
| Ẩn dữ liệu theo trường | Các trường đã biết (như email trong JSON) được loại bỏ hoặc thay thế theo lược đồ |
Tùy trường hợp | Dữ liệu có cấu trúc mà bạn biết trường nào chứa PII |
Với dữ liệu có cấu trúc, quy tắc theo trường nhanh và đáng tin cậy hơn bất kỳ mô hình nào. Hãy dùng API phát hiện PII cho văn bản tự do: tin nhắn trò chuyện, phiếu hỗ trợ, bản chép lời và tài liệu.
So sánh các API ẩn PII (tháng 10 năm 2026)
| Amazon Comprehend | Google Sensitive Data Protection | Azure Language PII | Microsoft Presidio | |
|---|---|---|---|---|
| Loại | API được quản lý | API được quản lý | API được quản lý (có cả container) | Mã nguồn mở, tự triển khai |
| Lời gọi chính | DetectPiiEntities |
projects.content.deidentify |
analyze-text với PiiEntityRecognition |
AnalyzerEngine + AnonymizerEngine |
| Trả trực tiếp văn bản đã ẩn PII | Không, trả về vị trí ký tự (dùng các vị trí đó để ẩn dữ liệu) | Có | Có (redactedText) |
Có |
| Token hóa có thể khôi phục | Không | Có (các phép biến đổi dựa trên mật mã) | Không | Có (các toán tử encrypt / decrypt) |
| Ngôn ngữ hỗ trợ cho PII | Tiếng Anh và tiếng Tây Ban Nha | Nhiều infoTypes, một số dành riêng cho từng quốc gia | Nhiều ngôn ngữ theo tài liệu | Tùy mô hình NLP bạn tải vào |
| Giới hạn đầu vào / đơn vị | 100 KB mỗi yêu cầu; tính phí theo mỗi 100 ký tự, tối thiểu 3 đơn vị | Tính phí theo GiB; tối thiểu 1 KB mỗi yêu cầu | Tính phí theo bản ghi văn bản | Tài nguyên tính toán của bạn |
| Hạn mức miễn phí | 50K đơn vị (5M ký tự) cho mỗi API mỗi tháng trong 12 tháng | 1 GiB đầu tiên mỗi tháng cho hoạt động kiểm tra | 5,000 bản ghi văn bản mỗi tháng (gói miễn phí) | Phần mềm miễn phí |
| Dữ liệu rời khỏi mạng của bạn | Có (AWS) | Có (Google Cloud) | Có, trừ khi bạn chạy container | Không |
Nguồn: Tài liệu PII của Amazon Comprehend, Bảng giá Comprehend, Tài liệu khử định danh của Google, Bảng giá Sensitive Data Protection, Tổng quan về Azure PII, Bảng giá Azure Language và Tài liệu Presidio, tất cả đều được kiểm tra vào ngày 27 tháng 10 năm 2026.
Chi phí là bao nhiêu?
- Amazon Comprehend: Trong ví dụ của chính AWS về Detect PII, 10,000 bình luận của khách hàng, mỗi bình luận dài 550 ký tự, được tính là 6 đơn vị cho mỗi yêu cầu; như vậy, 60,000 đơn vị với giá $0.0001 mỗi đơn vị có chi phí $6 (Bảng giá Comprehend, ví dụ 7). Yêu cầu ngắn được tính phí ở mức tối thiểu 3 đơn vị (300 ký tự), nên gộp các tin nhắn nhỏ thành lô sẽ tiết kiệm chi phí.
- Google Sensitive Data Protection: Hoạt động kiểm tra nội dung được miễn phí cho 1 GiB đầu tiên mỗi tháng, sau đó là $3.00 mỗi GiB, giảm xuống $2.00 mỗi GiB khi khối lượng lớn hơn; phí biến đổi được niêm yết là $2.00 mỗi GiB, sau đó là $1.00. Mỗi yêu cầu được tính phí tối thiểu 1 KB.
- Azure Language: Tính năng phát hiện PII được tính phí theo bản ghi văn bản, với 5,000 bản ghi văn bản miễn phí mỗi tháng ở gói miễn phí. Các gói trả phí được niêm yết trên trang giá Azure theo khu vực của bạn.
- Presidio: Không có phí giấy phép; bạn trả phí cho tài nguyên tính toán để chạy bộ phân tích và mô hình NLP.
Amazon Comprehend: DetectPiiEntities
Comprehend phát hiện PII trong văn bản tiếng Anh hoặc tiếng Tây Ban Nha. DetectPiiEntities trả về Type, Score, BeginOffset và EndOffset của từng thực thể; đầu vào tối đa là 100 KB văn bản UTF-8 (Tài liệu tham chiếu API). API không trả về văn bản đã ẩn PII, nên bạn phải tự thay thế các đoạn văn bản tương ứng.
import boto3
comprehend = boto3.client("comprehend", region_name="us-east-1")
text = "Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187."
resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en")
# Replace from the end so earlier offsets stay valid
redacted = text
for e in sorted(resp["Entities"], key=lambda e: e["BeginOffset"], reverse=True):
if e["Score"] >= 0.5:
redacted = redacted[:e["BeginOffset"]] + f"[{e['Type']}]" + redacted[e["EndOffset"]:]
print(redacted)
Việc xác thực sử dụng thông tin xác thực AWS tiêu chuẩn (vai trò IAM, SSO hoặc khóa truy cập) có quyền comprehend:DetectPiiEntities.
Google Cloud Sensitive Data Protection: content.deidentify
API của Google kiểm tra và biến đổi dữ liệu trong một lời gọi. Bạn chọn infoTypes (như EMAIL_ADDRESS và PHONE_NUMBER) cùng một phép biến đổi: replaceWithInfoTypeConfig, redactConfig, characterMaskConfig hoặc thay bằng định danh giả dựa trên mật mã (Tài liệu khử định danh).
curl -X POST \
"https://dlp.googleapis.com/v2/projects/$PROJECT_ID/content:deidentify" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"item": {"value": "Email dana.whitfield@example.com or call 212-555-0187."},
"inspectConfig": {
"infoTypes": [{"name": "EMAIL_ADDRESS"}, {"name": "PHONE_NUMBER"}, {"name": "PERSON_NAME"}]
},
"deidentifyConfig": {
"infoTypeTransformations": {
"transformations": [{"primitiveTransformation": {"replaceWithInfoTypeConfig": {}}}]
}
}
}'
Trường item.value trong phản hồi chứa văn bản như Email [EMAIL_ADDRESS] or call [PHONE_NUMBER]. Google khuyến nghị chỉ liệt kê các infoTypes bạn cần, vì quét theo tập mặc định sẽ làm tăng độ trễ.
Azure Language: nhận diện thực thể PII
Endpoint analyze-text của Azure trả về cả các thực thể và trường redactedText. Tham số redactionPolicies điều khiển đầu ra, chẳng hạn entityMask để dùng nhãn hoặc characterMask để dùng dấu hoa thị (Tài liệu tham chiếu REST).
curl -X POST "$AZURE_LANGUAGE_ENDPOINT/language/:analyze-text?api-version=2026-05-01" \
-H "Ocp-Apim-Subscription-Key: $AZURE_LANGUAGE_KEY" \
-H "Content-Type: application/json" \
-d '{
"kind": "PiiEntityRecognition",
"parameters": {"redactionPolicies": [{"policyKind": "entityMask"}]},
"analysisInput": {"documents": [
{"id": "1", "language": "en", "text": "My name is John Doe My phone number is 424 878 9192"}
]}
}'
Phản hồi mẫu trong tài liệu của Microsoft trả về "redactedText": "My name is [PERSON_1] My phone number is [PHONENUMBER_1]", cùng với loại, vị trí, độ dài và điểm tin cậy của từng thực thể. Azure cũng hỗ trợ phát hiện PII trong hội thoại và tài liệu, đồng thời cung cấp container để chạy mô hình trong môi trường của bạn.
Phiên bản Node.js
const res = await fetch(
`${process.env.AZURE_LANGUAGE_ENDPOINT}/language/:analyze-text?api-version=2026-05-01`,
{
method: "POST",
headers: {
"Ocp-Apim-Subscription-Key": process.env.AZURE_LANGUAGE_KEY,
"Content-Type": "application/json",
},
body: JSON.stringify({
kind: "PiiEntityRecognition",
parameters: { redactionPolicies: [{ policyKind: "entityMask" }] },
analysisInput: {
documents: [{ id: "1", language: "en", text: "Call Dana at 212-555-0187." }],
},
}),
}
);
const data = await res.json();
console.log(data.results.documents[0].redactedText);
Microsoft Presidio: ẩn PII bằng mã nguồn mở
Presidio chạy hoàn toàn trên hạ tầng của bạn. Bộ phân tích kết hợp nhận diện thực thể có tên bằng NLP, biểu thức chính quy, tổng kiểm tra và từ ngữ theo ngữ cảnh; bộ ẩn danh hóa áp dụng các toán tử như replace, mask, redact, hash và encrypt. Tài liệu nêu rõ rằng việc phát hiện tự động không thể bảo đảm tìm được tất cả dữ liệu nhạy cảm, vì vậy bạn cần lên kế hoạch bổ sung các biện pháp bảo vệ.
Chúng tôi đã cài Presidio (analyzer 2.2.365 với mô hình en_core_web_lg của spaCy) và chạy thử trên câu giả lập sau:
Xin chào, tôi là Dana Whitfield. Gửi email đến dana.whitfield@example.com hoặc gọi 212-555-0187. Số thẻ 4111 1111 1111 1111, SSN 078-05-1120. Đơn hàng #A-77231 được giao đến 42 Elm Street.
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig
text = ("Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187. "
"Card 4111 1111 1111 1111, SSN 078-05-1120. Order #A-77231 ships to 42 Elm Street.")
results = AnalyzerEngine().analyze(text=text, language="en")
for r in sorted(results, key=lambda r: r.start):
print(r.entity_type, repr(text[r.start:r.end]), round(r.score, 2))
out = AnonymizerEngine().anonymize(
text=text,
analyzer_results=results,
operators={
"DEFAULT": OperatorConfig("replace", {"new_value": "<REDACTED>"}),
"PERSON": OperatorConfig("replace", {"new_value": "<PERSON>"}),
"EMAIL_ADDRESS": OperatorConfig("replace", {"new_value": "<EMAIL>"}),
"CREDIT_CARD": OperatorConfig("mask", {"masking_char": "*", "chars_to_mask": 15, "from_end": False}),
},
)
print(out.text)
Những gì được phát hiện và những gì bị bỏ sót
| Văn bản | Được nhận diện là | Điểm | Đánh giá |
|---|---|---|---|
| Dana Whitfield | PERSON | 0.85 | Chính xác |
| dana.whitfield@example.com | EMAIL_ADDRESS | 1.0 | Chính xác |
| example.com (bên trong email) | URL | 0.5 | Nhận diện nhầm, chồng lấn với email |
| 212-555-0187 | PHONE_NUMBER | 0.4 | Chính xác nhưng độ tin cậy thấp |
| 4111 1111 1111 1111 | CREDIT_CARD | 1.0 | Chính xác (đã xác thực bằng tổng kiểm tra) |
| 078-05-1120 | PHONE_NUMBER | 0.4 | Sai loại: đây là số SSN mẫu không hợp lệ được dùng phổ biến, nên bộ nhận diện SSN đã loại bỏ |
| Elm Street | LOCATION | 0.85 | Đúng một phần; số nhà "42" vẫn còn trong văn bản |
| A-77231 (mã đơn hàng) | Không được phát hiện | Không áp dụng | Bị bỏ sót: mã định danh nghiệp vụ cần quy tắc tùy chỉnh |
Ba bài học từ lần kiểm thử nhỏ này:
- Ngưỡng phát hiện là sự đánh đổi giữa bỏ sót và nhiễu. Khi chạy lại với
score_threshold=0.5, số điện thoại (điểm 0.4) bị loại khỏi kết quả và không được ẩn. Hãy điều chỉnh ngưỡng theo từng loại thực thể, thay vì áp dụng chung cho tất cả. - Mã định danh riêng của bạn cần bộ nhận diện tùy chỉnh. Việc thêm
PatternRecognizercho\bA-\d{5}\bvới điểm 0.6 đã giúp phát hiện mã đơn hàng. Một giá trị có định dạng SSN giống thực tế (536-90-4399) được nhận diện làUS_SSNvới điểm 0.85. - Token hóa có thể khôi phục hoạt động hiệu quả. Sử dụng toán tử
encryptvới khóa 128 bit vàDeanonymizeEnginevớidecryptđã khôi phục chính xác văn bản ban đầu.
Quy trình ẩn PII cho ứng dụng LLM
Cách làm phổ biến cho sản phẩm AI là ẩn dữ liệu, gọi mô hình, rồi khôi phục những gì người dùng cần xem:
- Áp dụng quy tắc theo trường trước. Loại bỏ hoặc thay thế các trường PII đã biết trong dữ liệu có cấu trúc theo lược đồ.
- Phát hiện trong văn bản tự do. Chạy API PII hoặc Presidio trên tin nhắn, phiếu hỗ trợ và tài liệu.
- Dùng định danh giả nhất quán. Thay mỗi thực thể bằng một placeholder cố định (
<PERSON_1>) và giữ bảng ánh xạ trong dịch vụ của bạn, tuyệt đối không đưa vào prompt. - Gọi LLM bằng văn bản đã ẩn PII.
- Khôi phục các placeholder trong đầu ra của mô hình chỉ ở những nơi người dùng được phép xem giá trị thật.
- Ghi nhật ký bản đã ẩn PII cùng số lượng thực thể, thay vì bản gốc.
import os, re
from openai import OpenAI
from presidio_analyzer import AnalyzerEngine
analyzer = AnalyzerEngine()
client = OpenAI(api_key=os.environ["FLATKEY_API_KEY"], base_url="https://router.flatkey.ai/v1")
def non_overlapping(results, min_score=0.35):
kept = []
# prefer higher scores, then longer spans; drop anything overlapping a kept span
for r in sorted(results, key=lambda r: (-r.score, -(r.end - r.start))):
if r.score >= min_score and all(r.end <= k.start or r.start >= k.end for k in kept):
kept.append(r)
return sorted(kept, key=lambda r: r.start, reverse=True)
def pseudonymize(text):
mapping, counters = {}, {}
for r in non_overlapping(analyzer.analyze(text=text, language="en")):
counters[r.entity_type] = counters.get(r.entity_type, 0) + 1
token = f"<{r.entity_type}_{counters[r.entity_type]}>"
mapping[token] = text[r.start:r.end]
text = text[:r.start] + token + text[r.end:]
return text, mapping
ticket = "Customer Dana Whitfield (dana.whitfield@example.com) says order A-77231 never arrived."
safe, mapping = pseudonymize(ticket)
reply = client.chat.completions.create(
model="claude-haiku-5-5",
messages=[{"role": "user", "content": f"Draft a short apology email for this ticket:\n{safe}"}],
).choices[0].message.content
for token, value in mapping.items(): # restore only on your side
reply = reply.replace(token, value)
print(reply)
Bước non_overlapping rất quan trọng: nếu thiếu bước này, URL được phát hiện bên trong địa chỉ email sẽ làm sai quá trình thay thế. Khi có bước này, phiếu hỗ trợ dùng trong kiểm thử của chúng tôi trở thành Customer <PERSON_1> (<EMAIL_ADDRESS_1>) says order A-77231 never arrived. Mã đơn hàng vẫn được truyền qua nguyên trạng, đó là lý do bộ nhận diện tùy chỉnh ở phần trước cần có trong môi trường vận hành thực tế. Bộ ẩn danh hóa của Presidio tự xử lý các vùng chồng lấn cho bạn.
Xử lý lỗi và kiểm thử
| Rủi ro | Biện pháp giảm thiểu |
|---|---|
| API PII hết thời gian chờ hoặc trả lỗi 5xx | Chặn khi lỗi: không gửi văn bản chưa ẩn PII đến LLM; đưa vào hàng đợi và thử lại |
| Kết quả phát hiện có độ tin cậy thấp | Đặt ngưỡng theo từng thực thể; rà soát mẫu hằng tuần |
| Ngôn ngữ không được hỗ trợ | Phát hiện ngôn ngữ trước; AWS Comprehend PII chỉ hỗ trợ tiếng Anh và tiếng Tây Ban Nha |
| Mã định danh nghiệp vụ (mã đơn hàng, số tài khoản) | Bộ nhận diện bằng regex tùy chỉnh hoặc quy tắc theo trường |
| Nhận diện nhầm làm sai ý nghĩa | Danh sách cho phép đối với tên sản phẩm và địa chỉ công khai |
| PII trong đầu ra của mô hình | Chạy phát hiện trên phản hồi trước khi ghi nhật ký hoặc hiển thị cho người dùng khác |
| Nhật ký chứa dữ liệu gốc | Chỉ ghi văn bản đã ẩn PII và số lượng thực thể |
Hãy xây dựng tập kiểm thử có gán nhãn gồm các tin nhắn giả lập giống lưu lượng thực tế của bạn, bao gồm tên từ nhiều nền văn hóa, định dạng số điện thoại quốc tế và định dạng mã định danh riêng. Đo độ bao phủ phát hiện (recall) theo từng loại thực thể trước khi ra mắt và sau mỗi lần thay đổi quy tắc.
Chọn API ẩn PII
- Đã dùng AWS và văn bản là tiếng Anh hoặc tiếng Tây Ban Nha: Amazon Comprehend đơn giản và có chi phí thấp khi khối lượng nhỏ.
- Cần token hóa có thể khôi phục dưới dạng dịch vụ được quản lý, hoặc nhiều mã định danh riêng theo quốc gia: Google Sensitive Data Protection.
- Cần nhận trực tiếp văn bản đã ẩn PII, xử lý PII trong hội thoại hoặc tài liệu, hoặc triển khai container tại chỗ: Azure Language PII.
- Dữ liệu phải nằm trong mạng của bạn, hoặc bạn cần toàn quyền kiểm soát quy tắc: Presidio, kết hợp bộ nhận diện tùy chỉnh và quy trình đánh giá riêng.
Nhiều nhóm kết hợp các lựa chọn: dùng Presidio hoặc quy tắc theo trường trên luồng xử lý trực tiếp, và API được quản lý để quét tài liệu theo lô.
Vai trò của Flatkey trong quy trình này
Flatkey là cổng truy cập mô hình: một khóa và một endpoint tương thích OpenAI để truy cập nhiều LLM. Flatkey không phát hiện hay ẩn PII cho bạn, vì vậy hãy ẩn dữ liệu trong ứng dụng trước khi yêu cầu rời khỏi dịch vụ, như quy trình ở trên. Tài liệu Flatkey dành cho doanh nghiệp mô tả việc không lưu giữ nội dung yêu cầu, giúp giảm nguy cơ lộ dữ liệu nhưng không thay thế việc ẩn PII. Đọc thêm: Chính sách ẩn dữ liệu cho API AI, Quản lý khóa API an toàn, Theo dõi chi phí LLM và Danh mục mô hình Flatkey.
Câu hỏi thường gặp
API ẩn PII là gì?
Đây là API phát hiện dữ liệu cá nhân trong văn bản, như tên, email, số điện thoại và số giấy tờ định danh, rồi trả về vị trí của dữ liệu đó hoặc phiên bản văn bản đã loại bỏ, che hoặc thay thế dữ liệu.
API ẩn PII nào tốt nhất?
Điều đó phụ thuộc vào hệ thống công nghệ và dữ liệu của bạn. Amazon Comprehend phù hợp với văn bản tiếng Anh và tiếng Tây Ban Nha trên AWS, Google Sensitive Data Protection mạnh nhất về token hóa có thể khôi phục và nhiều infoTypes, Azure trả trực tiếp văn bản đã ẩn PII và chạy được trong container, còn Presidio là lựa chọn tốt nhất khi dữ liệu phải nằm trong mạng của bạn.
Có API ẩn PII miễn phí không?
Presidio là phần mềm mã nguồn mở miễn phí. Các dịch vụ được quản lý có hạn mức miễn phí: AWS Comprehend cung cấp 50K đơn vị (5M ký tự) cho mỗi API mỗi tháng trong 12 tháng, Google miễn phí 1 GiB kiểm tra đầu tiên mỗi tháng, và gói miễn phí của Azure bao gồm 5,000 bản ghi văn bản mỗi tháng.
Có nên ẩn PII trước khi gửi prompt đến ChatGPT, Claude hoặc các API LLM khác không?
Có, khi mô hình không cần giá trị thật. Hãy thay tên, thông tin liên hệ và mã định danh bằng định danh giả, gửi các placeholder đến mô hình, rồi khôi phục giá trị trong dịch vụ của bạn nếu người dùng cần.
Có thể khôi phục PII sau khi ẩn không?
Không thể khôi phục sau khi chỉ loại bỏ dữ liệu hoặc che ký tự. Token hóa hoặc dùng định danh giả dựa trên mã hóa có thể khôi phục bằng khóa hoặc bảng ánh xạ; bạn nên lưu trữ chúng an toàn và tách biệt với dữ liệu đã ẩn PII.
API phát hiện PII chính xác đến đâu?
Không API nào hoàn hảo. Trong lần kiểm thử Presidio của chúng tôi, một số điện thoại chỉ đạt điểm 0.4 và một mã đơn hàng bị bỏ sót cho đến khi chúng tôi thêm quy tắc tùy chỉnh. Hãy đo độ bao phủ phát hiện trên dữ liệu giả lập của chính bạn và chặn xử lý khi bộ phát hiện gặp lỗi.
Flatkey có ẩn PII không?
Không. Flatkey định tuyến yêu cầu đến các mô hình; việc ẩn PII cần diễn ra trong ứng dụng của bạn trước khi gửi yêu cầu.
