Data Processing Addendum

1. Roles of the parties

1.1 Allocation of roles. This Clause reflects, and does not vary, Privacy Policy Section 2.

• Customer is the controller of End User Personal Data. In answering Customer's calls, exchanging text messages, operating Customer's website chat, and handling Customer's reviews, Provider processes the personal data of End Users on Customer's behalf. Customer determines the purposes and means of that processing and is responsible for the lawful basis for it, for the notices given to End Users, and for the consents obtained from them, including the recording and artificial-intelligence disclosure obligations set out in Terms Section 7. Provider processes End User Personal Data as Customer's processor.
• Provider is the controller of Customer's own account data. Customer's business contact details, login and session records, billing and plan history, support correspondence, records of the documents Customer accepted and when, and Provider's logs of account usage are processed by Provider as controller under the Privacy Policy. This Addendum does not make Provider a processor in respect of that data.
• Website visitors. Personal data of visitors to Provider's website is processed by Provider as controller and is outside the scope of this Addendum.

1.2 Records retained by Provider as controller. Certain records survive termination of Customer's account and are retained for Provider's own compliance and legal-defense purposes rather than on Customer's instruction, including the consent evidence ledger, the do-not-contact and unsubscribe suppression lists, the carrier traffic ledger, and the records of assent to Provider's published documents; Clause 9.3 states the full list. In respect of those records Provider acts at least in part as a controller in its own right, and requests concerning them are directed to Provider under Clause 13.5.

1.3 Effect. This Addendum applies to the processing of End User Personal Data that Provider carries out for Customer under the Terms. It does not extend the scope of the Service and does not authorize Customer to submit to Provider any category of data that the Terms exclude, including protected health information and, on processing paths governed by the GDPR or UK GDPR, Article 9 special-category data unless Provider and Customer have agreed in writing and implemented a dedicated lawful workflow, as provided in Terms Section 10 and Privacy Policy Section 3.

2. Subject matter, duration, nature and purpose

2.1 Subject matter. Provider's provision of the Service to Customer, comprising an artificial intelligence receptionist and front desk that answers Customer's telephone, text, website chat and connected messaging channels, transcribes and summarizes interactions, books appointments, collects intake through secure links and hosted forms, and, where Customer enables those features, drafts and sends replies to Customer's reviews.

2.2 Duration. From the commencement of Customer's subscription until the later of (a) fourteen days after termination, when Customer Data is deleted under Clause 9, and (b) the expiry of the retention periods stated in Clause 9.3 for the categories that survive that deletion.

2.3 Nature of the processing. Collection, recording, transcription, optical character recognition, document text extraction, storage, structuring, retrieval, analysis and summarization, automated generation of replies and messages, transmission to the recipients Customer configures, secure deletion, and backup.

2.4 Purpose. To provide, operate, secure, support and improve the Service for Customer, and for no other purpose except as Clause 3 permits or applicable law requires.

2.5 Categories of data subjects. Customer's callers, texters, web chat visitors, form respondents, reviewers and email correspondents; persons recorded in the Service by Customer's personnel; and Customer's own owners and personnel to the extent their details appear in the data Customer submits.

2.6 Categories of personal data. Telephone numbers and caller line identification; recordings and transcripts of calls; the content of text messages and web chat; the content of reviews and of inbound and outbound email that Customer asks Provider to manage; voicemails and messages; names, email addresses and appointment details; documents Customer uploads through the dashboard, which may contain End User Personal Data; documents, photographs and video provided through a secure intake link or a hosted form; the answers an End User types into a hosted form; interaction metadata (time, duration, channel, outcome), including, for secure intake uploads, internet protocol address and device or browser information; consent and opt-out records; and the free-text notes and tags the Service maintains in respect of a contact.

2.7 Legally defined special-category data and ordinary confidential documents. Ordinary confidential professional documents, including legal, accounting and tax documents, are supported through secure intake and are not prohibited merely because they are confidential. They are distinct from protected health information and from special-category data under GDPR Article 9. Protected health information is prohibited. Where the GDPR or UK GDPR applies, Article 9 special-category data is prohibited unless Provider and Customer have agreed in writing and implemented a dedicated lawful workflow; no such workflow is included in the standard Service. Terms Section 10 permits non-clinical wellness businesses to use the Service, and an End User of such a business may volunteer wellness-related details that are not protected health information under HIPAA. Customer remains responsible for compliance with the rules applicable to its own vertical in respect of such content. Beyond the structured-identifier filter described in Clause 5.3(b), Provider does not detect, screen, filter or redact content that an End User volunteers, and nothing in this Clause constitutes a representation or warranty by Provider that such content is identified, excluded or removed.

2.8 Data whose submission the Terms prohibit. Where Customer submits, or permits the submission of, data whose submission Terms Section 10 prohibits, including protected health information and, where the GDPR or UK GDPR applies, Article 9 special-category data for which no dedicated lawful workflow has been agreed and implemented, Provider has no liability under this Addendum in respect of that data to the extent that the claim arises from its prohibited submission, and Customer indemnifies Provider in respect of it as provided in Terms Section 17. This Clause does not remove such data from the scope of this Addendum and does not vary the acknowledgement in Clause 2.7.

3. Processing on documented instructions

3.1 Documented instructions. Provider processes End User Personal Data only on Customer's documented instructions. Customer's documented instructions consist of, and are limited to: the Terms and this Addendum; the configuration Customer establishes and maintains in the Service, which constitutes the operative instruction set (hours, services, pricing, scripts, frequently asked questions, routing and escalation rules, connected channels, enabled features, retention and deletion elections, and the forms and intake links Customer publishes); the actions Customer and its personnel take in the dashboard; and any further instruction Customer gives in writing to the address in Clause 13.5.

3.2 Instructions outside the configuration. Where Customer requires processing that the configuration cannot express, Customer shall request it in writing. Provider may charge for work beyond the scope of the Service, and may decline an instruction that it cannot perform, that would require a change to the Service, or that Provider considers would place it in breach of applicable law.

3.3 Unlawful instruction. Provider shall inform Customer if, in Provider's opinion, an instruction infringes applicable Data Protection Laws, and may suspend the affected processing until the matter is resolved. This Clause imposes a duty to inform and does not oblige Provider to monitor Customer's compliance.

3.4 Processing required by law. Where a law binding on Provider requires processing beyond Customer's instructions, Provider shall inform Customer before carrying out that processing, unless that law prohibits such notification.

3.5 Processing not derived from Customer's configuration. The following processing is carried out in addition to the instructions described in Clause 3.1 and is disclosed here rather than treated as instructed processing:

• Provider uses Customer's business information and interaction history to build, tune and improve Customer's own agent, which is the Service.
• Provider uses transcripts and related data internally to secure, debug and improve the Service, using de-identified data wherever practicable.
• Provider does not sell personal data, does not disclose one customer's transcripts to another customer, and does not use Customer Content, Customer Data or End User Personal Data to train third-party or publicly available artificial intelligence models. This undertaking corresponds to Privacy Policy Section 4. It is given in respect of Provider's own processing and of Provider's configuration of Sub-processor settings; Provider does not represent that it audits a Sub-processor's adherence to that configuration.

3.6 Processing in accordance with instructions. Processing that Provider carries out in accordance with Customer's documented instructions, as those instructions are defined in Clause 3.1, is not a breach by Provider of this Addendum. Provider is not liable to Customer for any claim, including a claim brought by an End User or other third party, to the extent that the claim arises from Provider's processing of End User Personal Data in accordance with Customer's documented instructions.

3.7 De-identified and aggregated data. Provider may create de-identified and aggregated data from the processing described in this Addendum, and may retain and use it to secure, operate, analyze and improve the Service. Data is de-identified for the purposes of this Clause only where it no longer identifies, and cannot reasonably be used to identify, any natural person. Provider shall not attempt to re-identify any person from such data and shall not instruct or authorize a Sub-processor to do so. This Clause corresponds to the internal improvement use disclosed in Clause 3.5 and in Privacy Policy Section 4, and does not authorize any disclosure that Clause 3.5 excludes. Data that has been de-identified in accordance with this Clause ceases to be End User Personal Data and falls outside this Addendum. That exit does not affect the prohibitions on re-identification stated in this Clause, which survive it.

4. Confidentiality

4.1 Provider treats End User Personal Data as confidential and does not disclose it except to the persons and Sub-processors described in this Addendum or as required by law or legal process.

4.2 Persons with access. Access to production End User Personal Data is granted on a need-to-know basis, is limited by role within the Service, and administrative access through the Service is logged as described in Clause 5.2. Direct database and host access is not separately logged.

4.3 Future personnel. Before any employee, contractor or agent of Provider is granted access to End User Personal Data, that person shall be bound by a written obligation of confidentiality that survives the termination of their engagement and shall first receive security awareness training in accordance with Section 5 of Provider's Written Information Security Program.

5. Security measures

5.1 Security program. Provider's technical and organizational measures are set out in its Written Information Security Program (the "WISP"), an internal governance document maintained by Provider's Qualified Individual and benchmarked against 16 CFR 314.4. Provider maintains the WISP, reviews it at least annually and on the trigger events it identifies, and shall provide a current summary of it on request under Clause 10. Provider does not publish the WISP itself, which identifies hosts, data volumes and instance identifiers.

5.2 Measures in force. Annex 2 states the technical and organizational measures in force. In summary, they comprise: encryption in transit by TLS at the edge with HSTS preload, a modern cipher suite and a full security header set; encryption at rest of the primary database volume holding transcripts and contacts using a key managed by the hosting provider's key management service; encryption at rest of call recordings and consent clips using AES256 server-side encryption; column-level encryption of provider application programming interface keys and connected-account OAuth tokens using AES-256-GCM; role-based access control across three roles for Customer's team (owner, manager, staff) enforced through a single authorization path applied to every request and covered by automated tests, under which managers cannot access billing or cancel the Service, staff hold read-only access, and account export and account deletion are restricted to the owner; session security by httpOnly session cookies with server-side revocation, single-use magic link, code and OAuth sign-in, and enforcement of secret strength at boot in production; audit logging of write and mutation activity with the acting identity, and of administrative reads of Customer's data with the administrative identity and the resource read; restriction of the administrative surface to a single named identity on an allowlist subject to a verified-email check; tenant isolation by scoping every record to a customer identifier, enforced by an automated check that fails the build when a table is added without a per-customer purge or retain decision; validation of actual upload bytes, polyglot-file rejection and PDF object-graph inspection; malware scanning on Provider's own servers without a third-party scanning service; removal of structured identifiers from caller-volunteered content before storage as described in Clause 5.3(b); and the storage locations stated in Clause 11.

