Content Categories: Granular Classification for AI Policy
Every enterprise handles dozens of data types, and not all of them carry the same risk. A marketing draft and a patient diagnosis both flow through AI prompts, but the compliance obligations attached to each are fundamentally different. Treating all AI traffic the same — either blocking everything sensitive or allowing everything through — forces organizations into a choice between productivity and protection.
Content categories eliminate that choice. By classifying AI interactions into specific domains and sub-categories, policy rules can target exactly the data types that matter for each team, department, and compliance framework. The result is governance that is precise enough to protect regulated data without blocking the routine work that drives productivity.
What Content Categories Are
A content category is a classification label applied to AI prompts and responses based on what the content is about — not just what entities it contains. Where DLP detection identifies specific data patterns (credit card numbers, Social Security numbers, medical record numbers), content categories identify the business domain and sensitivity context of the entire interaction.
The Arbitex content category system organizes AI traffic into 8 top-level domains, each with sub-categories that reflect how enterprises actually segment their data handling obligations:
Financial Data — covering transaction records, account information, investment analysis, and financial reporting. Sub-categories distinguish between customer financial PII, internal financial projections, trading activity, and regulatory filings.
Healthcare & Clinical — covering patient records, clinical documentation, research data, and pharmaceutical information. Sub-categories separate PHI from clinical research notes, pharmacovigilance reports, and de-identified datasets.
Legal & Compliance — covering contracts, litigation materials, regulatory correspondence, and compliance documentation. Sub-categories distinguish privileged communications from routine compliance filings.
Human Resources — covering employee records, compensation data, performance reviews, and recruitment materials. Sub-categories separate personally identifiable employee data from aggregated workforce analytics.
Engineering & Technical — covering source code, architecture documents, infrastructure configurations, and technical specifications. Sub-categories distinguish proprietary algorithms from general technical discussion.
Sales & Customer — covering customer communications, pricing proposals, competitive analysis, and account data. Sub-categories separate customer PII from market intelligence.
Executive & Strategic — covering board materials, M&A activity, strategic planning, and financial forecasts. Sub-categories flag material nonpublic information distinct from general business planning.
Government & Defense — covering controlled unclassified information, export-controlled technical data, classified program references, and government contract materials. Sub-categories align with CMMC domains and ITAR categories.
Across these 8 domains, 27 sub-categories provide the granularity that compliance teams need to write policies matching their organization’s actual data handling requirements.
How Categories Integrate with the Policy Engine
Content categories are not standalone labels — they are first-class conditions in the policy engine. Every policy rule can target specific categories, and enforcement actions vary by category.
A healthcare organization might configure policies like: PHI sub-category triggers block enforcement when the destination is any external model, while de-identified clinical research sub-category triggers log-and-allow for approved research models. Both fall under the Healthcare & Clinical domain, but the enforcement is different because the compliance obligation is different.
A defense contractor might allow Engineering & Technical content to reach approved AI endpoints for code review assistance, while Government & Defense content with the CUI sub-category triggers block enforcement regardless of the destination model.
This is the difference between governance that works and governance that gets bypassed. When policies match the actual data handling requirements of each team, users do not need to work around them — the rules make sense for what they are doing.
Keyword-Based Detection at Tier 1
Content category assignment starts at the first tier of the DLP pipeline. Keyword-based detection runs compiled pattern sets that match domain-specific terminology, document markers, and contextual indicators. This is not entity extraction — it is domain classification based on the vocabulary and structure of the content.
Financial content is identified by terms like “revenue forecast,” “EBITDA,” “trading position,” and “quarterly guidance” — language that signals the business domain without necessarily containing specific regulated data points. Healthcare content is identified by clinical terminology patterns, medication references, and diagnostic language.
Keyword-based classification runs in microseconds, providing a category assignment before the slower NER and semantic tiers process the content. Early category assignment allows the policy engine to make routing decisions quickly — if a category is unconditionally blocked for the requesting user, there is no reason to wait for deeper analysis.
Admin UI for Custom Categories
The 8 domains and 27 sub-categories ship as defaults, but every organization’s data landscape is different. The admin portal provides full CRUD for content categories: create custom domains, define sub-categories with keyword sets, and link them to detection rules and policy conditions.
A pharmaceutical company might add a “Clinical Trial Data” sub-category under Healthcare & Clinical with keyword patterns specific to their trial identifiers, protocol references, and site codes. A financial institution might split the Financial Data domain into separate sub-categories for retail banking, wealth management, and institutional trading — each with different policy enforcement.
Custom categories inherit the same policy engine integration as built-in categories. Once defined, they appear in the policy rule builder as targeting conditions, and enforcement actions can be configured per category just like any default sub-category.
Why This Matters for Compliance Teams
Compliance teams managing AI governance across a large organization face a fundamental challenge: different departments handle different data types under different regulatory obligations, and a single set of rules cannot adequately govern all of them.
Content categories solve this by giving compliance teams the vocabulary to express their requirements precisely. Instead of writing a policy that says “block all sensitive data,” they can write policies that say “block PHI for external models, redact customer financial PII for approved models, and log engineering content for audit review.” Each rule targets a specific category, applies a specific enforcement action, and maps to a specific compliance framework requirement.
The audit trail captures category assignments alongside enforcement actions. When an auditor asks how the organization governs clinical data in AI workflows versus financial data, the answer is documented in the policy configuration and evidenced in the audit log — not described in a policy document that may or may not reflect actual system behavior.
From Classification to Confidence
Content categories are not a replacement for DLP detection — they are a layer on top of it. A prompt might contain no specific regulated data entities but still fall into a sensitive business domain. A strategic planning discussion that references no account numbers, no patient names, and no classified markings is still material nonpublic information if it describes an unannounced acquisition.
Category-level classification catches what entity-level detection cannot: the business context that determines whether content is sensitive. Combined with the DLP pipeline’s pattern matching, entity recognition, and semantic classification, content categories provide the governance granularity that regulated enterprises need to use AI confidently across every department and data type.
The alternative is what most organizations have today — a single set of rules applied uniformly to all AI traffic, with the inevitable result that the rules are either too restrictive for productivity or too permissive for compliance. Content categories make that tradeoff unnecessary.
Related
- Policy Engine — Rules-based AI governance for every request
- DLP Protection — Inspect every AI prompt for sensitive data
- Compliance Frameworks — Pre-built regulatory policy packs for every framework