title: "Governance & Compliance: Bảo mật dữ liệu doanh nghiệp khi dùng public model"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 3 — AI Agents & Platform Engineering"
order: 29
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "13 phút"
tags: ["ai governance", "data compliance", "pii masking", "audit trail", "data classification", "enterprise ai", "solutions architect", "ai-native"]

Governance & Compliance: Bảo mật dữ liệu doanh nghiệp khi dùng public model

Một kỹ sư trong team bạn đang debug một lỗi khó ở module thanh toán. Để tiết kiệm thời gian, họ copy nguyên đoạn log lỗi — kèm cả vài dòng dữ liệu giao dịch mẫu có tên khách hàng, số điện thoại, số tiền — rồi dán thẳng vào ChatGPT hoặc Claude.ai để hỏi "lỗi này do đâu". AI trả lời đúng, vấn đề được giải quyết trong năm phút. Không ai để ý rằng dữ liệu khách hàng thật vừa rời khỏi biên giới hạ tầng công ty, đi qua một API bên thứ ba, và không ai trong tổ chức biết chuyện đó đã xảy ra.

Đây không phải kịch bản hiếm gặp — đó gần như là hành vi mặc định của bất kỳ kỹ sư nào chưa được yêu cầu làm khác đi. Public LLM API tiện lợi, nhanh, và không có rào cản kỹ thuật nào ngăn việc dán bất kỳ nội dung gì vào ô chat. Vấn đề là tiện lợi đó đến từ việc dữ liệu rời khỏi vòng kiểm soát của bạn: nó đi tới hạ tầng của một nhà cung cấp bên ngoài, có thể được log lại, có thể (tùy chính sách nhà cung cấp) được dùng để cải thiện model, và chắc chắn không còn nằm trong phạm vi các cam kết bảo mật mà công ty bạn đã ký với khách hàng.

Với một CRM lưu dữ liệu khách hàng — tên, số điện thoại, lịch sử giao dịch, đôi khi cả thông tin hợp đồng — rủi ro này không trừu tượng. Nó có thể vi phạm điều khoản bảo mật trong hợp đồng B2B, vi phạm quy định bảo vệ dữ liệu cá nhân, hoặc đơn giản là làm mất niềm tin của khách hàng nếu họ biết dữ liệu của họ từng được dán vào một chatbot công cộng để "hỏi cho nhanh". Vai trò của Solutions Architect ở đây không phải là cấm dùng AI — cấm chỉ đẩy hành vi xuống dưới bàn, không giải quyết được gì — mà là thiết kế một khung governance đủ rõ ràng để mỗi kỹ sư biết chính xác: dữ liệu này thuộc loại nào, và loại đó được phép đi đâu.

Vấn đề

Governance cho AI trong doanh nghiệp không phải bài toán công nghệ — nó là bài toán phân loại và kiểm soát luồng dữ liệu. Ba lỗ hổng phổ biến nhất khi tổ chức chưa có chính sách rõ ràng:

• Không có ranh giới rõ giữa "dữ liệu nào được gửi đi đâu". Khi không có quy định thành văn, mỗi kỹ sư tự quyết định theo cảm tính: "chắc không sao đâu", "chỉ là vài dòng log thôi". Cảm tính của 50 kỹ sư khác nhau tạo ra 50 tiêu chuẩn khác nhau — tức là không có tiêu chuẩn nào cả.
• Không phân biệt được mức độ nhạy cảm của dữ liệu. Mã nguồn nội bộ, tài liệu marketing công khai, và dữ liệu cá nhân của khách hàng bị đối xử như nhau — hoặc gửi đi tất cả không suy nghĩ, hoặc cấm tất cả một cách vô lý khiến năng suất bị chặn không cần thiết.
• Không có nhật ký nào ghi lại việc AI đã được dùng ở đâu, với dữ liệu gì. Khi có sự cố rò rỉ hoặc một cuộc audit tuân thủ (SOC 2, ISO 27001, hoặc yêu cầu hợp đồng từ khách hàng doanh nghiệp), tổ chức không thể trả lời câu hỏi cơ bản: "trong sáu tháng qua, dữ liệu khách hàng nào đã được gửi tới AI API bên ngoài?"