5.3 Limitations. The measures described in Annex 2 are the entirety of the technical and organizational measures Provider has in force, and Provider does not represent or warrant that any measure not stated there is implemented. In particular:

• (a) Multi-factor authentication. Provider does not operate a multi-factor authentication module within the Service. Authentication to the Service is by Google OAuth or by a single-use emailed code, and no password credential exists within the Service for a second factor to protect. Any additional authentication factor applicable to the administrative identity is provided by the underlying identity provider and not by the Service. Provider does not represent or warrant that a product-level second factor is available or implemented.
• (b) Redaction of caller-volunteered content. Before storage, the Service automatically removes structured identifiers it recognizes with high confidence, namely payment card numbers, Social Security numbers, and bank routing and account numbers, replacing each with a marker naming what was removed. That removal is applied to the voice transcript before it is summarized, so derived summaries, insights, tags and vectors inherit it, and to every text channel turn, to stored message history, and to audit log previews. Apart from the minors protocol described in Clause 12, that filter is the only screening the Service performs on the content of a conversation. It is configured for precision rather than recall, and content it does not positively identify is retained as spoken or written. Provider does not represent or warrant that any other sensitive content an End User volunteers, including health details, names or addresses, is detected, screened, filtered or redacted.
• (c) Penetration testing and vulnerability assessment. Provider has not obtained a third-party penetration test and does not currently operate a scheduled vulnerability assessment. A cadence for both is ratified by the Qualified Individual as of 2026-07-30, and no assessment has yet been performed. Provider does not represent or warrant that the Service has been tested by a third party.

5.4 Changes to the measures. Provider may change its technical and organizational measures provided that the change does not materially reduce the overall level of security.

5.5 Customer's determination. Customer has reviewed the measures described in Annex 2 and the limitations stated in Clause 5.3, and determines that, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, they are appropriate to the risk presented by Customer's own use of the Service. Customer is responsible for that determination and for the configuration choices it makes in the Service.

6. Sub-processing

6.1 General written authorization by category. Customer gives Provider a general written authorization to engage Sub-processors for the provision of the Service. The authorization is granted by category of service and not by named vendor, and the authorized categories are listed in Annex 3, which also states the condition on which Provider engages each category for a given Customer. This corresponds to Privacy Policy Section 5, which describes sub-processor categories rather than naming the vendor in each one, so that a change of vendor within a category does not falsify a published statement. Provider separately publishes a partial named list at firstaiemployee.com/data-processors: that page names the vendors in the infrastructure and language-model categories and gives the category and the country alone for the operational categories.

6.2 Provider's undertakings. Provider shall:

• engage a Sub-processor only within a category listed in Annex 3 and only where the engagement is necessary for the provision of the Service;
• assess a Sub-processor's security and data handling before engaging it and record that assessment in Provider's sub-processor register;
• prefer providers whose published terms prohibit training on Customer's data and support zero retention, and configure those settings where the provider offers them; and
• remain fully liable to Customer for the acts and omissions of each Sub-processor it engages as if they were Provider's own, subject to Clause 13.1 and Terms Section 16.

6.3 No flow-down warranty; status of written terms. Provider does not represent or warrant that each Sub-processor is bound by written data protection terms no less protective than those in this Addendum. Provider records, for each category in which it has engaged a Sub-processor, whether written data protection terms are on file, are not held, or are not confirmed, and makes that record available to Customer on request under Clause 10.1. Where the record states that written data protection terms are not held or are not confirmed, Provider makes no representation that any such terms are in force with the Sub-processors in that category. Provider's liability under Clause 6.2 applies irrespective of that status.

6.4 Notice of change. Where Provider adds or replaces a Sub-processor in a manner that changes which third parties receive End User Personal Data, Provider shall notify Customer by email to the address on Customer's account, before the new Sub-processor begins processing where practicable and otherwise as soon as Provider is able. Notice under this Clause is given by email only; Provider does not maintain a subscription list, change feed or in-product notification for Sub-processor changes. Keeping the address on the account current and monitored is Customer's responsibility, and a notice sent to that address is effective when sent, as also provided in Privacy Policy Section 14.

6.5 Objection. Customer may object to a new Sub-processor on reasonable data protection grounds within thirty (30) days of the notice given under Clause 6.4. Provider shall use good faith efforts to make an alternative available. Where Provider is unable to do so, Customer may terminate the affected part of the Service without penalty, and Provider will refund prepaid fees for the unused remainder of the then-current billing period on a pro rata basis. Termination with that refund is Customer's sole remedy for an objection under this Clause.

6.6 Hosted form content and the artificial intelligence features of hosted forms. Where Customer enables an artificial intelligence feature of hosted forms, the content an End User types into that form is sent to the Sub-processors in the AI routing and inference category listed in Annex 3. The features to which this Clause applies are the two respondent-facing features, which answer a question the respondent asks while completing the form and which ask the respondent a follow-up question about an answer already given, and the owner-facing feature, which analyzes and summarizes the responses Customer has already collected. The following limbs govern that processing:

