Skip to content

Personal Data in Transcripts

Before a transcript is saved, Aelo scans it and replaces four kinds of structured identifiers:

DetectedReplaced with
Phone numbers[PHONE]
Email addresses[EMAIL]
Payment card numbers[CARD]
IBANs[IBAN]

For new transcripts processed through the current application repository paths, this happens before the text is written. The unredacted text is not retained through those paths. This does not redact the original audio or rewrite earlier database rows.

That is why you will sometimes see [PHONE] in a conversation you are reviewing. It is not a transcription error — the number was removed on purpose.

Card numbers are confirmed with the Luhn checksum and IBANs with the ISO 13616 mod-97 check. A random sequence of digits satisfies the Luhn checksum roughly one time in ten, so an unrelated 16-digit order number or reference code is occasionally redacted as a card by chance — the trade-off for never keeping anything that passes for a real card number. Phone numbers are matched against international dialling codes and checked against formatting that indicates an amount rather than a number, so a contract value of 1 234 567 890 stays readable in your transcript.

Names. Aelo does not remove personal names. They cannot be identified reliably by pattern, and greeting a customer by name is frequently part of what your scorecard measures — removing names would break your own evaluation.

Numbers spoken as words. When someone dictates a number aloud — “plus thirty-four, six hundred eleven…” — speech recognition writes it out as words, and no pattern can catch that. Redaction covers identifiers written in structured form.

Addresses and dates of birth. These are indistinguishable from ordinary speech and cannot be detected without removing legitimate content.

Redaction applies to the text. The original audio recording is stored unchanged until your retention period expires, so a number spoken during a call remains audible in the recording. Recordings are encrypted at rest and subject to the customer’s configured record-retention period (1–365 days, 365 by default) and the same record-deletion path as the rest of the record.

Transcripts processed before the current write-time guard became active were stored in full and have not been rewritten. Historical transcript previews, metadata text and word-level timestamps may also retain the originally written text. They remain subject to the customer’s configured retention period. The write-time behaviour described here applies to new conversations processed through the current application repository paths.

If you use auto-fill for empty CRM fields, one case changes: a field whose value is itself a phone number or an email address can no longer be filled from what was said during the call, because the analysis works from the redacted text.

The contact’s own number is unaffected — it reaches the CRM from the record itself, not from the transcript. Every other kind of field — an amount, a date, a product interest, a choice from a list — is unaffected too, because none of those are redacted.