Security and data
Where your callers' data sits, and who can touch it
A phone call is among the most sensitive data a business holds: a name, an ID number, a medical situation, a legal dispute — spoken aloud, and stored. This page sets out what the system actually does with that, including what we don't have.
The short answer
What happens to the personal data spoken during a call with an AI agent?
Every transcript passes through a Hebrew-aware layer that detects and masks identifying details, and each department decides for itself which entity types get masked. Access to recordings and transcripts is limited by role, and sensitive actions are written to an audit log. A citizen's erasure request has a dedicated workflow that nulls the caller identifiers, blanks the personal-data spans in the transcript, drops the recording and stamps a reference number you can quote back to them. Regulated bodies can run the entire system inside their own perimeter, model weights included, so no call data leaves the network. We hold no security-standard audit certification, and we don't claim otherwise.
What we don't have — before what we do
We do not hold SOC 2, we do not hold ISO 27001, and we are not HIPAA- or GDPR-certified. There is no such thing as a "GDPR certificate" to begin with, and HIPAA is US regulation that doesn't apply to most readers here — but they appear on so many security pages that it's worth saying plainly that they don't appear on ours. Rather than implying an accreditation we don't have, everything below describes controls that exist in the product, and you're welcome to have each one demonstrated live against a running system. If the standard you must meet requires a certified vendor, we'll say so on the first call rather than at procurement.
Personal-data detection and masking
A Hebrew call transcript is full of exactly what you can't leave in the clear: a full name, an ID number dictated digit by digit, an address, a phone number, the name of a doctor or an institution. The system runs a Hebrew-trained entity-detection layer over every turn of the conversation — not a general-purpose engine that treats Hebrew as an afterthought. What it finds is stored as positions within the text, so the transcript can be shown masked to anyone who shouldn't see the original, without losing the ability to analyse the call.
- Each department defines which entity types are masked for it — name, ID number, phone, address and more
- An entity type the system doesn't recognise is masked by default rather than exposed by accident
- Detection can be re-run over historical conversations after a settings change, so the past matches the present
- Masking applies to transcripts and exports alike — a CSV leaving the building can leave masked
Erasure requests — the full workflow
A citizen asking for their data to be deleted shouldn't have to settle for a verbal promise. An erasure request in the system is a recorded operation that can run over a single conversation, over every conversation from a given phone number, or over a date range and case id — and here is what it actually does:
- Caller identifiers — phone number, case id, name — are nulled on the conversation record
- Every span identified as personal data in the transcript is replaced with a block and does not remain in the text
- The detection positions themselves are cleared, so what was hidden can't be reconstructed from them
- The recording reference is emptied, so playback fails closed and plays nothing
- The conversation is marked as processed, stamped with who ran it, when, and the reference number
At the end of the process a reference number in a fixed format is stamped on the record. That is the number handed to the citizen, and it is also what lets you prove afterwards that the request was handled, when and by whom. In parallel an audit-log row is written for every affected conversation — not one row per request, but one row per record that was touched.
Who sees what
Permissions are by role, not by trust. Recordings are the sharpest case: there is no masking in audio — a voice is a voice — so access to them is restricted to the roles that need it, and a department that wants to open playback to view-only users has to switch that on deliberately. Sensitive actions are written to a reviewable audit log.
- Separate roles for an administrator, a quality reviewer and a viewer — and they don't all see the same thing
- Recording playback is open to administrators and reviewers; opening it to viewers is a separate, deliberate per-department setting
- Sensitive actions — erasure, export, settings changes — are logged with the actor and a timestamp
- Exports pass through the same permission checks and the same logging as viewing inside the system
Three deployment postures
The same system, three different answers to "how much of the outside world touches this data". The choice is yours, not ours.
Multi-tenant cloud
The fast route. We run the system, and each organisation's data is isolated from every other. Right for businesses not subject to regulation that dictates infrastructure control. Some model services in this posture are external services — which we state plainly, because it is precisely what a regulated body cannot accept.
Hybrid
The data plane — database, recordings, the masking layer and the guardrails — sits on infrastructure you control, while the models themselves run on separate dedicated hardware agreed with you. A deliberate compromise: cheaper than a full on-premise deployment, but not appropriate for every data classification, and we'll tell you when it isn't.
Fully self-hosted / on-premise
The whole system runs inside your perimeter, model weights included — speech recognition, the language model and speech synthesis. In practice: no audio segment and no transcript leaves your network for any external provider, ours included. This is the posture built for government bodies and regulated organisations, and it is supported in an air-gapped environment too.
Alignment with Israeli directive 5.43
For Israeli government bodies, information-security directive 5.43 is the frame of reference that actually matters — not SOC 2. We run an alignment effort against its requirements: role-based access control, action logging in an audit trail, minimisation of personal data through the masking layer, and the ability to run every component inside the organisation's own network. To be precise about it: alignment work is not an approval, and we present no approval. We're glad to walk the gap between the two clause by clause with your security officer.
What you should be asking us
If you're evaluating vendors in this space, these are the questions that separate a security page from a product. Ask us them too.
- Does the personal-data masking genuinely work on Hebrew, or is it an English engine pointed at Hebrew text?
- What exactly happens to a record after an erasure request — and what remains to prove the erasure happened?
- Is the recording reachable by the same people the transcript is, or are the two separated?
- If we require that data never leaves our network, do the models run on our side, or only the database?
- Which formal certifications do you actually hold, and which of them is relevant to the standard I answer to?
Call the agent now
A real call, in Hebrew. Exactly what your callers would hear.
Have the agent call me
Leave a number — the agent calls you in under a minute.
Updated: