AI Regulation for US Companies: A Practical Compliance Guide

Artificial intelligence is now part of ordinary US business operations. A sales team uses a generative assistant to draft messages, a contact center summarizes calls, a manufacturer predicts equipment failures, a bank reviews applications, a retailer personalizes offers, and an HR team searches and ranks résumés. The hard question is no longer whether your company uses AI. It is whether you know where it is used, what information it touches, which people it affects, what decisions it influences, and what evidence you can produce when a customer, employee, regulator, board member, or business partner asks.

This guide is for US company leaders, legal and privacy teams, product owners, and operations managers. It describes the landscape as of September 2026 and is practical operating guidance, not legal advice. Federal and state policy is changing, some measures are contested or subject to litigation, and effective dates matter. Confirm the current law, scope, exemptions, enforcement position, and application to your business with qualified US counsel before relying on this article for a launch or decision.

The US legal position in plain English

The United States does not have one comprehensive federal AI statute that classifies every AI system and imposes one nationwide set of duties. Instead, companies face a patchwork. Existing federal laws may apply to an AI enabled activity, federal agencies may enforce those laws, executive orders may direct government policy, voluntary frameworks may help companies manage risk, and state or city laws may impose requirements on particular uses. The answer depends on the company, product, data, people affected, sector, agency, state, city, and role in the AI supply chain.

Keep a legal register with separate labels. Binding law includes statutes, regulations, valid agency rules, court orders, and enforceable consent orders. Agency enforcement statements and policy guidance can show how an agency may interpret an existing law, but a blog post is not itself a new statute. An executive order generally directs federal agencies and does not automatically impose a private sector duty or preempt state law. NIST frameworks and industry standards are voluntary unless incorporated into a contract, rule, settlement, or internal requirement. State and local laws are binding within their jurisdiction when valid and in force.

That distinction is operationally important. A company may choose to adopt NIST AI RMF controls because they are useful and defensible, while separately identifying the FTC Act, a state privacy law, a city employment rule, a customer contract, and an applicable sector regulation. Do not describe a voluntary framework as law. Do not describe a proposal or future effective date as a current obligation. Do not assume that a federal announcement eliminates a state requirement.

Federal enforcement: the FTC Act and truthful AI claims

The Federal Trade Commission Act is one of the most important federal tools for AI risk. Section 5 prohibits unfair or deceptive acts or practices in or affecting commerce. The statute does not need to say the word AI for it to apply. A company can create risk by making a false claim about what its model can do, hiding material limitations, using personal information unfairly, allowing a product to produce foreseeable consumer harm, or marketing automation that does not work as represented.

The FTC's Keep your AI claims in check guidance is a useful starting point. Before publishing a claim such as accurate, unbiased, autonomous, secure, compliant, human level, or better than a person, ask what evidence supports it, which population and conditions were tested, how long the evidence remains valid, and whether the claim leaves out a material limitation. A benchmark result is not automatically evidence that a product will work for every customer, language, geography, or edge case.

Marketing, sales, product, and engineering should approve claims together. Preserve test protocols, sample selection, error rates, confidence intervals where appropriate, exclusions, and dates. If an AI product requires human review, customer configuration, clean input data, or a narrow use case, say so. Avoid turning a possibility into a promise. Claims about saving time, reducing cost, detecting fraud, preventing loss, or eliminating bias should be substantiated before publication, not defended after a complaint.

Consumer protection and unfair outcomes

Consumer protection risk begins with the outcome, not with the label attached to the model. A chatbot can give inaccurate financial or health information. A recommendation system can steer people unfairly. A pricing model can use sensitive proxies. A fraud tool can delay legitimate transactions. An automated collections workflow can contact the wrong person. A generative assistant can invent a policy, deadline, warranty term, or eligibility reason. Each use needs a defined purpose, allowed behavior, prohibited behavior, escalation path, and accountable owner.

Use point of interaction notices when a person needs to understand that they are dealing with automation or when the fact changes how they can respond. Give customers a practical human route for consequential matters. A notice hidden in terms of service is rarely a good substitute for clear, timely communication. Explain what the tool does, what it does not do, what information it uses at a useful level, and how to correct an error. Make the path accessible and available in the languages and channels your customers need.

Discrimination, employment, and civil rights risk

