Does an AI Receptionist Have to Support 911 Calls?

Usually no. 47 CFR §9.16 puts 911 direct-dial, on-site notification and dispatchable-location duties on the multi-line telephone system (MLTS) and on whoever manufactures, imports, sells, leases, installs, manages or operates it — not on an inbound AI answering layer. The rules reach MLTS installed after February 16, 2020, with location deadlines of January 6, 2021 and January 6, 2022.

That is the correct answer to the question as most buyers ask it, and it is also the answer that gets people into trouble, because the scope test is about where the AI sits in the call path, not about what the vendor calls the product. Kari’s Law (47 U.S.C. §623) and Section 506 of RAY BAUM’S Act are implemented by the Federal Communications Commission in 47 CFR §9.16, and §9.3 defines an MLTS broadly enough to include Centrex, VoIP, PBX, Hybrid and Key Telephone Systems. So the real question a technical buyer needs answered is: does bolting an AI receptionist onto my phone system make me an MLTS installer, manager or operator — and does it break direct dialling, swallow the notification, or destroy the location the Public Safety Answering Point (PSAP) needs?

This page answers that from the regulation itself. Every string in quotation marks below appears verbatim on the page it is attributed to. It is general information about a published rule, not legal advice.

What 47 CFR §9.16 actually requires, by device class

The single most useful thing to understand is that §9.16 has three separate obligations with three separate trigger dates, and they bind different roles. Read down the “who it binds” column before you read anything else.

MLTS 911 obligations by role and device class, 47 CFR §9.16

Obligation	Who it binds	What the rule requires	Date	Qualifier in the text	Provision
Direct 911 dialling — pre-configuration	Manufacturers, importers, sellers, lessors	System pre-configured so that, properly installed, “a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9”	Compliance date February 16, 2020	None stated	§9.16(a)(1)
Direct 911 dialling — as configured	Installers, managers, operators	Same standard, applied to the system as actually configured for use in the United States	Compliance date February 16, 2020	§9.3 permits extra patterns such as 9-911: “if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern”	§9.16(b)(1)
MLTS notification	Installers, managers, operators	Notification “to a central location at the facility where the system is installed or to another person or organization regardless of location”. It “must be initiated contemporaneously with the 911 call, provided that it is technically feasible to do so”, “must not delay the call to 911”, and “must be sent to a location where someone is likely to see or hear it”	Compliance date February 16, 2020	Required only “if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system”	§9.16(b)(2)(i)–(iii)
Capability to convey location	Manufacturers, importers, sellers, lessors	System must have the capability, after proper installation, of providing the dispatchable location of the caller to the PSAP with 911 calls	No date in the sub-paragraph; the FCC’s compliance timeline lists §9.16(a)(2) with (b)(3)(i) under January 6, 2021 and with (b)(3)(ii) and (iii) under January 6, 2022	None stated	§9.16(a)(2)
On-premises fixed telephones	Installers (capable of being programmed with and conveying); managers and operators (actually conveyed)	“shall provide automated dispatchable location”	No later than January 6, 2021	No technical-feasibility escape hatch in this sub-paragraph	§9.16(b)(3)(i)
On-premises non-fixed devices	Installers, managers, operators	Automated dispatchable location to the appropriate PSAP; failing that, “dispatchable location based on end user manual update, or alternative location information as defined in §9.3”	No later than January 6, 2022	Automated location required “when technically feasible”	§9.16(b)(3)(ii)
Off-premises devices	Installers, managers, operators	Automatic dispatchable location; failing that, manual update or “enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost”	No later than January 6, 2022	Automatic location required “if technically feasible”	§9.16(b)(3)(iii)

Two details worth carrying into a vendor conversation. First, the regulation uses “automated” in (b)(3)(ii) and “automatic” in (b)(3)(iii) — the FCC’s own compliance page describes both as automated dispatchable location, but if you are drafting contract language, quote the sub-paragraph rather than the summary. Second, §9.16(b)(3) cross-refers to “paragraphs (i), (ii) and (iii) of this section”, which in context means the three sub-paragraphs of (b)(3). Every cell above is drawn from the text of §9.16 as published by the Legal Information Institute, cross-checked against the eCFR rendering of Part 9, Subpart F.

