What we do with your callers' data, in writing

This Data Processing Addendum (the “DPA”) forms part of the Mirakash Termsand of any order form or other written agreement between you and us for the Mirakash platform (together, the “Agreement”). It applies automatically from the moment we first process Customer Personal Data for you, and for as long as we do. Accepting the Terms is accepting this DPA. Nobody needs to sign anything for it to bind both of us.

A countersigned copy. If your records need one, or you would like us to consider your own data processing terms instead, write to us through /contactunder “Legal notice, contract or DPA request”.

What wins in a conflict. If documents conflict about personal data, this order applies:

1. the Standard Contractual Clauses, with the UK and Swiss adaptations in section 09, where they apply;
2. this DPA;
3. the Terms and the rest of the Agreement.

Nothing in the Agreement limits or changes the Standard Contractual Clauses or the rights they give data subjects. The sections written for a particular law (sections 16 to 18) add to the general sections for data within that law. They never reduce them.

What it does not cover. This DPA covers personal data we process on your behalf when you use the platform. It does not cover personal data we handle for our own purposes as a controller: your account, billing, sales and support correspondence, identity checks we run before giving you phone numbers or senders, our website, our own Mirakash Guide assistant and our public demo call. Our privacy policy covers those. Records of what your users do inside your workspace, such as its audit trail, are Customer Personal Data. We also use sign-in and security records to keep the platform secure, and for that purpose we are a controller.

Us.Mirakash is provided by Aikolumi Software Pvt Ltd, a company incorporated in India (“we”, “us”). Card payments are collected for us by Naridon, Inc. (Delaware, USA) through Stripe; Naridon, Inc. does not process Customer Personal Data.

You.The business that accepted the Terms (“you”). The platform is for business use only, by people aged 18 or over.

Roles.For Customer Personal Data, you are the controller and we are your processor. Other laws use other names for the same roles. Under the CCPA you are the “business” and we are your “service provider”. Under India's DPDP Act you are the “Data Fiduciary” and we are a “Data Processor”.

If you are a processor yourself. Some customers run agents for their own clients, for example an agency or an outsourced contact centre. Then your client is the controller, you are its processor, and we are your sub-processor. In that case:

• you confirm that your client has authorised our appointment and the instructions you give us, including this DPA;
• you pass on to your client any notice from us under this DPA that it needs;
• we take instructions from you, not from your client, unless you have ceased to exist in law or the law requires otherwise;
• Module Three of the Standard Contractual Clauses applies to transfers (section 09).

Where we act for ourselves. We are a controller, not your processor, for the account, billing and security information described in section 01. We may also use information about how the platform performs, such as call counts, durations, error rates, latency and costs, to operate, bill and secure the service. We do so only in a form that does not identify the people your agents talk to.

In this DPA:

• Customer Personal Data means personal data we process on your behalf in providing the platform, as described in Annex I.
• Data Protection Lawmeans every law on personal data that applies to the processing under this DPA. Where they apply, that includes: the GDPR (Regulation (EU) 2016/679); the UK GDPR and the UK Data Protection Act 2018; the Swiss Federal Act on Data Protection (“FADP”); the California Consumer Privacy Act as amended by the California Privacy Rights Act (“CCPA”) and other US state privacy laws; India's Digital Personal Data Protection Act, 2023 and its rules (“DPDP Act”); and the UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (“PDPL”).
• Controller, processor, data subject, personal data, processing, personal-data breach and supervisory authorityhave the meanings the GDPR gives them. The matching terms of other laws, such as “business” and “service provider”, or “Data Fiduciary”, “Data Processor” and “Data Principal”, are read in the same way.
• Sub-processor means a third party we engage that processes Customer Personal Data. It does not include our own employees, or vendors you contract with directly (section 08).
• Standard Contractual Clauses or SCCs means the clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.
• UK Addendum means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, version B1.0, issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.
• Workspace means your account area on the platform, and console means the web application you manage it in.

We process Customer Personal Data only on your documented instructions, including about transfers to other countries, unless a law we are subject to requires us to do otherwise. If that happens, we will tell you before we process it, unless that law forbids telling you on important grounds of public interest.

Your documented instructions are:

