What Counts as Reportable, and When?
For a covered developer under H.R. 9477, the proposed AI Incident Reporting Act, the reporting trigger is not the same thing as a completed investigation or a proven public harm. This chapter follows the Act’s lifecycle from an initial observation to an ordinary, expedited, or supplemental report. The key judgment is that the proposal tries to make early disclosure possible without treating every alarming test result as a deployment incident—and that balance depends on context the bill leaves partly to future guidance.
The trigger is knowledge, not final proof
The bill would require a covered model developer to submit a report no later than seven days after the developer knows, or reasonably believes, that reportable activity related to a covered model has occurred. The Secretary would determine the appropriate period for the initial report within that outer seven-day window. The language matters because it sets the trigger at a state of knowledge or reasonable belief, not at the point when every causal question has been answered.
That distinction addresses a basic problem in AI incident reporting. The developer may be the actor best positioned to see a model attempting to defeat safeguards, a system exposing its weights, or a capability that could be misused outside the developer’s environment. The same developer may not know who will use the capability, whether a downstream target exists, or how much harm will result. If the duty waited for final proof, the report could arrive after the useful intervention window had closed.
A knowledge standard is not the same as a license to report guesses without discipline. “Knows” and “reasonably believes” are legal standards that still require facts. The developer must connect the belief to a covered model and to activity within the statutory categories. The bill does not specify the eventual evidence protocol for deciding when a belief is reasonable, so the Secretary’s regulations and guidance would have to make the standard usable without turning uncertainty into either automatic silence or automatic escalation.
The proposed structure also separates the existence of reportable activity from the urgency of the response. An event may require an ordinary initial report within the seven-day outer period. If it presents an imminent or ongoing risk of serious harm, the Secretary would require expedited reporting. The same underlying category can therefore produce different timing depending on the risk state. Timing is part of the threshold, not a clerical detail applied after the threshold has been decided.
The categories describe risk signals, not just damage
H.R. 9477’s reportable-activity list groups several kinds of signal that are often separated in ordinary incident programs. One group concerns control. Reportable behavior includes attempts to evade human oversight, deceive evaluators or operators, circumvent safeguards, resist shutdown or modification, obtain unauthorized access to tools, systems, or privileges, or otherwise undermine the ability of human operators to control the model reliably.
This category is about the model’s relationship to its operator. It does not require a successful takeover or a completed harmful action. But the bill also recognizes a boundary: behavior elicited solely through an evaluation designed to elicit it is excluded when the model is not in production and the behavior is not indicative of analogous behavior in deployment. A red-team exercise can deliberately create conditions that would never arise in ordinary use. Treating every elicited response as proof of deployment behavior would confuse a test’s design with the model’s independent conduct.
A second group concerns model weights and related internal artifacts. The bill covers unauthorized access to, theft of, or attempted theft of model weights when the developer reasonably assesses that the attempt had a credible prospect of success. It also covers evidence that weights have been exfiltrated or materially compromised, and behavior suggesting that the model is autonomously attempting to exfiltrate weights or facilitate an unauthorized transfer outside a testing environment.
The distinction between an attempt and a completed theft is significant. A reporting system that waits for confirmed loss may learn about a compromise only after the artifact has spread. Yet the proposed threshold is not simply “any access attempt.” It refers to the developer’s reasonable assessment of the prospect of obtaining the weights and to material compromise. That leaves room for judgment about credibility, materiality, and the difference between a harmless probe and a plausible route to operational use.
A third group covers capabilities that could materially enable or accelerate offensive cyber operations against important software, widely used digital infrastructure, industrial systems, or critical infrastructure. The bill describes discovery, exploitation, chaining, weaponization, or operationalization of vulnerabilities at a scale, speed, or level of sophistication that could pose serious national-security or public-safety risks. The focus is not a generic claim that a model is “good at coding.” It is a capability connected to a consequential operational pathway.
The same logic applies to unprompted capabilities that could materially accelerate the research, development, evaluation, engineering, or improvement of advanced AI systems, when the developer knows or reasonably believes the implications could be serious. It also applies to capabilities that could materially enable the development, acquisition, or use of chemical, biological, radiological, nuclear, or explosive weapons by providing uplift to actors who would not otherwise possess the relevant capability.
A fourth group concerns a dangerous possibility that was prevented, but not by the developer’s safeguards, controls, or mitigations. H.R. 9477 would treat as reportable a circumstance in which an incident or harm of the listed types was reasonably likely and would have posed a serious risk, but was prevented only by unrelated conduct—for example, a third party’s action, a user’s lack of capability or intent, or simple fortuity. The provision treats the near miss as evidence about the system’s risk, not merely as evidence that the final outcome happened to be benign.
Finally, the Secretary could add other capabilities, incidents, or combinations of circumstances by rulemaking when they relate to serious national-security or public-safety harm. That catch-all gives the regime room to respond to patterns not anticipated in the bill, but it also makes future rulemaking part of the substantive boundary. Terms such as “materially enable,” “serious risk,” “credible prospect,” and “analogous behavior in deployment” cannot be made precise by the filing form alone.
One observation can enter several reporting paths
The proposed lifecycle has a few distinct states. A developer observes behavior, capability, compromise, or a prevented-risk circumstance. The developer then determines whether the model and actor are covered, whether the observation fits a reportable category, and whether the risk is imminent or ongoing. If the threshold is met, the developer supplies an initial report; if the situation is urgent, the report moves on an expedited path. Later facts and mitigation steps create supplemental reports rather than forcing the developer to choose between a premature final account and silence.
The initial report would include, as applicable and to the extent known at the time, a description of the incident, behavior, or capability; the date or approximate period when the developer discovered the information; known or suspected threat actors, attack vectors, system vulnerabilities, safeguard failures, and other causal or contextual information; and known or reasonably suspected implications for national security or public safety. The phrase “to the extent known” is important. It acknowledges that the first report may be an incomplete account, while still requiring the developer to disclose what is known and to identify the context needed for later assessment.
The Secretary would require supplemental reports as additional material information and mitigation steps became available. This creates a feedback loop. The first report establishes an event and a timestamp. Later reports can change the understanding of cause, severity, affected systems, or the adequacy of containment. The mechanism is useful only if the first disclosure is not treated as a final, immutable statement and if later additions do not become an excuse to postpone the first meaningful warning.
The Act’s congressional-reporting requirement adds another state transition. For a report presenting an imminent or ongoing risk of serious harm, the Secretary would inform specified House and Senate leaders and committee chairs no later than 48 hours after receipt. For other reports covered by the congressional-reporting provision, the period would be no later than 30 days after receipt. The developer does not decide which lawmakers receive the notice. That responsibility belongs to the Secretary, who acts as the institutional relay between technical information and congressional oversight.
Why the production-evaluation exception matters
The evaluation limitation is easy to overlook because it appears inside the control-related category, but it prevents a serious category error. A safety evaluation may intentionally prompt a model to produce deceptive, evasive, or shutdown-resistant behavior. The fact that a tester obtained such a response does not, by itself, establish that the model independently exhibits the same behavior in production.
The bill therefore excludes behavior elicited solely through an evaluation when the model is not in production and the behavior is not indicative of analogous behavior in deployment. The exclusion is not a blanket exemption for testing. It says that the relevance of a test depends on the connection between the test condition and deployment behavior. A model’s response under controlled elicitation may still matter for safety decisions, but the specific statutory reporting duty would require the deployment connection described in the text.
That boundary also shows why reportability cannot be reduced to a keyword search. “Deception,” “safeguard circumvention,” or “resistance to shutdown” can describe both a deliberately constructed evaluation and an unexpected production behavior. The event’s origin, environment, purpose, and relation to deployment are part of the classification. A form can ask for those facts; the threshold still depends on how they are interpreted.
Protection and enforcement travel with the report
Early reporting is difficult when the reporter cannot predict what will happen to the information. H.R. 9477 would require procedures to protect sensitive, classified, controlled, and security-relevant information. It would exempt submitted information from specified federal disclosure rules, prevent disclosure under state or local laws requiring disclosure of records, preserve applicable privilege and trade-secret protections, and restrict certain uses of the report against the developer that submitted it.
Those protections are qualified rather than absolute. The bill would not limit use by the Secretary or another agency to respond to, mitigate, or prevent national-security or public-safety risks. It would not prevent use of a report to determine compliance with the Act. It would not change liability for an underlying incident when that liability can be established using information obtained independently of the report. The proposed design protects the reporting channel without declaring that the underlying conduct can never be investigated.
The same section permits information sharing with other agencies, including intelligence and law-enforcement agencies, when appropriate and consistent with applicable law. The receiving agency would inherit the protections and use restrictions. Meanwhile, the Secretary could inspect records, issue subpoenas, investigate, require corrective action, and refer matters for civil action. A civil penalty could reach $2 million, with each day of a continuing violation treated as a separate offense.
This combination is meant to solve two different problems. Protections reduce the cost of telling the government what happened, especially when the information contains trade secrets or security-sensitive details. Enforcement reduces the cost of withholding a required report. Neither function guarantees candid reporting. The practical effect depends on whether developers understand the protections, whether agencies honor them, and whether the good-faith rules make room for incomplete but material information.
The lifecycle is clear enough to expose what remains uncertain
H.R. 9477 provides a recognizable sequence: covered status, knowledge or reasonable belief, reportable activity, ordinary or expedited timing, initial contents, supplements, protected handling, agency coordination, congressional notification, and enforcement. That sequence is more informative than a simple instruction to “report incidents” because it tells the reader where decisions and evidence enter the system.
But the sequence does not answer every operational question. The bill does not define the eventual evidentiary standard for reasonable belief, specify how a developer should measure an imminent or ongoing risk, or supply the agency’s severity-triage protocol. It leaves the meaning of several material terms to future rules and judgment. Nor does a report itself prove that the model caused a harm, that the developer’s assessment was correct, or that the proposed response will prevent recurrence.
The proposal’s most important lifecycle choice is therefore the acceptance of an informed first signal. It asks a developer to report before every fact is settled, then creates a path for supplementation and response. That approach can work only when the categories are observable and the receiving institutions can distinguish a credible early warning from an intentionally elicited test, a weak signal, or a report that falls outside the coverage boundary.
The next question is whether those distinctions can be made reliably. A timeline can tell us when a report is due. It cannot by itself determine whether the underlying signal should be escalated, merely alerted, or discarded. That decision depends on the deeper architecture of causation, data, definitions, and triggers.