• (a) Categories of data. What is sent is the respondent-typed text of the answers concerned and the question text of the form to which those answers belong, and, for the owner-facing analysis, the answers within the set of responses Customer selects. No call audio is sent in this lane. This Clause adds no category of personal data to Clause 2.6.
• (b) Retention by the Sub-processor. Requests in this lane are routed with the zero-data-retention setting the routing provider offers, so that the request is served and nothing is retained after it has been served. That setting is a configuration Provider makes on its own account, taken together with the terms the inference provider publishes. Clause 6.3 governs the status of written data protection terms with the Sub-processors in this category, and Provider does not represent or warrant a retention outcome inside a Sub-processor's own systems. Provider's own retention is unchanged and continues to be governed by Clause 9.3. Clause 11.2 states what Provider does and does not represent about the location of the language model step, and this Clause does not vary it.
• (c) No training. The undertaking in Clause 3.5 applies in full to this lane, so the content is not used to train third-party or publicly available artificial intelligence models. The limits Clause 3.5 states on that undertaking apply to it equally.
• (d) Three switches, and all three must agree. Content reaches a Sub-processor in this lane only where three conditions are satisfied at the moment of the request: a fleet-wide switch held by Provider is on, which is off unless Provider sets it and which Provider may turn off for every Customer at once; Customer has opted in on its own account, which switch reads as off and cannot be moved while the fleet-wide switch is off; and Customer's account does not carry the exclusion described in limb (e). Where any one of the three is not satisfied, no content is sent and the feature does not run.
• (e) Health-regulated exclusion. Where Customer's account carries the health-regulated exclusion, no respondent content from that account is sent to a Sub-processor in this lane in any circumstance, and the exclusion overrides both the fleet-wide switch and Customer's own opt-in. That exclusion is a control over routing. It does not vary Clause 1.3 or Clause 2.7, under which protected health information may not be submitted to the Service at all, and it is not a representation that the Service is suitable for protected health information.
• (f) Status of the features. Provider does not represent that any feature described in this Clause is available to Customer. As at the effective date of this version of this Addendum, the fleet-wide switch described in limb (d) is off, no account carries the opt-in, and no respondent content is sent in this lane. This Clause states what the processing is if and when Customer enables such a feature, and states nothing more than that.

7. Assistance with data subject requests

7.1 Assistance. Taking into account the nature of the processing, Provider assists Customer by appropriate technical and organizational measures, in so far as possible, in fulfilling Customer's obligation to respond to requests to access, rectify, erase, port, restrict or object. The functions described in Clause 7.2 are made available for that purpose at no additional charge. Where an End User contacts Provider directly, Provider does not respond on Customer's behalf; Provider refers the End User to Customer as controller and, where the End User identifies the Customer, passes the request to Customer. Provider does not operate a cross-account lookup and cannot identify the relevant Customer from an End User's contact details alone.

7.2 Functions available to Customer.

• Per-contact export. From the contact record in the dashboard, Customer may download a single JSON export of data held in respect of one identified person, comprising that person's profile, calls, transcripts, messages, intake, review requests, related records and attachment metadata. Attachment file contents are not embedded in the JSON. Customer retrieves those contents separately through authenticated attachment downloads while the attachments remain available under the applicable retention period. The JSON file identifies, in plain language, the records retained under an exemption and therefore not reproduced in it, and the places in which that person's data may survive that the export does not reach, as described in Clause 7.4.
• Per-contact erasure and receipt. From the same record, Customer may erase one person. The erasure executes a declarative manifest that identifies each table, the action taken (deletion, deletion together with stored files, detachment, anonymization, or scrubbing of a free-text field), and the reason for it. The erasure returns a receipt, drafted so that Customer may forward it to the person who made the request, stating what was erased, what was retained and under which exemption, what could not be completed, and the steps available in respect of it. An operation that could not delete a stored file reports that fact and remains capable of retry rather than reporting success.
• Account-level export. The account owner may download the account's records and CRM attachment metadata in JSON format at any time from Settings and may download the same attachment metadata through the separate CSV export available there. Attachment file contents are not embedded in either export and are retrieved separately through authenticated attachment downloads while the attachments remain available under the applicable retention period. Together, these functions are the means of return referred to in Clause 9.1.
• Account deletion on demand. The account owner may purge the account's Customer Data from the dashboard. Where a subscription is active, the deletion cancels it in the same act, on the account owner's express acknowledgement of that consequence, and the account owner may elect immediate deletion or deletion at the end of the period already paid for.
• Suppression on erasure. An erasure writes an SMS suppression entry for the relevant number where none exists, because the consent ledger survives the erasure under Clause 9.3 and a retained grant without a corresponding suppression entry would permit an erased person to be contacted again.

7.3 Requests beyond the available functions. Where Customer requires assistance that the functions in Clause 7.2 do not provide, Provider shall give reasonable assistance and may charge for it.

7.4 Limitations of erasure. A per-contact erasure does not reach records that carry no identifier linking them to the contact. Those records are: web chat and Messenger threads, which are keyed to a session or platform identifier rather than a telephone number; hosted form responses, in which the respondent is identified only within the answers; per-day aggregate call insight rollups, which carry no name or number and expire with the account; public reviews retrieved from a platform, for which the platform is the source of record and the person removes the review where it was posted; draft replies to those reviews; platform-level audit records written without a customer identifier; and Business Files Customer uploads through the dashboard, because erasing an End User does not remove Customer's own uploaded documents. Each of these limitations is stated in the erasure receipt. Provider does not represent or warrant that a per-contact erasure removes every record relating to an End User.