• the Agreement, including this DPA;
• how you set up and use your workspace in the console: your agents and their prompts, tools and knowledge; who they call or message; recording and redaction settings; retention windows; and who you give access to;
• the calls you make to our API, and the webhooks and integrations you connect;
• any other written instruction we both agree to.

Many changes to these settings are written to your workspace's audit trail against the person who made them. That includes agent edits and publishes, retention and redaction changes, member and role changes, and API keys and connectors.

If we think an instruction is unlawful. We will tell you straight away if, in our opinion, an instruction infringes Data Protection Law. We may pause the processing that instruction concerns until you confirm, change or withdraw it. This does not make us responsible for checking your instructions in general.

What you are responsible for. As controller you are responsible for the lawfulness of what you ask us to do. In particular, you are responsible for:

• having a lawful basis for the processing, and giving the people your agents talk to the notices the law requires. Where the law requires it, that includes telling them they are talking to an AI agent and that the call is recorded;
• any consent you need, for example for recording, for marketing calls and messages and for contacting people on do-not-call registers, and for honouring opt-outs;
• not sending us special categories of personal data, health information, payment card data or children's data except as Annex I allows;
• any decision you make using what your agents produce, including a decision with legal or similarly significant effects on a person;
• the security of your own accounts, devices and API keys, and of the systems you connect.

Subject matter and duration. We process Customer Personal Data to provide the Mirakash platform to you, for the term of the Agreement and afterwards until we have deleted or returned it (section 14).

Nature and purpose. Your agents answer and place phone calls, chat on websites through our widget, and send and receive messages. To do that, the platform carries the conversation, turns speech into text and back, has an AI model decide what to say, and runs the tools you connect. It then stores and analyses the result so you can review it. The data this produces about the person on the other end falls into these groups:

• Contact identifiers: the phone number or email address the conversation arrived on or was placed to, names, and whatever your own systems passed us alongside them.
• Audio: the live audio of a call and, where recording is on, the stored recording. Recordings are kept only for agents set up to tell the caller the call is recorded. Test calls you place from the console are recorded.
• Transcripts, messages and what is derived from them: what was said or written, the summary, the post-call analysis, fields an agent extracted because you told it to, and quality scorecards.
• Operational records: when the conversation happened, how long it ran, which tools the agent used, what it cost, and whether it was handed to a person.
• Your content: knowledge-base documents, contact lists and datasets you upload, which may themselves contain personal data.
• Your users: the names, work email addresses, roles and activity records of the people you invite to your workspace.

Annex I sets this out in the format the Standard Contractual Clauses use.

No training. We do not use Customer Personal Data to train, fine-tune or improve AI models. Where the platform learns from your calls, for example the lessons a call teaches one of your agents, that stays inside your workspace and changes only your own agents. What our vendors may do with the data we send them is covered in section 08.

We give access to Customer Personal Data only to our employees and contractors who need it to run, support or secure the platform, and only as far as they need it. Everyone we authorise is bound by a duty of confidentiality, by contract or by law, that continues after their work for us ends.

Our rule is that our people open a customer's workspace only when you ask, for example to help with a support request, or when we must investigate a security incident, stop abuse or meet a legal duty. That rule is ours to keep: the software does not enforce it everywhere. A small number of platform operator accounts can technically reach any workspace's conversations.

We implement and maintain the technical and organisational measures in Annex II. They protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure and unauthorised access. We chose them with regard to the state of the art, the cost, the nature, scope, context and purposes of the processing, and the risks to the people concerned, as Article 32 of the GDPR requires. We may change them over time, but not in a way that lowers the overall protection they give.

In outline: data is encrypted in transit and at rest. Recordings live in private storage and are never served from a public or pre-signed link. Playing one goes through the platform, which checks that the listener is signed in, that the conversation belongs to their workspace and that their role includes listening to audio. Inside your workspace you control access with four roles and optional per-agent scopes, all enforced on the server. Sign-ins, role changes, exports, recordings played, transcripts opened and deletions each become a row in an append-only, hash-chained audit trail. You can read, export and verify that trail, and stream it to your own security tools.

What we do not have. We hold no security certification and no independent audit report of our controls today. Our database runs in a single availability zone, so if that data centre failed we would restore from backup rather than switch over. Annex II lists these gaps next to the measures, so you can weigh them yourself.

