First, the honest disclaimer: we are an engineering studio, not your lawyers, and nothing here is legal advice. What we can do is translate a large piece of regulation into the terms a small team building software actually needs, because the gap between "there is an EU law about AI" and "here is what my six-person company has to have done by a specific Sunday" is where most teams are currently stuck, and stuck usually means doing nothing.
The specific Sunday is the second of August, 2026. That is the date the EU AI Act's obligations for high-risk AI systems become enforceable. The reflex for a small team is immediate and wrong: that is enterprise stuff, we are too small, it does not apply to us. Size is not the test. What your software decides about people is the test, and a lot of unremarkable features clear that bar.
The EU AI Act does not care how many people work at your company. It cares what your system decides about a person, and whether they live in the EU. A five-person team with an AI hiring filter is more exposed than a thousand-person team whose AI writes marketing copy.
Are you even in scope?
Most AI features are not high-risk, and the Act mostly leaves them alone. A chatbot, a summariser, a code assistant, a recommendation engine for films: low-risk, minimal obligations, get on with your life. The high-risk list is specific, and it is defined by domain of use, not by cleverness of model. The categories that catch ordinary companies are the ones that touch someone's access to a life outcome.
The ones we see startups walk into without noticing: employment, meaning anything that screens, ranks, or scores job candidates or manages workers, the exact kind of AI hiring filter half the market is now shipping; access to essential services, meaning credit scoring, insurance pricing, and eligibility decisions for benefits or services; education, meaning systems that score exams or gate admissions; and biometrics. If your product makes or materially informs a decision in one of those areas, you are likely looking at a high-risk system, and the fact that you are a startup changes nothing about that.
That deployer point is the one that surprises people. A team that assumes the compliance burden lives entirely with the model provider, because they only called an API, can still be a deployer of a high-risk system with its own obligations around human oversight, monitoring, and using the thing as intended. "We just used a model someone else made" is not the shield it feels like. It is the same misplaced confidence we wrote about in security is not a feature: assuming the risky part is somebody else's department right up until it is demonstrably yours.
What "compliance" concretely means
If you are in scope, the Act stops being abstract and turns into a checklist of things that must exist. Stripped of the legal language, a provider of a high-risk system is on the hook for roughly these:
A risk management process that runs across the system's life, not a one-time memo. Data governance: knowing what your training and input data is, and that it is relevant and not junk. Technical documentation thorough enough that a regulator could understand how the thing works. Automatic logging of what the system did, so decisions can be traced. Meaningful human oversight, a real person able to understand and override it, not a rubber stamp. And then the formal layer: a conformity assessment, a declaration, CE marking, and registration in the EU database before the system goes to market. Deployers carry a lighter but real subset, centred on oversight, monitoring, and using the system within its intended purpose.
None of this is exotic to a team that already builds carefully. Logging, documentation, a human in the loop, knowing your data: these overlap heavily with things a disciplined engineering practice does anyway. The Act's demand is mostly that you do them deliberately, write them down, and can produce the evidence, which is a different thing from having them live only in your senior engineer's head.
The deferral you should not bet on
Here is the part that is actively causing teams to freeze. There is a real, live proposal, part of a broader simplification package that cleared a key EU vote at the end of June, to defer the high-risk obligations, with dates as late as December 2027 being discussed. So a rational-sounding voice in the room says: relax, they are going to push it back, do nothing.
Do not run your company on that voice. Until the deferral is actually enacted and published, the second of August 2026 remains the legally binding date, and a proposal that has cleared one step of the EU process is not the same as law. Betting your compliance posture on a not-yet-passed amendment is a wager where being wrong is expensive and being right only saved you a few months of work you needed to do eventually anyway. Treat a possible extension as breathing room if it arrives, never as a plan.
A deferral that has not been enacted is a rumour with good sourcing, not a deadline. Build for the date on the books; enjoy the extra runway if it comes. The reverse bet has no upside worth the downside.
The minimum viable path
For a small team that has just realised it might be in scope, panic is not a plan and neither is a six-figure consulting engagement. The proportionate path has a clear first move: find out, in writing, whether any of your features are high-risk. Most teams discover the honest answer is no, and the entire exercise ends there with a documented rationale, which is itself worth having. That triage is an afternoon, not a quarter.
If something is in scope, the sane sequence is: identify the specific high-risk system and write down why it qualifies; determine whether you are the provider, the deployer, or both, because the obligations differ; then close the gap between the list above and what you already have, which for a careful team is usually smaller than feared, mostly documentation, logging, and making the human oversight explicit and real. The formal conformity and registration steps come last and are where you buy specialist help, once you actually know what you are registering. The mistake is inverting that order and starting with expensive process before you have even confirmed you are in scope.
What we actually do for clients
When a client ships anything near the high-risk categories, we fold this into the build rather than bolting it on at the end, for the same reason we build a deployment pipeline on day one: the controls the Act wants, traceable logging, clear documentation, a genuine human-override path, are cheap when designed in and painful when retrofitted under a deadline. A system built to be explainable and auditable from the first commit is most of the way to compliant as a side effect of being well engineered.
We are candid about the boundary. We build the technical evidence, the logging, the documentation, the oversight mechanisms, and we help a team understand honestly whether it is in scope. We do not sign the legal conclusions, and for the formal conformity assessment and registration we tell clients to bring in a specialist, because that is exactly the point where an engineering studio should stop and a lawyer should start. The value we add is making sure that when the lawyer arrives, the hard technical work is already done and documented, instead of being a scramble. It is the same lesson as securing an agent that can move money: the regulated, high-consequence surfaces are the ones you engineer for deliberately, early, and on purpose.
The bottom line
The EU AI Act is not, for most small teams, the existential threat the loudest coverage implies, nor the irrelevance the "we are too small" reflex assumes. It is a specific obligation that lands on specific kinds of software on a specific date, and the only genuinely dangerous position is not knowing which of those describe you. Spend the afternoon it takes to find out. If you are clear, you have a documented answer and peace of mind. If you are not, you have found out with time to act instead of after a regulator did the finding for you. Either way you have replaced the worst state a team can be in, uncertainty plus inaction, with a decision, which is the whole job.