Cái khó của bài toán này là nó không thể giải quyết bằng một công cụ kỹ thuật đơn lẻ. Bạn không thể "chặn" hành vi copy-paste bằng firewall — dữ liệu đi qua trình duyệt, qua clipboard, qua một tab web hoàn toàn hợp pháp. Governance ở đây là sự kết hợp giữa chính sách rõ ràng bằng văn bản, công cụ hỗ trợ tuân thủ chính sách đó (masking, gateway kiểm soát), và cơ chế giám sát (audit log) — thiếu một trong ba, hai cái còn lại gần như vô nghĩa.

Kỹ thuật cốt lõi

Data classification: bước đầu tiên và bắt buộc trước khi hỏi "dùng AI như thế nào"

Trước khi quyết định một luồng dữ liệu có được gửi tới public LLM API hay không, tổ chức cần một hệ thống phân loại dữ liệu theo mức độ nhạy cảm — độc lập với việc có AI hay không, vì đây vốn là nguyên tắc an ninh dữ liệu cơ bản, AI chỉ là một kênh xử lý dữ liệu mới cần áp policy này vào.

flowchart TD
    A[Dữ liệu cần xử lý] --> B{Phân loại độ nhạy cảm}
    B -->|Công khai| C[Public: đã publish/không\nchứa thông tin định danh]
    B -->|Nội bộ| D[Internal: business logic,\nmã nguồn, tài liệu nội bộ]
    B -->|Nhạy cảm| E[Sensitive: PII khách hàng,\ndữ liệu tài chính, hợp đồng]
    B -->|Cực kỳ nhạy cảm| F[Restricted: dữ liệu y tế,\nthanh toán, bí mật thương mại cốt lõi]

    C --> G[Public LLM API: tự do sử dụng]
    D --> H[Public LLM API: được phép,\ncó review với code/logic nội bộ]
    E --> I{Cần dùng public model?}
    I -->|Có| J[PII masking bắt buộc\ntrước khi gửi]
    I -->|Không cần thiết| K[Ưu tiên xử lý nội bộ]
    F --> L[Model riêng/on-premise\nhoặc private cloud instance]

    J --> M[Audit log: ghi nhận request,\ndata type, người thực hiện]
    L --> M
    H --> M

Nguyên tắc cốt lõi: mức độ nhạy cảm quyết định kênh xử lý, không phải sự tiện lợi. Dữ liệu càng nhạy cảm, càng cần kiểm soát chặt — hoặc bằng cách ẩn danh hóa trước khi gửi, hoặc bằng cách không gửi ra ngoài biên giới hạ tầng công ty.

PII masking — lớp phòng thủ cho dữ liệu nhạy cảm trung bình

Với dữ liệu ở mức "Sensitive" nhưng vẫn cần dùng public model (ví dụ debug một lỗi liên quan tới dữ liệu khách hàng), giải pháp không phải "cấm" hay "cho phép vô điều kiện" mà là che dấu thông tin định danh cá nhân (PII masking) trước khi dữ liệu rời khỏi hệ thống nội bộ. Ý tưởng: thay thế giá trị PII thật bằng placeholder có cấu trúc tương tự, giữ đủ ngữ cảnh để AI vẫn hiểu và giúp ích được, nhưng không còn khả năng truy ngược về cá nhân thật.

Model riêng/on-premise cho dữ liệu cực kỳ nhạy cảm

Với dữ liệu ở mức "Restricted" — dữ liệu thanh toán, hồ sơ y tế (nếu có), bí mật thương mại cốt lõi — PII masking không đủ an toàn, vì đôi khi chính cấu trúc/ngữ cảnh dữ liệu (không chỉ tên/số điện thoại) đã là thông tin nhạy cảm. Lựa chọn kiến trúc phù hợp là:

• Model self-hosted (mở trọng số, chạy trên hạ tầng công ty quản lý, ví dụ trong VPC riêng) — dữ liệu không bao giờ rời khỏi biên giới hạ tầng do tổ chức kiểm soát.
• Private instance của nhà cung cấp cloud (offering doanh nghiệp có cam kết hợp đồng riêng về việc không dùng dữ liệu để train, có DPA — Data Processing Agreement — ký riêng) — khác về bản chất pháp lý so với việc dùng API công khai không có hợp đồng riêng.

Lựa chọn giữa hai hướng phụ thuộc vào ngân sách, năng lực vận hành hạ tầng ML nội bộ, và yêu cầu tuân thủ cụ thể (một số ngành/khách hàng yêu cầu dữ liệu không rời khỏi region cụ thể, hoặc không được xử lý bởi bên thứ ba dưới bất kỳ hình thức nào).

Audit trail — không phải để trừng phạt, mà để trả lời được câu hỏi "đã xảy ra chuyện gì"

Dù chọn kênh nào, tổ chức cần một nhật ký ghi lại: ai đã dùng AI, với loại dữ liệu gì, qua công cụ nào, vào lúc nào. Đây không phải công cụ giám sát nhân viên theo nghĩa tiêu cực — nó là điều kiện tiên quyết để trả lời được các câu hỏi bắt buộc trong audit tuân thủ, và để phát hiện sớm khi có vi phạm chính sách xảy ra thay vì biết được qua sự cố rò rỉ dữ liệu.

Thực hành

Bảng phân loại dữ liệu — dùng làm chính sách chính thức của tổ chức

Đây là bảng phân loại cụ thể, áp dụng trực tiếp cho ngữ cảnh một CRM như hệ thống hiện tại của bạn. Bảng này nên được đính kèm trong onboarding kỹ sư mới và trong wiki nội bộ, không chỉ nằm trong đầu Solutions Architect:

Prompt mẫu: script kiểm tra + PII masking trước khi gửi dữ liệu ra ngoài

Đây là một prompt cụ thể, dùng làm bước tiền xử lý bắt buộc trước khi paste dữ liệu CRM vào bất kỳ public AI tool nào — có thể tích hợp thành một bước thủ công (kỹ sư tự chạy trước khi hỏi AI) hoặc tự động hóa thành một CLI nội bộ:

Vai trò: Bạn là công cụ ẩn danh hóa dữ liệu (data anonymizer), nhiệm vụ DUY NHẤT
là thay thế thông tin định danh cá nhân (PII) trong đoạn dữ liệu dưới đây bằng
placeholder có cấu trúc tương tự, KHÔNG thay đổi bất kỳ nội dung nào khác.

Quy tắc thay thế bắt buộc:
- Tên người -> [CUSTOMER_NAME_1], [CUSTOMER_NAME_2]... (đánh số theo thứ tự
  xuất hiện, cùng một tên luôn map về cùng một số)
- Số điện thoại -> [PHONE_1], [PHONE_2]...
- Email -> [EMAIL_1], [EMAIL_2]...
- Địa chỉ cụ thể -> [ADDRESS_1], [ADDRESS_2]...
- Số CMND/CCCD/mã số thuế cá nhân -> [ID_NUMBER_1]...
- Số tài khoản ngân hàng/số thẻ -> [BANK_ACCOUNT_1]... (nếu xuất hiện, CẢNH BÁO
  rõ ràng ở cuối rằng loại dữ liệu này KHÔNG nên xử lý qua kênh này dù đã mask)
- GIỮ NGUYÊN: số tiền giao dịch, ngày tháng, trạng thái đơn hàng, mã lỗi kỹ
  thuật, cấu trúc JSON/log — vì đây là thông tin cần thiết để debug và không
  phải PII.