What is yours. Security is shared. You control who has access to your workspace and with which role, whether your workspace requires multi-factor authentication, the API keys you create, the vendor accounts and systems you connect, and what data you send us.

Health and card data. We do not sign business associate agreements, so the platform must not be used for protected health information. It has not been assessed against payment card industry standards. Unless we have agreed otherwise in writing, do not use it to collect payment card numbers.

General authorisation. You give us general written authorisation to engage sub-processors to help provide the platform. The sub-processors we use are listed on our sub-processors page, which forms Annex III of this DPA. For each one it says what the vendor does and where it processes data.

Which ones handle your data. A voice agent is a chain of services. Something turns speech into text, something decides what to say, something turns the answer back into speech, and something carries the call. Which vendors run for you depends on how your agents are set up: the model you choose, the language they speak and the channels you use. A text-only chat agent involves no telephony. If a vendor fails during a call, the platform can move that part of the call to the next vendor in a failover chain, so a call can reach a vendor other than the one you chose. The compliance scope page in your console (Settings → Scope, for admins) lists the model vendors your conversations have actually used, the speech vendors your agents are set up to use, and your carriers.

Notice of changes.We will give at least 30 days' notice before a new or replacement sub-processor starts processing Customer Personal Data. We will update the sub-processors page and tell every customer who has asked to be notified. To ask, use /contactand choose “Notify me of sub-processor changes”. If we must replace a sub-processor urgently to keep the platform running or secure, we may do so with shorter notice. We will then tell you as soon as we can, and your right to object still applies.

Your right to object. You may object to a new sub-processor on reasonable data protection grounds, in writing through /contact, before the notice period ends. We will then work with you in good faith on a solution. There often is one, because many vendors are chosen per agent: you may be able to use a different vendor for the same job, or your own account with a vendor. If we cannot offer a reasonable solution, you may end the affected part of the service before the change takes effect, without penalty. We will refund any fees you paid in advance for the part you can no longer use.

Their obligations. We will bind each sub-processor, by written contract, to data protection obligations that protect Customer Personal Data at least as well as this DPA does, including sufficient guarantees about security. We remain fully liable to you for how our sub-processors perform those obligations.

Where that stands today.We are completing a review of every vendor's data processing terms. Many vendors' standard business terms include a data processing agreement. Where a vendor's do not, or where we have not yet accepted one, we are putting one in place. Until that review is finished we cannot show you a signed agreement for every vendor. Ask through /contact and we will tell you the current position for any vendor on the list.

Model training by vendors.Where a vendor offers a setting that stops it storing requests or using them to improve its models, and we have built it in, we use it. For example, our requests to OpenAI's chat API ask it not to store them, and our requests to Deepgram opt out of its model-improvement programme. We have not yet confirmed in writing, for every vendor, that it will not train on the data we send it. That is part of the review above.

Your own vendor accounts are not our sub-processors. You can connect your own account with a vendor: for a model, speech, embeddings, storage or avatars; your own carrier, SIP trunk or SIM gateway; your own messaging accounts; or a tool, webhook or MCP server. That vendor then processes the data under your contract with it. It is your processor or an independent party you chose, not our sub-processor. We send data to it on your instruction, and we are not responsible for what it does with that data.

Your own account is not a hard fence, though. If we cannot fetch your key for a call, or your vendor fails during a call, the platform may run that part of the call on our own vendor account instead, so the call is not dropped. For that call, our vendor is our sub-processor under this DPA.

Where we store it.We host the platform in Amazon Web Services' eu-central-1 region in Frankfurt, Germany. That includes the application, the database and its backups, recordings and application logs.

Where it still goes. Customer Personal Data does leave the European Economic Area:

• During a live conversation, it goes to the model, speech, telephony and messaging vendors that run it. Several of them process data in the United States. Google's Gemini API, one of the model services we use, runs on Google's global infrastructure and cannot be pinned to the EU today.
• Aikolumi Software Pvt Ltd is a company in India, and our personnel may access the platform from outside the EEA to operate and support it.

For customers subject to European, UK or Swiss data protection law, we therefore treat our processing as a transfer and put the safeguards below in place. Where an adequacy decision covers a transfer, that decision applies instead.