8. Security incidents, assistance and impact assessments

8.1 Notice to Customer. Where Provider becomes aware of a breach of security leading to the unauthorized access to, or the unauthorized disclosure, alteration, loss or destruction of, End User Personal Data that Provider processes for Customer (a "Security Incident"), Provider shall notify Customer without undue delay. Provider does not withhold notice pending the conclusion of an investigation; where facts remain to be established, Provider states what is known and supplements the notice as further facts emerge. This Clause corresponds in substance to Privacy Policy Section 14. An unsuccessful attempt is not a Security Incident: pings, port scans, denial of service attempts and failed log-in attempts do not give rise to notice under this Clause unless they result in unauthorized access to, or loss of, End User Personal Data.

8.2 No fixed notification period. Provider does not undertake to give notice of a Security Incident within any fixed number of hours. The standard under this Addendum is notice without undue delay.

8.3 Content of the notice. To the extent known at the time, the notice states what occurred and when Provider learned of it; the categories of personal data and the records or accounts involved; the measures Provider is taking to contain and investigate the Security Incident and to reduce the risk of recurrence; and the measures Provider recommends to Customer, including any step that only Customer can take. Matters not yet established are identified as such.

8.4 Delivery of the notice. Notice is given by email to the address on Customer's account and to any additional security contact Customer has provided. Keeping those addresses current and monitored is Customer's responsibility, and a notice sent to them is effective when sent.

8.5 Notification of End Users. Customer, as controller of End User Personal Data, is responsible for notifying End Users. Provider notifies Customer and supports Customer's notification obligations rather than assuming them, provides the information Customer reasonably requires to assess the Security Incident and to make any notification required of it by law, and responds to reasonable follow-up requests. Provider does not notify Customer's callers, texters, chat visitors or email correspondents directly unless required by law or requested by Customer. Where Provider is controller, as described in Clause 1.1, Provider notifies the affected persons itself.

8.6 Customer's own obligations. This Clause states Provider's obligations to Customer. It does not replace, reduce or satisfy any notification obligation of Customer under the laws applicable to it, including state breach notification statutes, and it does not transfer responsibility for those notifications to Provider.

8.7 Impact assessments and prior consultation. Taking into account the information available to it, Provider provides reasonable assistance with Customer's data protection impact assessments and with any prior consultation with a supervisory authority, in each case in so far as they relate to Provider's processing. That assistance consists of responding to a security questionnaire and providing the materials described in Clause 10.1. Provider may charge a reasonable fee for assistance given under this Clause 8, excluding any step that this Clause 8 itself obliges Provider to take.

8.8 Vulnerability reports. Where Customer believes it has identified a vulnerability in the Service, or suspects an incident involving data Provider holds, Customer shall email [email protected] with "Security" in the subject line, with sufficient detail to locate or reproduce the matter, and shall allow Provider a reasonable opportunity to investigate and remedy it before disclosing it publicly.

8.9 Notice is not an admission. A notice given under this Clause 8, and any step Provider takes to contain or investigate a Security Incident, is not an acknowledgement or admission of fault or liability on Provider's part.

8.10 Incidents caused by Customer. The notification obligations in this Clause 8 do not apply to an incident caused by Customer, by a person acting on Customer's behalf, or by Customer's own configuration, credentials or connected accounts. Provider may nonetheless inform Customer of such an incident, and doing so does not extend this Clause to it.

9. Deletion and return on termination

9.1 Return. At any time during the subscription and before the deletion under Clause 9.2 is carried out, the account owner may export the account's records and CRM attachment metadata as a JSON file from the dashboard and may export the same attachment metadata through the separate CSV download available there. Attachment file contents are not embedded in either export and are retrieved separately through authenticated attachment downloads while the attachments remain available under the applicable retention period. Together, the JSON export, CSV metadata export and those authenticated downloads are the means by which Customer takes its data. The exports carry stated row and size limits and declare within the exported files where they were truncated; Provider supplies the remainder on request under Clause 7.3. Provider does not offer bespoke migration services or extracts in other formats. Customer is responsible for maintaining its own copies of any Customer Data it wishes to retain beyond termination, and the return functions described in this Clause are the means Provider makes available for doing so.

9.2 Deletion. Subject to the legal-hold and saved-job-file exceptions in this Clause, Customer Data is deleted within fourteen (14) days after termination of the account. On termination the account is suspended, any telephone number provisioned to Customer is released, and a deletion date fourteen days forward is recorded on the account. A legal hold stops deletion without a time limit. While any file is under legal hold, an account purge fails and deletes nothing; Customer has no customer-facing control to set a legal hold. A customer upload saved to a job remains on the owner-selected retention schedule stated in Clause 9.3. The purge otherwise removes the account's data in a defined, foreign-key-safe order recorded in a manifest that a build-blocking test maintains. The fourteen-day period is Customer's opportunity to reinstate the account. Deleted data may persist in encrypted backups for approximately fourteen to fifteen days.

9.3 Retention schedule and records that survive deletion. The first two categories below state the retention rules for documents and files held in Customer's account. The remaining categories are retained after the deletion under Clause 9.2 because a legal obligation requires it, because the record is necessary for the establishment, exercise or defense of legal claims, or because a suppression must outlive an erasure:

