This agreement is between you, the customer, as controller, and Mirakash as processor, and it covers the personal data we process on your behalf when you run voice and chat agents on the platform. It does not cover the mirakash.com website, which we run for our own purposes and which has its own privacy policy.

You decide the purpose: which agents run, what they ask, who they call, how long the recordings are kept, and what happens when someone asks to be deleted. We carry that out. The settings in your workspace are your documented instructions to us — which is why every one of them that matters is written to the audit trail with your own user against it.

Running an agent produces four kinds of personal data about the person on the other end:

• Contact identifiers — the phone number or email address the conversation arrived on or was placed to, and whatever your own systems passed us alongside it.
• Audio — the recording of the call, where you have recording turned on for that agent. An agent with consent turned off is transcript-only by design and produces no audio at all.
• Transcripts and what is derived from them — what was said, the summary drawn from it, the post-call analysis, and any fields an agent extracted because you told it to.
• Operational records — when the call happened, how long it ran, which tools the agent used, what it cost, and whether it was escalated to a person.

The categories of data subject are whoever your agents speak to: your customers, applicants, patients, students or callers. We process all of it only to provide the platform to you, to keep it running and secure, and to bill you for it.

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

Both default to 90 days. That is deliberate — the alternative default, keeping everything forever, is exactly what the retention question on every security questionnaire is asking about, and a default nobody opens is the only setting most workspaces will ever have. You can set either window to any whole number of days from one to ten years in Settings → Call data, or choose to keep data indefinitely, which has to be selected deliberately and is recorded when it is.

A sweep runs twice a day. For every conversation past its window it computes the SHA-256 of the recording and of the transcript, writes those hashes into your workspace's audit trail as a receipt, and only then deletes the object, the transcript segments and the summary. The receipt is written first and the write cannot be skipped: if the trail cannot be written, the data is not deleted. An unrecorded deletion is indistinguishable from data loss, and we would rather keep data a day longer than be unable to prove we removed it.

The conversation record itself survives the sweep, with its audio and words gone and the proof of what used to be there on the row. It was billed and it is in a month's numbers; deleting it would quietly rewrite your own reporting.

Backups are the exception every honest DPA has to name: a deleted recording can persist in an encrypted database backup until that backup rolls out of its own cycle. Backups are never used to serve a request and are restored only to recover the platform after a failure.

You can honour an erasure request yourself, in the console or over the API, without opening a ticket with us and without waiting for us — which is the only arrangement that works when the statutory clock is thirty days and the request arrived at your privacy desk, not ours.

Settings → Call data takes a phone number or an email address, tells you exactly how many conversations match and how many carry audio, and deletes nothing until you confirm. The same operation is available as a single authenticated call to POST /api/data/erase, with a preview mode that counts without deleting, so your own ticketing system can do it.

An erasure goes further than the retention sweep. It removes:

• the recording, the transcript segments and the summary;
• the post-call analysis and anything an agent extracted;
• tool-call notes, issue evidence, scorecard remarks and escalation reasons — every place a caller's words could still be quoted;
• the caller's identifier itself, and the carrier's own reference back to it.

What stays is the conversation's existence, its duration and its cost, and our quality judgements about your agent— scores, severities, the tactic a call taught us — with every quotation stripped out. Those are records about the service, not about the person, and letting them be deleted would mean a workspace could erase its own quality history by asking on a caller's behalf.

Both the request and the deletion are written to your audit trail with the hashes of everything removed. The identifier is deliberately not written there — putting the number we just deleted into the one store we promise not to prune would defeat the erasure — so the receipt carries a salted hash of it and a short non-reversible label instead, which is what the erased rows then read. Two requests about the same caller are still recognisably about the same caller.

Everything is encrypted in transit and at rest. Recordings live in private object storage and are never served from a public URL: playing one goes through the platform, which checks that you are signed in, that the conversation belongs to your workspace, and that your role includes listening to audio — a reviewer can read what was said without being handed a recording of somebody saying it.

Access inside your workspace is yours to control: four roles, optional per-agent scopes, and twenty-three separate permissions, each enforced on the server rather than hidden in the interface. Every sensitive action — a sign-in, a role change, an export, a recording played, a transcript opened, a deletion — becomes a row in an append-only, hash-chained audit trail that you can read, export, verify and stream to your own SIEM.

On our side, access to production is limited to the people who operate it, sits behind multi-factor authentication, and is logged. We notify you without undue delay, and in any case within 72 hours of becoming aware, of any personal-data breach affecting your data, with what we know and what we are doing about it.

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 over the telephone network. Which of those run for you depends on how your agents are configured — a text-only chat agent involves no telephony and no speech vendor at all.

We will tell you before adding or replacing a sub-processor that touches your conversations, and you may object. No sub-processor is permitted to train models on your conversations, and we do not either.

Most of what a controller needs from a processor, you can get without asking us: export everything held about a caller, erase it, read the audit trail, and verify that the trail has not been altered. That is on purpose — a right you have to open a support ticket to exercise is a right with our queue in front of it.

Where you do need us, we will help you with data-subject requests you cannot complete yourself, with a data protection impact assessment, and with a regulator's enquiry. On termination we delete your workspace's data, or return it first if you ask, within thirty days.

We will publish a new version here and date it. Where a change materially reduces the protections in it we will tell you before it takes effect. An executed copy stays as executed: this page changing does not change a signed agreement.

Questions, a redline, or a request for a counter-signed copy: /contact.