EU Standard Contractual Clauses. Where the GDPR applies to your processing, the SCCs are incorporated into this DPA by reference and completed as follows:

• Module Two (controller to processor) applies where you are a controller. Module Three (processor to processor) applies where you are a processor.
• Clause 7: the optional docking clause applies.
• Clause 9: Option 2, general written authorisation, with the notice period in section 08.
• Clause 11: the optional wording on an independent dispute resolution body does not apply.
• Clause 13: the competent supervisory authority is the one described in Annex I, part C.
• Clauses 17 and 18: the SCCs are governed by the law of an EU Member State that allows third-party beneficiary rights, and disputes under them go to the courts of an EU Member State, as those clauses require.
• Annexes: Annexes I, II and III of this DPA complete Annexes I, II and III of the SCCs.

Accepting the Terms counts as each party signing the SCCs, including their annexes. If the SCCs are replaced or amended by the European Commission, the new version applies from the date the Commission sets, with the same choices where they still fit.

United Kingdom. Where the UK GDPR applies, the UK Addendum is incorporated by reference. Tables 1 to 3 of its Part 1 are completed with the details in this section and in Annexes I to III, and its Part 2 Mandatory Clauses apply.

Switzerland. Where the FADP applies, the SCCs apply with these changes:

• the Federal Data Protection and Information Commissioner is the competent supervisory authority for transfers governed by the FADP;
• references to the GDPR are read as references to the FADP for those transfers;
• “Member State” in Clause 18(c) does not stop data subjects in Switzerland from bringing claims where they usually live.

Onward transfers.Where a sub-processor processes Customer Personal Data in a country without an adequacy decision, we will rely on a recognised transfer mechanism for that transfer. Examples are the SCCs, or the vendor's participation in the EU-US Data Privacy Framework. Confirming the mechanism for each vendor is part of the review in section 08.

The Data Privacy Framework. For transfers to us, we rely on the SCCs, not on the EU-US Data Privacy Framework.

Transfer impact assessments. We will give you the information you reasonably need to assess a transfer. That includes which vendors process data and where, and how we handle requests from public authorities (section 19). As a US company, we may be subject to US laws that let authorities require access to data we control, even when it is stored in the EU.

India and the UAE have their own transfer rules. They are covered in sections 17 and 18.

Given what we process and the information available to us, we help you meet your own obligations under Data Protection Law. Some of that help is built into the platform, so you can act without waiting for us. The rest we do by hand. This section says which is which.

Requests from the people your agents talk to.

• Access and copies. Each conversation, with its transcript, recording and analysis, is open to your team in the console. Admins can export a list of every conversation with the phone number or email address it arrived on. The erasure preview in Settings → Call data counts the conversations matching a number or address. There is no single export of everything held about one person yet. Ask us and we will put a copy together.
• Erasure.You can erase a caller's conversations yourself (section 12). That tool reaches the person's conversations and the other records that hold their number or address, with the exceptions section 12 lists. For those, ask us.
• Objection and opt-out.You can add numbers to your workspace's opt-out list. The platform checks that list before an agent dials, before a template message is sent and before an agent starts a text or WhatsApp message. Every agent has a built-in step that records a spoken or typed request to stop when the conversation has a phone number, and a text, WhatsApp or RCS reply of only STOP (or a similar single word) is recorded automatically. Requests that arrive any other way, by email or in a website chat, you add yourself.
• Correction and other rights. Where the console does not let you do what a request needs, ask us and we will help.

Ask for this help through /contact. We will give it in time for you to meet the shortest period the law that applies to you requires.

If a person asks us directly about Customer Personal Data, we will not answer the request ourselves unless the law requires us to. We will pass it to you without undue delay and tell the person we have done so.

Impact assessments and regulators. We will help you with a data protection impact assessment, and with any prior consultation of a supervisory authority, where either concerns our processing. That help starts with this DPA and its annexes, the sub-processors page, and the compliance scope page and evidence pack admins can download from the console. We will also give reasonable further help on request. We will cooperate with a supervisory authority that asks about our processing for you.

Security and breaches. We help you meet your own security and breach obligations through section 07, section 13 and Annex II.

Cost. The self-service tools cost nothing extra. For help that takes significant work beyond them, we may charge a reasonable fee. We will agree it with you before we start, and we will not charge where the need arises from our own breach of this DPA.

