← Ataski · Trust & security · DPA · Subprocessors

This is the canonical English version. Native translations for DE / ES / FR / PT / RU are pending counsel sign-off.

AI Disclosure Statement — Cross-Cutting Policy

Last updated: 2026-05-12 Status: Draft for legal review; load-bearing for all AI-drafted customer outbound.

Scope

Applies to every Ataski role that generates AI-drafted communications sent to third parties on behalf of a customer. Currently affects: SDR (devon-v2), Niche SDR (anya-v0), Renewal Hunter (tom-v1), Inbound Lead Concierge (kate-v0), Account Health Watcher (nina-v0), plus any future role with outbound communication surface.

Regulatory anchors

  1. California SB 1001 (Bot Disclosure) — California Business & Professions Code §17941. Requires disclosure when a "bot" attempts to incentivize a sale or influence a vote, used online with a person in California. Email outreach falls in scope.

  2. CCPA / CPRA Notice-at-Collection — Cal. Civ. Code §1798.100(a)-(b). Requires notice at or before collection of personal information. B2B exemption expired Jan 1, 2023; business contact info from CA residents is in scope.

  3. CAN-SPAM Act (federal) — already enforced in existing SDR pipeline (verified sender, opt-out, physical address); not duplicated here.

Disclosure requirements

A. AI bot disclosure (SB 1001)

Every AI-drafted email sent to a recipient inferred as a CA resident MUST include:

B. CCPA notice-at-collection (CA recipients)

First email touch to an inferred CA recipient MUST include in footer:

C. Opt-out / unsubscribe (universal, CAN-SPAM + CCPA + CASL)

Implementation

Template hooks

templates/email/_disclosure_footer.html — new partial, conditional render: - {% if recipient.ca_resident %} → render SB 1001 + CCPA notice block - {% else %} → standard footer (CAN-SPAM + unsubscribe only)

Recipient state inference

src/ataski/compliance/recipient_state.py — new module: - infer_us_state(contact: Contact) -> str | None - Sources (priority order): explicit address > LinkedIn snippet location > firmographic HQ state > None - Returns ISO 3166-2:US code or None - is_ca_resident(contact) -> bool returns True on state==CA or None (conservative default)

Audit logging

Every outbound email row (outreach_sends table) carries: - recipient_inferred_state — for audit & compliance reporting - disclosure_variantca_full, standard, etc.

Current status (2026-05-24). Live meeting recording (Recall.ai bot-join) is paused while we finalize per-participant consent capture per docs/adrs/0068-live-recording-dispatch-gate.md. Manual transcript upload remains supported. When live recording is re-enabled, the consent-capture flow described below ships first; customers will receive 48-hour notice before re-enable. The disclosure text in this section describes the eventual flow per the ADR — it is the contract every live-recording dispatch MUST honor once the RECALL_BOT_DISPATCH_ENABLED flag flips back on.

Scope. Applies to every role that joins a live meeting on a customer's behalf — initially Meeting Coordinator (Recall.ai bot), also Board Pack Drafter's meeting pipeline when it dispatches its own bot.

Per-meeting consent capture (target state, gated behind ADR-0068). When live recording is re-enabled and ANY participant is located in a two-party-consent US state OR the participant's jurisdiction is unknown (conservative default), the operator will be required to trigger pre-meeting consent capture before the bot is dispatched:

Bot-join announcement (target state, gated behind ADR-0068). Whether or not per-meeting consent is required, the recording bot's join surface will signal AI presence:

Customer-as-controller. Per ToS §8, the legal obligation to obtain consent under the destination-state wiretap statute runs with the customer. Ataski will provide the capture mechanism when live recording is re-enabled per ADR-0068; the audit log and the export endpoint are live today. The customer's legal counsel owns the posture determination.

Tracking

Triggers to update this document