Skip to main content
Back to blog

ITU-T PIN and Remote-Party Determination — What the 60-Day AI-Voice Study Is Actually Deciding

The ITU-T's PIN (remote-party determination) work item asks how a network should establish whether the remote party on a voice call is a person or a machine — and how that determination should travel. Here is what the 60-day study window is deliberating, what platforms ship today, and which of the controls is yours to set rather than wait for.

Orbit Editorial Team

Quick answer: The ITU-T's PIN work item — PIN as in remote-party determination, the question of what kind of party is on the far end of a call — is deliberating one problem from two directions. The first: how a network establishes whether the remote party on a voice call is a human or a machine, and how that determination travels alongside the call so the network does not have to take the originator's word for it. The second, from the outbound side: when a machine is the calling party, how the called party learns it before entrusting anything to the conversation. It is a standards-track study with a stated 60-day deliberation window, not a shipped specification — so the honest read is that nothing called "PIN support" can exist in any platform yet, anyone selling it is selling vaporware, and the decisions that matter for a CPaaS buyer are the ones the study will make about signaling paths, marking granularity, and who is allowed to make the determination in the first place. This post maps what is being decided, what Devotel Orbit already ships on the AI-voice side regardless of the outcome, and which parts of your AI-disclosure posture are tenant-owned controls you can set today.

This is the buyer-facing explainer in the same family as the number regulatory preview post — timed news desk, not a product announcement: a standards conversation your AI-voice roadmap will eventually intersect, plus the tenant-owned posture you can run while it runs.

The boundary is deliberate, not a gap

The absence of a "PIN implementation" section in any vendor's feature list is a deliberate industry boundary — the study is still deciding what there is to implement.

Three questions the deliberation has to close before an implementation can exist:

  • Where does the determination live? An originating platform can declare "this caller is an automated agent" the way an outbound platform declares an attestation level under STIR/SHAKEN. A terminating network can infer machine-likeness from audio characteristics. Those are different architectures with different trust properties — a declaration relies on the originator's honesty, an inference relies on a classifier the originator does not control. The study has to pick, or define how the two coexist.
  • What granularity does the marking carry? A binary human-or-machine flag is the crude version. A richer answer names the machine's operator, its purpose class, or a disclosure it committed to making. Each step up in granularity is a step up in the identity and trust infrastructure underneath it — the same trajectory caller identity took from STIR/SHAKEN attestation up to Rich Call Data branding.
  • Who is trusted to make it? Whatever the marking is, someone signs it, and the ecosystem has to decide whose signature a terminating carrier is willing to lean on. US caller-identity precedent says attestation failures concentrate at interconnect points; a party-determination scheme inherits that trust question wholesale.

Until those three settle, "PIN support" in a marketing page is a promise against an unfinished spec. The boundary between "study in progress" and "shippable product" is exactly where the industry is standing, and standing there is the correct behavior — shipping against a moving specification is how vendors end up with a compliance page full of retractions.

What a platform ships today, study or no study

None of the above changes what Devotel Orbit already ships on AI voice — the deliberation is about a network-carried determination, and everything below is platform-level and live now:

  • Native AI voice agents that answer and place calls, with a human handback path for the moment a conversation needs a person — described in the AI voice agents overview.
  • A published per-stage latency budget — endpointing, speech-to-text, model time-to-first-token, text-to-speech, and the media path, each with an open target and a methodology — on the latency benchmark page. A standards discussion about who is on the call does not change the physics of how fast the machine answers.
  • Per-call quality scoring that grades every AI conversation against rubrics you configure — including explicit binary checks for the disclosures your operation requires, like the AI-identification line an agent says in its greeting. Coverage of your outcome space is a rubric-design task you own, explained in the AI agent QA explainer.
  • Full-fidelity records of what actually was said — transcripts, recordings, and the per-call audit material a future party-determination regime would verify against, whatever form its marking takes.

What the study is still deliberating, and therefore what nobody ships: a standardized indicator on the call itself that a terminating network can consume, a trust model for whose determination counts, and the marking vocabulary — binary flag versus richer party description. When those close, platforms that kept clean records and explicit call semantics are the ones with a short integration distance.

The tenant-owned angle: your disclosure and party posture is a configuration, not a wait

The usable position during a standards window is the one Orbit's compliance model already assumes: disclosure obligations are obligations your operation carries — determined by your jurisdiction, your use case, and counsel's read of both — and the platform's job is to give you the controls to enforce them, never to decide them for you.

