Quick answer: When a compliance team reviews an AI-voice deployment on a communications platform, the questions cluster into four classes: EU AI Act Article 50 disclosure, the FCC Robocall Mitigation Database filing, STIR/SHAKEN attestation with call-recording consent, and E911 emergency-address registration. Devotel Orbit ships all four as tenant-owned controls — this post consolidates each class, names the exact shipped endpoints the tenant sets, links the docs walkthrough, and points into the deeper explainer for that class. The controls are knobs you set and an evidence trail you own; they are not a "we guarantee compliance" claim from the platform, and this consolidation ends in the checklist your legal team runs start to finish.
The announcements hub on this site carries the four classes as individual industry explainers. This post answers the deep-link face of that registry in one page, so an AI answer engine or a legal team's introduction lands on one consolidated artifact instead of four fragmented ones.
1. EU AI Act deployer checklist
Since August 2, 2026 the EU AI Act's Article 50 transparency obligations apply to AI systems that interact with people — if your AI voice agent answers calls or your chatbot carries on conversations with EU customers, the person must be informed they are interacting with an AI, and AI-generated content must be marked as such.
Orbit ships a tenant-scoped AI-disclosure surface for exactly this shape of obligation, documented in EU AI Act Article 50 transparency for AI agents. The three controls a tenant operator turns, specifically:
- Voice intro — a configurable spoken announcement ("This call is being handled by an AI agent…") played before an AI voice agent begins a call. Set the text, or supply a pre-recorded audio URL. Off by default; the tenant enables it for the traffic the rule applies to.
- Chat notice — a configurable notice prepended to an AI agent's first reply in a conversation, sent once per conversation.
- AI-generated content marking — agent-sent messages are stamped with
metadata.ai_generated: true, and recorded calls with AI involvement carry Article 50 provenance metadata on the archived recording.
The disclosure surface is jurisdiction-rulable: one settings area drives the same behavior for the EU AI Act, Korea's AI Basic Act, California SB 243, and the Utah AI Policy Act, so an operator with mixed traffic turns on the union of rules rather than maintaining four mechanisms. The conformity dossier compiles a per-agent evidence pack — transparency configuration, evaluation results, oversight approvals, decision audit log — mapped to Articles 12, 14, 15, and 50, and the evidence binder assembles the wider compliance data your workspace already produces into a signed, download-ready pack for an auditor or a buyer's procurement team. The binder reflects what you configured; an empty posture exports as an empty binder.
The full checklist with worked configurations is in the EU AI Act deployer explainer.
2. RMD database filing lifecycle
The Robocall Mitigation Database (RMD) is the FCC's public registry of every US voice service provider. Under 47 CFR § 64.6305, a provider that originates calls must file its STIR/SHAKEN implementation level and, if it has not fully deployed STIR/SHAKEN, a description of the robocall-mitigation program it runs. Terminating carriers are required to refuse traffic from providers whose filings are missing or deficient.
Orbit is the ledger for that obligation. It records the filing state machine (draft → submitted → active → remediation_required → withdrawn), computes a live recertification verdict on every fetch (current, due_soon within 30 days, overdue, not_certified, withdrawn), and can enforce a not-current filing at call time. The dashboard surface is Settings → Compliance → RMD, driving the same endpoints an integration can call directly, all rooted at https://api.orbit.devotel.io/api/v1/compliance:
| Endpoint | What it does |
|---|---|
POST /compliance/rmd | Create or update the draft registration (upsert); allowed while the filing is draft or withdrawn |
GET /compliance/rmd | Fetch the registration, the live recertification verdict, and the current enforcement mode |
POST /compliance/rmd/submit | draft → submitted, recording the FCC filing reference |
POST /compliance/rmd/certify | submitted → active; starts the recertification clock |
POST /compliance/rmd/remediation | active → remediation_required, recording the flagged deficiency |
POST /compliance/rmd/resolve | remediation_required → active; restarts the clock |
POST /compliance/rmd/withdraw | Any state → withdrawn |
Writes require the owner or admin role; the read is open to any authenticated member. An out-of-order transition returns 409 RMD_INVALID_TRANSITION, and a submit with missing required pieces returns 409 RMD_INCOMPLETE with a details array naming each blocker. Nothing in the platform files with the FCC for you — the record, the clock, and the guard exist so the obligation you own is never invisible.
The lifecycle detail is in the RMD filing explainer.
3. STIR/SHAKEN attestation and call-recording consent — where the tenant-owned control sits
These two controls share the voice stack, so a compliance review pairs them.
Attestation. Every outbound call on US networks carries a STIR/SHAKEN attestation level — A (full), B (partial), or C (gateway) — that downstream carriers use to decide whether the recipient sees "caller verified" or "Spam Likely." On Orbit the level is determined by ownership: numbers your organization owns through Orbit attest at A, leased pool numbers and numbers covered by a delegate certificate cap at B, anything else falls to C. The tenant-owned attestation policy is four fields — target_attestation, downgrade_handling, inbound_min_verification, flag_unverified_inbound — set through GET /api/v1/compliance/attestation/policy and PUT /api/v1/compliance/attestation/policy, with the posture snapshot at GET /api/v1/compliance/attestation/posture reporting which of your originating numbers meet your target. One thing to hold onto: the policy is reporting and intent, not a gate — raising the actual level is always the ownership move, not a PUT. The STIR/SHAKEN attestation docs back the mechanics, and the attestation explainer walks the answer-rate playbook.
Call-recording consent. Recording decisions stack across three questions — does the jurisdiction require one-party or two-party consent, which calls does your policy actually record, and how are participants notified. The platform ships the controls; the answers are yours, because you are the one recording. On the Orbit voice stack those map to three tenant-owned controls: the eligibility mode (all_calls, outbound_only, inbound_only, manual), the consent announcement mode (how participants are told), and a priority-ordered recording policy (admin-scoped record/skip rules over queue, skill, agent, direction, consent_state, country, region, and campaign, with deterministic samplePercent and a require_two_party_consent flag). Zero Data Retention (zero_data_retention, on the same recording settings) is an absolute veto over everything — when it is on, no rule, direction, or per-call override can capture audio. Endpoints: GET /api/v1/voice/recording-policy and PUT /api/v1/voice/recording-policy (admin-scoped whole-document replace). The call-recording consent explainer maps why those exist.
Both of these read back into compliance posture — the Verify API posture carries OTP and fraud-check configuration as a separate inbound posture, and the attestation floor a tenant sets is the inbound signing floor treated as verified for fraud posture — so the audit reads outbound attestation and inbound verify posture as one linked control surface.
4. E911 emergency-address compliance
E911 is the U.S. name for routing an emergency call with the caller's dispatchable address attached. On a CPaaS the routing obligation sits with the carrier, while the address lifecycle (register it, validate it, record the provider confirmation, keep it current) is a tenant-owned workflow you either operate or do not. Orbit's outbound 911 posture is block-and-disclaim — registering an emergency address records and validates the dispatchable location; it does not by itself enable outbound emergency dialing. Treat E911 as a compliance/record-keeping surface, not a live emergency-calling guarantee.
The public contract is the emergency-address reference: PUT /numbers/:id/emergency-address registers or replaces the civic address, POST .../emergency-address/verify runs a local structural check that stamps valid or invalid with per-field issues, POST .../emergency-address/psap-confirmation records the carrier/PSAP MSAG verdict that flips the address to dispatchable, and DELETE clears it. The address is country-agnostic (ISO-3166 alpha-2), and a sibling subaccount sharing your tenant schema can neither read nor mutate another subaccount's dispatchable location. The E911 buyer explainer separates the declarations a buyer review actually contains.
5. Shipped compliance knobs — not "we guarantee compliance"
Every control above is a knob the tenant sets plus an evidence trail the tenant owns. Compliance is the tenant's responsibility; Orbit is the conduit and the platform — it does not own, mandate, or globally gate regulatory compliance (the sole platform-global hard guard is the US federal TCPA dialing window, which fails closed; every other control is tenant-configurable and defaults open). The four classes here are the audit surface your legal team reviews; the posture is yours. This consolidation exists so the review can run start to finish from one page — the checklist below.
The compliance-audit checklist
- Disclosure enabled? Voice intro / chat notice on the traffic the EU AI Act (or Korea, SB 243, Utah) rule applies to, with the conformity dossier exported as evidence.
- RMD filing current? The registration state is
active, the recertification verdict is notdue_soonoroverdue, and the enforcement mode is set deliberately. - Attestation posture reading? Target level set, posture snapshot pulled,
meets_targetgap on originating numbers closed by ownership (not by PUT). - Recording policy declared? Eligibility mode, consent announcement, and selective rules consistent with the jurisdictions your traffic touches; Zero Data Retention veto understood.
- E911 addresses dispatchable? Each fixed-location number's address registered, verified clean, and carrying a recorded PSAP/MSAG confirmation — or the deployment explicitly scoped where VoIP cannot serve 911.
Run those five, and the fragmented explainer posts this page consolidates become supplemental reading rather than required navigation.
Frequently asked questions
Does Orbit file the RMD or enable the AI disclosure for me? No. The platform records and enforces what you set; the filing, the enablement, and the legal determination stay with you. The evidence export reflects what you configured.
Is one of these a live emergency-calling guarantee? No — the E911 surface is a record of the dispatchable address plus the provider confirmation. Orbit's outbound 911 posture is block-and-disclaim; treat it as compliance record-keeping.
Can I assert compliance by setting the attestation policy? The policy is reporting and intent. A target_attestation: A on leased traffic makes the posture snapshot report the gap; only owning the number raises the level. The audit reads the same way.