U.S. AI policy news often reaches the public as a safety slogan. The harder question is legal and operational: when a system contributes to a bad hire, a denied claim, a bad medical summary, a hallucinated citation, or a discriminatory outcome, who is responsible? AI regulation explained without that question leaves companies, customers, and workers in a fog that is convenient for everyone except the person who was harmed.
I am not a lawyer, and this is not legal advice. It is a reporter’s map of how responsibility is currently split among vendors, deployers, integrators, insurers, and existing bodies of law that did not wait for a new AI statute.
The Split That Already Exists
American law already knows how to assign responsibility for defective products, unfair credit, employment discrimination, medical malpractice, defamation, and consumer deception. What it does not yet have, at the federal level, is a single AI-specific liability regime that answers every edge case. Into that gap, companies have written contracts.
Those contracts often try to push operational risk to the deployer: you chose the prompts, you chose the workflow, you chose not to review. Vendors keep responsibility for the hosted service running, for some security terms, and for their own marketing claims. Integrators sit in the middle and hope both sides’ paper holds.
Parties who may share a high-stakes failure
The model provider that trained and hosted the system
The application vendor that wrapped it in a product
The enterprise that configured, prompted, and accepted the output
The employee who hit send
The insurer who may or may not treat the event as covered
A regulator using existing sector rules rather than a new AI law
Read the announcement. Then read the incentives. The incentive in most launch materials is to describe “copilots,” which sounds like help. Help is easier to disclaim than a system of record.

What Existing Law Already Reaches
If a hiring tool has a disparate impact, equal-employment rules still apply whether or not the vendor called the model “AI.” If a credit decision is automated, fair-lending and adverse-action rules still care. If a health system uses a model in clinical support, professional standards and institutional policies still exist. If a chatbot misleads a consumer, the FTC’s deception authority did not vanish.
Courts will spend years mapping those older rules onto newer tools. That mapping will be slower than product cycles. It will also be more consequential than a voluntary code of conduct.
Where disputes tend to concentrate
Setting | Typical fight | Why it is hard |
|---|---|---|
Employment and housing | Bias and notice | The model is a component, not the whole decision |
Consumer chat | Misleading claims | Fluency looks like knowledge |
Professional services | Standard of care | What would a careful human have reviewed? |
Safety-critical operations | Causation | The human and the model both touched the outcome |
Copyright and privacy | Data lineage | Training, fine-tuning, and logs are different facts |
AI regulation explained as if these rows were empty is incomplete. They are crowded. They are just not labeled “the AI Act” in U.S. code.

Contracts, Insurance, and the Human in the Loop
The phrase “human in the loop” is doing a lot of legal work. If a person is expected to catch the model’s mistakes, the organization is arguing that the model was advisory. If the person is given 400 summaries an hour, the loop is a fiction. Responsibility follows the fiction until a court or a regulator decides it does not.
Insurance markets are still pricing this. Some policies exclude “generative” events or cyber-adjacent failures. Some require specific controls. The details are dull and decisive. A company that cannot describe its review process will have a difficult claim file, whatever the model card said.
I keep a question on the last page of the notebook for these stories: who really benefits, and who really pays? The vendor benefits if liability is treated as a customer-configuration problem. The customer pays in review labor. The person affected by the decision pays if nobody’s paper reaches them.
Practical questions for any high-stakes deployment
Is the output recorded, attributable, and retrievable later?
Is there a named human whose job includes saying no, with time to do it?
Do the vendor terms allow the customer to pin a model version?
What incidents must be reported internally, and to whom externally?
If the system is wrong, is there a path for the affected person that does not require understanding the model?
If the answers are shrugs, you do not have an accountability design. You have a tool and a hope.
What Policymakers Are Actually Arguing About
When Congress, agencies, and statehouses say “AI accountability,” they are often arguing about whether to create new duties or to clarify that old ones apply. New duties can include incident reporting, evaluations before deployment, and disclosure to affected people. Clarifying old ones can be faster and less theatrical.
I will keep covering both. The useful story is not “someone should be responsible.” The useful story is which someone, under which document, with which evidence trail. Until that is specified, high-stakes mistakes will be followed by a familiar sequence: an apology, a closed beta, and a fight over whose appendix governs.
Here is what changed, and what did not. Systems that speak in complete sentences entered settings that used to require forms and professionals. The need for an assignable adult did not go away. This is meaningful as a governance problem. It is not yet a solved legal architecture.
No notes on this sheet yet.