AI can create discrimination risk even when a system never receives race, sex, age, disability, religion, or another protected characteristic. Location, school, employment gaps, names, language, device type, schedule availability, health related descriptions, and other variables can act as proxies. An apparently neutral score can produce disparate outcomes in recruiting, promotion, scheduling, performance management, discipline, credit, housing, insurance, education, or access to services.

Federal civil rights and employment laws remain relevant. Depending on the activity, consider Title VII, the Americans with Disabilities Act, the Age Discrimination in Employment Act, the Fair Housing Act, the Equal Credit Opportunity Act, the Fair Credit Reporting Act, and other sector or program rules. Agencies including the Equal Employment Opportunity Commission, Consumer Financial Protection Bureau, Department of Housing and Urban Development, and Department of Justice may apply existing authority to algorithmic conduct. The exact theory and agency jurisdiction depend on the facts.

For employment, document the job related purpose, vendor, data sources, validation, accommodation process, reviewer responsibilities, and candidate or employee notice. Test selection rates and error patterns across relevant groups where lawful and statistically meaningful. Make an accommodation route easy to find. Do not let a recruiter treat a score as a final decision without a process for reviewing context, correcting source data, and considering qualified people who do not fit the training pattern.

A person in the loop is not enough by itself. The reviewer needs relevant information, time, authority, training, and a genuine ability to disagree. Measure overrides and outcomes, not just whether a human clicked approve. If reviewers are expected to accept every result, they are functioning as a rubber stamp. Name who is accountable for the decision and retain enough evidence to reconstruct how the recommendation affected the outcome.

Privacy and data security still govern the data

There is no general federal consumer privacy law that covers every US business, but privacy obligations can arise from state comprehensive privacy laws, sector laws, federal enforcement, contracts, promises in a privacy notice, and common law. Depending on the data and activity, consider the Health Insurance Portability and Accountability Act, the Gramm Leach Bliley Act, the Children's Online Privacy Protection Act, the Fair Credit Reporting Act, state privacy and breach laws, biometric laws, health data laws, and rules for education, communications, or financial records.

Start every AI use with a data flow. Identify the source, purpose, legal or contractual authority, fields, recipients, retention, hosting locations, model provider, subprocessors, logs, embeddings, evaluation sets, and deletion path. Distinguish data used to answer a request from data used to train, fine tune, evaluate, monitor, or improve a vendor's service. A customer who supplied information to obtain support may not have expected that information to become training data for a general model.

Minimize before you anonymize. Names can be removed while a person remains identifiable from a combination of dates, location, job title, account details, or distinctive facts. Use field filtering, redaction, tokenization, pseudonymization, access controls, separate development data, and short retention where they preserve the purpose. Cover prompts, uploads, outputs, retrieval indexes, embeddings, telemetry, and incident tickets. Test whether a system can reveal information from its context to a user who should not receive it.

Security review should include prompt injection, insecure plugins, excessive tool permissions, data exfiltration, model supply chain risk, poisoned data, secret exposure, vulnerable dependencies, and logging gaps. An AI agent with permission to send an email or alter a record should have narrowly scoped credentials, transaction limits, confirmation steps, and monitoring. Treat a vendor's security certification as evidence to review, not as a substitute for understanding your configuration and data flow.

NIST AI RMF and the GenAI Profile

The NIST AI Risk Management Framework is a voluntary framework designed to help organizations manage AI risk. Its core functions, Govern, Map, Measure, and Manage, provide a practical structure for assigning accountability, understanding context, testing performance, and treating identified risks. It is not a federal statute and does not automatically create a private right of action. A company should state clearly whether it has adopted the framework internally, in a contract, or as a reference point.

NIST's Generative AI Profile adapts the framework to generative AI risks such as confabulation, data privacy, harmful bias, information integrity, cybersecurity, intellectual property, and value chain dependence. Use it to make a risk conversation concrete. Map each relevant risk to an owner, control, test, threshold, evidence location, and review date. Do not claim that a NIST reference means a system is safe or legally compliant.

Executive orders and federal policy

Executive orders and presidential policy documents can change federal agency priorities, procurement direction, standards work, reporting, or government research. They do not automatically create the same duties as an act of Congress, and they do not automatically preempt state laws. The June 2026 executive order on promoting advanced artificial intelligence innovation and security should be read with its text, implementation instructions, agency actions, and later developments. Confirm what applies to your company rather than summarizing the order as a universal private sector mandate.