Who is not covered: the boundary that is the whole answer

A QUALIFY question is answered by its boundary. Four exclusions do most of the work here.

1. Answering inbound calls is not the regulated path. §9.16(b)(1) is about whether “a user may directly initiate a call to 911 from any station equipped with dialing facilities”. An AI receptionist that answers calls arriving at your published number is on the terminating leg. It is not a station your staff dial out from, and nothing in §9.16 requires an answering service — human or AI — to detect an emergency, transfer to a PSAP, or act as a 911 route. If you are working out where the agent physically attaches, our note on how an inbound AI caller sits on your phone line covers the trunk-and-number side of it.

2. Legacy systems. §9.17(b) sets the compliance date for Subpart F at February 16, 2020 “unless otherwise noted”, and applies the subpart to systems “manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020, unless otherwise noted”. The two qualifiers matter: the dispatchable-location dates in §9.16(b)(3) are the “otherwise noted” ones. Read the boundary carefully, too — the regulation excludes systems installed on or before February 16, 2020, and the FCC’s own timeline correspondingly lists the direct-dial and notification obligations as attaching from February 17, 2020. The FCC’s hub page states that the rules “do not apply with respect to any MLTS that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed on or before February 16, 2020”. The Commission’s MLTS FAQ adds that some legacy systems may still be covered by state versions of Kari’s Law enacted before the federal law, so the federal exemption is not the end of the enquiry.

3. Anything that is not an MLTS. §9.15 applies Subpart F to MLTS and to persons in the business of manufacturing, importing, selling, leasing, installing, managing or operating them. A sole trader on a single mobile service with an AI answering their calls is outside it. Note the FAQ’s expansion in the other direction, though: the definition also reaches outbound-only MLTS that let users make 911 calls but do not let PSAPs call back.

4. Anything outside the United States. §9.16 regulates manufacture, import, sale, lease, installation, management and operation “for use in the United States”. It has no application to an Australian deployment.

When the answer changes: four deployments that pull an AI layer into scope

Each of these moves the AI layer from “adjacent application” to “part of the system that owes duties”.

The AI terminates the trunk or owns the dial plan. §9.3 defines a person engaged in the business of installing an MLTS by the tasks performed, which “may include, but are not limited to, establishing the dialing pattern for emergency calls, determining how calls will route to the Public Switched Telephone Network (PSTN), and determining where the MLTS will interface with the PSTN”. A voice-AI deployment that sits as a session border element in front of the PBX, or that rewrites dial patterns, is doing exactly those things. The definition also notes those tasks “may also be performed on a more or less regular basis by the MLTS operator as the communications needs of the enterprise change” — so this is not a one-time question answered at go-live.

The deployment counts as a core upgrade. If your MLTS predates the cut-off, the legacy exemption holds only until you change the system materially. The FCC’s MLTS FAQ says: “While not all upgrades trigger coverage by Kari’s Law, we generally consider upgrades to core MLTS software or hardware functions to be of sufficient magnitude to bring an MLTS within the scope of the statute and rules.” Whether an AI answering layer is a core upgrade or an adjacent endpoint is a factual question about your architecture, and it is worth getting the vendor to answer it in writing.

The AI console becomes the notification destination. Vendors routinely offer to pipe system events into an agent dashboard or ticket queue. If MLTS notification lands there, §9.16(b)(2) now applies to that destination.

Staff use it as their phone system. The moment softphones behind the AI layer are the stations your employees dial from — including remote workers — you are in §9.16(b)(3)(ii) and (iii) territory, with the January 6, 2022 date and the location fallbacks that go with it.

The Interception Test: six checks to run against a voice-AI vendor

Here is the failure mode stated plainly, then the test that finds it. An AI answering layer creates a 911 problem only when it intercepts a path the regulation protects — the outbound dial path from a station, the notification path to a person, or the location path to the PSAP. Marketing copy never tells you which paths a deployment touches. These six questions do. They are the checks we would want run against any vendor in this category, including us.

