Compliance
OpenRouter in United States
Structured issue-spotting for deploying OpenRouter in United States, read against the rules for that jurisdiction.
- Source
- Rules engine over a generic brief — no anchored quote on this page
- Verified
- Evidence not verified
- Confidence
- Low
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
01What this reading assumes
- Jurisdiction
- United States
- Principal framework
- Sectoral, not omnibus. FTC Act §5 (15 U.S.C. 45) is the general backstop for unfair or deceptive AI and data practices. HIPAA (45 CFR Part 164) covers protected health information; the GLBA Safeguards Rule (16 CFR Part 314) covers financial institutions; FCRA (15 U.S.C. 1681) governs consumer reports and adverse-action notices, which is the statute AI credit, tenant and employment screening most often engages; the COPPA Rule (16 CFR Part 312) covers under-13 data, and the 2025 amendments’ compliance deadline has passed. There is no federal cross-border transfer regime for ordinary personal data. State law supplies what the federal layer does not: California’s CCPA and the CPPA’s ADMT regulations, Colorado’s automated decision-making statute from 2027, Illinois BIPA and the Illinois Human Rights Act AI amendment, Texas TRAIGA, Connecticut Public Act 26-15 and New York City Local Law 144.
- Delivery assessed
- Model API
- Data leaves the network
- unknown — the deciding question for a hosted product
- Vendor home jurisdiction
- United States
- Verified vendor positions
- none — every vendor position below is a question, not an assurance
- Rules evaluated
- 41
- Rules fired
- 13
Assumptions about use
- An internal deployment used by employees, not a public-facing product.
- A person reads the output before acting on it — but that is not recorded, so the engine reports it as a gap rather than assuming it.
- No significant automated decision is taken about a person by the system alone.
02Issues to work through
Cross Cutting
Confidentiality duties bind independently of data protection law
Material can be entirely free of personal data and still be the material a contract stops you disclosing. Client retainers, non-disclosure agreements, supplier contracts and common-law duties are the usual sources, and several of them require consent before a third party processes the material at all — which a model API call is.
- Required checks
- Review the confidentiality clauses in the contracts covering the material going into the system.
- Identify any contract requiring notice or consent before a subcontractor processes the material.
- Decide whether the deployment needs a confidentiality carve-out negotiated into new contracts.
- Vendor questions
- Will the vendor accept a confidentiality undertaking beyond its standard terms?
- Which staff at the vendor can access customer content, under what controls?
- Technical controls
- Segregate the most sensitive corpora into an index that the general assistant cannot reach.
Human review required — take this to your counsel
What ends up in a prompt, and where it goes next
Every prompt is a transfer of whatever it contains. Staff paste more than they intend, retrieved context travels with the prompt, and system prompts can often be extracted from the output. Assume anything reaching the model has left your control unless the contract and the architecture say otherwise.
- Required checks
- Write down which categories of information may be entered into a prompt, and tell people.
- Establish what the system prompt contains and whether disclosing it would matter.
- Establish which shadow tools staff are already using; the policy has to name the permitted ones.
- Vendor questions
- Are prompts and completions retained, for how long, and can retention be set to zero?
- Are prompts used for abuse monitoring, and if so who can read them and for how long?
- Technical controls
- Redact or block high-risk patterns before the prompt leaves the application.
- Keep prompt and completion logs out of general-purpose observability tools.
- Set an explicit retention period on prompt logs and enforce it.
The acceptable-use policy may exclude your use case
Acceptable-use policies commonly carve out unsupervised legal, medical and financial advice, decisions about people without human review, and some surveillance and biometric uses. They are incorporated into the contract by reference and change without a signature, so the version that matters is the one live on the day you rely on it.
- Required checks
- Read the acceptable-use policy against your actual use case, not against a summary of it.
- Where a carve-out applies, decide whether human review brings the use back inside the policy.
- Set a reminder to re-read the policy — it changes without notice to you.
- Vendor questions
- Does your acceptable-use policy permit this use case, and will you confirm that in writing?
- How are we notified when the acceptable-use policy changes?
Human review required — take this to your counsel
Being able to reconstruct a decision months later
The question that arrives after a complaint is what the system was shown and what it produced on a particular day. Models change, prompts change, and indexes are rebuilt, so the answer has to be recorded at the time. Without it, the only available response is that the output cannot be reproduced.
- Required checks
- Decide what is recorded per interaction: model and version, prompt template version, retrieved document ids, output, reviewer and outcome.
- Set how long those records are kept, balanced against the retention duties that also apply to them.
- Vendor questions
- Does the vendor pin model versions, and how much notice is given before a model is retired or changed?
- Technical controls
- Version prompt templates in source control and log the version used.
- Log the model identifier and version returned by the provider, not the one you requested.
Vendor documentation has not been verified
We could not verify a data processing agreement, a subprocessor list, a position on training on customer data and a stated processing region for this vendor from a retrieved document. That is a gap in our evidence, not a finding against the vendor: until a document has been fetched and read, nothing here should be treated as settled either way.
- Required checks
- Obtain the current versions of the processing agreement, subprocessor list, security page and any regional-processing commitment.
- Check that what the sales conversation promised also appears in the contract.
- Vendor questions
- Where is your data processing agreement published, and which version applies to us?
- Where is your subprocessor list, and how much notice do we get before it changes?
- Do you train on customer content by default, and where is that stated contractually?
- In which country or region is inference performed, and where are logs retained?
We were not told whether a person reviews the output
Where output influences a decision about a person, the reviewer has to be able to disagree with it. That needs three things a rubber-stamp review lacks: enough information to judge, enough time to judge, and an override that is used often enough to be real. Design it before the volume makes it impossible.
- Required checks
- Name the role that reviews the output and what they see when they do.
- Decide what evidence is retained about each review, so the practice can be shown to exist.
- Set a threshold below which the system must not act without review.
- Vendor questions
- Does the product expose the retrieved context and the confidence behind a suggestion, or only the answer?
- Technical controls
- Show the reviewer the retrieved sources next to the suggestion, not the suggestion alone.
- Record the reviewer’s decision, including overrides, as part of the audit trail.
Human review required — take this to your counsel
An AI deployment creates new copies of the data
Vector indexes, prompt logs, completion caches, evaluation datasets, fine-tuning checkpoints and backups are all copies of the source material in places the existing retention schedule does not mention. Deletion requests are the moment this is discovered, because deleting the source document does not delete its embedding.
- Required checks
- List every store the deployment creates and add each to the retention schedule.
- Establish how a deletion request propagates to the index, the caches and the logs.
- Establish how long backups keep material that has been deleted from the live system.
- Vendor questions
- What does the vendor retain, where, and for how long after we delete our copy?
- Technical controls
- Store the source document id with every embedding so deletion can cascade.
- Set time-to-live on prompt and completion logs rather than relying on manual cleanup.
The vendor’s terms may not permit the deployment you are planning
Provider terms routinely restrict things architectures assume: sharing seats, building a competing service, benchmarking and publishing results, reselling capacity, and processing certain data categories. A consumer or self-serve plan often carries different terms from the enterprise agreement, and the enterprise agreement is the one worth reading.
- Required checks
- Identify which contract actually governs — self-serve terms, an order form, or a negotiated agreement.
- Check restrictions on seat sharing and on service accounts, which a shared internal assistant can breach without anyone noticing.
- Check whether the terms allow the categories of data you intend to send.
- Vendor questions
- Which agreement governs our use, and can we have the current version in writing?
- Are there restrictions on the data categories or the industries we may use the service for?
United States
The transfer rule that bites is about who the vendor is, not where the data sits
There is no general US restriction on exporting personal data, but 28 CFR Part 202 makes data brokerage, vendor agreements, employment agreements and investment agreements covered data transactions when they give a covered person access to bulk US sensitive personal data. An AI vendor with support engineers, contractors or a subprocessor in a country of concern turns an ordinary SaaS agreement into a restricted transaction, and a US-region endpoint says nothing about that.
- Required checks
- Establish whether the data is US sensitive personal data and whether the volumes reach the rule’s bulk thresholds.
- Map the vendor’s ownership, its subprocessors and where its support and engineering staff actually sit.
- If the answer is yes anywhere, treat the CISA security requirements, due diligence and recordkeeping as project work, not paperwork.
- Vendor questions
- In which countries are your support, engineering and administrative staff located, and can any of them access customer data?
- Who owns the company, and is any owner or subprocessor established in a country of concern?
- Do you already operate a compliance programme for the Data Security Program, and will you evidence it?
- Technical controls
- Restrict vendor support access to a break-glass path with per-session approval and a retained audit trail.
Human review required — take this to your counsel
Tell us which states, because the AI duties are state duties and they disagree
The binding AI obligations on a private deployer in the United States are state obligations — bias audits, automated decision-making notices and opt-outs, biometric consent, generative AI disclosure — and they do not agree with one another. This brief does not name a state, so we cannot say which apply. A federal executive order now directs the Justice Department to challenge state AI laws, but a law being litigated is still a law in force.
- Required checks
- Name the states where the people affected by the system live and where the organisation does business.
- Design to the strictest rule that reaches you rather than to a per-state matrix, unless the cost of the strictest rule is real.
- Track the federal preemption litigation, but do not plan on it succeeding.
There is no federal privacy statute to comply with — work out which state law reaches you
The United States has no general federal privacy statute. What applies to a deployment is a sectoral statute if the sector is regulated, plus whichever state privacy laws reach the organisation by revenue, record count or the residence of the people in the data. That is a scoping exercise, not a compliance checklist, and it has to happen before any control is designed — the answer differs for a California consumer, an Illinois employee and a Texas customer.
- Required checks
- List the states whose residents appear in the data, and check each state law’s applicability thresholds against the organisation’s revenue and record counts.
- Decide whether a sectoral statute applies — health, financial, education, children — because that changes the analysis before any state law does.
- Record the states you concluded do not reach you, with the threshold that got you there, so the decision can be revisited when the numbers change.
- Technical controls
- Capture the state of residence where it is already known, so scoping is a query rather than a guess.
FTC Act §5 reaches what you say about the AI, not just what it does
Section 5 of the Federal Trade Commission Act declares unfair or deceptive acts or practices in or affecting commerce unlawful. For an AI deployment that means the marketing copy, the accuracy claims, the privacy policy and the statement about whether customer data trains a model are all in scope, and a claim the system cannot support is the exposure — regardless of whether any AI-specific rule applies.
- Required checks
- Match every public accuracy or capability claim to a measurement you could produce if asked.
- Check the privacy policy actually describes what happens to prompts, retrieved documents and logs.
- Confirm nothing published says data is not used for training unless the vendor has committed to that in writing.
- Vendor questions
- Will you state in the contract that customer content is not used to train or improve your models?
The NIST AI Risk Management Framework is voluntary until a contract names it
The NIST AI Risk Management Framework is intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, use and evaluation of AI systems. It carries no penalty of its own. It becomes binding through the back door: customer contracts, state statutes and federal acquisition terms name it, so a deployment that ignores it often has to retrofit the artefacts later.
- Required checks
- Check whether any customer contract or state rule already names the framework or its Generative AI Profile.
- Produce the Govern, Map, Measure and Manage artefacts as the project runs, rather than reconstructing them for an audit.
- Vendor questions
- Have you mapped your product to the AI Risk Management Framework, and will you share that mapping?
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
03What this reading does not know
- Whether any of the data falls into a special or sensitive category.
- Whether any material is covered by legal professional privilege.
- Whether prompts or documents leave the company network.
- Whether a person reviews the output before it is acted on.
04Instruments these issues point at
- regulationDOJ Data Security ProgramProhibits data-brokerage transactions with countries of concern and makes vendor, employment and investment agreements giving covered persons access to bulk US sensitive personal data restricted transactions, subject to CISA security requirements, due diligence and recordkeeping.
- statuteFTC Act §5Declares unfair or deceptive acts or practices in commerce unlawful. The general federal backstop for overstated AI capability claims, undisclosed AI use and inadequate data practices — it reaches an AI deployment through what the deployer says about it, not through a technology-specific duty.
- standardNIST AI RMFVoluntary framework structured around Govern, Map, Measure and Manage. The de facto reference for US AI governance programmes, and frequently named in contracts and in state law — which is how a voluntary framework becomes a contractual obligation.
05Vendor documents being watched
- Data residencyhttps://openrouter.ai/docs/guides/features/sovereign-ainot yet fetched
- Privacy policyhttps://openrouter.ai/docs/guides/privacy/data-collectionnot yet fetched
- Security pagehttps://openrouter.ai/docs/guides/features/zdrnot yet fetched
- Terms of servicehttps://openrouter.ai/termsnot yet fetched
06Ask about your own deployment
This page reads the rules against a generic organisation. Your size, industry, data and existing contracts change which of these issues matter and which fall away.