Federal procurement and public sector work

Most private companies do not become subject to federal public sector rules merely because they use AI internally. The analysis changes when a company sells an AI system to a federal agency, supports an agency decision, handles government data, works under a federal contract, or supplies a product that must meet a solicitation or agency security requirement. Contract clauses, agency policies, acquisition rules, accessibility requirements, records obligations, security controls, and audit rights can flow into the delivery relationship.

State and local laws require a separate map

State and city rules are where many practical obligations arise. They may cover a specific technology, sector, data type, decision, notice, disclosure, testing process, or developer role. Definitions and thresholds differ. A law can apply because the person is in a state, the employer is located there, the service is offered there, the company meets revenue or data thresholds, or the business contracts with a covered entity. A national website does not prove that one national policy is sufficient.

California: privacy, employment, and generative AI developments

California companies and companies doing business with California residents should assess the California Consumer Privacy Act as amended by the California Privacy Rights Act, along with regulations and future amendments. The analysis can include sensitive personal information, profiling, data use, rights requests, service providers, contractors, automated decision technology, and security. Thresholds, exemptions, and regulations matter. Map the particular business and data rather than copying a generic California checklist.

California has also developed requirements and proposals concerning generative AI and frontier models. Depending on the measure, a rule may focus on disclosures, synthetic content, transparency, safety testing, incident reporting, documentation, or developers of powerful models rather than every ordinary business deployer. These developments can change through enactment, amendment, implementation, litigation, or delay. Identify the covered actor, trigger, effective date, and enforcement mechanism in your legal register. Do not present a proposal, vetoed bill, or pending rule as current law.

Colorado SB 26-189, effective January 1, 2027

Colorado's SB 26-189 is a future-dated item for planning as of September 2026. Its stated effective date is January 1, 2027. It should therefore be marked as a Colorado requirement with a future effective date, not as an obligation that began when this article was published. Review the enrolled or current official text, amendments, rules, guidance, definitions, thresholds, exemptions, and any litigation before finalizing a control plan.

The practical lesson is to build the Colorado review into the 2026 product calendar. Identify high impact uses, affected Colorado individuals, deployer or developer roles, notices, appeals or human review, risk management, impact assessments, data controls, and documentation that the current text may require. Test the process before January 1, 2027, but label internal early adoption as a risk decision rather than claiming the law already applies. Counsel should confirm the operative provisions and any implementation changes close to the effective date.

Texas TRAIGA and HB 149

Texas's Responsible Artificial Intelligence Governance Act, commonly called TRAIGA, and HB 149 should be assessed by companies that operate in Texas, serve Texans, employ people there, or supply covered systems. Use the current official statutory text, effective dates, definitions, agency materials, and any amendments when determining scope. A Texas reference in a vendor presentation is not enough to establish whether a particular use is covered or exempt.

For planning, screen for prohibited or restricted practices, transparency and disclosure triggers, profiling or consequential decisions, developer and deployer responsibilities, complaint handling, data governance, and enforcement exposure. Record whether the company is developing, deploying, selling, or materially modifying a system. A system used only for internal drafting may have a different profile from one that affects employment, housing, credit, insurance, healthcare, or access to services. Have Texas counsel confirm the current status before launch.

Illinois employment AI requirements

Illinois employers should pay particular attention to the Illinois Artificial Intelligence Video Interview Act and later employment AI requirements, including the Illinois Human Rights Act amendments addressing the use of AI in employment decisions. Requirements can concern notice, consent, explanation, deletion, bias, or discriminatory effects, and the exact scope depends on the current text and use. An employer should not assume that a vendor's recruitment feature satisfies Illinois obligations.

Before using AI in recruiting, interviewing, promotion, evaluation, scheduling, or discipline, document the purpose and job relevance. Give the required notice, provide a meaningful accommodation path, confirm what the vendor does with recordings and data, test for disparate impact, and define human review. Coordinate the AI process with record retention, candidate communications, privacy, employee relations, and the company's existing equal employment program. Check the current Illinois law and guidance with counsel because requirements can be amended and enforcement interpretations can develop.

New York City Local Law 144

