Almost always, yes. Section 6(1) of the Privacy Act 1988 (Cth), as in force on 4 June 2026, defines personal information as information about an identified individual or an individual who is reasonably identifiable, and the OAIC gives a telephone number as a common example. Which field it sits in changes nothing.
The hard half is that on an agentic voice platform the number of the caller does not only sit in a database column you control. It is copied into identifiers — room names, span attributes, call-statistics log lines — places a retention policy was never written to reach. This page is the boundary: what is inside the definition, what is genuinely outside it, and the four conditions that move a field across. It is general information only; the determination is fact-specific and the regulator whose guidance governs it is the Office of the Australian Information Commissioner.
The definition, in the words the Act actually uses
Compilation No. 104 of the Privacy Act 1988 (Cth), compiled 4 June 2026, defines it at s 6(1):
personal information means information or an opinion about an identified individual, or an individual who is reasonably identifiable: (a) whether the information or opinion is true or not; and (b) whether the information or opinion is recorded in a material form or not.
Both limbs matter and neither may be dropped. Paragraph (b) decides the question people actually ask: a value does not have to be in a record or a database to be personal information. A number rendered into a log line is information about an individual in exactly the sense the definition uses. The OAIC APP Guidelines put a telephone number on their own list of common examples at paragraph B.89.
The Guidelines add a point at B.31 that is rarely quoted and directly on point: collection “may also take place when an APP entity generates personal information from other data it holds, such as the generation of an audit log”. On that reading, writing the number into a log line is itself a collection event, not a side effect of one.
The boundary: what is NOT personal information in your logs
The definition has a real edge, and the page is worth nothing if it pretends otherwise. Things that sit outside it, on ordinary facts:
- The number dialled, not the number calling. A LiveKit callee dispatch rule names the room after the called destination. Where that is a business line, the room name is not information about the caller at all.
- Synthetic call identifiers. SIP call ID, trunk ID, dispatch rule ID, job ID, room SID — platform-generated, carrying no caller-derived value.
- Aggregate counters. Audio packet counts, retransmission totals, duration in minutes, codec labels. Facts about a session, not about a person.
- A value nobody could practically resolve. The OAIC states at B.96 that the test is objective and has practical regard to context: even where identification is technically possible, if doing so is so impractical that there is almost no likelihood of it occurring, the information would not generally be regarded as personal information.
The trap in that last bullet is who “nobody” means. The Guidelines answer it at B.95 with a licence plate: most entities could not identify a car owner from one, but an entity with access to the registration database could, so the same string is personal information in one set of hands and not in another. Your hands hold the call record. That fact decides most of these questions.
The identifier is a data flow
The rule worth taking away, which we use as a design check:
The identifier-is-a-data-flow rule: anything you name a session after has already been exported to everywhere that session was observed. If a value would need redacting in a log line, it must not appear in a name.
The platform vendor says this first. LiveKit documents it on its own dispatch rule page as a warning, read 18 September 2026: an individual dispatch rule “names each room after the caller’s phone number, which is personally identifiable information. Room names are recorded in logs and traces throughout LiveKit and aren’t removed by PII redaction.”
The mechanism is visible in the source. In livekit/protocol, EvaluateDispatchRule sets the room to the caller number, prefixes it if a room prefix is configured, and appends a random suffix unless no_randomness is set; it sets the participant identity to the literal string sip_ joined to that same number. Both travel with the session, and a transcript redaction setting will never touch either, because neither is in the transcript. Finding these leaks in a stack you did not build is a procedure of its own, covered in our walkthrough on auditing a voice platform for leaked keys and PII.
Threshold table: this field, in this place, on these facts
Verified against the LiveKit SIP documentation, the livekit/protocol source on main (last commit touching sip/sip.go dated 4 September 2026) and the livekit-agents 1.8.2 release, all read 18 September 2026.
| Where the value lands | What the value is by default | Personal information? | Does your retention policy reach it? |
|---|---|---|---|
| Call record in your own database | Full caller number | In scope | Yes — this is the field the policy was written for |
| Room name, individual dispatch rule | Prefix, full caller number, random suffix | In scope | Usually not — room names outlive the call in logs, traces, webhook bodies and recording metadata |
| Participant identity, individual rule | sip_ joined to the full caller number |
In scope | Usually not — identity is a join key across systems |
Participant attribute sip.phoneNumber |
Full caller number | In scope | Depends — omitted entirely when hide_phone_number is set on the rule |
Room name with hide_phone_number set |
Last four digits plus random suffix | Depends on what else you hold | Partially — it is a shorter string, not a different kind of string |
Participant identity with hide_phone_number set |
sip_ joined to 16 hex characters of a SHA-256 digest |
Depends — you can recompute the digest | No, and it still links every record of that caller together |
| Agent trace span attribute for the room name | Marked lk.pii.room_name in 1.8.x |
In scope | Yes on that path — the in-process filter drops it under project redaction |
| SIP call-statistics log line | Bound room field |
In scope | No — field-level redaction was declined on 3 September 2026 (see below) |
| Room name inside a span name or a log message body | Whatever the room is called | In scope | No — the LiveKit telemetry module states these are not redactable |
| Third-party observability or error-tracking backend | Everything above that was exported | In scope | You still hold it under s 6(1) — see the next section |
| Callee dispatch rule room name | The number that was dialled | Out of scope as to the caller | Not applicable |
| SIP call ID, trunk ID, rule ID, room SID | Platform-generated | Out of scope | Not applicable |
What changes the answer
Four conditions move a field across the boundary.
1. What else you hold. The OAIC lists the factors at B.94; the one that decides this case is other information either held by or available to the APP entity that holds the information. Truncating to the last four digits removes nothing if the full number is one join away in your CRM. This is the licence plate case, and you are the registration database.
2. Whether you can reverse it. Setting hide_phone_number on the dispatch rule replaces the participant identity with a truncated SHA-256 digest of the number, cuts the room name back to the last four digits, and omits the number from participant attributes entirely. The truncation and the digest come from the livekit/protocol source rather than from the dispatch rule reference: EvaluateDispatchRule in sip/sip.go reassigns the number to its last four digits before the room-naming switch reads it, at lines 890 and 931 as at 18 September 2026. The attribute omission is the documented part, on the LiveKit SIP participant reference. The OAIC de-identification guidance classifies hashing of identifiers as a technique that “will obscure the original identifier, rather than remove it altogether”, and treats information as de-identified only where there is no reasonable likelihood of re-identification occurring in the relevant release context. You hold the input, so you can always recompute the digest: a good control for a third party you export to, not de-identification in your own hands.
3. Who is looking. The same room name can be out of scope in an aggregated vendor dashboard and in scope in your own log aggregator, because the surrounding context differs. Where the data is then allowed to land is a residency question: our page on data residency for AI voice agents walks the audio and the transcript hop by hop and covers APP 8 cross-border disclosure, which this page does not.
4. Whether you still hold it. Under s 6(1) an entity holds personal information if it has possession or control of a record containing it. The OAIC extends that at B.84 to a record you have the right or power to deal with, even if it does not physically possess or own the medium — expressly including storage outsourced to a third party. Your observability vendor holding your room names does not move them off your books.
What APP 11 actually requires, quoted in full
APP 11.1: if an APP entity holds personal information, it must take such steps as are reasonable in the circumstances to protect the information (a) from misuse, interference and loss; and (b) from unauthorised access, modification or disclosure.
APP 11.2 is the destruction obligation, and it is four conjuncts, all of which must be satisfied before the duty bites. If (a) an APP entity holds personal information about an individual; and (b) the entity no longer needs the information for any purpose for which it may be used or disclosed under Schedule 1; and (c) the information is not contained in a Commonwealth record; and (d) the entity is not required by or under an Australian law, or a court or tribunal order, to retain it — then the entity must take such steps as are reasonable in the circumstances to destroy the information or to ensure that it is de-identified. Paraphrases that drop limb (c) or (d) make the obligation broader than the Act; paraphrases that stop at limb (a) make it narrower.
The OAIC adds at paragraph 11.39 of its APP 11 guidance that those steps must reach all copies it holds, including copies archived or held as back-ups, and at 11.51 to 11.52 that where irretrievable destruction is impossible, putting the information “beyond use” can be the reasonable step instead. A retention window that expires the line is the ordinary way to satisfy this; a room name replicated into six systems is the ordinary way to fail it.
What the platform shipped, and what it declined
Two feature requests against livekit/sip record practitioners hitting exactly this. Both are closed, and closed does not mean fixed. Status and dates re-verified against the GitHub API on 18 September 2026.
- Issue #726, “Feature Request: PII-safe room names for Individual / Callee dispatch rules”, opened 15 June 2026 and closed 20 July 2026. The maintainer closed it stating there were no major action items, suggested a callee rule with randomisation as a short-term way not to store the caller number, and named webhook-based dispatch rules as the long-term solution.
- Issue #821, “Feature request: field-level log redaction for the SIP call-statistics line (room name may carry caller-derived data)”, opened 30 August 2026 and closed 3 September 2026. The maintainer reply is explicit: there is no plan to add redaction of that kind, and webhook-based room creation is the intended answer.
Our own backlog note for this page had recorded the opening dates as the close dates. Correcting that changed the conclusion: nothing shipped on the log path, so there is no redaction flag to wait for.
The telemetry path moved in the opposite direction. livekit-agents 1.8.0, released 5 September 2026, moved PII filtering in-process: content was previously stripped at the LiveKit Cloud collector, and under project redaction it now never reaches any exporter, Cloud included. The room name is covered on that path — the span attribute constant is literally named lk.pii.room_name, and the filter drops any attribute whose key contains a dot-delimited pii segment. That is the agent SDK span, not the same path as the platform-side logs and traces the dispatch rule warning is about, which is why both statements are true at once. The module docstring states the limit plainly: content must never be embedded in span names, event names or log message bodies, because those are not redactable. The current release is 1.8.2, published 15 September 2026. What that filter does and does not cover is the subject of our guide to OpenTelemetry spans for voice agents.
A note on counting, because a false zero is easy here: GitHub issue search does not stem. Searching the full text of every issue in livekit/sip, open and closed, on 18 September 2026: redact returns one issue, redaction returns two and PII returns three, one of them unrelated. Three separate single-repository counts on one query form, not a total, and a title-scoped or open-only search returns different numbers again — and the one-result query is the one that would have hidden #726.
Doing this yourself versus handing it over
The method above is genuinely runnable. Name the room after a value you generated rather than one the caller supplied — the documented route is a callee rule over a wildcard trunk where you control the destination user part, so the room takes your own unique ID. Pass the caller number as a participant attribute instead, where it is a field that can be omitted. Then audit for copies: log aggregator, metrics labels, trace backend, error tracker, recording filenames, webhook receivers. Set a retention window on each and verify it fires.
| Situation | Do it yourself | Hand it over |
|---|---|---|
| One dispatch rule, one log sink, calls in one country | Yes — a configuration change and one retention setting | Not worth the overhead |
| Identifiers already in production and replicated to third-party backends | Possible, but you are now doing back-fill across systems you do not own | Worth pricing |
| A regulator or an enterprise buyer is asking where the number goes | Only if you can produce the hop-by-hop map on request | Yes — the evidence is the deliverable, not the config |
| Transcripts or identifiers cannot leave your own network at all | Not achievable on a shared control plane | Private deployment is the only structure that answers it |
The honest cost of the do-it-yourself path is not the change, which is an afternoon. It is the standing work: someone re-runs the audit each time a plugin, an exporter or a dispatch rule changes, and keeps the map current enough to hand to a buyer. That is why Zian AI supports private model deployment on customer infrastructure — so where an identifier may travel has a structural answer rather than a configuration answer. The reform timetable that will change parts of this is tracked in our Privacy Act review preparation guide, and whether you may record the call at all is a separate statute covered in call recording laws in Australia for AI agents.
Frequently asked questions
Is a phone number personal information under the Privacy Act?
In almost every case, yes. Section 6(1) of the Privacy Act 1988 (Cth) covers information about an identified individual or an individual who is reasonably identifiable, and the OAIC lists a telephone number among its common examples of personal information in Chapter B of the APP Guidelines. This is general information and the determination is fact-specific.
Does it stop being personal information because it is in a log line and not a database?
No. Limb (b) of the section 6(1) definition applies whether or not the information is recorded in a material form, so the container does not decide the question. The OAIC also treats generating an audit log as a collection of personal information in its own right.
Does keeping only the last four digits solve it?
Not by itself. The OAIC test asks what other information the entity holds or has available. If the full number is one lookup away in your own CRM or call record, the shortened value is still about an individual who is reasonably identifiable by you, even where it would not be by a stranger.
Does hashing the caller number count as de-identification?
The OAIC describes hashing of identifiers as obscuring the original identifier rather than removing it, and treats information as de-identified only where there is no reasonable likelihood of re-identification in the relevant release context. Because you hold the input, you can recompute the digest, so it is a control on export rather than de-identification in your own systems.
Does APP 11.2 force me to delete every log line that contains a number?
Only when all four of its conditions are met at once: you hold it, you no longer need it for any purpose permitted under Schedule 1, it is not in a Commonwealth record, and no Australian law or court or tribunal order requires you to keep it. When they are met, the duty is to take reasonable steps to destroy or de-identify the information, and the OAIC says that reaches every copy you hold, including archives and backups.
My observability vendor stores the room names. Is that still my problem?
Yes. Under section 6(1) an entity holds personal information if it has possession or control of a record containing it, and the OAIC extends that to a record you have the right or power to deal with even where a third party stores it. Outsourcing the storage does not move the obligation.
Next step
If you want a straight answer on where a caller identifier travels, that is a conversation worth having before the pilot.