The Interception Test — six architecture checks, each traced to the provision it tests

#	Check	What to ask the vendor	Fail signal	Provision tested
1	Dial path	Is the agent inbound-only, or does any outbound leg from a staff station traverse your platform?	The platform proxies or re-originates staff outbound calls but the vendor has never considered 911	§9.16(b)(1)
2	Digit map	Can anything — a prefix, an access code, a menu step, an agent barge-in — be interposed before a dialled 911 completes?	911 is treated as a normal destination in a dial plan that requires a trunk-access digit	§9.16(b)(1); §9.3 “Pre-configured”
3	Notification destination	Where does MLTS notification land, and is a human likely to see or hear it there?	Notification routed into an autonomous queue, agent inbox or ticketing webhook with no person on the other end	§9.16(b)(2)(iii)
4	Location source	Which system computes dispatchable location, from what data, and is it automated?	“The agent asks the caller for their address”	§9.16(b)(3)(i)–(iii); §9.3
5	Upgrade magnitude	Does deployment modify core MLTS software or hardware functions, or attach as an adjacent SIP endpoint?	Vendor will not answer in writing, on a system installed before February 16, 2020	§9.17(b); FCC MLTS FAQ
6	Named responsibility	Who is the MLTS manager of record after go-live, and does the contract say so?	Silence — which leaves the regulatory presumption where it already sits	§9.17(a)(2)

Check 2 is the one people skip because they think of an AI agent as a menu replacement. It is not: an inbound attendant and a dial plan are different objects, which is the distinction we drew in AI voice agents versus IVR phone trees. Check 3 has a subtlety worth knowing: the FCC’s MLTS FAQ states that the destination point “must be a location where someone is likely to see or hear the notification, but it does not have to be continuously staffed or monitored”. Unstaffed is permitted; unread by any human is a different proposition, and a queue that only a bot consumes is not obviously a location where someone is likely to see or hear it. If your escalation design depends on getting a person onto the call quickly, the mechanics in our piece on handing a live call to a human with context are the relevant ones.

Why a dispatchable location cannot be derived from a conversation

This is the check that fails most often, and it fails for a definitional reason rather than an engineering one. §9.3 defines dispatchable location as “the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party”. The FCC’s MLTS FAQ defines the automated version as location “that is generated automatically, without action by the 911 caller”.

An agent that asks “what is your address?” produces the opposite of that on both counts. It is caller-supplied, so it is not generated without action by the caller; and it is unvalidated free text, so it is not a validated street address. At best it is “dispatchable location based on end user manual update” — which §9.16(b)(3)(ii) and (iii) permit only for on-premises non-fixed and off-premises devices, and only where automated location is not technically feasible. For on-premises fixed telephones, §9.16(b)(3)(i) states the requirement flatly, with no feasibility qualifier: automated dispatchable location, no later than January 6, 2021. No conversation satisfies it.

There is a narrow, related arrangement the Commission has addressed. Some enterprises route 911 to an on-site security desk or response team rather than straight to the PSAP. The MLTS FAQ says the Bureau “does not interpret Kari’s Law as requiring such routing arrangements to be changed, but advises enterprises and MLTS managers and operators to consult with state and local 911 authorities”, and describes those arrangements as operating with the knowledge and consent of the local PSAP. An autonomous voice agent is not an on-site emergency response team, and treating it as one would be reading that guidance well past what it says.

Who carries the risk, and what the rule does and does not say about penalties

§9.17(a)(2) is short and it settles most contractual arguments: “In the event of noncompliance with §9.16(b), the person engaged in the business of managing the multi-line telephone system shall be presumed to be responsible for the noncompliance.” That presumption sits with the enterprise’s MLTS manager unless something displaces it. A vendor agreement that is silent on who manages the system does not move it.