Two windows are set per workspace, because audio and text are different risks. The audio is a person's voice, and the text is what they said. Deleting the audio after thirty days while keeping the transcript for a year is a normal thing to want.

Both default to 90 days. You can set either window, in Settings → Call data, to any whole number of days from one day to ten years. You can also choose to keep data with no window at all, which has to be chosen deliberately and is recorded in your audit trail. Stored recordings have a hard limit in any case: our storage deletes every recording 365 days after it was made, whatever the workspace setting.

How deletion runs.A sweep runs twice a day. For every conversation past its window, it computes a SHA-256 hash of the recording and of the transcript. It writes those hashes into your workspace's audit trail as a receipt, and only then deletes the data. The receipt is written first, and that step cannot be skipped: if the trail cannot be written, the data is not deleted. We would rather keep data half a day longer than be unable to prove we removed it. Each run handles a limited batch of conversations per workspace. A workspace with a very large number of conversations expiring at once may take more than one run to clear.

What the sweep removes. When the transcript window passes, the sweep removes:

• the transcript;
• the summary and the post-call analysis;
• tool-call notes and issue evidence;
• quotations kept for agent lessons;
• escalation reasons and scorecard remarks;
• the caller's satisfaction comment and the text of a counted outcome's verdict;
• any test scenario captured from the conversation, which would replay the caller's words.

When the recording window passes, it deletes the recording. Once a conversation is past the shorter of the two windows and none of its content is left, the sweep also removes the phone number or email address it arrived on, and the carrier's reference to the call. Not before: while any content remains, the identifier is what lets an erasure request find it.

What the sweep keeps.The conversation record itself survives, with its time, duration, cost and scores. It was billed and it is in a month's numbers. Deleting it would quietly rewrite your own reporting.

An agent's own window.An agent's guardrails can also set how long its call data is kept. That setting is recorded but not yet enforced: today the sweep applies your workspace's two windows to every agent. When we switch it on, an agent's conversations will be kept for the shorter of its window and the workspace's, never longer, and we will tell you before we do.

Test numbers. A number your team verified to ring during setup is deleted 12 months after it was last used (a code, a test call, or a call through the trial fence), and one that was never verified after 30 days. The receipt goes to your audit trail first, as above.

Backups. The database is backed up automatically. Backups are encrypted, kept in the same Frankfurt region for 14 days, and used only to recover the platform after a failure. Data deleted from the database can therefore persist in a backup for up to 14 days. Recordings are not versioned or backed up, so a deleted recording is gone at once.

If we ever restore the database from a backup, our recovery procedure re-applies every deletion made after the backup was taken, using the receipts in your audit trail, before the restored data is used. That procedure is written down but has not yet been tested in a real restore.

Other records.Your workspace's audit trail is kept for at least 365 days, and by default for as long as the workspace exists. Our application logs are kept for 14 days.

When the statutory clock is running and the request arrived at your privacy desk, not ours, you should not have to wait for us. So you can honour most of an erasure request yourself.

How it works. An admin of your workspace enters a phone number or an email address in Settings → Call data. It is matched exactly after normalisation, never fuzzily: a phone number by its digits, an email address ignoring case. The console shows how many conversations match and how many carry audio, and deletes nothing until the admin confirms. One request handles up to 500 conversations. If there are more, repeat it.

The console does this through an endpoint, POST /api/data/erase. That endpoint only accepts a signed-in admin's console session from our own site. It cannot yet be called from your own systems with an API key.

For each matching conversation, an erasure removes:

• the recording, the transcript and the summary;
• the post-call analysis and anything an agent extracted;
• tool-call notes, issue evidence, quotations kept for agent lessons, scorecard remarks and escalation reasons, so the caller's words are not quoted anywhere;
• the caller's identifier itself, and the carrier's own reference to the call.

The same request, matched by the same rule, also deletes the person from your workspace's other records:

• entries on campaign call lists;
• calls booked to them, pending or done, and their callback preferences;
• consent records your workspace holds for them;
• which persona they were introduced to;
• their number as a test number in your workspace;
• WhatsApp call permissions they granted or refused; on the WhatsApp call log their WhatsApp ID is removed and the row (time, duration) stays for billing;
• rows your agents saved about them, or from their calls, in your Mirakash data tables;
• test scenarios captured from their calls, and the text of any counted outcome's verdict.