• Business Files. Documents Customer uploads through the dashboard as business records have no fixed retention period. They are kept until a human deletes them or the account is purged.
• Customer uploads saved to a job. The account owner selects a retention period of ninety days, one year, three years or seven years. That period begins when the job is completed. If the job is never completed, the file is kept indefinitely. A legal hold stops deletion without a time limit.
• Consent and opt-out evidence. The append-only consent ledger, retained for five years from the later of the date the record was created, the date it was last relied upon to contact the person it concerns, and the date consent was revoked. The telephone number is stored as a one-way hash together with the final four digits and is not stored in full. That hash is pseudonymisation and not anonymisation. The ledger expires on its own schedule and not with the account.
• Suppression lists. The SMS STOP list and the email unsubscribe list. A number that has opted out remains opted out irrespective of which customer it was associated with.
• The carrier traffic ledger for business text messaging, recording what was sent, to which number, and under which campaign, retained as a carrier compliance obligation.
• Billing, tax and financial records, comprising Customer's account record (with credentials, connected channel tokens and capability fields scrubbed and outstanding sessions revoked), aggregate usage counters containing no message content, referral credit records, the ledger of paid carrier actions, refund obligations, and chargeback dispute records.
• The audit and compliance trail, recording which action occurred, when, and under which identity, including the record of the purge itself. Audit records carrying conversational previews are Customer Data and are deleted.
• Call recording ledger records, recording where audio was held and its consent clip or legal hold status. The audio objects themselves are purged, save for consent clips and audio under legal hold, which are retained on their own schedule.
• Records of assent, recording who agreed to which version of the Terms, when, and from which internet protocol address.
• Any record subject to a legal hold or that Provider must retain to comply with law, to resolve a dispute, or to enforce its agreements.
• The association between Customer's account and its application programming interface key, so that a returning customer retains the same key. The key value is sealed at rest.
• Pre-account onboarding drafts, where information was submitted before an account existed. Those drafts carry their own expiry and are pruned on that schedule rather than by the account deletion.
• Records concerning Customer in Provider's own sales systems, where Customer was previously a prospect. Those records are processed by Provider as controller, are not Customer Data, and are not affected by the purge.

This schedule states retention categories that Terms Section 18 and Privacy Policy Section 7 summarize. It does not represent that every category in the schedule is deleted by an account purge or that every retained category has a fixed retention period.

9.4 Certification of deletion. Provider shall confirm deletion in writing on request. Confirmation is produced on request and is not issued automatically.

10. Audit and information rights

10.1 Information made available. On request, no more than once in any twelve-month period, Provider shall provide a written attestation of compliance with this Addendum, a current summary of the WISP, the entry in Provider's sub-processor register for each category listed in Annex 3 that Customer engages, applying the conditions stated in the fourth column of that Annex, and in which Provider has engaged a Sub-processor, together with the current status of written data protection terms for that category as described in Clause 6.3, and reasonable written responses to a security questionnaire. In addition, where a Security Incident has affected Customer's End User Personal Data, Customer may request those materials once in respect of that Security Incident, on reasonable notice and within ninety (90) days of Provider's notice under Clause 8; the materials provided on such a request are the materials described in this Clause 10.1, updated to reflect that Security Incident. Provider shall make available the information reasonably necessary to demonstrate compliance with its obligations as a processor, and shall inform Customer promptly if Provider concludes that it can no longer meet an obligation under this Addendum.

10.2 No on-site audit; no certification. Provider does not offer on-site audits or physical inspection of its premises or facilities, and the materials described in Clause 10.1 are the entirety of the audit and information rights granted under this Addendum. Provider holds no SOC 2 report, no ISO 27001 certification, and no completed third-party penetration test, and does not represent otherwise in response to any security questionnaire or other request.

10.3 Regulated verticals. Where Customer is subject to the GLBA Safeguards Rule, Internal Revenue Code Section 7216, or SEC Regulation S-P, this Addendum is not the applicable instrument. As provided in Terms Section 10(e), a separate data-processing or safeguards addendum, where executed between the parties, governs Provider's handling of such information; Provider does not represent that any such addendum is in force absent that execution.

11. Location of processing and international transfers

11.1 Storage locations. The database holding transcripts and contacts, call recordings, account data, and backups are stored in United States regions of Provider's hosting provider. Uploaded intake media and hosted documents are stored in object storage in a United States region of the same provider; the Service refuses in production to operate against a region outside the United States.

11.2 Matters on which Provider makes no representation.

• The language model step. Requests are routed on Provider's behalf to inference providers that are headquartered in the United States and whose terms prohibit training on Customer's data and prohibit its retention beyond the serving of the request. Those providers operate datacenters in more than one country, and none of them publishes which datacenter served an individual request. Provider does not represent a processing location for that step.
• The edge. Provider's content delivery and domain name services operate on global anycast by design, and request and response bodies may therefore terminate at a point of presence outside the United States unless regional services are purchased. Provider does not represent that this step occurs within the United States.
• General. Provider does not represent or warrant that all processing of End User Personal Data occurs exclusively within the United States, and makes no representation as to the location of the personnel who administer the systems on which the Service runs.

