afka uses analytics cookies to see how visitors use the site, and a service that can identify the company a visitor works for. We do not sell your data. Decline and none of it loads.
This Data Processing Agreement (“DPA”) describes how afka processes personal data on your behalf when you use the Service. It forms part of, and is governed by, our Terms of Service, and reflects the requirements of GDPR Article 28 and similar laws.
This Data Processing Agreement (the DPA) is entered into between Afka, Inc., a Delaware corporation with its mailing address at 2810 N Church St STE 89857, Wilmington, DE 19802, United States (afka), and the customer identified in the applicable order form, subscription or online registration (the Customer). Each is a Party.
This DPA forms part of, and is incorporated by reference into, the afka Terms of Service and any order form or other written agreement governing the Customer’s use of the Services (together, the Agreement). Capitalised terms used but not defined here have the meanings given in the Agreement. This DPA applies from the date the Customer accepts the Agreement or first uses the Services, whichever is earlier, and for so long as afka processes Customer Personal Data. It is the version published on this page and supersedes any earlier version; afka will make available, on written request, the version in effect on any given date.
In respect of Customer Personal Data, the Customer is the Controller and afka is the Processor. Where the Customer is itself a Processor acting on behalf of a third-party Controller, afka is a Sub-processor of the Customer, the Customer warrants that it has that Controller’s authority to appoint afka on these terms, and references to the Customer’s instructions are to instructions the Customer is permitted to give.
afka acts as a Controller for a limited set of data it processes for its own purposes, including account administration, billing, security telemetry and product analytics. That processing is described in the afka privacy policy and falls outside this DPA.
afka shall process Customer Personal Data only on the Customer’s documented instructions, including as regards transfers to a third country, unless required to process by Union, Member State or other applicable law to which afka is subject; in that case afka shall inform the Customer of the legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
The Agreement, this DPA, and the Customer’s use and configuration of the Services (the channels it connects, the agents it creates, the autonomy level it sets for each agent, the integrations it enables, the tasks it assigns and the approvals it grants) together constitute the Customer’s complete and final documented instructions. Additional or alternative instructions must be agreed in writing, and afka may charge for implementing them under Section 5.5.
afka shall immediately inform the Customer if, in afka’s opinion, an instruction infringes Data Protection Laws. afka may suspend performance of the affected instruction, without liability, until it is confirmed, amended or withdrawn, and is not obliged to perform an instruction it reasonably considers unlawful.
These are set out in Annex I. In summary, afka processes Customer Personal Data to operate AI colleagues that receive work from the Customer’s users in a connected channel, plan it, act in the Customer’s connected tools within the autonomy the Customer has configured, and report back, and to write every action taken to an append-only audit record available to the Customer.
afka shall not, and shall require that its AI providers do not, use Customer Personal Data to train general-purpose AI models or for advertising, cross-context behavioural advertising or similar profiling purposes.
Where the CCPA applies, the Customer is the Business and afka is a Service Provider receiving Customer Personal Data solely for the business purpose of providing the Services. afka shall not sell or share Customer Personal Data; shall not retain, use or disclose it for any purpose other than performing the Services and the business purposes set out in this DPA, or outside the direct business relationship between the Parties; and shall not combine it with personal information received from or on behalf of another person, or collected from afka’s own interaction with a Data Subject, except as the CCPA permits a Service Provider to do. In addition:
The disclosure of Customer Personal Data to afka is not a sale or a sharing of personal information, and afka provides no monetary or other valuable consideration for it.
Where the Customer connects a Google account, afka’s use and transfer of information received from Google APIs to any other application adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:
The Customer is responsible for the lawfulness of the Customer Personal Data it makes available and of the instructions it gives. It shall establish a lawful basis for the Processing; give all notices and obtain all consents required under Data Protection Laws from its personnel, its customers and any other Data Subject, including in respect of the participation of an afka meeting assistant in a call and the connection of any Customer-Enabled Integration; comply with the terms of each connected platform; and configure the autonomy, approval and access settings of the Services appropriately to its risk. The afka meeting assistant joins a call as a named, visible participant and announces itself on joining; the Customer remains responsible for any further notice or consent required in its jurisdiction.
The Services are not designed, certified or intended to process Regulated Data, and the Customer shall not submit Regulated Data to them. Regulated Data means: (a) protected health information subject to the Health Insurance Portability and Accountability Act; (b) payment card data subject to the Payment Card Industry Data Security Standard; (c) non-public personal financial information subject to the Gramm-Leach-Bliley Act; (d) special categories of personal data within the meaning of Article 9 of the GDPR, and personal data relating to criminal convictions and offences within the meaning of Article 10; (e) personal data of children under sixteen (16) years of age; (f) data subject to export control restrictions, including the United States Export Administration Regulations and the International Traffic in Arms Regulations; and (g) any other data subject to sector-specific legal requirements imposing safeguards not expressly provided for in the Agreement or this DPA.
If the Customer requires the Services to process Regulated Data, the Parties must execute a separate written addendum, such as a business associate agreement, before any such data is submitted. afka may suspend or terminate the affected Services immediately on discovery of Regulated Data, without a cure period, and the Customer is responsible for regulatory exposure arising from its breach of this Section 2.8.
afka shall ensure that any person authorised to process Customer Personal Data, whether an employee, officer or contractor, is subject to a written obligation of confidentiality that survives the end of that person’s engagement, or is under an appropriate statutory obligation of confidentiality.
afka shall limit access to Customer Personal Data to personnel who need it to provide, secure, support or bill for the Services, shall grant that access on the principle of least privilege, and shall revoke it promptly when it is no longer required. Such personnel shall receive appropriate instruction on handling that data and on the requirements of this DPA.
Taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of the Processing, as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, afka shall implement and maintain appropriate technical and organisational measures to ensure a level of security appropriate to that risk, as required by Article 32 of the GDPR and equivalent provisions of the other Data Protection Laws.
The measures in place as at the date of the version of this DPA published on this page are described in Annex II. afka may update those measures provided that no update reduces the overall level of protection afforded to Customer Personal Data; material changes will be published on the afka legal pages at afka.ai/legal.
The Customer is responsible for its own use of the controls the Services make available, including roles and capabilities, agent autonomy and approval requirements, application programming interface keys, single sign-on where its plan includes it, and review of the audit record.
If afka receives a request from a Data Subject to exercise a right in relation to Customer Personal Data, afka shall forward it to the Customer without undue delay and in any event within five (5) business days of receipt. afka shall not respond except to confirm to the Data Subject that the request relates to the Customer and to direct the Data Subject to the Customer, unless the Customer instructs afka in writing to respond or applicable law requires a response.
Taking into account the nature of the Processing, afka shall assist the Customer by appropriate technical and organisational measures, insofar as possible, in fulfilling its obligation to respond to requests to exercise the rights of Data Subjects, including access, rectification, erasure, restriction, portability and objection. Where the Services provide a self-service function for an operation, including export of the audit record and deletion of a task or of a single call and its transcript, the Customer shall use that function in the first instance.
Taking into account the nature of the Processing and the information available to it, afka shall provide reasonable assistance to the Customer in ensuring compliance with Articles 32 to 36 of the GDPR and their equivalents, namely security of processing, notification of a personal data breach to the supervisory authority, communication of a breach to the data subject, data protection impact assessment, and prior consultation.
If afka receives a legally binding request from a public authority for disclosure of Customer Personal Data, afka shall, unless prohibited by law, notify the Customer without undue delay and use reasonable efforts to obtain a waiver of any prohibition on notification. afka shall challenge a request it considers unlawful under the law of the requesting authority, shall disclose the minimum permissible on a reasonable interpretation of the request, and shall document each such request for the Customer.
Assistance under this Section 5 that goes beyond the ordinary course of providing the Services, including assistance that cannot be delivered through the self-service functions, bespoke data extraction, audit support under Section 9, questionnaires beyond afka’s standard security documentation, and consultation time, may be charged at afka’s then-current professional services rates on reasonable prior written notice of the estimated charge. afka shall not charge for assistance that Data Protection Laws require a processor to provide without charge.
A Personal Data Breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data transmitted, stored or otherwise processed by afka or by a Sub-processor.
afka shall notify the Customer of a Personal Data Breach without undue delay and in any event within seventy-two (72) hours of becoming aware of it, by email to the Customer’s account administrator of record and, where the severity of the incident warrants it, by any other means reasonably available to afka.
The notification shall include, to the extent known at the time and supplemented as further information becomes available: the nature of the Personal Data Breach, including where possible the categories and approximate number of Data Subjects and records concerned; its likely consequences; the measures taken or proposed to address it, including measures to mitigate its adverse effects; the date or period of the incident and the date afka became aware of it; and the afka contact point from whom more information may be obtained.
afka shall investigate the Personal Data Breach, take all commercially reasonable steps to contain and mitigate its effects and minimise resulting damage, preserve relevant evidence and log records, and cooperate with the Customer in its investigation and in any notification it must make to a supervisory authority or to a Data Subject. Where the incident constitutes a breach of security under an applicable United States state data breach notification law, afka shall provide the notifications required of a processor or service provider under that law.
The following do not constitute a Personal Data Breach and are not notifiable: unsuccessful attempts to gain access to the Services or to afka systems; pings, port scans, network probes and similar reconnaissance; denial of service attempts and traffic that is absorbed or blocked; failed sign-in attempts and credential-stuffing traffic that does not result in access; automated bot traffic challenged or blocked at the edge; and content security policy reports and similar browser telemetry. None of these compromises the confidentiality, integrity or availability of Customer Personal Data. afka records and monitors such events as part of its security operations and, on request, will describe its handling of them under Section 9. Notification of, or response to, an incident is not an acknowledgement of fault or liability.
The Customer grants afka a general written authorisation to engage Sub-processors for the purpose of providing the Services, subject to this Section 7. The Sub-processors engaged as at the date of the version of this DPA published on this page are authorised, and afka may continue to use them.
afka shall engage each Sub-processor under a written contract imposing data protection obligations that are in substance no less protective than those imposed on afka by this DPA, in particular the obligation to provide sufficient guarantees to implement appropriate technical and organisational measures so that the Processing meets the requirements of Data Protection Laws. Where the engagement involves a restricted transfer, afka shall put in place an adequate transfer mechanism. afka remains fully liable to the Customer for the performance of each Sub-processor’s data protection obligations as if the acts and omissions of the Sub-processor were afka’s own.
The current list of afka’s Sub-processors, identifying each Sub-processor, the service it provides and the categories of data it may process, is published in the Privacy Policy at afka.ai/legal/privacy, forms part of this DPA, and is summarised by category in Annex III. The published list is the operative list for the purposes of this Section 7 and of Clause 9 of the Standard Contractual Clauses. A Customer who would rather be sent a copy, or who wishes to subscribe a further address for notices of changes to it, may write to privacy@afka.ai.
afka shall notify the Customer of any intended addition or replacement of a Sub-processor by email to the Customer’s account administrator of record, and to any additional address the Customer has subscribed for that purpose, and by updating the published list referred to in Section 7.2, in each case at least thirty (30) days before the intended Sub-processor begins to process Customer Personal Data.
The Customer may object in writing within thirty (30) days of that notice, provided the objection is based on reasonable data protection grounds. If it does, afka shall not appoint the proposed Sub-processor for the Processing of Customer Personal Data until afka has taken reasonable steps to address the objection and has given the Customer a reasonable explanation of those steps. If the objection is not resolved within fifteen (15) days after afka’s receipt of it, the Customer may terminate the affected Services without penalty, to the extent those Services require the proposed Sub-processor, on written notice. Such termination gives rise to no liability for either Party, save for payment obligations accrued before termination and any refund of prepaid fees for the unused portion of the subscription term for the terminated Services.
Where a change of Sub-processor is required urgently to maintain the security or continuity of the Services, afka may make the change and give notice as soon as reasonably practicable thereafter, and the objection right applies from the date of that notice.
The providers of Customer-Enabled Integrations are not Sub-processors of afka solely by virtue of the Customer connecting them, unless they are expressly listed as afka Sub-processors on the Sub-processor list referred to in Section 7.2.
When the Customer connects a Customer-Enabled Integration, or instructs an afka agent to act in it, Customer Personal Data is transmitted to that platform at the Customer’s instruction and within the scopes the Customer has granted. Processing of that data by the platform provider is governed by the Customer’s own agreement with that provider and is outside afka’s control. The Customer is solely responsible for reviewing, approving and managing its use of Customer-Enabled Integrations, for the scopes it grants, for the notices and consents required in respect of them, and for compliance with the terms of each connected platform. Where the Services deliver to a platform using the credentials of the connecting member, the resulting action appears in that platform under that member’s own name.
A provider may appear both as an afka Sub-processor and as the provider of a Customer-Enabled Integration. Where that is so, the provider’s status as an afka Sub-processor applies only to afka’s own use of that provider’s services in connection with the provision of the Services, and does not extend to the Customer’s separate use of, or relationship with, that provider.
The connector platform through which the Customer connects third-party accounts is an afka Sub-processor in respect of afka’s own use of it. Where a connector is managed by that platform, the OAuth grant authorising access to the connected account is held by the connector platform, and afka holds a reference to that connection rather than the grant itself.
afka stores and routinely processes Customer Personal Data in environments located in the United States. Application hosting, background processing, caching and product analytics for the Services are operated in United States regions.
The primary managed database is located in the United States, in the East US (North Virginia) region. Application compute runs in the United States. afka does not offer European Union data residency.
Any multi-region redundancy, backup or disaster recovery environment shall be limited to regions disclosed in this DPA, on the Sub-processor list referred to in Section 7.2 or in afka’s security documentation. Incidental cross-border transit of Personal Data may occur in the ordinary course of internet routing, network operations or service delivery.
Where the Processing involves a transfer of Personal Data out of the European Economic Area to a third country not the subject of an adequacy decision (a restricted transfer), the Parties incorporate the Standard Contractual Clauses into this DPA by reference, as completed and amended by Section 8.3, and those Clauses form an integral part of this DPA. Module Two (controller to processor) applies where the Customer acts as Controller and afka as Processor. Module Three (processor to processor) applies where the Customer acts as Processor and afka as Sub-processor. In each case the Customer is the data exporter and afka the data importer.
With regard to Section 8.2 above, the Parties agree that the Standard Contractual Clauses are completed as follows:
Where the Processing involves a restricted transfer subject to the UK GDPR, the Parties incorporate the UK Addendum into this DPA by reference, completed as follows:
For such transfers, references in the Standard Contractual Clauses to the GDPR are read as references to the UK GDPR and references to Member State law as references to the law of the United Kingdom, the governing law is the law of England and Wales, the courts of England and Wales have jurisdiction, and the competent supervisory authority is the Information Commissioner.
Where the Processing involves a restricted transfer subject to the Swiss FADP, the Standard Contractual Clauses apply as incorporated by Sections 8.2 and 8.3, amended as follows: references to the GDPR are read as references to the Swiss FADP insofar as the transfer is governed by it; the term Member State is read so as not to prevent Data Subjects in Switzerland from exercising their rights in their place of habitual residence in accordance with Clause 18(c); references to a competent supervisory authority are read as references to the Swiss Federal Data Protection and Information Commissioner (the FDPIC) insofar as the transfer is governed by the Swiss FADP; and where a transfer is subject to both the GDPR and the Swiss FADP, the authority identified in Part C of Annex I acts in respect of the GDPR transfer and the FDPIC in respect of the Swiss transfer. Where the Swiss FADP protects the data of legal entities, the Standard Contractual Clauses also protect such data until any revision removing that protection enters into force.
If afka adopts an alternative lawful transfer mechanism for a restricted transfer, including any successor to the Standard Contractual Clauses or a certification under an approved framework, that mechanism applies instead of the mechanism in this Section 8 for the transfers it covers, provided it complies with Data Protection Laws and afka gives the Customer notice of its adoption.
afka shall make available to the Customer all information necessary to demonstrate compliance with Article 28 of the GDPR and equivalent provisions of the other Data Protection Laws. On reasonable written request, and subject to Section 9.4, afka shall provide: afka’s security documentation and its mapping of the controls described in Annex II to the requirements the Customer identifies; a completed copy of afka’s standard security questionnaire; a description of the measures in place at the relevant time; and, where afka holds one, a copy or executive summary of a current independent third-party audit report or attestation covering the Services.
afka does not currently hold an independent third-party audit report or certification in respect of the Services and makes no representation that it does. Any such report afka obtains will be made available under this Section 9.1. Until then, the information made available consists of afka’s security documentation and control mapping together with Annex II.
The Customer may exercise the right in Section 9.1 once in any twelve (12) month period, and more frequently: following a Personal Data Breach materially affecting Customer Personal Data; where required by a Supervisory Authority or by Data Protection Laws; or where there has been a material change to the measures described in Annex II.
If the Customer, acting reasonably and in good faith, determines that the information made available under Section 9.1 is insufficient in respect of a specific and identified matter, the Customer may conduct a targeted audit of that matter, itself or through an independent auditor that is not a competitor of afka and is bound by appropriate confidentiality obligations. Such an audit shall: be subject to at least thirty (30) days prior written notice specifying the scope, the matter to be examined and the proposed methodology; take place during normal business hours; be limited to systems, documentation and personnel relevant to that matter; be conducted so as to protect the confidentiality and security of afka’s other customers and not to disrupt afka’s business, systems or operations unreasonably; and be at the Customer’s expense, including afka’s reasonable costs of supporting it under Section 5.5. Remote and document-based audits are preferred, and afka may require that any on-site element be limited to what cannot reasonably be examined remotely. The Customer shall provide afka with the audit findings and shall treat them as afka’s confidential information.
All information disclosed and all findings made under this Section 9 are afka’s confidential information and may be used by the Customer only to assess afka’s compliance with this DPA and its own compliance with Data Protection Laws. afka may withhold or redact information to the extent necessary to protect the confidentiality, security or personal data of other customers, to protect trade secrets, or to comply with a legal obligation, and shall explain the basis for any redaction.
Nothing in this Section 9 limits the audit and inspection rights of a Supervisory Authority, or the rights of the data exporter under Clause 8.9 of the Standard Contractual Clauses or under the UK Addendum. Where those Clauses apply, this Section 9 sets out the manner in which such rights are ordinarily to be exercised and does not restrict them.
On termination or expiry of the Agreement, on deletion of the Customer’s afka account, or otherwise after the end of the provision of the Services, the Customer may, at its choice, export or request the return of Customer Personal Data processed on its behalf. The Services provide self-service export of the audit record in CSV and NDJSON formats, and afka shall provide reasonable assistance with any further export requested, subject to Section 5.5.
If the Customer does not request the return or export of Customer Personal Data within thirty (30) days following termination, expiry or account deletion, the Customer instructs afka to delete that Customer Personal Data, including existing copies, and afka shall do so within sixty (60) days after the end of that thirty (30) day period. After that thirty (30) day period, Customer Personal Data may no longer be available to the Customer and may not be recoverable.
During the term, the Customer may delete Customer Personal Data through the Services, including deletion of a task and its content, deletion of a single call and its transcript (which the Services refuse until the meeting assistant has been removed from the call), and disconnection of a connected account. On disconnection of a connector managed by the connector platform, afka revokes the connection at that platform by application programming interface call and records the disconnection in the audit record. The OAuth grant for a connector managed by the connector platform is held by that platform and is revoked there. afka shall action any further written deletion request within sixty (60) days of receipt, subject to Section 10.4.
afka operates one automatic, product-wide retention window. Speech captured from meetings is deleted on a rolling thirty (30) day window: meeting transcripts and the associated speech recognition samples are deleted, and the stored prompt of a task and the stored context of an approval are emptied while the task or approval record itself is retained. afka does not record video of meetings and maintains no recording library; the meeting assistant transcribes.
Content security policy reports, voice session records and expired approval records are also swept on a rolling basis. afka does not operate a general automatic deletion sweep beyond what is stated in this Section 10.3. Other than as stated in this Section 10.3, deletion occurs on the Customer’s request or on the deemed instruction under Section 10.1.
afka may retain Customer Personal Data to the extent required by applicable law, or to the extent it is subject to a reasonable legal hold in connection with actual or reasonably anticipated litigation, regulatory investigation or dispute. In that case afka shall retain only what is required, for only so long as it is required, shall continue to protect it in accordance with this DPA, and shall delete it when the requirement ends. Backup media are overwritten in the ordinary course of the backup rotation operated by afka’s platform providers; afka does not publish a backup retention period and does not represent that deletion from active systems is immediately reflected in backup media.
On the Customer’s written request made within sixty (60) days of completion of deletion under Section 10.1, afka shall provide written confirmation that Customer Personal Data has been deleted in accordance with this Section 10, identifying anything retained under Section 10.4 or Section 10.6 and the basis for its retention.
The Customer should understand, before relying on Section 10.1, that the afka audit record is not deleted and cannot be deleted. The record is append-only: entries cannot be altered or removed, and the record survives deletion of the underlying working data.
The audit record contains no speech or message content. An audit row records the actor, the action taken, the target of the action, the timestamp, the credit cost, the identifier of the run, a reference to the approval that authorised the action where one was required, and whether the action was initiated by a human or by an agent. It does not contain meeting speech, the body of a channel message, the body of an email, the content of a document, or the content of a task prompt.
An audit row may therefore contain identifiers that constitute Personal Data, such as the identifier or name of the user who acted or approved and the identifier of a target record in a connected system. Where the Customer requires the erasure of such identifiers in order to respond to a Data Subject, the Parties shall discuss in good faith what can be done consistently with the integrity of the record and with the Customer’s own obligation to maintain records of processing and of decisions taken. afka’s position is that retention of this minimal record is necessary for the establishment, exercise and defence of legal claims and for the security of processing. The record is exportable by the Customer at any time in CSV and NDJSON formats.
Each Party’s liability arising out of or in connection with this DPA, including under the Standard Contractual Clauses and the UK Addendum, is subject to the exclusions and limitations of liability set out in the Agreement. This DPA creates no separate or additional cap, and claims under it count towards, and are not additional to, the aggregate cap in the Agreement. Nothing in this DPA or the Agreement excludes or limits either Party’s liability to the extent it may not be excluded or limited under applicable law, or limits the rights of a Data Subject under the Standard Contractual Clauses, the UK Addendum or Data Protection Laws.
The Customer shall indemnify afka against all losses, damages, fines, penalties, costs and expenses (including reasonable legal fees) arising out of a claim by a Data Subject, a legal person or a Supervisory Authority to the extent that claim arises from: the unlawfulness of the Customer’s instructions; the Customer’s failure to establish a lawful basis or to give the notices or obtain the consents required under Section 2.7; the Customer’s submission of Regulated Data in breach of Section 2.8; or the Customer’s use of, or the acts and omissions of the provider of, a Customer-Enabled Integration.
afka shall indemnify the Customer against all losses, damages, fines, penalties, costs and expenses (including reasonable legal fees) arising out of a claim by a Data Subject, a legal person or a Supervisory Authority to the extent that claim arises from afka’s breach of this DPA or of the obligations imposed on a processor by Data Protection Laws, including administrative fines imposed on the Customer to the extent attributable to that breach.
The same procedure applies to a claim under either limb of Section 11.2. The Party seeking indemnity shall notify the other promptly in writing, shall give the indemnifying Party sole control of the defence and settlement (except that no settlement imposing a non-indemnified obligation or admission on the indemnified Party may be made without that Party’s consent, not to be unreasonably withheld), and shall provide reasonable cooperation at the indemnifying Party’s expense. A failure to give prompt notice reduces the indemnity only to the extent the indemnifying Party is prejudiced by the delay.
Where both Parties are responsible for damage caused by a breach of Data Protection Laws, each shall bear the portion of the liability corresponding to its responsibility; where one Party has paid compensation in full to a Data Subject, it may claim back from the other that part corresponding to the other Party’s responsibility.
This DPA takes effect as set out in Section 1.1 and continues for the duration of the Agreement. It terminates automatically on termination or expiry of the Agreement, except that provisions which by their nature should survive, including Sections 3, 6, 9, 10, 11 and this Section 12, and the Standard Contractual Clauses and the UK Addendum in respect of Customer Personal Data still held by afka, survive for so long as afka processes or retains Customer Personal Data.
In the event of a conflict or inconsistency, the following order of precedence applies:
Where the Standard Contractual Clauses or the UK Addendum give the Parties a choice, the choice made in Section 8 applies. This DPA does not reduce any commitment afka has made in a signed agreement where that commitment offers a higher level of protection.
Notices under this DPA shall be in writing. afka gives notice to the Customer by email to the account administrator of record for the Customer’s workspace and, where this DPA so provides, additionally by posting to the afka legal notices page at afka.ai/legal. The Customer is responsible for keeping that address current and for subscribing any additional address at which it wishes to receive notice. The Customer gives notice to afka by email to support@afka.ai and, where postal notice is required, to Afka, Inc., 2810 N Church St STE 89857, Wilmington, DE 19802, United States.
Requests, questions and notices concerning this DPA, the Processing of Customer Personal Data, a Data Subject request, a request for the Sub-processor list, correspondence for the representative identified in Part C of Annex I, or a Personal Data Breach should be sent to privacy@afka.ai. Everything else, including support, billing, sales and general contract notices, should be sent to support@afka.ai. Where a matter requires formal service, a copy should be sent by post to the address above.
This DPA is governed by the law that governs the Agreement, except that Sections 8.3 to 8.5 and the clauses incorporated by them are governed as stated in those Sections. If any provision is held invalid or unenforceable, the remainder continues in effect. Neither Party may vary the Standard Contractual Clauses or the UK Addendum except as those instruments permit. afka may update this DPA from time to time; where an update materially reduces the protection afforded to Customer Personal Data, afka will give at least thirty (30) days prior notice under Section 12.3, and the Customer may terminate the affected Services without penalty if it objects.
Data exporter. Name: the Customer, being the legal entity that entered into the Agreement with Afka, Inc., as identified in its order form or, where it subscribed online, in the billing and workspace details recorded in its afka account. Address: as recorded in that account or order form. Contact person: the account administrator of record for the Customer’s workspace, or such other privacy contact as the Customer notifies to afka in writing. Activities relevant to the data transferred: use of the Services to receive, plan, carry out and report on work performed by AI colleagues in the Customer’s connected channels and connected tools. Role: Controller, or Processor where the Customer processes the data on behalf of a third-party controller. Signature and date: the Customer accepts this Annex and the Standard Contractual Clauses by entering into the Agreement, on the date the Agreement takes effect.
Data importer. Name: Afka, Inc., a Delaware corporation. Address: 2810 N Church St STE 89857, Wilmington, DE 19802, United States. Contact person: privacy contact, Afka, Inc., privacy@afka.ai. Activities relevant to the data transferred: provision of the Services described in Section 1.3, including hosting, agent execution, meeting transcription, voice interaction, delivery of agent actions to connected tools, maintenance of the append-only audit record, support and billing. Role: Processor, or Sub-processor where the Customer acts as Processor. Signature and date: Afka, Inc. accepts this Annex and the Standard Contractual Clauses by making the Services available under the Agreement, on the date the Agreement takes effect.
| Item | Description |
|---|---|
| Categories of data subjects | The Customer’s employees, contractors, officers and other authorised users; participants in meetings an afka meeting assistant is invited to join, including participants who are not the Customer’s personnel; participants in conversations in a connected channel to which an afka agent has been added; the Customer’s own customers, prospects, candidates, suppliers and other counterparties whose data appears in a connected tool within the scopes granted, or in a message, task or document submitted to the Services; and participants in a voice interaction conducted through the Services. |
| Categories of personal data |
|
| Sensitive data | The Services are not designed, certified or intended to process special categories of personal data within the meaning of Article 9 of the GDPR, personal data relating to criminal convictions and offences, or the other categories of Regulated Data defined in Section 2.8, and submission of such data is prohibited. The Parties do not intend such data to be transferred. If it is nonetheless present in content the Customer submits, it is processed under the same measures set out in Annex II, and the Customer remains responsible for it under Section 2.8. No restrictions or safeguards specific to sensitive data are applied. |
| Frequency of the transfer | Continuous, for the duration of the Agreement, on each occasion that a user interacts with an agent, an agent performs a task, a meeting assistant joins a call, a voice interaction takes place, or a connected account is read from or written to. |
| Nature of the processing | Collection, recording, organisation, structuring, storage, retrieval, consultation, use, transcription, indexing and embedding for retrieval, submission to AI models for inference, execution of model-written code in an isolated sandbox, transmission to connected tools at the Customer’s instruction, disclosure by transmission to Sub-processors, logging, erasure and destruction. |
| Purposes of the transfer and further processing | To provide the Services in accordance with the Agreement and the Customer’s documented instructions, namely to operate AI colleagues that receive work, plan it, act in the Customer’s connected tools within the configured autonomy, seek human approval where the Services require it, and report back; to transcribe meetings the Customer invites the assistant to; to maintain the append-only audit record; to secure the Services and prevent abuse; and to provide support and billing. |
| Retention period | Meeting transcripts and speech recognition samples are deleted on a rolling thirty (30) day window, and the stored prompt of a task and the stored context of an approval are emptied on the same window, as described in Section 10.3. Content security policy reports, voice session records and expired approval records are swept on a rolling basis. Other Customer Personal Data is retained for the duration of the Agreement and deleted in accordance with Section 10, that is, on request during the term or following the deemed instruction after termination, subject to the legal hold exception in Section 10.4 and to the append-only audit record described in Section 10.6, which is retained. |
| Transfers to sub-processors: subject matter, nature and duration | Transfers are made to the Sub-processors identified on the Sub-processor list referred to in Section 7.2 and summarised by category in Annex III. The subject matter and nature of each transfer is the provision to afka of the infrastructure or service identified for that Sub-processor on that list (for example hosting, managed database and authentication, caching, workflow orchestration, sandboxed code execution, AI inference, speech to text, embeddings, web research, connector management, meeting transcription, voice and telephony, email delivery, product analytics, bot detection or payment processing), limited to what is necessary for that purpose. The duration is the duration of the Agreement, or until the Sub-processor is replaced or removed under Section 7.3, and thereafter until deletion in accordance with Section 10. |
The competent supervisory authority for the purposes of Clause 13 of the Standard Contractual Clauses is the Prezes Urzedu Ochrony Danych Osobowych (the President of the Personal Data Protection Office), the supervisory authority of the Republic of Poland.
The basis is as follows. Where the data exporter is established in an EEA Member State, that Member State’s authority is competent under the first paragraph of Clause 13(a). Where the data exporter is not so established but falls within the territorial scope of the GDPR under Article 3(2) and has appointed a representative under Article 27, the authority of the Member State in which that representative is established is competent under the second paragraph of Clause 13(a). Afka, Inc. is not established in the European Union and has designated a representative in the Union under Article 27 of the GDPR, established in Poland, as stated below. The Parties accordingly identify the supervisory authority of Poland, the Prezes Urzedu Ochrony Danych Osobowych, as the authority with which afka will engage for the purposes of Clause 13. This identification concerns the competent supervisory authority only: the governing law of the Standard Contractual Clauses and the choice of forum are those elected in Section 8.3, and neither is affected by it.
For restricted transfers subject to the UK GDPR the competent authority is the Information Commissioner; for those subject to the Swiss FADP it is the Federal Data Protection and Information Commissioner.
EU representative (Article 27 GDPR). Name: Dmitry Melnik. Country of establishment: Poland. Contact email: privacy@afka.ai. Data Subjects and Supervisory Authorities may contact the representative at that address, marked for the attention of the EU representative, in addition to the contact details in Section 12.3.
This Annex describes the measures implemented by afka as data importer, following the itemised headings of the Annex II template to the Standard Contractual Clauses. Where a measure is provided by an underlying platform provider, this Annex says so. afka holds no SOC 2 report of any type, no ISO 27001 certification and no ISO 42001 certification.
| Measure | What afka does |
|---|---|
| Pseudonymisation and encryption of personal data | Personal data is encrypted in transit using TLS on every exposed network path; encryption at rest is provided by the underlying managed database, storage and hosting providers. Where a hash suffices, afka stores no recoverable secret: application programming interface keys, directory bearer tokens and mobile link tokens are stored as a SHA-256 hash, shown once at creation and never retrievable, with only a prefix and the last four characters kept for display. Connection references for connected accounts are held in the managed database platform’s secret vault; for connectors managed by the connector platform the OAuth grant itself is held by that platform, not by afka. Pseudonymisation is applied structurally in the audit record: speech and message content are kept out of it at the point of writing, so the record carries actor, action and target references rather than content (Section 10.6). |
| Ensuring ongoing confidentiality, integrity, availability and resilience of processing systems and services | Tenant isolation is enforced in the database, not in application code: row level security is enforced on every tenant table, keyed on the tenant identity carried in the verified access token, and server-side functions re-resolve the calling tenant on the server rather than trusting a client-supplied identifier. Model-written code executes in an isolated microVM with one guest kernel per task, destroyed after the run and never reused across workspaces, subject to CPU, memory, wall-clock and credit caps and deny-by-default network egress. Each run receives short-lived scoped tokens rather than long-lived credentials; a backend tool gateway injects credentials at execution time, so the model never sees a credential. The audit record is append-only, protected by database triggers, giving an integrity guarantee independent of application behaviour. |
| Ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident | Backup and point-in-time restoration of the primary database, and redeployment of application services, are functions of the managed database and hosting platforms and are performed using those providers’ facilities. afka operates no backup infrastructure of its own and publishes no backup retention period. Durable workflow orchestration allows long-running work to resume after a failure rather than being lost. afka does not operate a documented restoration test. |
| Regularly testing, assessing and evaluating the effectiveness of the measures | afka verifies the effectiveness of its tenant isolation and retention measures automatically before any change is released; a failing verification prevents release. A stricter report-only content security policy runs alongside the enforced policy and reports violations to a dedicated endpoint, giving continuous evaluation of the browser security posture. afka has not performed independent penetration testing and holds no independent third-party audit report. |
| User identification and authorisation | Authentication is provided by the managed authentication platform, by email and through Google and Microsoft, the latter two providing OIDC. SAML 2.0 single sign-on is shipped and available on the highest self-serve plan and on enterprise plans; it is bound to a verified company domain, one domain per workspace, and enforcement (turning password sign-in off for the domain) ships disabled and requires at least one successful single sign-on sign-in before it can be enabled. Authorisation is role and capability based: owner, administrator and member roles carry different capabilities, sensitive operations are gated on a named capability (for example the audit export capability, which owners and administrators always hold and a member holds only if granted), and loosening an agent’s autonomy requires the workspace owner. Application programming interface key scopes are re-intersected with the creating user’s live capabilities on every authentication call, so a key cannot outlive the permissions of the person who created it, and the key management scope cannot be granted to a key. Automated directory-based deprovisioning (SCIM) is not available; deprovisioning is performed by the Customer in the application or, where single sign-on enforcement is enabled, at its identity provider. |
| Protection of data during transmission | All traffic to the Services is carried over TLS. HTTP Strict Transport Security is set with a max-age of 604800 seconds (one week). Browser-facing responses carry X-Frame-Options set to DENY, a referrer policy, a permissions policy and a same-origin cross-origin opener policy. An enforced content security policy is served alongside a stricter report-only policy reporting to a dedicated endpoint. Bot detection is applied at the edge using a managed challenge service. Outbound network access from the sandbox in which model-written code executes is deny-by-default. Transmission to a connected tool occurs only at the Customer’s instruction and within the scopes granted. |
| Protection of data during storage | Customer Personal Data is stored in a managed Postgres database with row level security on every tenant table and FORCE row level security on the core tables. Speech recognition samples are stored in a table readable by neither anonymous nor authenticated database roles and reachable only through server-side code. Connection references are held in the platform secret vault; secrets are never placed in files shipped to the browser, never in the frontend bundle and never in a client-exposed build variable. Keys and bearer tokens are stored hashed. No video of meetings is stored, because none is captured. |
| Physical security of locations at which personal data are processed | afka owns and operates no data centres and does not hold Customer Personal Data on premises or on removable media in the ordinary course. Physical security of the facilities in which Customer Personal Data is processed is provided by the managed database, hosting and infrastructure providers identified on the Sub-processor list referred to in Section 7.2, and by the cloud providers underlying them, under those providers’ own physical security programmes. afka personnel reach production only through those providers’ consoles and application programming interfaces, authenticated by the provider, and never by physical access to hardware. |
| Events logging | Every action taken by an agent or a user is written to an append-only audit record. The audit record is append-only: an attempt to alter or delete an entry is rejected. A row carries the actor, the action, the target, the timestamp, the credit cost, the run identifier, a reference to the authorising approval where one was required, and whether the initiator was a human or an agent. The record is exportable by the Customer through a server-side function that verifies the caller’s token, resolves the tenant on the server and checks the audit export capability, in CSV and in NDJSON for ingestion into a security information and event management system; the export itself is recorded in the audit record. The record is append-only and is not cryptographically signed or notarised. Infrastructure and application logs are additionally available through the hosting and database platforms. |
| System configuration, including default configuration | The Services are configured to fail safe. Agent autonomy has three settings, and two independent floors sit above the setting the Customer chooses: a category-based floor that always requires a named human approval for refunds, payments, payouts and adverse decisions, and for a defined list of actions including processing a cancellation, changing a subscription, an offboarding action, an account change and spending money; and a second, independent approval rule covering the same money and people action sets. An action the system does not recognise fails safe to gated. Pending approvals expire on a time to live and are swept, and spend caps are summed across decomposed actions. Metered overage is off by default and spend is blocked at one hundred percent (100%) of the configured limit. Single sign-on enforcement ships disabled. |
| Internal IT and IT security governance and management | Security controls are enforced technically and are verified before a change reaches production. All changes reach production through version control and the continuous integration pipeline. Access to production platforms is on the principle of least privilege and is authenticated at each provider, and credentials are centralised in the platform secret vault. Personnel are subject to written confidentiality obligations under Section 3. |
| Certification and assurance of processes and products | afka holds no SOC 2 report of any type, no ISO 27001 certification and no ISO 42001 certification. Any report or certification afka obtains will be made available under Section 9.1. The underlying infrastructure, database, hosting, model and connector providers maintain their own certifications and audit reports, available from those providers directly and relevant to the layers they operate. The assurance available today consists of afka’s security documentation, the control mapping described in Section 9.1 and this Annex II. |
| Ensuring data minimisation | An agent reads the conversations it has been added to and direct messages with it, not the whole of the Customer’s workspace. Access to a connected account is limited to the OAuth scopes the Customer grants; afka requests only the four Google scopes listed in Section 2.6 and requests no scope that reads the contents of a mailbox. Meetings are transcribed and not recorded, and no video is captured or stored. Speech and message content are kept out of the audit record at the point of writing. Submission of Regulated Data is prohibited. Support access is limited to what is required to resolve the matter raised. |
| Ensuring data quality | The Customer controls the inputs to the Services and can correct account and workspace data in the application. The approval mechanism gives a named human the opportunity to review and correct a proposed action before it takes effect, and the audit record gives the Customer an independently reconcilable account of what was done, by whom and under what approval. Where a Data Subject requests rectification, afka assists under Section 5.2. Outputs generated by AI models are probabilistic, and the Customer remains responsible for reviewing them before relying on them. |
| Ensuring limited data retention | One automatic, product-wide retention window is operated: meeting transcripts and speech recognition samples are deleted on a rolling thirty (30) day window, and on the same window the stored prompt of a task and the stored context of an approval are emptied while the task or approval record itself is kept. Content security policy reports are swept at thirty (30) days; voice session records and expired approvals are swept on a rolling basis. Other records are retained for the duration of the Agreement and deleted on request or following the deemed instruction in Section 10.1. afka operates no general automatic deletion sweep beyond what is stated here and publishes no backup retention figure. |
| Ensuring accountability | The append-only audit record is the primary accountability measure: it records who did what, to what, when, under whose approval and at what cost, and cannot be altered or removed. Approvals record the approving human and are referenced from the resulting action. The Sub-processor list is published and changes to it are notified in advance under Section 7.3. This DPA, that list and this Annex together constitute the record afka makes available under Section 9.1. Loosening an agent’s autonomy requires the workspace owner, so a change in risk posture is attributable to a named person. |
| Allowing data portability and ensuring erasure | The Customer can export the audit record at any time in CSV and in NDJSON through a self-service function gated on the audit export capability. Customer Personal Data can be deleted during the term at the level of a task, of a single call and its transcript (which the Services refuse until the meeting assistant has been removed from the call), and by disconnecting a connected account, which revokes the connection at the connector platform and records the disconnection. On termination the return and deletion mechanic in Section 10 applies, subject to the legal hold exception and to the append-only audit record described in Section 10.6. Further export or deletion assistance is provided under Sections 5.2 and 10.2. |
| Measures to be taken by the sub-processor to provide assistance to the controller | Each Sub-processor is engaged under a written contract imposing obligations in substance no less protective than those in this DPA, including obligations to assist with security, breach notification, data subject requests and deletion. Where a Sub-processor holds data afka must reach in order to assist the Customer under Section 5 or Section 10, afka uses the administrative interfaces and contractual routes available to it with that Sub-processor. afka remains liable to the Customer for a Sub-processor’s performance under Section 7.1. |
afka engages Sub-processors in the categories below. This Annex fixes the shape of the processing chain; the identity of each individual Sub-processor, the service it provides and the categories of data it may process are set out on the list referred to in Section 7.2, which afka publishes in the Privacy Policy at afka.ai/legal/privacy, which forms part of this DPA, and which is the operative list for the purposes of Section 7 and of Clause 9 of the Standard Contractual Clauses. Changes to that list are notified as Section 7.3 describes.
A provider named on that list in one of these categories is an afka Sub-processor only in respect of afka’s own use of that provider in connection with the Services. Where the Customer separately connects the same provider as a Customer-Enabled Integration, Sections 7.4 and 7.5 apply.