Đầu ra bắt buộc gồm hai phần:
1. Đoạn dữ liệu đã ẩn danh hóa, giữ nguyên format gốc.
2. Bảng mapping (chỉ lưu cục bộ, KHÔNG gửi đi cùng dữ liệu đã mask) giữa
   placeholder và giá trị gốc, để có thể map ngược kết quả AI trả về nếu cần.

Nếu phát hiện dữ liệu thuộc nhóm Restricted (password, API key, số thẻ ngân
hàng, token xác thực), DỪNG xử lý và trả về cảnh báo: "Phát hiện dữ liệu
Restricted — không được xử lý qua công cụ này, liên hệ team bảo mật."

--- DỮ LIỆU CẦN XỬ LÝ ---
{{paste đoạn log/dữ liệu cần hỏi AI vào đây}}

Snippet minh họa: middleware chặn PII lọt ra ngoài ở tầng code (phòng vệ kỹ thuật bổ sung cho chính sách)

Với các tính năng tích hợp AI ngay trong sản phẩm (ví dụ chatbot hỗ trợ nội bộ gọi LLM API để trả lời câu hỏi dựa trên dữ liệu CRM), chính sách bằng văn bản là chưa đủ — cần một lớp kiểm soát kỹ thuật chặn trước khi request rời khỏi hệ thống:

// pii-guard.service.ts — chặn/ẩn danh PII trước khi gọi public LLM API
import { Injectable, Logger } from '@nestjs/common';

interface PiiScanResult {
  containsRestrictedData: boolean;
  maskedContent: string;
  detectedTypes: string[];
}

@Injectable()
export class PiiGuardService {
  private readonly logger = new Logger(PiiGuardService.name);

  // Pattern cơ bản — trong thực tế nên bổ sung theo đặc thù dữ liệu VN
  // (số điện thoại VN, mã số thuế cá nhân...) và cân nhắc dùng NER model
  // chuyên dụng thay vì chỉ regex cho độ chính xác cao hơn.
  private readonly patterns = {
    email: /[\w.-]+@[\w.-]+\.\w+/g,
    phoneVN: /\b(0|\+84)[0-9]{9,10}\b/g,
    creditCard: /\b\d{4}[ -]?\d{4}[ -]?\d{4}[ -]?\d{4}\b/g,
    apiKeyLike: /\b(sk|pk|api|token)[-_][A-Za-z0-9]{16,}\b/gi,
  };

  scanAndMask(rawContent: string): PiiScanResult {
    const detectedTypes: string[] = [];
    let masked = rawContent;

    // LƯU Ý QUAN TRỌNG: patterns ở trên dùng flag "g"/"gi" và được lưu làm
    // field instance của một provider singleton — .test() trên regex global
    // di chuyển lastIndex sau mỗi lần gọi và KHÔNG tự reset về 0 khi có match.
    // Nếu tái sử dụng trực tiếp qua nhiều request khác nhau, lastIndex còn sót
    // lại từ request trước có thể khiến request sau bỏ sót PII/credential nằm
    // ở đầu chuỗi — một false negative nghiêm trọng cho đúng loại service có
    // vai trò an ninh. Luôn reset lastIndex = 0 trước mỗi lần .test() để đảm
    // bảo mỗi lần quét luôn bắt đầu lại từ đầu chuỗi.

    // Restricted: chặn hoàn toàn nếu phát hiện credential/secret
    this.patterns.apiKeyLike.lastIndex = 0;
    if (this.patterns.apiKeyLike.test(rawContent)) {
      this.logger.error('[PII-GUARD] Phát hiện API key/token — chặn request');
      return { containsRestrictedData: true, maskedContent: '', detectedTypes: ['credential'] };
    }
    this.patterns.creditCard.lastIndex = 0;
    if (this.patterns.creditCard.test(rawContent)) {
      this.logger.error('[PII-GUARD] Phát hiện dữ liệu thẻ thanh toán — chặn request');
      return { containsRestrictedData: true, maskedContent: '', detectedTypes: ['payment_card'] };
    }

    // Sensitive: mask thay vì chặn
    // (String.prototype.replace tự reset lastIndex trước khi quét nên các
    // dòng replace bên dưới an toàn — chỉ .test() ở trên mới cần reset thủ công)
    this.patterns.email.lastIndex = 0;
    if (this.patterns.email.test(rawContent)) {
      masked = masked.replace(this.patterns.email, '[EMAIL_MASKED]');
      detectedTypes.push('email');
    }
    this.patterns.phoneVN.lastIndex = 0;
    if (this.patterns.phoneVN.test(rawContent)) {
      masked = masked.replace(this.patterns.phoneVN, '[PHONE_MASKED]');
      detectedTypes.push('phone');
    }

    return { containsRestrictedData: false, maskedContent: masked, detectedTypes };
  }
}