On consequences: §9.17(a)(1) provides that §§9.16(a)(1) and (b)(1) and (2) “shall be enforced under title V of the Communications Act of 1934, as amended, 47 U.S.C. 501 et seq., except that section 501 applies only to the extent that such section provides for the punishment of a fine”, and §9.17(a)(3) allows complaints under §§1.711 through 1.737. The FCC’s hub page states that it “will closely monitor any complaints about alleged violations of these 911 rules”. We are not quoting a dollar figure here, because neither §9.16 nor §9.17 sets one — amounts come from the enforcement provisions and the Commission’s inflation-adjusted forfeiture schedules, and deriving a number from those is a job for counsel, not for a vendor blog. If you are building the wider control set around an AI calling deployment, our write-up on compliance architecture for AI sales agents in regulated industries covers the documentation layer.

Australia: the same question has a different regulator

Kari’s Law and Section 506 of RAY BAUM’S Act are United States federal law, and §9.16 is expressly limited to conduct “for use in the United States”. Australia regulates the emergency call service through a separate instrument, the Telecommunications (Emergency Call Service) Determination 2019, made under the Telecommunications (Consumer Protection and Service Standards) Act 1999 and in force as a 1 November 2025 compilation. Its structure tells you where the duties land: Part 2 sets requirements for carriers and carriage service providers, Part 3 sets requirements for the emergency call person. An application-layer answering service is neither. We could not locate an Australian instrument imposing Kari’s Law-style direct-dial or on-site-notification obligations on enterprise phone systems; we looked at the Determination’s table of contents on the Federal Register of Legislation and at the ACMA’s published emergency-call service pages. Treat that as not located rather than as settled, and check with an Australian telecommunications lawyer before relying on it.

Frequently asked questions

Does my AI receptionist have to support 911?

Not under 47 CFR §9.16, if it only answers inbound calls. The rule’s direct-dial obligation is about whether a user can initiate a call to 911 from a station equipped with dialling facilities, and it binds the MLTS and its manufacturer, seller, installer, manager or operator. An inbound answering layer is on the other leg of the call. The answer changes if the same platform sits on your outbound dial path.

Is an AI answering service a multi-line telephone system?

Not by itself. §9.3 defines an MLTS as a system of common control units, telephone sets, control hardware and software and adjunct systems, naming Centrex, VoIP, PBX, Hybrid and Key Telephone Systems. The FCC’s MLTS FAQ reads that definition as covering the full range of networked communications systems serving enterprises, including IP-based and cloud-based systems. Whether a specific AI deployment forms part of that system depends on whether it performs control and routing functions or attaches as an endpoint.

What happens if I add an AI voice agent to a phone system installed before 2020?

It depends on how deep the change goes. The FCC’s MLTS 911 page confirms the rules do not apply to systems installed on or before February 16, 2020, but the Commission’s MLTS FAQ states that “we generally consider upgrades to core MLTS software or hardware functions to be of sufficient magnitude to bring an MLTS within the scope of the statute and rules”. Ask the vendor, in writing, whether deployment modifies core MLTS software.

Can an AI agent collect the caller’s address instead of automated dispatchable location?

Not for on-premises fixed telephones. §9.16(b)(3)(i) requires automated dispatchable location for those devices, with no technical-feasibility qualifier, and the FCC’s MLTS FAQ defines automated dispatchable location as location generated automatically, “without action by the 911 caller”. Caller-supplied address information is at best the manual-update fallback, which §9.16(b)(3)(ii) and (iii) allow only for non-fixed and off-premises devices where automated location is not technically feasible.

If 911 fails, is my vendor liable or am I?

The regulation names a starting point rather than a final answer. 47 CFR §9.17(a)(2) provides that where there is noncompliance with §9.16(b), the person engaged in the business of managing the MLTS “shall be presumed to be responsible for the noncompliance”. Contractual allocation between you and a vendor is a separate matter from the regulatory presumption, and does not by itself displace it.

Do Kari’s Law and RAY BAUM’S Act apply to my Australian business?

No. Both are United States federal instruments and §9.16 is limited to systems manufactured, imported, sold, leased, installed, managed or operated “for use in the United States”. Australian emergency-call obligations run through the Telecommunications (Emergency Call Service) Determination 2019, whose Part 2 addresses carriers and carriage service providers. If you operate a US site or US-based remote staff on the same platform, the US rules can still reach that deployment.