Last updated: 2026-07-14 Status: Draft for legal review; load-bearing for all AI-drafted customer outbound.
This policy applies categorically, to every role that generates AI-drafted communications sent to third parties on a customer's behalf — by whatever channel (§C and the channel trigger below) — and to every such role Ataski ships in the future. It attaches to the capability, not to a list of roles.
A role is in scope the moment it can put an AI-drafted message in front of someone who is not the customer. No role is out of scope because it is new, renamed, merged into another role, or absent from an enumeration.
Why there is no list here. This document previously enumerated the roles in scope. Every enumeration in our legal and compliance corpus had rotted by 2026-07-14: this one still named a role that had been withdrawn from the Service, and one that was retired two months earlier and must never be reintroduced. A stale scope list in a document that governs our SB-1001 / CCPA notice-at-collection footers is not a typo — it is a defective compliance control, because it under-describes what the footers must cover. The categorical scope above cannot go stale.
The roles the Service currently offers are published on the workforce catalog (the canonical registry,
src/ataski/web/role_registry.py); the roles that Process personal data are named in the DPA, which derives that roster from the same registry rather than from prose.
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.
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.
CAN-SPAM Act (federal) — already enforced in existing SDR pipeline (verified sender, opt-out, physical address); not duplicated here.
Every AI-drafted email sent to a recipient inferred as a CA resident MUST include:
First email touch to an inferred CA recipient MUST include in footer:
/privacy/optout?email=<urlencoded>)/privacy/optout endpoint with pre-filled recipient contextList-Unsubscribe + List-Unsubscribe-Post headers on ALL sales-role transports (Postmark, BYO Gmail, BYO Outlook, BYO SMTP — ataski.compliance.one_click_unsubscribe mints the signed per-send URL; POST /unsubscribe/one-click/{token} suppresses on first click) + the visible footer linktemplates/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)
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)
Every outbound email row (outreach_sends table) carries:
- recipient_inferred_state — for audit & compliance reporting
- disclosure_variant — ca_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:
src/ataski/compliance/wiretap_state_gate.py: CA, CT, DE, FL,
IL, KS, MD, MA, MI, MT, NV, NH, NJ, NY, OR, PA, VT, WA.src/ataski/meeting_consent_flow.py):
evaluate participants → send per-participant consent-request
emails → record per-participant meeting_consents rows → only
then dispatch the recording bot. The customer-facing
/meetings/consent route, the consent-token module, the Postmark
email template, and the operator UI ship before the
RECALL_BOT_DISPATCH_ENABLED flag flips back on.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:
<Tenant entity> Recap Bot - AI note-taker
(bot_display_name)."<Entity> Recap Bot is joining to draft a meeting recap
with AI assistance. If you do not consent to being recorded,
please object now or leave the meeting."
(bot_join_announcement_text).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.
tests/test_compliance_disclosure.py — asserts CA recipient outbound has both SB 1001 and CCPA footer text present