A U.S. startup founder may discover the problem during a routine enterprise sales call. The product team has built an AI hiring assistant, customer-service agent, or document-generation feature, and European customers are already using it. There's no European office, no local subsidiary, and perhaps no employee in the EU. Yet the company may still need to assess whether the EU AI Act applies to its product, contracts, data practices, and deployment model.
That's why AI Policies Explained needs to start with business reality rather than abstract principles. A policy document alone won't protect a company if nobody knows which systems exist, who approved them, what controls apply, or what evidence proves those controls worked. The practical question for a U.S. founder in 2026 is simple: Which AI rules reach the business, and what must the business be able to demonstrate?
The EU AI Act and Your US-Based Business
A Seattle SaaS company launches an AI feature for customers in several markets. Its engineers train the product in the United States, its contracts use Washington law, and its support team works from North America. A European customer signs up, uploads data, and relies on the system for a business decision. The founder may assume U.S. operations keep the company outside European regulation. That assumption can create a costly blind spot.
The EU AI Act can matter to businesses outside the European Union when their AI systems are placed on the EU market, provided to people in the EU, or used in ways connected to EU operations. The relevant analysis isn't limited to incorporation, office location, or where the model was trained. Product functionality, customer location, role in the AI supply chain, and intended use all matter.
A U.S. provider may be responsible for a system it supplies to European customers. A U.S. company may also act as a deployer when it uses a third-party model internally for hiring, customer support, fraud review, or operational decisions. Those roles can create different duties, so the first legal task is classification, not policy drafting.
Practical rule: A company should treat EU access as a trigger for review, not wait for a European office or regulator to appear.
The Act also intersects with other legal exposure. Companies assessing AI products should review their contractual allocation of responsibility, security controls, privacy practices, and potential claims involving defective or harmful software. A focused overview of EU product liability for AI and software can help founders connect AI governance with broader product-risk planning.
The first internal question should be, “Where are EU users, customers, employees, or affected individuals in this product's lifecycle?” The EU AI Act guidance for businesses provides another starting point for mapping that exposure before the company commits to a European launch or renews a major customer contract.
Understanding the EU AI Act Scope and Objectives
The EU AI Act uses a risk-based structure. Instead of imposing identical obligations on every AI application, it assigns duties according to the potential effect on health, safety, fundamental rights, and public life. That approach reflects a practical distinction between an AI spam filter and an automated system that influences access to employment.
The law's objectives include safer and more trustworthy AI, protection of fundamental rights, transparency, accountability, and oversight. Those objectives affect product design, not just legal review. A team that can explain what its system does, where its data came from, how users can challenge outputs, and who can intervene is better positioned to manage both regulatory and commercial risk.
Identify the company's role
A U.S. business should determine which role it occupies for each system:
- Provider: The organization that develops an AI system or has one developed and places it on the market or puts it into service under its name.
- Deployer: The organization that uses an AI system under its authority, including an employer or business using a vendor's tool.
- Importer: The organization that brings an AI system from outside the EU into the EU market.
- Distributor: The organization that makes an AI system available in the EU supply chain without being the provider or importer.
One company can hold different roles at different points. A startup may be a provider for its own customer-facing model, a deployer of an external foundation model, and a distributor of an embedded third-party component. The contract, user interface, marketing language, and technical control over the system can all affect the analysis.
Map the cross-border data path
AI compliance also depends on the information flowing through the system. The company should document where prompts, training data, personal information, generated content, and logs originate and where they are stored or accessed. Cross-border transfers can create a separate privacy workstream, so counsel should review cross-border data transfer planning alongside AI obligations.
A useful scope assessment records the system's purpose, users, geographic availability, decision impact, provider or deployer role, vendor dependencies, and affected individuals. That inventory gives the business a defensible basis for deciding whether a product falls into a prohibited, high-risk, transparency-focused, or lower-risk category.
The Four AI Risk Tiers Explained
The EU AI Act's central idea is straightforward: higher potential harm produces heavier obligations. Classification still requires care because the same technical model can create different legal risk depending on its intended purpose and deployment context. A general language model used for drafting internal notes isn't assessed in the same way as an AI tool used to rank job applicants.
Unacceptable risk
This category covers practices considered incompatible with the Act's fundamental-rights protections. A social-scoring system that evaluates people based on unrelated behavior and uses that evaluation to produce unfair treatment is a useful example. Manipulative systems that exploit vulnerabilities can also raise serious concerns.
For a startup, the practical response isn't to build a larger compliance file. The response may be to stop the use case, redesign the workflow, or refuse the customer requirement. Product teams should test the intended purpose before launch, because a prohibited function can't be rescued by adding a disclosure after deployment.
High risk
High-risk systems receive the most demanding operational treatment. An AI system that sorts or ranks resumes for employment decisions illustrates the concern. The system may affect a person's access to work, so errors, biased outputs, poor data, or weak human review can create material consequences.
A high-risk assessment should examine the decision being supported, the people affected, the quality and relevance of training and testing data, the ability of a human reviewer to understand and challenge outputs, and the organization's monitoring process. A vendor's statement that its model is “responsible” doesn't replace the buyer's own use-case analysis.
Limited risk
Limited-risk systems generally trigger transparency duties rather than the full high-risk control set. A customer-service chatbot is the familiar example. The user should understand that the interaction involves AI, particularly where a person could otherwise believe they're dealing with a human representative.
Transparency also affects generated or manipulated content. Clear notices, usable explanations, and escalation paths are more effective than dense legal text hidden in terms of service. The business should place information where users make decisions, not where only lawyers are likely to find it.
Minimal or no risk
Spam filters, recommendation features, and ordinary productivity tools may fall into the lower-risk category, depending on their purpose and deployment. Lower risk doesn't mean no governance. Security, privacy, intellectual property, accuracy, and consumer-protection issues can still apply under other laws or contracts.
| Risk Level | Description | Regulatory Approach | Example |
|---|---|---|---|
| Unacceptable risk | AI practices that threaten fundamental rights or exploit people | Prohibition or removal of the use case | Social scoring |
| High risk | Systems that can materially affect safety or important rights | Strict controls, documentation, oversight, and monitoring | Resume-sorting tool |
| Limited risk | Systems where users need clear awareness of AI involvement | Transparency and disclosure duties | Customer-service chatbot |
| Minimal or no risk | Ordinary uses with comparatively limited impact | No equivalent high-risk regime, subject to other legal duties | Spam filter |
A startup should document the reasoning behind its classification rather than record only the label. A practical AI risk assessment framework can help connect the risk tier to product purpose, affected people, controls, and approval authority.
Key Obligations for AI Providers and Deployers
Once a system falls into a regulated category, the organization needs controls that operate inside the product lifecycle. A policy that says “employees must use AI responsibly” won’t answer whether the model was tested, whether the training data was appropriate, whether a reviewer could intervene, or whether incidents were recorded.
Build controls around the system
For providers and deployers, the core work usually includes:
- Risk management: Maintain a living process that identifies foreseeable risks, assigns owners, records mitigations, and revisits assumptions after deployment.
- Data governance: Define how training, validation, and testing data are selected, assessed, cleaned, documented, and protected. Teams should record known limitations instead of treating data quality as an unverified vendor promise.
- Technical documentation: Keep enough information for reviewers to understand the system’s purpose, architecture, capabilities, limitations, testing, dependencies, and changes.
- Transparency: Tell users when they’re interacting with AI and explain material limitations in language they can act on.
- Human oversight: Give qualified people authority, access, time, and training to review outputs, override decisions, pause use, and escalate incidents. A nominal reviewer who can’t understand or change the result isn’t meaningful oversight.
- Conformity assessment: Complete the required assessment work before placing an applicable system on the market or putting it into service.
- Cybersecurity and monitoring: Protect the system against foreseeable attacks, monitor performance after launch, record incidents, and use findings to improve controls.
The technical file should connect evidence to requirements. Approval logs, test results, version histories, vendor diligence, user notices, reviewer training, and incident records can show how the company operated the system, not merely what its policy promised.
Prove the policy was followed
One industry report found that 25% of firms had no AI rules at all, and it emphasized that a policy document isn’t the same as an auditable control (Kiteworks’ analysis of the AI policy gap). The important question is no longer only, “Does the company have an AI policy?” It’s, “Can the company show that people followed it?”
A workable evidence system assigns each AI use case an owner and stores artifacts in a controlled location. The record should show who approved the use, what risk assessment applied, which vendor and model version were involved, how human review worked, what training occurred, and how exceptions were handled.
Evidence beats aspiration. Regulators, enterprise customers, and investors may care less about elegant principles than whether the company can produce a coherent record of decisions and controls.
Conformity Penalties and Enforcement Timelines
The EU AI Act creates urgency through both phased application and significant penalties. The timing matters for U.S. businesses because a product already available to EU users may need review before a founder has finished building a formal compliance function.
Prohibited AI practices and AI literacy obligations applied from 2 February 2025, while governance provisions and obligations for general-purpose AI models became applicable on 2 August 2025, according to the European Commission’s EU AI Act regulatory framework. The penalty mechanics also required practical implementation by 2 August 2025, when Member States were required to establish, notify, and implement national rules for penalties and fines (implementation timeline for the AI Act).
Understand the financial exposure
The maximum administrative fine for prohibited AI practices is up to €35 million or 7% of worldwide annual turnover, whichever is higher, while other non-compliance can reach €15 million or 3% of worldwide annual turnover. Supplying incorrect, incomplete, or misleading information can trigger fines up to €7.5 million or 1% of worldwide annual turnover, as described in the European Commission’s AI Act penalty FAQ.
Those figures shouldn’t be treated as a budgeting exercise. The more immediate business risks may include product suspension, customer termination, delayed procurement, remediation expense, and reputational damage. A startup that can’t explain its model inventory or vendor responsibilities may face commercial friction even before a formal penalty process concludes.
Treat dates as operating milestones
The company should translate legal dates into internal milestones:
- Identify EU-facing systems and owners.
- Stop or redesign any potentially prohibited use.
- Confirm AI literacy and training responsibilities.
- Review general-purpose model dependencies and provider documentation.
- Build evidence for high-risk and transparency obligations.
- Establish a monitoring calendar for regulatory and product changes.
A deadline is useful only when someone owns the work. The board, founders, general counsel, product leadership, and engineering team should know which decisions require legal approval and which can proceed under an established control.
Practical Compliance Steps for US Startups
A U.S. startup doesn’t need to begin with a massive governance manual. It needs a reliable operating system for finding AI use, classifying it, assigning responsibility, and preserving evidence. The most effective approach usually starts with inventory and moves toward controls that fit the company’s actual products.
Start with an AI inventory
The inventory should include customer-facing features, internal tools, embedded vendor capabilities, experiments, browser extensions, automated decision support, and systems employees use outside the approved technology stack. Each entry should record the business purpose, users, data types, geographic reach, vendor, model, owner, and decision impact.
The company can then classify each use case and document why. A marketing assistant, a support chatbot, a recruiting screener, and an identity-verification system shouldn’t share one generic approval path.
Convert the inventory into governance
A workable governance program assigns distinct responsibilities:
- Executive sponsor: Sets risk tolerance and resolves business trade-offs.
- Legal or compliance lead: Maps regulatory duties, contracts, notices, and escalation requirements.
- Product owner: Maintains the use-case description, testing record, and change history.
- Engineering and security: Controls access, logging, testing, model changes, and incident response.
- Human reviewers: Exercise documented oversight and report failures or uncertainty.
Vendor diligence deserves special attention. Contracts should address permitted uses, data retention, security, audit cooperation, incident notice, model changes, intellectual property, subcontractors, geographic processing, and allocation of regulatory duties. A vendor’s compliance statement is useful evidence, but it doesn’t eliminate the deployer’s responsibility for how the system is used.
The NIST AI Risk Management Framework offers a practical structure through four functions, govern, map, measure, and manage, and says trustworthy AI characteristics should be integrated into organizational policies, processes, procedures, and practices (NIST AI Risk Management Framework for Generative AI). For generative AI, NIST specifically recommends documenting the origin and history of training data and generated data, supporting auditability and provenance tracking.
A startup that is designing customer or employee data flows should also review privacy by design principles before deployment. Privacy controls work better when they shape architecture, permissions, retention, and user choices from the beginning rather than being added after a product has accumulated data.
The following video can help teams frame the operational discussion before converting it into an internal checklist.
Finally, establish change triggers. A new model, new data source, new customer segment, new country, changed decision purpose, security incident, or material performance shift should reopen the assessment. Compliance should travel with product change, not sit in a folder that nobody revisits.
Building Your Ongoing AI Governance Strategy
AI governance is an operating function, not a one-time document. The 2025 Stanford AI Index reported that AI-related mentions in legislative proceedings across 75 major countries rose 21.3% in 2024, showing that policymaking is accelerating rather than settling (Stanford AI Index policy and governance findings).
A durable program gives one person authority to maintain the inventory, establishes recurring reviews, tracks vendor and model changes, tests incident procedures, and reports unresolved risks to leadership. It also separates low-risk experimentation from deployments that affect employment, eligibility, safety, privacy, or access to important services.
For founders seeking a broader operating model, Freeform’s AI governance strategies can provide an additional reference point. Companies can also use an AI governance policy framework to formalize ownership, approval rules, documentation, and incident readiness.
The immediate priority is practical: appoint an owner, inventory every AI use case, classify the EU exposure, preserve evidence, and set a review cadence. That approach helps a U.S. business respond to changing rules without freezing product development.
By Design Law Firm & Legal Consultancy, PLLC advises startups and growing companies on AI governance policies, risk assessments, contracts, privacy, and incident readiness. Visit By Design Law Firm & Legal Consultancy, PLLC to discuss a practical compliance program for EU-facing AI products and U.S. operations. Contact our law office at (206) 593-1519.
