Company controls
PII means personally identifiable information, such as an identity number or bank account details. Redaction replaces recognised sensitive information before it is used by supported AI features. It reduces exposure, but does not make all data anonymous.
Before using chat with company information
- Ask for the record through an available tool instead of pasting an entire personnel file.
- Include only the details needed for the question. Keep passwords, access keys and unnecessary personal information out of the conversation.
- If you administer AI Settings, review redaction and enabled features before staff use them.
- Treat AI audit access as sensitive access, even when redaction is enabled.
AI Settings controls company enablement, enabled features, provider/model, token budget and PII redaction. New settings default to AI off and redaction on. Viewing settings and AI audit records requires view_ai; updating settings requires manage_ai. Chat separately requires use_ai_chat and the AI module licence.
The chat pipeline checks enabled settings and recorded monthly usage before its provider call. These checks describe in-app chat; the public website assistant has its own platform settings and does not expose tenant tools.
What redaction does
With company redaction enabled, ordinary chat scans the message, text history and attachment text using the configured field list. Free text is checked by two detectors: the built-in patterns below, and Google Cloud Sensitive Data Protection, which adds context-based detection of names and street addresses when a company includes the person_name and address categories in its field list. If the cloud detector is unavailable the built-in patterns still apply. Structured tool results also pass through field-name and text-pattern checks before being returned to the model, and identity and bank fields are withheld from tool results before any of this runs.
The default field list is:
ssn, bank_account, salary, id_number, tax_id
Supported text categories also include credit_card, phone, email and date_of_birth. These are pattern names, not a guarantee of complete detection:
| Category | Examples of detected patterns |
|---|---|
| ssn | Dashed US SSN shape |
| bank_account | An 8–17 digit number following account, acct or a/c |
| tax_id | EIN shape or an A/P-prefixed Kenyan KRA PIN shape |
| id_number | Passport-style codes and labelled national/statutory identifiers |
| salary | Dollar-prefixed amounts or certain comma-grouped numbers |
| credit_card | Certain grouped 15–16 digit shapes |
| phone | US-style or Kenyan mobile formats |
| Email-address pattern | |
| date_of_birth | A numeric date labelled DOB, date of birth or born on |
Matches become placeholders such as [SSN REDACTED]. Unknown category names have no text detection rule. Unlabelled numbers, unusual formats, names and free-text addresses may remain; avoid supplying unnecessary sensitive information.
Structured redaction additionally masks known sensitive scalar field names, including identity numbers, bank/M-Pesa details, dates of birth and individual pay amounts. Aggregate pay-run totals and structural salary-band metadata are not treated like an individual's salary field.
UUID record identifiers are preserved so follow-up tools can address the record. Dates remain usable timestamps. Preserving an identifier is not anonymisation: an identifier linked to a person can still be personal data.
Different feature paths
- Document ingestion applies a fixed identifier-pattern scrub before chunking and embedding, independently of the chat redaction toggle. It is still pattern-based.
- Public website chat applies a fixed redaction list and uses product metadata, not authenticated tenant records.
- Payroll anomaly analysis removes recognised direct identifiers while retaining analytical amounts and record identifiers. This is pseudonymisation, not anonymous data or a promise that re-identification is impossible.
Company redaction can be disabled. That changes which raw inputs reach the provider and can be recorded. Provider keys configured through the settings services are encrypted and masked on read; company credentials can fall back to platform keys.
Audit records
AI audit records include feature, provider/model, prompt and response information, token counts, latency, status and detected redaction categories. The status enum includes success, error, rate_limited, budget_exceeded and pii_blocked; an enum value does not imply every rejection path produces a row.
The logged prompt is not a complete provider transcript. Ordinary successful chat logs the processed user message, while the budget-exceeded branch records no message text at all: it stores the fixed string "[Request rejected: monthly token budget exceeded]". Responses and analytical data can also be sensitive. Audit access must therefore be treated as access to sensitive records, even when the company's redaction toggle is on.
Actions and access
Why can a name or number still appear? Redaction recognises particular formats and field names. A name, an unusual number format or text outside those fields may remain. Do not interpret an unmasked result as approval to share it more widely.
Does turning off Tools remove company documents? No. Chat can still receive retrieved policy excerpts. The Tools switch controls live tool calls, not every source of context.
Tools execute with caller permissions and tenant context. General writes use agentic mode; streaming chat also permits approval-gated low/medium-risk self-service writes. The web Always allow this session choice can approve later calls of the same tool automatically during that session.
See Using the AI Assistant for controls and Security Overview for authentication, encryption and audit boundaries.