Overview
Data classification and grading identifies sensitive information carried by fields in Catalog (such as phone numbers, ID card numbers, email addresses, and bank card numbers), and drives the unified implementation of downstream policies such as column-level masking, row-level filtering, and access auditing based on the identification results. DataBuddy provides two types of capabilities, supported by the same set of sensitive tags and masking policy metadata:
Writing sensitive identification results to Skill: After AI identifies sensitive data on Catalog fields, Skill writes the identification conclusions (sensitive tags, confidence levels, and recommended masking policies) back to the corresponding fields as the basis for column-level masking.
Masking Policy Management Skill: Used to create masking policies based on business semantics in Buddy conversations, maintain mappings from user groups to masking methods, and associate policies with one or more sensitive tags.
Note:
In the current version, data classification and grading is provided as a Skill interface and is invoked by the Buddy agent and the AI identification pipeline. A visual Classification and Grading Management page will be launched in a future iteration, and this document focuses on Skill behavior. The query experience and field binding method after a masking policy is created are consistent with column-level masking. For details, see Column-Level Access Control.
Core Concepts
Concept | Description |
Sensitive Tag | A metadata tag that describes the data sensitivity type of a field, such as PII/Phone Number, PII/ID Card Number, and Finance/Bank Card Number. All tags share the same tenant-level namespace. |
Masking Policy | A collection of masking methods applied by user group when a field is read. A masking policy can be associated with multiple sensitive tags. |
Masking Method | Built-in field value transformation methods (such as masking, Hash, and retaining the first/last digits). Masking methods take effect by user group, and unmatched user groups return plaintext. |
Sensitive Identification Result | Sensitive determination given by the AI model for a Catalog field, including sensitive tags, confidence, and the recommended masking policy to bind. |
Field Binding | Action of associating a masking policy with a specific Catalog → Schema → Table → Column. A field can be bound to only one masking policy at a time. |
Prerequisites
The current account can now log in to the workspace and has permission to use Buddy.
To maintain masking policies, the current account must have policy management permissions in the target Catalog (by default, Workspace administrators and data security administrators).
To write sensitive identification results, the caller must have the Owner or Manage permission on the target Table. For permission semantics, refer to Members and Permission Management. A naming convention for sensitive tags in this workspace has been established (for example, unified prefixes such as PII/, Finance/, and Internal/) to avoid multiple tags with the same semantic meaning.
Use Limits
Limit | Description |
Applicable Scope | Sensitive tags and masking policies are shared across all catalogs within the current tenant + current region. |
Field Binding Relationship | A field can be bound to only one masking policy at a time. If written multiple times, the latest result takes effect. |
User Group Coverage | Masking methods take effect by user group. User groups not configured in the policy return plaintext when querying this field. |
Masking Method Scope | Currently, system built-in masking methods are provided, and custom masking functions are not supported yet. |
Invocation Method | In the current version, classification and grading results can only be maintained and written through the Skill API. The visual management page will be launched later. |
Usage
Maintaining Desensitization Policies: Desensitization Policy Management Skill
The Masking Policy Management Skill is used in Buddy conversations to:
Create, update, and delete masking policies.
Maintain the associated user groups and masking methods of the masking policy.
Associate a masking policy with one or more sensitive tags.
Typical call semantics are as follows (the actual Skill name and parameters are subject to the version exposed by Buddy):
Create a masking policy for "Customer Phone Number":
- Associate sensitive tag: PII/Phone Number.
- User group "Customer Service Tier 1": Keep the first and last 3 characters and replace the rest with *.
- User group "Data Analyst": Return only the Hash result.
- Other user groups: Return plaintext by default.
After receiving the intent, Buddy calls the Masking Policy Management Skill to create a policy and return the policy ID, which can be referenced when sensitive identification results are written later.
Note:
Once a policy is created, it shares the same semantics as column-level masking. For subsequent field binding on the Catalog table details page and runtime masking behavior during SQL / Notebook queries, see Column-Level Permission Control.
Writing Sensitive Identification Results: Sensitive Identification Result Writing Skill
The Sensitive Identification Result Writing Skill is used to persist the sensitive identification output from AI models into Catalog field metadata. Typical flow:
1. The AI identification pipeline scans the target fields in Catalog to obtain candidate sensitive tags and confidence levels.
2. The business side (Buddy or an external process) filters trusted identification results based on a threshold.
3. Call the Sensitive Identification Result Writing Skill to write the following information back to the field:
Sensitive tag (such as PII/Phone Number).
Confidence level (optional, for auditing and subsequent review).
Recommended masking policy (optional, can directly reference the policy ID created by the Masking Policy Management Skill).
4. After a successful write, downstream column-level masking, row-level filtering, and access auditing logic take effect based on the latest sensitive tags and masking policies.
Calling convention recommendations:
Convention | Recommended practice |
Tag naming | Use the planned tag namespace of the workspace consistently to avoid the coexistence of phone / mobile / PII/Phone Number. |
Write idempotency | When the same field is written to multiple times, the tags and policy from the latest write take effect. To trace historical results, record call logs on the caller side. |
Exception handling | If a write fails, the caller should retry or manually review it to avoid silently losing sensitive identification conclusions. |
FAQs
Q: What should I do if the sensitivity tags identified by AI are not highly reliable?
A: It is recommended that the business side filter sensitive identification results by confidence threshold before writing them to the Skill, and write only tags that meet the threshold. Low-confidence results can go through a manual review process and be written after the review is passed.
Q: What happens if new identification results are written to a field that is already bound to a desensitization policy?
A: The latest write takes precedence, and the original binding relationship will be overwritten. If the business needs to retain historical binding records, record the change log on the caller side.
Q: What is returned when a user group queries a field that is not covered by the desensitization policy?
A: Plaintext is returned by default. To enforce masking for uncovered user groups, explicitly add the user groups to the policy and specify the masking method.
Q: When will the visualized classification and grading management page be available?
A: The current version only provides the Skill API. The visual page is planned for a future iteration. Before the management page is launched, it is recommended to use Buddy conversations or automated processes to call the Skill for unified tag and policy maintenance.
References
Column-level permission control