What stays is the conversation's existence, its duration and cost, and quality scores about your agent, with every quotation stripped out. Those are records about the service, not about the person.

What it keeps on purpose: the opt-out.If the person is on your workspace's opt-out list, that entry stays. Deleting it to satisfy an erasure would put the number back among those an agent may dial, against the objection the person already made. The console reports the kept entry, so you can tell the person why one record about them still exists. If they want it removed as well, ask us.

What it does not reach. An erasure by identifier does not find the same person in:

• knowledge-base documents you uploaded;
• your own team's chats with the in-console assistant;
• the step-by-step logs of automated workflow runs;
• your audit trail, which records thatthings happened (including a verdict's summary line) and is not rewritten;
• website chats, which carry no phone number or email address.

Knowledge-base documents can be deleted in the console. For the rest, ask us through /contact. We will delete them within 30 days of your request, or sooner where the law requires.

The receipt. The request and the deletion are both written to your audit trail, with the hashes of everything removed. The identifier itself is deliberately not written there. Instead, the receipt carries a hash of it, salted with your workspace, and the erased conversations carry a short label derived from that hash. So two requests about the same caller can be recognised as the same caller. The salt is not secret. Someone who already has a phone number could check whether a label matches it, so treat the labels as pseudonymous, not anonymous.

We will tell you without undue delay, and in any case within 72 hours, after we become aware of a personal-data breach affecting Customer Personal Data.

We will write to the owners and admins of your workspace at the email addresses on their accounts, and use any other contact you have given us for this purpose.

As far as we know it at the time, the notice will describe:

• the nature of the breach, including the categories and approximate number of people and records concerned;
• its likely consequences;
• what we have done or propose to do about it, including to limit its effects;
• who you can contact for more information.

Where we do not have all of this at once, we will send what we have and follow up as we learn more. We will take reasonable steps to contain and investigate the breach and limit its effects, and keep you informed. We will help you notify supervisory authorities and the people concerned where you must. That includes, where they apply, the Data Protection Board of India and each affected Data Principal, the UAE Data Office, and US state breach laws.

We will not notify your regulators or the people concerned on your behalf unless you ask us to or the law requires it. Telling you about a breach is not an admission of fault or liability.

If you suspect a breach affecting the platform, tell us straight away through /contact.

When the Agreement ends, you choose whether we delete Customer Personal Data or return it to you first. We then delete it, including copies, unless a law requires us to keep it. If one does, we keep only what that law requires, protect it under this DPA, and delete it when the requirement ends.

Return. Before your access ends, you can export what the console lets you export: the conversation list, your datasets, and your audit trail with its deletion receipts. There is no one-click export of a whole workspace, and no bulk export of transcripts or recordings. For those, ask us through /contact and we will prepare a copy by hand, in a common machine-readable format.

Deletion. Within 30 days after the Agreement ends, or after you ask if that is sooner, we delete Customer Personal Data from our live systems. Database backups roll off within a further 14 days and are used only for disaster recovery. Stored recordings never outlive the 365-day storage limit in any case. There is no self-service way to delete a whole workspace yet, so our staff carry out the deletion. We will confirm it to you in writing on request.

Proof. Export your audit trail before your access ends. The hashed receipts in it show what was deleted during the life of your workspace, and its hash chain can be verified. The audit trail is Customer Personal Data too, so it is deleted with everything else.

We make available to you all the information needed to show that we meet our obligations under Article 28 of the GDPR and this DPA. We allow for and contribute to audits, including inspections, by you or an auditor you appoint.

Documents first. Start with:

• this DPA and its annexes;
• the sub-processors page;
• the compliance scope page and evidence pack in your console;
• your workspace's own audit trail, whose hash chain you can verify;
• our written answers to reasonable security questionnaires.

We have no independent audit report or certification to give you today.

Then an audit. You may audit our processing of Customer Personal Data, on site or remotely, in any of these cases: that information is not enough to show we meet this DPA; a supervisory authority requires it; or a personal-data breach has affected your data. The conditions are:

• you give reasonable advance notice in writing;
• the audit takes place during business hours;
• your auditor is bound by confidentiality and is not our competitor;
• it is carried out so that it does not expose other customers' data or put the platform's security at risk.

Supervisory authorities. We will let a supervisory authority with jurisdiction audit us as the law requires.

Sub-processors. Audits of our sub-processors happen through the information, reports and audit rights they give us. We will share what their terms let us share.

Where Customer Personal Data is “personal information” under the CCPA, we are your service provider. Where you are a service provider yourself, we are your contractor or subcontractor. You disclose it to us only for the limited and specified business purposes of providing, supporting and securing the platform for you, as described in section 05 and Annex I. We:

• will not sell it or share it. “Share” here means for cross-context behavioural advertising;
• will not keep, use or disclose it for any purpose other than those business purposes. That includes any other commercial purpose, and any use outside the direct business relationship between you and us. The only exceptions are those the CCPA and its regulations allow a service provider, such as detecting security incidents, protecting against fraud or illegal activity, and meeting legal obligations;
• will not combine it with personal information we receive from anyone else, or collect from our own dealings with consumers, except as those regulations allow;
• will meet the obligations the CCPA places on us, and give it the level of privacy protection the CCPA requires;
• will tell you if we decide we can no longer meet our obligations under the CCPA;
• will help you respond to consumer requests (section 10), within the limits described there;
• will bind any sub-processor to the same restrictions in writing (section 08).

You may take reasonable and appropriate steps to make sure we use the personal information consistently with your obligations under the CCPA (section 15). On notice to us, you may also take reasonable and appropriate steps to stop and remediate any use of it you have not authorised, including requiring us to delete it. We certify that we understand these restrictions and will comply with them.

Other US states. Where another US state consumer privacy law applies, such as those of Virginia, Colorado, Connecticut or Texas, we are your processor. This DPA sets out your instructions, the nature and purpose of the processing, the types of data and its duration, as those laws require. It also covers:

• the duty of confidentiality (section 06);
• deletion or return (section 14);
• information and assessments (section 15);
• binding sub-processors in writing, with notice and the chance to object (section 08).

Where the DPDP Act and its rules apply to Customer Personal Data, as and when their provisions come into force, you are the Data Fiduciary and we are a Data Processor you engage under a valid contract, the Agreement. We will:

• process personal data only on your instructions, and only to provide the platform to you;
• keep reasonable security safeguards to prevent a personal data breach, as described in Annex II;
• tell you about a personal data breach without undue delay (section 13). We will include the details you need to inform the Data Protection Board of India and each affected Data Principal, in the form and within the time the rules prescribe. We send what we know as soon as we know it, because those deadlines are short;
• erase personal data when you instruct us, when the Agreement ends (section 14), or when you tell us the purpose is no longer being served, unless a law requires us to keep it;
• help you respond to Data Principals exercising their rights to access, correction and erasure, grievance redressal and nomination, within the limits in section 10;
• follow any restriction the Central Government notifies on transferring personal data to a country outside India.

You remain responsible for what the Act places on a Data Fiduciary. That includes notice and consent, and verifiable consent from a parent or lawful guardian before processing the data of anyone under 18. It also includes publishing contact details for grievances. If a Data Principal contacts us about your processing, we will pass it to you (section 10).

Availability of the platform is restricted by country and may change. The PDPL may apply to the processing we carry out for you, including because the people concerned are in the UAE. Where it does, you are the controller and we are your processor, and we will:

• process personal data only in line with your instructions and the Agreement, for the purposes and period set in it;
• apply the technical and organisational measures in Annex II;
• tell you about a breach without undue delay (section 13), so you can notify the UAE Data Office and the people concerned as that law requires;
• delete or return personal data when the processing ends (section 14);
• help you respond to data subject requests (section 10).

Transfers of personal data out of the UAE are made in the cases Articles 22 and 23 of the PDPL permit. Where that law requires a contract binding the recipient to its protections, this DPA is that contract. If regulations or official guidance under the PDPL set further requirements, we will work with you to meet them, or tell you if we cannot.

Personal data in the Dubai International Financial Centre and Abu Dhabi Global Market is governed by those free zones' own data protection laws, not the PDPL. If yours is, tell us before you start, so we can agree the transfer terms those laws require.

We do not disclose Customer Personal Data to a public authority unless the law compels us to. We have not built any back door or similar mechanism into the platform to give authorities access to data. If we receive a legally binding request for Customer Personal Data, we will:

• check that it is valid and within the authority's powers. After a careful assessment, we will challenge it where there are reasonable grounds to consider it unlawful, including by appeal where appropriate;
• try to redirect the authority to request the data from you directly;
• tell you promptly what was asked for, which authority asked, on what legal basis, and how we responded, unless the law forbids it. If it does, we will use our best efforts to get that restriction waived, so we can tell you as much as possible, as soon as possible;
• disclose only the minimum the request requires, on a reasonable reading of it;
• keep a record of the request and our response, and share it with you where the law allows.

Each party's liability arising out of or relating to this DPA, in contract, tort or otherwise, is subject to the limitations and exclusions of liability in the Terms. Any reference there to a party's liability means its total liability under the Agreement and this DPA together.

That does not limit a party's liability to data subjects under the SCCs, or any liability Data Protection Law does not allow to be limited. It does not limit data subjects' rights. Our liability for our sub-processors (section 08) is subject to the same terms.

This DPA takes effect when you accept the Terms. It lasts as long as we process Customer Personal Data for you, including after the Agreement ends, until we have deleted or returned it under section 14. Parts of this DPA that by their nature should last beyond that continue. These include confidentiality (section 06), liability (section 20) and every obligation about data we still hold.

If any part of this DPA is invalid or unenforceable, the rest stays in effect. The invalid part is read as closely to its purpose as the law allows. This never changes the SCCs.

We may update this DPA to reflect changes in the law, in guidance from regulators, in our sub-processors or in our security measures. We will publish each new version on this page with its date. If a change materially reduces the protection this DPA gives you, we will tell you before it takes effect. No change can alter the SCCs.

A signed copy stays as signed. This page changing does not change a countersigned agreement unless both parties agree.

This DPA is governed by the same law as the Terms, and disputes about it go to the same courts. The exception is where Data Protection Law or the SCCs require a different law or forum; then that law or forum applies, to the extent required.

Contact. Every route goes through our contact form:

• a countersigned copy, a redline, an objection or a notice under this DPA: Legal notice, contract or DPA request;
• notice of sub-processor changes: Notify me of sub-processor changes;
• a suspected breach or a vulnerability: Report a security vulnerability.

People asking about their own data should contact the business whose agent they spoke to. They can also use one of the privacy topics on the contact form, and we will pass the request to that business.

This annex completes Annex I of the SCCs. It describes the processing under this DPA whether or not a transfer takes place.

A. The parties

B. Description of the processing

C. Competent supervisory authority

Under Clause 13(a) of the SCCs, the competent supervisory authority is the one that has authority over you, the data exporter. That depends on where you are established or, if you are not established in the EU, where your representative is. Where the UK Addendum applies, it is the UK Information Commissioner. Where the FADP applies, it is the Federal Data Protection and Information Commissioner.

This annex completes Annex II of the SCCs. It lists only measures we have checked are in place, as of the date above, and then the ones that are not.

Not in place today

• No security certification and no independent audit report.
• The database runs in a single availability zone, and backups are not copied to another region. Recordings have no backup.
• The restore procedure, including re-applying deletions after a restore, has not been tested.
• Round-the-clock alerting and on-call cover are not yet in place.
• There is no automated scan of third-party code for known vulnerabilities.
• Signed data processing terms with every vendor are not yet complete (section 08).
• Hardening of our own administrator access to the cloud account is still in progress. That account also hosts other products that are not part of Mirakash.
• Redaction does not detect health information. If redaction fails, the conversation is stored unredacted rather than lost. Live audio and text reach the model and speech vendors before any redaction.
• Agents that use a native-audio model speak straight to the caller, so the check before speaking does not cover them. A check after each turn corrects unsupported claims instead, but it cannot stop something already said.
• Platform operator accounts can technically reach any workspace (section 06). Opt-out numbers are stored in plain text.

This annex completes Annex III of the SCCs. Our sub-processors page is the list of record. It names each sub-processor, what it does and where it processes data, and it is where changes are announced (section 08). In summary, sub-processors fall into these groups:

Vendors you connect with your own account are not in this annex (section 08).