New York City's Automated Employment Decision Tools page describes Local Law 144, which regulates certain automated employment decision tools used in hiring or promotion in New York City. Covered employers and employment agencies generally need a bias audit conducted within the applicable interval, public information about the audit, and required notices, subject to the law's definitions, exemptions, and effective requirements. The rule is local. It is not a nationwide employment AI law.

Map whether the tool qualifies as an AEDT, whether the employer or agency uses it for a covered decision, which candidates or employees are in scope, and who must receive notice. Vet the auditor and audit methodology, preserve data and version information, publish what is required, and do not assume that an audit certificate proves a tool is fair for every use. A tool can pass a narrow audit and still be unsuitable because of validity, accessibility, privacy, job relevance, or operational problems.

Create an AI inventory before writing a policy

A policy drafted before discovery describes an imaginary company. Ask every function to list purchased software, embedded AI features, APIs, experiments, browser tools, open source models, spreadsheet add-ons, agents, and uses created without procurement approval. Reconcile responses against software asset records, cloud bills, identity groups, expense reports, data inventories, product roadmaps, vendor questionnaires, and security logs. Shadow AI is a governance finding, not a reason to omit a use.

• System and feature, model or provider, version, owner, users, purpose, lifecycle stage, and connected actions.
• Input data, output recipients, personal or sensitive information, confidential material, children’s data, biometric information, and retention.
• Affected people, states and cities, sector, decision impact, autonomy, human review, override authority, and ability to stop.
• Vendor, contract, hosting, subprocessors, data training settings, security controls, incident contact, and exit plan.
• Known limitations, evaluation results, fairness and accuracy concerns, legal classification, open questions, and next review date.

Risk tiering that helps people decide

Use an internal tiering model, while making clear that your tiers are not a claim that US law has adopted one national classification. A low tier can cover drafting or summarization with no sensitive input and no decision effect. A medium tier can cover customer interaction, internal retrieval, or workflow recommendations that require verification. A high tier can cover employment, credit, housing, health, eligibility, safety, biometric information, legal rights, essential services, or autonomous action. A prohibited tier should stop uses that violate law, create unacceptable harm, or cannot be governed with available evidence.

For every tier, define minimum controls and approval authority. Reclassify when the model, data source, user group, geography, connected action, or business purpose changes. A low risk drafting tool can become high risk when it receives customer files or sends final legal notices. A customer chatbot can become more consequential when it gains account access. Record why the use received its tier, who accepted residual risk, and what event triggers a new review.

Controls for data, vendors, and human review

For each high or medium use, complete a privacy and AI impact review before production. Describe the purpose, alternatives, affected people, data, model, vendor, locations, retention, outputs, downstream decisions, risks, controls, residual risk, owner, and review date. Add questions about accuracy, disparate impact, accessibility, language, automation bias, prompt injection, model drift, data poisoning, harmful content, and the ability to reverse an action.

Vendor due diligence should identify the supplier's role, model family, versions, hosting, subprocessors, support access, change process, known limitations, and incident history. Contract for input and output use, training settings, retention, deletion, security, breach notice, cooperation, material change notice, audit evidence, continuity, export, rollback, and termination assistance. The vendor controls parts of the model, but your company controls purpose, configuration, users, data, and downstream decisions.

Notices, testing, records, and incident response

Use notices that match the interaction. Tell people when AI is being used where that fact matters, explain the purpose in clear language, identify the human route, and describe how to correct or question an outcome. For generated content, consider labeling, provenance, approval, and records based on the context, applicable law, platform, and risk of confusion. Keep notice versions, locations, translations, accessibility checks, and approval owners.

An AI incident can be a privacy breach, biased outcome, fabricated customer advice, unsafe recommendation, prompt injection, data poisoning, unauthorized autonomous action, misleading synthetic content, model outage, loss of logs, or failed human review. Connect AI response to the existing security and privacy program, but capture model version, input or retrieval reference, output, action, reviewer, affected people, reproducibility, containment, and vendor escalation. Preserve evidence without copying sensitive data into a broad ticket.

A practical 30, 60, and 90-day plan

Days 1 to 30 should create visibility and stop avoidable exposure. Appoint an executive sponsor, legal or privacy lead, security contact, and use case owners. Issue an interim rule for sensitive data, unapproved tools, and high impact decisions. Inventory uses across business, IT, HR, product, security, procurement, and suppliers. Screen each use for federal law, state and local scope, consumer or employment effect, vendor data use, customer disclosure, and autonomous action. Assign an owner and due date to every unknown.