Concretely, on the outbound and inbound AI-voice side today:

  1. Write the AI-identification disclosure into the agent's opening. The greeting prompt is tenant-authored; a sentence that names the caller as an automated agent goes in it the same way a recording notice does. Which disclosure your operation owes is your call — say it plainly is a reasonable universal default.
  2. Score the disclosure as a pass/fail rubric. A disclosure the agent should deliver but occasionally skips is a silent failure unless something measures it. A binary rubric line — "the agent identified itself as automated in the first turn" — turns your disclosure posture into a per-call, reportable number instead of a prompt nobody audited.
  3. Keep the verification trail. Call transcripts and recordings are the evidence layer any future party-determination questions get answered from. A platform that retains them per call is holding your side of a conversation a regulator has not finished having yet.
  4. Decide for humans and machines, both directions. Inbound, the party question mirrors: an AI answering service receives machine callers too, and your posture toward them — answer, screen, route — is likewise a tenant setting, not a platform mandate.

A standard may eventually move some of this from "your prompt and your rubric" to "a field the network carries." It will not move the accountability: whose obligations, whose recordings, whose rubric. That allocation is the operating model whether the study lands in 60 days or six months.

A checklist for the study window

  1. Inventory where machines speak for you. List the flows where an AI agent originates or answers calls — the population a party-determination regime would touch first.
  2. Audit the greeting of each. Does the agent identify itself as automated, on every flow, in words a recipient understands?
  3. Make the audit a metric. For each flow, add the disclosure rubric so "says it" becomes "measured every call," not "written once."
  4. Track the study's three open questions — signaling location, marking granularity, trust model — as a monitoring task, the way outbound teams track attestation: an input to your roadmap, not a blocker on it.
  5. Keep the records. Transcripts and recordings per call, retained, so any future verification regime reads your traffic from evidence rather than from memory.

Frequently asked questions

Does Devotel Orbit support ITU-T PIN today?

No — and nothing called that can exist yet, because the study has not finished deciding what there is to support. The study is deliberating how a remote-party determination should be established and carried; until it closes, any "PIN support" claim is vaporware. What Orbit ships today is the platform-level side of the same problem: native AI agents with a latency budget, per-call quality scores, and the record layer a future determination regime would verify against.

Who decides whether my AI voice agent has to disclose itself?

You do, under the obligations your operation carries — jurisdiction, use case, counsel's read. The controls are tenant-owned: the disclosure lives in your agent's greeting prompt, and a rubric you configure can score whether the agent delivered it on every call. Orbit does not decide your disclosure posture; it makes the posture you chose measurable.

Is remote-party determination the same problem as STIR/SHAKEN attestation?

Adjacent, not the same. Attestation proves the number — that a network authenticated the caller's right to use the calling number. Party determination asks what kind of caller — human or machine — is on the call, and how that fact travels. The architectures inform each other: declaration versus inference, who signs the claim, how a terminating network consumes it. Attestation took years to settle the same questions for number identity; the AI-party study is earlier in the equivalent arc.

If the study standardizes a machine-party marker, is my disclosure work wasted?

No. A network-carried marker would change how the determination travels, not whose obligation disclosure is — and your rubric, greeting, and records stay the foundation any marker gets built on. Configuration you set now is the shortest path to compliance under whatever granularity the study lands on.

What exactly should I watch in the 60-day window?

Three outputs: the signaling decision (whether the determination is originator-declared, terminator-inferred, or both), the marking granularity (binary flag versus a richer party description), and the trust model (whose determination a network is willing to rely on). Each maps to an integration question for your AI-voice stack — none of them maps to "stop shipping."

The takeaway

The ITU-T PIN study is worth tracking precisely because it is early: the signaling location, the marking granularity, and the trust model are all still open, which means the integration shape is not yet fixed — and the buyer move is not to wait for it. The tenant-owned posture you can run today is unchanged by how the study lands: say what the caller is talking to, score that the saying happens, and keep the records that turn a future question into a lookup. The AI agent QA explainer covers the rubric side; the attestation walkthrough covers the adjacent identity layer; and the latency benchmark is where the machine's side of the conversation is measured in the open.

Published 1 September 2026.

ITU-T PIN and Remote-Party Determination — What the 60-Day AI-Voice Study Is Actually Deciding — Orbit by Devotel