// ai-gateway.interceptor.ts — bắt buộc mọi call ra public LLM API đi qua guard
// và ghi audit log, không cho phép gọi trực tiếp từ bất kỳ module nào khác
import { Injectable, ForbiddenException, Logger } from '@nestjs/common';
import { PiiGuardService } from './pii-guard.service';

@Injectable()
export class AiGatewayService {
  private readonly logger = new Logger(AiGatewayService.name);

  constructor(private readonly piiGuard: PiiGuardService) {}

  async callPublicLlm(params: {
    userId: string;
    purpose: string;
    content: string;
  }): Promise<string> {
    const scan = this.piiGuard.scanAndMask(params.content);

    if (scan.containsRestrictedData) {
      this.auditLog(params.userId, params.purpose, 'BLOCKED', scan.detectedTypes);
      throw new ForbiddenException(
        'Dữ liệu chứa thông tin Restricted (credential/thẻ thanh toán) — không thể gửi tới AI API bên ngoài.',
      );
    }

    this.auditLog(params.userId, params.purpose, 'ALLOWED_MASKED', scan.detectedTypes);

    // ... gọi LLM API thật với scan.maskedContent thay vì params.content gốc
    return `[gọi LLM với nội dung đã mask, detected: ${scan.detectedTypes.join(', ') || 'none'}]`;
  }

  private auditLog(userId: string, purpose: string, decision: string, detectedTypes: string[]) {
    // Ghi vào bảng audit riêng (không chung với application log thông thường),
    // giữ tối thiểu 12 tháng để phục vụ audit tuân thủ
    this.logger.log(
      `[AI-AUDIT] user=${userId} purpose=${purpose} decision=${decision} pii_types=${detectedTypes.join(',') || 'none'} ts=${new Date().toISOString()}`,
    );
  }
}

Điểm quan trọng của thiết kế này: mọi lời gọi tới public LLM API đều bắt buộc đi qua một gateway duy nhất (AiGatewayService), không cho phép module nghiệp vụ tự ý gọi SDK của nhà cung cấp AI trực tiếp. Đây chính là điểm kiểm soát tập trung — nếu mai này chính sách thay đổi (thêm loại PII cần mask, đổi ngưỡng chặn), bạn sửa một chỗ thay vì rà soát hàng chục nơi gọi AI rải rác trong codebase.

Cạm bẫy thường gặp

1. Nhân viên dán dữ liệu nhạy cảm vào công cụ AI công cộng qua trình duyệt, hoàn toàn ngoài tầm kiểm soát của mọi lớp guard kỹ thuật. Middleware và gateway ở trên chỉ kiểm soát được các luồng gọi AI API từ trong hệ thống — chúng không ngăn được một kỹ sư mở tab ChatGPT/Claude.ai trên trình duyệt cá nhân và dán trực tiếp log chứa dữ liệu khách hàng vào đó để "hỏi cho nhanh". Đây là lỗ hổng lớn nhất trong thực tế, vì hành vi này diễn ra hoàn toàn hợp pháp về mặt kỹ thuật (không có exploit, không cần quyền đặc biệt) và không để lại dấu vết trong hệ thống nội bộ. Giải pháp không nằm ở công nghệ mà ở đào tạo + chính sách: đào tạo bắt buộc cho mọi kỹ sư mới về bảng phân loại dữ liệu, kèm quy định rõ "dùng tài khoản AI cá nhân để xử lý dữ liệu công ty là vi phạm chính sách", và cân nhắc cấp tài khoản AI doanh nghiệp (có DPA, có audit) để kỹ sư có lựa chọn hợp lệ thay vì phải dùng "chui" tài khoản cá nhân.

2. Thiếu chính sách rõ ràng bằng văn bản, khiến mỗi cá nhân tự quyết định theo cảm tính riêng. Khi không có bảng phân loại dữ liệu chính thức được công bố và onboarding cho toàn team, mỗi kỹ sư hình thành một "cảm giác" riêng về việc gì được phép — người thì thận trọng quá mức tới mức không dám hỏi AI cả những câu vô hại, người thì thoải mái dán bất cứ thứ gì vì "chưa ai nói không được". Kết quả là rủi ro không đồng nhất trong toàn tổ chức: một phòng ban có thể tuân thủ nghiêm ngặt trong khi phòng ban khác vô tình vi phạm liên tục mà không biết. Chính sách phải được viết thành văn bản cụ thể (như bảng phân loại ở trên), phổ biến rộng, và review định kỳ — không thể dựa vào "văn hóa chung" hay "mọi người tự hiểu".

3. Coi PII masking là biện pháp an toàn tuyệt đối, bỏ qua rủi ro tái định danh (re-identification) qua ngữ cảnh. Che tên và số điện thoại không có nghĩa là dữ liệu đã hoàn toàn ẩn danh — nếu đoạn dữ liệu còn giữ đủ chi tiết đặc thù (ví dụ: "khách hàng duy nhất ở khu vực X mua gói dịch vụ Y trị giá đúng Z đồng vào ngày cụ thể"), một người biết ngữ cảnh vẫn có thể suy ra danh tính dù tên đã bị mask. Với dữ liệu có tính đặc thù cao (giao dịch giá trị lớn, khách hàng doanh nghiệp ít số lượng), cần đánh giá thêm liệu tổ hợp thông tin còn lại có tạo ra "dấu vân tay" đủ để tái định danh hay không — nếu có, biện pháp đúng là không gửi ra ngoài chứ không phải mask thêm vài trường nữa rồi coi là đủ an toàn.

🧭 Góc nhìn Solutions Architect
Nếu một khách hàng doanh nghiệp yêu cầu audit "trong sáu tháng qua, dữ liệu của chúng tôi đã được gửi tới AI API bên ngoài nào, bao nhiêu lần, ai thực hiện" — tổ chức của tôi có trả lời được bằng dữ liệu thật hay chỉ bằng lời hứa? Chính sách phân loại dữ liệu tôi đang có có đủ cụ thể để một kỹ sư mới đọc xong biết chính xác phải làm gì với một dòng log cụ thể, hay vẫn còn khoảng xám để mỗi người tự diễn giải? Và lớp guard kỹ thuật tôi xây có bao phủ được toàn bộ luồng dữ liệu ra ngoài, hay chỉ chặn được đường đi qua hệ thống mà bỏ sót đường đi qua trình duyệt cá nhân?

🔗 Bài viết liên quan

• [Bài 26] Evaluation & Monitoring: Làm sao biết Agent làm đúng hay đang "ảo giác" — cùng tư duy cần lớp kiểm soát/giám sát có hệ thống thay vì tin vào "trông có vẻ ổn" (ans-26-evaluation-monitoring-ao-giac.md)
• [Bài 20] AI Integration Patterns: Nhúng LLM/Agents vào hệ thống — thiết kế gateway tập trung cho lời gọi AI là một pattern tích hợp cụ thể nối tiếp bài này (ans-20-ai-integration-patterns-nhung-llm-agents.md)

Bài trước: LLM Ops (LLMOps) · Bài tiếp theo: Future of Engineering