11.3 Contractual guarantee on request. Where Customer requires a contractual guarantee that no processing occurs outside the United States, Customer shall inform Provider before subscribing. Provider will either agree such a guarantee in writing or state plainly that it cannot.

11.4 EEA and UK data. In ordinary operation Provider does not process personal data originating from the European Economic Area or the United Kingdom, and the Service is directed to businesses in the United States. If Provider were to agree in writing to process such data, the parties would put appropriate safeguards in place for its transfer, which may include the European Commission's Standard Contractual Clauses. Clause 6.3 governs the status of written terms with Sub-processor categories, and nothing in this Clause varies it.

12. Minors and children's data

12.1 Customer's obligation. As provided in Terms Section 7, Customer shall not direct the Service at, or knowingly use it to collect personal information from, children under 13 (or under the age that the law applicable to Customer sets, such as 16 where required), and Customer is responsible for the children's-data obligations arising in respect of its End Users.

12.2 Provider's protocol. Provider operates an actual-knowledge protocol rather than an age gate. Where a caller or texter is identified as being under 18, the agent collects no further information, including name, callback details, consent, review requests and referral requests, directs a genuine emergency to 911, and ends the conversation. On the voice channel the call recording is then deleted, the transcript is replaced with a fixed line identifying no detail, the caller name is cleared, and the derived tags and search vectors are removed with it. The contact is flagged, and while that flag is set every consent capture path refuses to record and review, referral and affirmation senders omit that recipient. A revocation of consent is not suppressed by the flag, so a STOP received from a child takes effect. A recording subject to a legal hold is not deleted, the redaction of text still applies, and any retained file is recorded rather than retained silently.

12.3 Limitations. Provider does not verify the age of any person, because verification is itself collection. Provider does not analyze recordings to estimate the age of a speaker. Identification on text channels is not automated: the instruction to cease collection is enforced in the agent prompt on every text channel, and no flag is written from those channels. Provider does not represent or warrant that minors are detected automatically on any channel.

12.4 Requests by a parent or guardian. A deletion request made by a parent or guardian requires no separate process. The per-contact erasure described in Clause 7.2 erases a child's data, and Provider honors such a request through Customer.

13. General

13.1 Precedence. This Addendum forms part of the Terms. Where a provision of this Addendum conflicts with a provision of the Terms or of the Privacy Policy on the subject matter of data protection, this Addendum prevails. On every other subject matter the Terms prevail. Nothing in this Addendum varies, limits or expands Terms Section 16 (limitation of liability) or Terms Section 17 (indemnification), which continue to apply in full to any claim arising out of or relating to this Addendum.

13.2 Term. This Addendum takes effect as provided in the Incorporation paragraph above and continues for so long as Provider processes End User Personal Data for Customer, together with the retention periods stated in Clause 9.3.

13.3 Governing law and disputes. This Addendum is governed by the laws of the State of Wyoming, without regard to its conflict-of-laws rules, and the dispute resolution, arbitration and venue provisions of Terms Section 19 apply to it.

13.4 Amendment. Provider may update this Addendum where applicable law or Provider's processing changes. Material changes affecting Customer are notified by email to the address on Customer's account or through the Service before they take effect, on the basis stated in Terms Section 20.

13.5 Notices. Notices under this Addendum are given to [email protected] for data protection matters and to [email protected] for legal notices, in each case to First AI Employee LLC, 30 N Gould St Ste N, Sheridan, WY 82801.

13.6 No separate execution. This Addendum is accepted by Customer's acceptance of the Terms and requires no signature. No separate counterpart is issued.

13.7 No third-party beneficiaries. This Addendum confers no right on any person who is not a party to it, and a claim relating to this Addendum may be brought only by a party against a party. This Clause does not limit any right an End User has against the controller of that End User's personal data under applicable law.

Annex 1. Description of the processing

Annex 2. Technical and organizational measures

The measures listed in this Annex are the entirety of the technical and organizational measures Provider has in force. Items 11 to 13 state limitations rather than measures. Clause 5.3 governs those items.

