EU AI Act Compliance for Small Dev Teams

The EU AI Act sounds like something that only applies to companies with a legal department. For most small teams building with AI, most of it does not apply to you. But the part that does apply is easy to miss precisely because you assumed the whole thing was someone else’s problem.

The four risk tiers, briefly

The Act sorts AI systems into four categories, and almost everything about your obligations follows from which one you land in.

Unacceptable risk is banned outright. Social scoring, certain kinds of biometric categorization, manipulative systems designed to exploit vulnerabilities. If you are reading this post you are almost certainly not building one of these, this tier exists mostly to rule things out, not to worry about.

High risk covers AI used in specific sensitive contexts, hiring, credit scoring, medical devices, critical infrastructure, law enforcement, and a defined list of other categories in the regulation’s annexes. This tier carries the heavy obligations, risk management systems, technical documentation, human oversight, conformity assessments, registration in an EU database. If your product falls here, this post is not enough, you need actual legal review.

Limited risk is where most AI products that talk to end users land, chatbots, AI-generated content, systems interacting with people. The obligation here is mainly transparency: tell users they are interacting with AI, and label AI-generated content as such where the Act requires it.

Minimal risk is everything else, which is most internal tooling, most developer-facing AI features, most AI used as a component rather than as the product’s core decision-maker. Largely unregulated.

What this means if you are a small team shipping an AI feature

Ask yourself honestly which tier you are in before doing anything else. Most small teams building an AI-powered feature, a chatbot, a content generator, an AI coding assistant, land in limited or minimal risk. That is a meaningfully smaller compliance burden than the headlines about the Act suggest.

If you are limited risk, the practical checklist is short:

• Disclose that users are talking to an AI system, clearly, not buried in a terms-of-service document
• Label AI-generated content as AI-generated where it could otherwise be mistaken for human output
• Keep basic documentation of what the system does and does not do

That is genuinely most of it for a lot of products. It is not nothing, but it is not the twelve-month conformity assessment process that high-risk systems require.

Where small teams actually get caught out

The mistake is not usually ignoring the Act entirely, it is misjudging which tier you are in. A hiring tool that screens resumes with an AI component is high risk even if the AI part feels like a small piece of a bigger product. A feature that scores customer creditworthiness, even as a secondary signal alongside human review, likely falls under high risk too. The classification is based on the use case and context, not on how central the AI feels to your product’s identity.

If your product touches employment decisions, access to essential services, credit, education, or biometric identification in any way, do the tier classification properly and get it checked, do not assume you are minimal risk because the AI part feels incidental.

What you can actually ignore for now

If you are building general-purpose AI tooling, a code assistant, an internal automation, most B2B SaaS features that use AI as an implementation detail rather than the product’s core value judgment, the heavy machinery of the Act, conformity assessments, EU database registration, quality management systems, does not apply to you. Full applicability for high-risk systems lands August 2026, and if you are not in that tier, that deadline is not yours to worry about.

Do not build a compliance program for a tier you are not in. That is wasted effort that would be better spent on the actual product.

The one thing worth doing regardless of tier

Even outside the Act’s specific requirements, basic documentation of what your AI feature does, what data it uses, and what its known limitations are, is good practice on its own. It is also the thing that makes a tier reassessment fast later if your product’s scope changes and you suddenly need to check again.

AIVory Guard runs compliance scanning inside your IDE, catching some of the technical documentation and data-handling gaps that show up regardless of which regulatory tier you end up in. It is not a substitute for legal review if you land in high risk. For most small teams building most AI features, though, the actual obligation is narrower than it looks from the outside, and the first step is just being honest with yourself about which tier you are actually in.