The EU AI Act entered into force in August 2024, and its provisions are rolling out in phases through 2027. If you are a team of 3 to 15 people building AI-powered software, you probably have two questions: does this apply to me, and what do I actually need to do?
Here is the short version. The Act applies to any AI system placed on the EU market or whose outputs are used within the EU, regardless of where your company is incorporated. A Delaware C-Corp serving users in Berlin still falls under its scope. The good news is that most small teams building typical SaaS products fall into the "minimal risk" or "limited risk" categories, which means your compliance burden is manageable. But you need to know which bucket you are in, because the gap between buckets is enormous.
The Four Risk Tiers, Simplified
The Act classifies AI systems into four tiers based on what the system does, not how it works. A simple logistic regression model used for credit scoring is high-risk. A large language model used to generate marketing copy is not. The categories:
- Unacceptable risk (banned): Social scoring by governments, real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions), manipulation of human behavior through subliminal techniques. If you are a startup, you are almost certainly not here. These are tools of state surveillance and behavioral coercion.
- High risk (heavy obligations): AI systems used in hiring, credit scoring, education admissions, law enforcement, critical infrastructure management, and medical diagnostics. These require full technical documentation, conformity assessments, human oversight mechanisms, and registration in the EU database. The penalties for non-compliance go up to EUR 35 million or 7% of global annual turnover, whichever is higher.
- Limited risk (transparency obligations): Chatbots, deepfake generators, emotion recognition systems, and AI-generated content. You must disclose to users that they are interacting with an AI system. That is basically it.
- Minimal risk (no specific obligations): Spam filters, recommendation engines, inventory optimization, most internal tooling. The vast majority of AI systems in production today fall here. No special requirements.
The critical question for your team is whether your product touches any of the eight high-risk domains listed in Annex III of the Act. Those domains are: biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border management, and justice and democratic processes.
What "High Risk" Actually Means in Practice
If your AI system is classified as high risk, here is what the Act requires:
- Technical documentation: A detailed description of the system, its intended purpose, the training data (including provenance and any known biases), the model architecture, performance metrics, and known limitations. The Act specifies the exact structure in Annex IV. Expect this to be 30 to 50 pages for a moderately complex system.
- Risk management system: A documented process for identifying, analyzing, and mitigating risks throughout the system lifecycle. This is not a one-time exercise. You must update it whenever the system is substantially modified.
- Data governance: Training, validation, and testing datasets must meet quality criteria. You need to document data collection methodologies, identify potential biases, and show you have examined the data for relevance, representativeness, and statistical properties.
- Transparency to deployers: You must provide enough information for the entity deploying your system to interpret its outputs and use it correctly. This includes the system's capabilities, limitations, intended purpose, and accuracy metrics.
- Human oversight: The system must be designed so that humans can understand its outputs, override or interrupt it, and intervene when it produces erroneous or harmful results.
- Accuracy, robustness, and cybersecurity: You need to demonstrate that the system performs as intended, is resilient to errors and adversarial attacks, and has appropriate security measures.
- Conformity assessment: Before placing a high-risk AI system on the EU market, you must conduct a conformity assessment to verify it meets all the above requirements. For systems not already covered by sectoral legislation, you can self-assess. For those covered by existing regulations (like medical devices), a third-party notified body is required.
What General Purpose AI (GPAI) Rules Mean for You
If you are fine-tuning or deploying a foundation model like GPT-4, Claude, or Llama, you need to understand the GPAI provisions. These apply to the providers of foundation models, not necessarily to downstream teams using them through APIs. If you are building on top of OpenAI's API, OpenAI bears the GPAI provider obligations, not you.
But if you are training your own foundation model or significantly fine-tuning an open-weight model and releasing it, the GPAI rules apply to you. Requirements include:
- Technical documentation of the model, its training process, and its capabilities
- A copyright compliance policy showing you have a policy to respect EU copyright law, including the text and data mining opt-out mechanism
- A detailed summary of the training data content, to be made publicly available
- For models deemed to pose systemic risk (training compute exceeds 10^25 FLOPS), additional obligations including adversarial testing, incident reporting, and cybersecurity protections
For most small teams, the GPAI rules are relevant only if you are releasing your own models. If you are an API consumer, focus on the risk classification of your specific application instead.
The Compliance Timeline
The Act's provisions are phased in over three years:
- February 2025: Prohibitions on unacceptable risk practices took effect. This is already live.
- August 2025: Obligations for GPAI providers, including transparency requirements and copyright compliance policies.
- August 2026: Full application of high-risk AI system requirements. This is the big deadline. If you are building a high-risk system, your documentation, risk management, and conformity assessments must be complete by this date.
- August 2027: Requirements for high-risk systems embedded in regulated products (medical devices, machinery, toys, etc.) under existing EU product safety legislation.
If your product is in the high-risk category and you do not have a compliance plan in place right now, you are behind. The August 2026 deadline is 15 months away at time of writing, and the documentation requirements are substantial.
A Practical Compliance Checklist for Small Teams
Here is a step-by-step process that a small team can actually execute without hiring a compliance consultant.
Step 1: Classify your AI system
Go through Annex III of the Act. Does your product fall into any of the eight high-risk domains? Be honest here. A hiring tool that screens resumes is high risk. A chatbot that helps users navigate your documentation is limited risk. An internal tool that clusters customer support tickets is minimal risk.
If you are unsure, err on the side of caution and treat it as high risk. The cost of over-documenting is far lower than the cost of non-compliance.
Step 2: Map your data flows
Document what data goes into your model, where it comes from, how it is processed, and what comes out. For high-risk systems, you need to trace training data provenance, identify potential biases, and document any data cleaning or preprocessing steps.
For most teams, this means building a living document that tracks: data sources, collection dates, preprocessing steps, known biases or gaps, and validation results. A shared Google Doc or Notion page works fine for this. The Act does not mandate a specific format.
Step 3: Build your technical documentation
Use Annex IV as your template. It specifies the exact sections required. For a small team, plan on 1 to 2 weeks of focused work to produce the initial document for a high-risk system. You will need input from your engineers (model architecture, training process), your product people (intended use, target users), and your data team (training data, performance metrics).
The key sections to get right:
- A clear, precise description of the system's intended purpose
- Performance metrics on relevant subgroups (not just aggregate accuracy)
- Known limitations and failure modes
- Human oversight mechanisms
- Cybersecurity measures
Step 4: Implement human oversight
For high-risk systems, you need to build interfaces that allow human operators to understand, override, and interrupt the system. This is not just a UI feature. It is a design principle.
Practical implementations include: confidence scores on every prediction, clear explanations of how the system reached its output, a mechanism for users to flag incorrect results, and audit logs that record every system decision with timestamps. If you are building a credit scoring tool, for example, you need to show the human reviewer which features drove the score and allow them to override the automated decision.
Step 5: Set up your quality management system
The Act requires a quality management system for high-risk AI providers. For a small team, this does not need to be an ISO 9001 certification. It needs to be a documented, repeatable process that covers: how you test model performance before deployment, how you monitor performance in production, how you handle incidents and complaints, and how you manage updates and retraining.
Write this down. Keep it updated. The EU regulators will ask for it.
Step 6: Handle transparency requirements
Even if your system is not high risk, you may need to disclose that users are interacting with an AI. For chatbots, this means a clear disclosure at the start of the conversation. For AI-generated content (images, video, audio), you must label it as artificially generated. For deepfakes, you must disclose that the content is not real.
This is straightforward to implement and applies broadly. If your product has any AI-generated content that could be mistaken for human-created content, add a disclosure.
Common Mistakes Small Teams Make
I have seen teams make the same errors repeatedly when approaching EU AI Act compliance.
Treating compliance as a legal-only problem. The technical documentation requirements cannot be filled in by a lawyer. Your engineers need to own the sections on model architecture, training data, performance metrics, and failure modes. Legal review comes after.
Assuming "we are too small to be targeted." The Act applies based on what your system does and who it serves, not your company size. A two-person startup building a hiring screening tool has the same high-risk obligations as Workday. There is no SMB exemption.
Confusing "we use AI" with "we are an AI system provider." If you use GitHub Copilot to write code, you are a deployer, not a provider. The Act's heavy obligations fall on providers. Deployers of high-risk systems have obligations too (using the system as intended, monitoring performance, keeping logs), but they are lighter than provider obligations. Know which role you play.
Ignoring the GPAI copyright provisions. Even if you are just fine-tuning a model, you need a documented copyright compliance policy. The EU text and data mining opt-out mechanism (Article 4 of the DSM Directive) means rights holders can opt out of having their content used for AI training. If you are scraping data to train models, you need to check for opt-outs.
What This Costs
For a small team building a high-risk AI system, expect to invest roughly:
- 80 to 120 engineering hours for initial technical documentation
- 20 to 40 hours for data governance documentation
- 2 to 4 weeks of development time to add human oversight mechanisms, audit logging, and transparency features
- Ongoing: approximately 10% of engineering capacity for continuous compliance monitoring, documentation updates, and incident response
For limited-risk and minimal-risk systems, the cost is minimal. A transparency disclosure for a chatbot takes an afternoon to implement. The real cost is in the high-risk tier, and that is where you need to make a deliberate decision about whether your product belongs there.
The Takeaway
Classify your system honestly. If it is minimal risk, document that classification and move on. If it is limited risk, add the required transparency disclosures, which you can implement in a day. If it is high risk, start your documentation now. The August 2026 deadline is firm, the penalties are real, and the work required is substantial but manageable for a focused small team.
The Act is not designed to crush small companies. It is designed to make sure that AI systems affecting people's lives, from hiring decisions to credit scores, meet a minimum standard of transparency, accountability, and safety. If you are building something in those domains, you should want these safeguards anyway. Compliance is not just a legal checkbox. It is a way to build a product that people can trust.
Start with Annex III. Figure out your risk tier. Then work backward from there.