Days 31 to 60 should convert findings into controls. Approve risk tiers and decision records. Publish the employee acceptable use standard and role based training. Create an approved tool catalogue. Update procurement questionnaires and priority vendor contracts. Complete impact reviews for the highest exposure uses. Configure access, redaction, retention, logging, notices, human escalation, and incident intake. Build a legal register that distinguishes binding law, enforcement position, executive policy, voluntary framework, proposal, and future effective date.

Days 61 to 90 should test the operating model. Run performance, fairness, privacy, security, accessibility, and language tests appropriate to each use. Sample logs and human overrides. Run an incident tabletop. Test rollback and vendor outage procedures. Add a change gate for new models, prompts, data sources, integrations, and user groups. Report open high risks, overdue evidence, training coverage, material incidents, correction time, and upcoming state dates to leadership. Set a quarterly review cadence.

Evidence checklist

• AI inventory with owner, purpose, provider, version, data, users, affected people, geography, tier, and review date.
• Legal register labeling statute, regulation, order, enforcement guidance, executive policy, voluntary framework, proposal, source, and effective date.
• Impact review with alternatives, residual risk, approval conditions, human review, notices, and reassessment triggers.
• Data flow, privacy analysis, retention schedule, access review, deletion process, and rights request handling.
• Model and dataset documentation, evaluation methods, limitations, fairness checks, accessibility, language tests, and change history.
• Vendor diligence, contract clauses, subprocessors, security evidence, data use settings, incident commitments, and exit plan.
• Human review instructions, escalation routes, override samples, reviewer training, and evidence that review was effective.
• Incident register, preserved evidence, impact assessments, communications, corrective actions, and restart approval.
• Executive decisions, risk acceptances, exceptions, KPIs, audit samples, and scheduled legal and governance reviews.

KPIs that show control

Measure coverage and effectiveness together. Coverage measures include the percentage of known uses inventoried, the percentage with an owner and tier, completed high risk reviews, approved tool adoption, staff training by role, vendor evidence coverage, and material changes reviewed before release. Outcome measures include human review completion, override rate by use, error rate by relevant group or language, privacy incidents, time to contain, time to correct an affected record, rollback success, and unresolved high risks by age.

Common mistakes US companies should avoid

• Waiting for a comprehensive federal AI statute before controlling data, claims, discrimination, security, and high impact decisions.
• Calling an executive order, NIST framework, agency blog, proposal, or future effective date binding law for every private company.
• Assuming federal policy automatically preempts state or city laws. It does not do so merely because the policy concerns AI.
• Treating a vendor's compliant or responsible AI statement as a legal classification, impact review, or deployment decision.
• Using consent or a disclaimer as a cure for an unfair purpose, excessive collection, weak security, or a misleading outcome.
• Calling a person human in the loop when they only click approve and cannot understand, challenge, override, or stop the result.
• Testing only average cases or English performance while ignoring protected groups, disability, accessibility, edge cases, and regional language.
• Keeping unlimited prompts and outputs, copying sensitive data into tickets, or forgetting derived indexes, embeddings, and telemetry.
• Launching one national workflow without mapping California, Colorado's future January 1, 2027 date, Texas, Illinois, New York City, and other relevant jurisdictions.
• Buying a governance platform that creates a second inventory instead of connecting to identity, procurement, privacy, security, product, and incident systems.

Build versus buy

Buy mature commodity capabilities such as identity, access management, asset discovery, training delivery, ticketing, evidence storage, vendor questionnaires, monitoring, and controlled model access. Build or configure the judgment heavy parts: your use case taxonomy, federal and state legal register, risk appetite, approval gate, impact review, human review design, evaluation thresholds, escalation rules, and executive reporting. A platform can organize evidence, but it cannot decide whether a hiring workflow has a discriminatory effect or whether a reviewer can genuinely correct an outcome.

What can we do for you?

Magna Products helps US companies turn scattered AI experiments into controlled, useful operations. We can inventory your AI use cases, map federal, state, and local considerations, design practical risk and impact workflows, review customer and employment processes, strengthen vendor requirements, and connect human review, incident response, and evidence to the systems your teams already use. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritized 30, 60, and 90 day implementation backlog.