Security & Human Governance
AI proposes. Identity, consent, policy, and people govern the action.
ChatPress is designed for systems that can influence real customer relationships. Security therefore includes more than model output: it includes who may act, which knowledge is approved, what the customer has permitted, who reviewed the decision, what actually happened, and which evidence remains.
Governed action boundary
Policy
Evidence
Review
Audit
Control model
Security controls apply at every step of the customer journey.
The customer timeline carries identity, permission, ownership, and evidence alongside marketing, workflow, commerce, and outcomes. A channel message can proceed only when the applicable controls are satisfied.
Identity & workspace boundary
Every deployment requires a defined workspace, accountable users, scoped roles, and an explicit boundary around which customer and business data may be resolved.
Consent & action eligibility
Channel permission, purpose, quiet hours, entitlement, exclusions, and applicable deployment rules are evaluated before an action is eligible.
Versioned knowledge & provenance
Policies, offers, claims, scripts, curriculum, and review rubrics are versioned so an action can be related to the source context used at the time.
Human review & exception handling
High-impact or uncertain actions can require approval, adjustment, reassignment, rejection, or escalation to an accountable operator.
Evidence-bearing events
Every important action should answer seven questions.
1. Who?
Which customer identity, operator, service account, model, or external system participated?
2. In which boundary?
Which organization, workspace, deployment, channel account, and environment applied?
3. From which source?
Which version of knowledge, policy, prompt, offer, rubric, or customer state informed the decision?
4. Was it permitted?
Which consent, eligibility, entitlement, cooldown, role, or exception rule allowed—or blocked—the action?
5. Who reviewed it?
Was the action automatic within an approved boundary, or approved, changed, rejected, or escalated by a named human?
6. What executed?
Which message, workflow, order, entitlement, service step, credential, or silence decision actually occurred?
7. What outcome followed?
Was the outcome delivered, attended, completed, paid, renewed, corrected, deleted, or still unresolved—and what evidence supports it?
AI governance
The model proposes; authorized people and business rules decide.
ChatPress applies reviewable decisions and deployment rules. Contacting a person, changing an entitlement, issuing a credential, publishing a claim, or declaring an outcome requires the applicable permission and authorized workflow.
Approved-source grounding
Generated actions use approved, versioned business knowledge with a traceable source and reviewer.
Risk-based review
A deployment can define which actions remain inside an approved automation boundary and which require a human decision.
Uncertainty and exceptions
Missing context, conflicting identity, unclear consent, unusual commercial terms, or sensitive cases pause the workflow and route it to the assigned owner.
No invented outcomes
Message opens and clicks record engagement. Purchases, attendance, and certifications each require their own verified business event.
Responsibility boundaries
Controls only work when ownership is explicit.
Baoqi Smart / ChatPress
Own the shared product control design, workspace and role model, deployment configuration boundaries, event and evidence primitives, provider inventory, security roadmap, and escalation path for platform issues.
Deployment operator
Own the lawful basis and consent for customer data, approved source knowledge, staff access, review policies, channel accounts, business exceptions, service delivery, and customer-facing notices.
External providers
Messaging, model, payment, cloud, identity, credential, and analytics providers remain separate systems with their own availability, security, data-processing, and regional terms.
Deployment control checklist
Controls are configured and evidenced per deployment.
A deployment review should cover the actual data, providers, regions, channels, customer rights, and workflow impact involved. Requirements vary; a generic checkbox cannot replace that review.
Data map & minimization
Document required data fields, purpose, source, destination, sensitive classes, and whether the journey can operate with less data.
Access & secrets
Define roles, least-privilege access, service-account ownership, secret handling, environment separation, and access-review cadence.
Retention & deletion
Set retention, export, correction, deletion, legal-hold, and evidence-preservation rules appropriate to the deployment and jurisdiction.
Backup, recovery & incident path
Document providers, backup scope, restore responsibility, operational contacts, escalation thresholds, communication ownership, and test evidence.
Assurance posture
We publish certification and compliance status only for independently completed, documented scope.
SOC 2, ISO 27001, HIPAA, PCI DSS, and other certification or regulated-industry status will be listed only after independent completion and evidence for the applicable scope.
At the current stage, the security program is organized around documented control ownership, least privilege, provider and data-flow visibility, evidence preservation, backup and incident responsibilities, deployment-specific consent, and a staged assurance roadmap.
Security architecture, data flows, provider scope, control ownership, open gaps, and remediation plans are reviewed during the appropriate customer or investor diligence process. Regional hosting and data-residency requirements are confirmed for each deployment.
Security review
Map the data and decision boundary before deployment.
Tell us which journey, channels, regions, customer data, providers, and actions are in scope. We will identify the control owners, evidence, open questions, and human review points.