An ordinary social conversation
“Anyone trying the new lunch spot on Friday?”
This does not describe an actionable compliance event. It should leave the compliance-processing workflow according to configured filtering and retention behavior.
Security & privacy / The design principles
Compliance intelligence without indiscriminate surveillance.
Sentia is designed around explicit permissions, relevant-data processing, controlled AI workflows, and transparent evidence handling.
Intended platform controls · Implementation in development
Privacy by architecture
A useful signal starts with a clear boundary.
Compliance-relevant processing should be intentional and limited. An integration is not permission to inspect everything it could technically expose.
Sentia’s intended model begins with explicitly authorized sources and least-privilege permissions. Organizations select the channels and collection boundaries relevant to their compliance workflows; private conversations are excluded by default.
Data minimization, sensitive-information protection, and organizational visibility are design requirements. Their effectiveness depends on implementation, configuration, and ongoing review.
- Explicit authorization
- Approve the source and scope before collecting relevant events.
- Collection boundaries
- Make channel selection, source permissions, and purpose understandable and configurable.
- Minimized context
- Reduce unnecessary sensitive content before downstream processing wherever technically feasible.
- Organizational control
- Define permissions, review requirements, and follow-up behavior rather than relying on unrestricted automation.
The processing pipeline
Six stages. A controlled path through context.
A preliminary relevance check is one part of the design. It cannot, by itself, guarantee privacy or establish what is transmitted, stored, or retained.
The proposed architecture distinguishes collection permissions, relevance, minimization, classification, mapping, and workflow handling. Those boundaries allow each stage to be assessed on its own responsibilities and limitations.
AI classification should receive only permitted context after minimization wherever technically feasible. Its output can suggest a workflow; it should not be treated as independently established truth.
PERMITTED INPUT → CONTROLLED OUTPUTIntended controls
- 01
Authorized message or system event
Collection begins inside explicitly approved sources and scopes. Private conversations are excluded by default in the intended design.
- 02
Preliminary relevance filtering
Configurable rules identify potentially relevant operational events. Non-relevant content leaves the compliance workflow according to configured filtering and retention behavior.
- 03
Sensitive data detection & minimization
Identify sensitive fields and redact or minimize them before downstream AI processing wherever technically feasible. Detection and redaction may have limitations.
↓ MINIMIZED CONTEXT BEFORE DOWNSTREAM AI, WHERE TECHNICALLY FEASIBLE - 04
AI intent classification
Classify the permitted, minimized context to determine whether it may describe an actionable compliance event. Uncertain output should be escalated rather than treated as established fact.
- 05
Compliance context mapping
Associate candidate events with applicable operational requirements and proposed control mappings. A suggested mapping remains subject to review.
- 06
Controlled task or evidence workflow
Generate or update a scoped task or evidence record according to organizational permissions, verification policies, follow-up limits, and human approval requirements.
This diagram describes design intent. It does not assert that all content is never transmitted or retained, or that filtering alone guarantees privacy.
What should enter the workflow?
Operational relevance is a decision, not a blanket license.
Relevance rules distinguish operational instructions from social conversation within permitted sources. Processing and retention follow the organization’s configured boundaries and review policies.
An access-related instruction
“Alex is leaving. Please review cloud access and revoke the approved permissions.”
This may indicate an offboarding access-review requirement. It is a candidate for a scoped task and subsequent verification—not evidence that access has already been revoked.
Evidence security
Preserve provenance. Be precise about assurance.
A reviewable evidence trail needs clear sources, limited access, meaningful verification states, and an understandable lifecycle.
- Source references
- Retain enough provenance to identify the originating event and understand the source’s authority and scope.
- Access permissions
- Keep evidence access within the organization’s approved permission model, including who can inspect or review a record.
- Evidence metadata
- Capture relevant context and timestamps without treating the collection of metadata as proof of the underlying activity.
- Verification records
- Distinguish what an owner reported from what an authoritative connected system can substantiate.
- Cryptographic hashes
- Use integrity digests to support change detection. A hash does not establish the truth of the original event or imply immutable storage.
- Audit trails
- Preserve the relevant workflow and review history, subject to implementation and configured access and retention controls.
- Retention policies
- Define collection and retention behavior explicitly. Filtering does not establish that content was never transmitted or stored.
- Human review
- Keep source suitability, completeness, exceptions, and evidence acceptance subject to an appropriate reviewer.
AI governance
Defined permissions. Visible reasoning. Human judgment.
AI assistance should help people coordinate work while preserving the organization’s control over the process.
Limited processing scope
Use explicitly authorized sources and purpose-bound context. More available data should not automatically mean more permitted processing.
Explicit automation permissions
Configure which tasks and follow-ups may be generated, the channels that may be used, and the decisions that require approval.
Explainable provenance
Keep the source references and relevant context attached to suggestions so reviewers can inspect the basis of the workflow.
Escalation on uncertainty
Preserve ambiguous classifications, missing records, and conflicting inputs. Route them to authorized people instead of silently assigning a successful outcome.
Controlled follow-up behavior
Respect approved routing, reminder limits, and escalation rules. Human oversight should remain available throughout the workflow.
Security transparency
Design intent is not an assurance claim.
Understand the platform’s development status, intended safeguards, and approach to independent assurance before deciding what your organization needs.
Start with your requirements
Discuss your authorized sources, access boundaries, and evidence requirements with our team. The access request form asks for business contact information, not business-system credentials or employee conversations.
Privacy and workflow safeguards
Authorized access, least privilege, minimization, controlled classification, evidence handling, and human oversight describe the planned architecture. Exact protections and retention behavior depend on implementation and configuration.
Independent assessment
No certification, penetration-test result, specific encryption implementation, compliance attestation, or third-party audit result is asserted here. SOC 2 workflow focus and ISO 27001 alignment are product directions, not certification claims.
Less friction. More assurance.
Let’s talk about your security requirements.
Contact the team to discuss access boundaries, processing expectations, evidence handling, and the intended architecture.