1. Transport security. TLS at the edge with HSTS preload, a modern cipher suite, and a full security header set including frame denial and a permissions policy restricting camera, microphone and geolocation.
2. Encryption at rest. The primary database volume is encrypted with a key managed by the hosting provider's key management service; call audio objects are encrypted with AES256; provider keys and OAuth tokens are sealed at the column level with AES-256-GCM.
3. Access control. Three-role role-based access control for Customer teams enforced through a single authorization path; owner-only restrictions on account export, account deletion, per-contact export and per-contact erasure; a single-identity allowlist for administrative access subject to a verified-email check; administrative preview sessions of a Customer's account are read-only and every write is refused; key-based SSH restricted to a single operator; enforcement of production secret strength at boot; session security by httpOnly, same-site session cookies with server-side revocation per identity, and single-use sign-in links and codes.
4. Network controls. The database listens on the private interface only and is not reachable from the public internet; application-level rate limiting on the general, authentication and carrier-webhook lanes, with a shared counter store available across processes; token authentication on the carrier inbound-message webhook, which the carrier does not sign; CORS and CSRF protections; an insecure-direct-object-reference check on every customer-scoped route.
5. Logging. Write and mutation activity is audited with the acting identity; administrative reads of Customer's data are audited with the administrative identity and the resource read; secrets and personal identifiers are masked at the point of writing in edge access logs and application logs; edge access logs and application logs are retained for thirty days and then deleted; misconfiguration is surfaced by validation at boot.
6. Tenant isolation. Every record is scoped to a customer identifier; an automated check fails the build where a table is added without a purge or retain decision, and a second automated check fails the build where a mutating route is added without an authorization gate.
7. Upload content validation. The Service validates actual file bytes rather than relying on the file type supplied by the browser, rejects polyglot files, and traverses PDF object graphs to reject JavaScript, OpenAction, EmbeddedFile and XFA content.
8. Data minimization at capture. The agent is instructed never to request or accept payment card numbers, Social Security numbers, bank or identification numbers, or health details, and to offer a secure link or a callback instead.
9. Biometrics. Recordings are not used to create a voiceprint or any other biometric identifier and are not used to identify or verify any person by voice. Returning callers are recognized by telephone number and prior interaction history.
10. Disposal. A declarative purge manifest and a per-contact erasure manifest, each covered by automated checks that fail the build, together with a rolling audio retention sweep and an intake media reaper.
11. Redaction of caller-volunteered content, partial. Structured identifiers (payment card numbers, Social Security numbers, bank routing numbers, and account numbers stated as such) are replaced with named markers at every point at which caller-volunteered text is persisted. Other sensitive content an End User volunteers is not filtered. See Clause 5.3(b).
12. Multi-factor authentication. No multi-factor authentication module exists within the Service, and no password credential exists within it. See Clause 5.3(a).
13. Penetration testing and scheduled vulnerability assessment. Not performed. A cadence is ratified by the Qualified Individual as of 2026-07-30; no assessment has yet been performed. See Clause 5.3(c).
14. Backups. A nightly encrypted dump to an offsite versioned bucket with server-side encryption, and a weekly automated restore drill that verifies the restored database against the live schema ledger and alerts the operator on both success and failure.
15. Children's data. The actual-knowledge protocol described in Clause 12, comprising suppression of every further collection and of every consent capture once the flag is set, and, on the voice channel, replacement of the call transcript, clearing of the derived tags and search vectors, and deletion of the call recording save where it is under a legal hold.
16. Upload malware scanning. The Service scans uploads for malware on Provider's own servers. Provider uses no third-party malware scanning service. Uploads are also validated against a file-type allowlist and per-type size caps.

Annex 3. Authorized sub-processor categories

Categories are authorized in place of vendor names for the reason stated in Clause 6.1. Provider publishes the vendors it names, category by category, at firstaiemployee.com/data-processors; that page is partial by design, and the operational categories there give the category and the country alone. A current list of named vendors for every category below is available on request under Clause 10.1.

Scope by channel. This Annex lists the maximum set of categories for the Service. The categories a Customer actually engages depend on the channels that Customer's account uses, and the fourth column states the condition for each one. Where the condition is not met, Provider engages no Sub-processor in that category for that Customer and no End User Personal Data of that Customer reaches one. A Customer that uses the website chat channel alone engages no Sub-processor in the telephony and messaging, speech to text, text to speech or identity verification categories, because that Customer holds no telephone number and no caller audio exists. Clause 10.1 is scoped to match: on request, Provider provides the register entry for the categories that Customer engages.

The author of a language model is not a Sub-processor. In the AI routing and inference category, Provider names the routing provider and the inference providers that receive the request. Provider does not name the author or publisher of the model weights those inference providers run. That party receives no request, holds no data and carries out no processing on Provider's behalf, so it is not a Sub-processor and no obligation in Clause 6 applies to it. Clause 11.2 states what Provider does and does not represent about the location of the inference step itself.

Two vendors named here. The authorization stays categorical, and Provider names vendors at firstaiemployee.com/data-processors rather than in this Annex, so that a change of vendor within a category does not falsify this Addendum. Two are repeated here because they are the two Customers ask about. OpenRouter routes the language-model step to the closed set of inference providers that page names. Composio holds the connections Customer authorizes from its dashboard and no others. On a calendar connection, Composio processes the availability and appointment details needed for booking, including the name and email address of the person being booked. On a connection to Customer's business software, Composio receives only the call fields the selected action requires, including the caller's name, telephone number and completed-call summary. During setup, it reads destination names and identifiers so Customer can choose and verify the target. Before a managed write, it also reads only the First AI Employee event marker from the selected sheet column, a matching Notion page title and marker block, or task and card names to prevent a retry from creating a duplicate. Provider does not use those reads to import or synchronize the rest of Customer's account. Composio does not receive call audio, and it receives call data only for a call that reaches an integration Customer has connected. It does not carry Customer's connected messaging channels. A change to either vendor follows Clause 6.4.

Services Customer connects to its own accounts are Customer's own service providers, not Sub-processors of Provider. These include the calendar account itself, the business software a connected integration writes into, review platforms, the messaging destinations Customer chooses for summaries and notifications, and any automation Customer builds in its own Zapier account, to which Provider posts events at a destination Customer supplies. Data flows to them on Customer's instruction, Customer's agreement with each such service governs that processing, and Customer can disconnect them at any time. The distinction is who chose the vendor: Provider chose the broker that holds the authorized connections and answers for it under Clause 6.2, and Customer chose both the accounts that broker connects to and any workflow tool Customer operates itself.