A Seattle SaaS founder closes a first deal with a customer in Germany. The product was built for the U.S. market, the engineering team is in Washington, and the company has no European office. Then procurement asks for an EU AI Act assessment. The founder's immediate questions are practical: does one EU customer create regulatory exposure, does embedding an outside model change the answer, and when does a small company start carrying provider-level duties?
Those questions matter because the Act follows the AI system, its role, and its market activity, not the size of a company's headquarters. U.S. startups and Washington State businesses can face obligations when they sell AI-enabled services into the EU, operate systems for EU customers, or produce outputs used there. The legal analysis also sits alongside GDPR, contract, employment, biometric, consumer-protection, and cybersecurity requirements.
Why the EU AI Act Matters to a U.S. Founder
The EU AI Act became law through a staged process. The European Parliament formally adopted it on 13 March 2024, with 523 votes in favor, 46 against, and 49 abstentions, and it entered into force on 1 August 2024 after publication in the EU's Official Journal, as documented by the European Parliament's adoption announcement. The Act doesn't wait for a company to open a European subsidiary before it matters.
A Seattle company can be a provider if it develops an AI system and places it on the EU market under its own name. It can be a deployer if it uses a third-party system under its authority, including an API embedded in customer service, hiring, credit, or internal operations. It may occupy both roles for different products or workflows.
Practical rule: An EU customer is a trigger for analysis, not a conclusion that the company is either covered or exempt.
The most common mistake is treating the model vendor as the only responsible party. A founder choosing the model, configuring the prompts, selecting the input data, defining the intended purpose, and controlling production use may still carry deployer duties. A company that substantially modifies a system, changes its intended purpose, or markets it under its own name may move into provider territory.
Cross-border data issues can compound the problem. A company assessing EU exposure should also review its data-transfer structure through a practical cross-border data transfer guide for Seattle companies, rather than treating AI compliance as a substitute for GDPR analysis.
This article's core recommendation is straightforward: inventory every AI use, classify each use by role and risk, preserve evidence, and negotiate vendor terms before an EU customer makes the issue urgent.
What the EU AI Act Is and How It Actually Works
The EU AI Act is best understood as a product-safety-style regulation for AI systems. It isn't a voluntary code of conduct or a general promise to use technology responsibly. It establishes legal obligations based on the risks created by a system, its intended purpose, and the way people or organizations use it.
The risk model sits alongside existing law. GDPR still governs personal data, lawful bases, transparency, security, and individual rights. Employment, consumer-protection, product-safety, cybersecurity, and sector rules can also apply. A compliant AI Act file won't cure an unlawful data transfer or discriminatory employment practice.
The reach is broader than many U.S. operators expect. The Act addresses providers placing systems on the EU market, deployers located in the EU, and certain systems whose outputs are used in the EU. That can catch a Washington company selling an AI-driven service to an EU customer, even when the product team, servers, and legal entity remain in the United States.
The rollout is deliberately staggered
The first prohibitions became applicable on 2 February 2025, while general-purpose AI obligations began on 2 August 2025. The main transparency rules under Article 50 apply from 2 August 2026, with a grace period for certain pre-existing systems until 2 December 2026, according to the European Parliament's timeline.
The high-risk schedule extends further. Certain sensitive-use cases are scheduled for 2 December 2027, and some AI systems embedded in regulated products have a later milestone of 2 August 2028, as described in the Act's penalty and application provisions at Article 99 of the EU AI Act.
For founders, the staggered structure changes the planning question. “Prepare by 2026” is too vague to be useful. A company needs a date-specific plan for prohibited practices, GPAI responsibilities, transparency controls, and high-risk evidence.
The Four Risk Tiers Explained With Real Examples
The risk tier determines the compliance response, but classification depends on the system's intended purpose and actual use. A general-purpose chatbot may create limited-risk transparency duties in one setting, while an AI tool used to rank job candidates can create high-risk concerns in another.
Unacceptable risk
The Act prohibits certain practices because the use itself creates an unacceptable threat. Examples include social scoring, manipulative systems that exploit vulnerabilities, and untargeted scraping of facial images to build recognition databases. A founder building a consumer app should also treat facial-analysis and behavior-shaping features as immediate red-flag subjects, not features to launch first and review later.
Some biometric identification uses have narrow law-enforcement exceptions subject to strict conditions. Those exceptions don't create a safe harbor for ordinary commercial product design.
High risk
High-risk systems can affect safety or fundamental rights. Recognizable examples include AI used in hiring, credit scoring, education scoring, biometric identification, critical infrastructure, migration, asylum, and border control. A U.S. provider doesn't avoid the category merely because conformity work happens in Seattle. Providers must prepare the technical and governance evidence required for the applicable system.
High-risk obligations include risk management, data governance, traceability, human oversight, technical documentation, accuracy, reliability, and cybersecurity. The European Commission describes these requirements on its AI regulatory framework page.
Limited risk
Limited-risk systems usually trigger transparency duties rather than the full high-risk stack. Familiar examples include chatbots that interact directly with people, deepfake-generation tools, and emotion-recognition systems. Users may need to know that they're interacting with AI, and synthetic or manipulated content may need appropriate marking.
Minimal risk
Spam filters, recommendation engines, and internal productivity tools generally sit at the lower end of the framework. They usually don't receive new mandatory obligations under the Act beyond voluntary codes, although existing privacy, security, employment, and consumer laws still apply.
| Risk Tier | Example Use Case | Key Obligation |
|---|---|---|
| Unacceptable risk | Social scoring or manipulative behavior systems | Prohibition, subject to narrow statutory exceptions |
| High risk | Hiring, credit, education, biometrics, critical infrastructure | Lifecycle risk management, documentation, oversight, testing, and applicable conformity requirements |
| Limited risk | Chatbots, deepfakes, emotion recognition | User and content transparency |
| Minimal risk | Spam filters, recommendations, internal productivity tools | No new general duties under the Act, with voluntary governance available |
A useful next step is to document the reasoning behind each classification in an AI risk assessment framework. The file should explain the intended purpose, affected people, data, jurisdiction, and facts supporting the conclusion.
Provider Versus Deployer Duties and Why the Distinction Matters
The Act assigns duties according to a company's role in the AI lifecycle. A provider develops a system or places it on the market under its own name. A deployer uses a system under its authority. The same startup can be a provider for a product it sells and a deployer for an AI service it buys.
Providers carry the engineering file
A provider of a high-risk system needs evidence that regulators can inspect. That includes documented risk management, data-governance controls, training, validation and testing data quality, logging, human oversight, technical documentation, cybersecurity, post-market monitoring, and incident reporting.
Article 11 documentation should capture the system's purpose, architecture, versioning, datasets, validation results, and risk controls. Article 15 addresses measurable characteristics such as accuracy, resilience, and cybersecurity. The practical consequence is important: a provider needs evidence about the live production version, not merely an old training snapshot.
The European Commission's AI Act guidance identifies the lifecycle nature of these obligations. Engineering teams should therefore preserve version histories, test results, data-lineage records, mitigation testing, monitoring outputs, and approved changes.
Deployers control the use case
Deployers must follow provider instructions, assign effective human oversight, monitor operation, preserve relevant logs, and respond appropriately to serious incidents. A deployer may also need a data-protection impact assessment where personal-data processing creates the relevant level of risk.
Third-party integration doesn't automatically transfer responsibility. If a Washington company selects an API, decides which employees or customers are evaluated, supplies the input data, and puts the output into an operational decision, that company has meaningful deployer responsibilities.
Documentation should explain not only what the system does, but who approved its use, under which instructions, with what data, and what happens when the output is wrong.
Resellers, importers, distributors, and customizers can occupy different positions depending on branding, modification, and market activity. Each business should map its role for each use before assessing obligations. Contract review can then address documentation access, audit support, incidents, security, and model changes through an AI contract review process.
Comparing Provider and Deployer Obligations Side by Side
The distinction becomes clearer when responsibility is placed next to control. Providers control system design and market placement. Deployers control the operational setting, users, data, and decisions affected by the system.
| Provider Duties | Deployer Duties |
|---|---|
| Maintain lifecycle risk management and data governance | Use the system according to provider instructions |
| Prepare technical documentation and records | Assign competent human oversight |
| Test accuracy, robustness, and cybersecurity | Monitor operation and preserve relevant logs |
| Design human-oversight controls | Conduct relevant impact assessments |
| Complete applicable conformity assessment and registration | Inform affected people or workers where required |
| Conduct post-market monitoring and serious-incident reporting | Stop or contain use after a serious incident |
| Support regulator access and maintain quality management | Retain, protect, or return data under applicable terms |
| GPAI providers maintain model documentation and training-content records | Integrators assess how the model's use creates deployer duties |
| Importers and distributors verify required information and documentation | Product manufacturers assess AI embedded in regulated products |
An SMB integrating an external model should assume that some obligations remain in-house. The vendor may control foundational model training, but the customer often controls prompts, fine-tuning, data sources, access permissions, human review, and the final business decision.
A company can also accumulate duties. A startup may provide a customer-facing application, deploy a separate AI tool for hiring, and distribute a third-party product through its sales channel. Substantial modification, a new intended purpose, or branding under the startup's name can create provider-level consequences.
For a broader operational checklist, an EU AI Act compliance roadmap can help teams organize obligations by lifecycle stage. It shouldn't replace role-specific legal classification, but it can give a small team a usable starting structure.
A Practical Compliance Roadmap for Startups and SMBs
A small company doesn't need a giant compliance department to start. It needs a written record that answers basic questions consistently and survives employee turnover, vendor changes, and customer diligence.
Start with an inventory
List every AI tool, model, feature, vendor, business unit, and data flow. Record the vendor, model version, purpose, users, inputs, outputs, personal data, affected individuals, EU exposure, and whether the company develops, modifies, brands, resells, or operates the system.
Include ordinary tools. An HR résumé screener, customer-service assistant, sales-enrichment platform, code assistant, and image generator can create different legal questions even when no team labels them “AI products.”
Classify with written reasoning
For each use, record whether it involves a prohibited practice, high-risk category, transparency trigger, GPAI role, or lower-risk function. Don't copy the vendor's marketing label into the legal conclusion. Document the assumptions, intended purpose, affected population, data sources, and reason the classification is defensible.
The company should also assign an owner, approval gate, acceptable-use rule, prohibited-use list, access control, data-minimization standard, and vendor-diligence process. An AI risk assessment template can make those decisions repeatable across products and departments.
Build the evidence before the customer asks
High-risk work requires test results, human-oversight procedures, impact assessments where relevant, monitoring records, data-governance evidence, and technical documentation. General-purpose AI providers face separate documentation, copyright, and training-content obligations. A downstream deployer should obtain the records needed to understand limitations and control use.
Vendor contracts should address:
- Documentation access: The vendor should identify the model, version, intended purpose, limitations, testing, and relevant controls.
- Operational visibility: The contract should cover logs, model-change notices, security information, and support for investigations.
- Incident cooperation: Terms should require prompt notice and practical assistance when an output creates a serious event.
- Data restrictions: The company should control whether prompts, customer data, or confidential material can be used for training or product improvement.
- Audit and assessment support: The vendor should provide reasonable assistance with conformity work, customer diligence, and regulator requests.
A governance program also needs an incident plan that can identify, contain, investigate, preserve evidence, notify the provider, and escalate serious events within applicable deadlines. Teams looking for a broader operational checklist can review these top 10 AI governance practices as a supplement to legal advice.
The following video can support internal discussion about implementation priorities:
Washington businesses should map Washington privacy, employment, biometric, and consumer-protection rules beside EU requirements. The AI Act is not a substitute for those obligations. Reassessment should occur whenever the purpose, model, data, jurisdiction, or material system behavior changes.
Enforcement, Penalties, and Recent Political Shifts
The Act entered into force on 1 August 2024, but enforcement doesn't arrive as one event. The first prohibitions applied on 2 February 2025, GPAI obligations began on 2 August 2025, and the main Article 50 transparency rules apply from 2 August 2026, with a grace period for certain existing systems until 2 December 2026, according to the European Parliament's official timeline.
Member State authorities handle much of the national enforcement structure, while EU-level mechanisms address designated responsibilities, including general-purpose AI oversight. The maximum penalty for prohibited AI practices reaches EUR 35 million or 7% of global annual turnover, whichever is higher. Other violations can reach EUR 15 million or 3% of worldwide turnover, while incorrect or misleading information can reach EUR 7.5 million or 1% of worldwide turnover, as set out in Article 99 of the Act.
The turnover-based structure matters to multinational companies because exposure isn't limited to EU revenue. A smaller company should still take the figures seriously, but it should also understand that maximum penalties aren't an automatic assessment in every matter.
Political changes have made the calendar more nuanced, not irrelevant. The EU's AI Omnibus amendments have shifted some high-risk milestones, including 2 December 2027 for certain stand-alone sensitive-use systems and 2 August 2028 for certain regulated-product AI systems, while the already scheduled transparency and GPAI enforcement milestones remain central to near-term planning. The European Commission's European approach to artificial intelligence reflects the need for role-specific preparation rather than a generic “wait for 2026” strategy.
The sensible response this quarter is to fix inventory, classification, contracts, and evidence. Political delay may give a high-risk team more runway, but it doesn't make missing records, prohibited uses, transparency failures, or poor vendor controls safe.
Your Next Steps and When to Call Outside Counsel
A startup or SMB can begin with a focused governance sprint:
- Inventory every AI component. Include SaaS tools, APIs, internal scripts, embedded models, and customer-facing features.
- Classify each use. Record the tier, role, intended purpose, affected people, EU connection, and reasoning.
- Document data and oversight. Preserve data sources, version records, testing, limitations, approval owners, and human-review procedures.
- Update vendor contracts. Address model changes, logs, security, incidents, data use, audit support, and documentation access.
- Create a governance log. Track approvals, incidents, complaints, changes, monitoring, and reassessments.
Outside counsel should be involved before launch when the company processes biometric or children's data, deploys AI in hiring or credit, operates in a regulated sector, substantially modifies a model, or sells an AI system into the EU. A Seattle technology attorney adds the most value when product design, contracts, privacy, employment, and cross-border deployment intersect. An in-house privacy lead or compliance operations owner may handle routine inventory and monitoring once the legal classification and control framework are established.
A workable starter plan assigns ownership immediately, completes the inventory next, documents high-concern uses after that, and then updates vendor terms and incident procedures. The company should put a recurring review on the calendar whenever a model, purpose, data source, customer market, or production behavior changes.
By Design Law Firm & Legal Consultancy, PLLC helps Washington founders and technology companies assess AI roles, classify risk, review vendor contracts, and build practical governance and incident-readiness processes for EU AI Act exposure. Visit By Design Law Firm & Legal Consultancy, PLLC to discuss an AI compliance plan tied to the company's products, customers, and operating reality.
