"We are not in Europe" is not an answer
A software company in Lagos, Accra or Nairobi builds a tool that scores job applicants, or a chatbot for customer support, or a credit model. It has no office in Europe, no European staff and no plan to open one. So the EU AI Act is somebody else's problem.
Sometimes that is correct. More often it is an assumption nobody has tested. The Act was written to reach beyond the EU's borders, in the same way the GDPR did, and for the same reason: Europe regulates the market it protects, not the place the vendor sits. Whether you are caught depends on what you build, who uses it and where the output ends up.
This is an explainer, not legal advice. The details of a specific product need a lawyer. But the structure is simple enough to reason about before you pay for one.
What the Act is, in outline
The EU AI Act entered into force in August 2024, with obligations phasing in over the following years. Some provisions, such as the bans on certain practices, applied first. Rules for general purpose AI models came next. The bulk of the requirements for high risk systems follow later, and the timetable has been the subject of ongoing discussion in Europe, so check current dates rather than relying on a blog post, including this one.
The Act takes a risk based approach. It sorts AI systems into broad tiers:
- Unacceptable risk: practices that are prohibited outright, such as certain forms of manipulation or social scoring.
- High risk: systems used in sensitive areas, such as employment, education, access to essential services including credit, and some safety components of regulated products. These carry the heaviest obligations.
- Limited risk: systems with transparency duties, for example telling people they are talking to an AI or labelling synthetic content.
- Minimal risk: everything else, which is most software and is largely left alone.
Separate rules apply to providers of general purpose AI models, with extra duties for those considered to carry systemic risk.
How it reaches outside Europe
The Act applies on the basis of where a system is placed on the market, put into service or used, not where the company is incorporated. In broad terms, you can be covered if:
- You are a provider who places an AI system on the EU market or puts it into service in the EU, wherever you are established.
- You are a provider or deployer outside the EU, and the output of your system is used in the EU.
- You are a deployer (a business using an AI system) established in the EU, even when the provider is elsewhere.
Two roles matter here. A provider develops a system or has one developed and offers it under its own name. A deployer uses a system in the course of its work. Obligations differ between them, and a company can be both.
The second bullet is the one that catches people. Consider a Ghanaian company that sells a recruitment screening tool to a multinational with offices in Europe. Or a Nigerian lender whose model is used to assess applicants who live in an EU country. The vendor never set foot in Europe, yet its output affects people there. That is the pattern the Act has in mind.
What changes if you are in scope
The consequences depend almost entirely on the tier.
Minimal risk systems face few specific obligations. Most internal automation, recommendation features and productivity tools sit here.
Transparency duties are modest. If users interact with a chatbot, they should know it is not a person. Generated or manipulated media should be identifiable as such.
High risk systems carry a substantial programme: a risk management process, quality and governance requirements for training and testing data, technical documentation, record keeping, human oversight, accuracy and robustness measures, and in many cases conformity assessment before the system goes to market. Providers based outside the EU generally need to appoint an authorised representative inside it.
General purpose model providers have documentation and transparency duties, including around training content and copyright policy, with more demanding obligations for the most capable models.
Penalties are significant. The most serious breaches, such as using a prohibited practice, can bring fines up to a percentage of worldwide annual turnover, with lower tiers for other violations. For small companies, the rules aim for proportionality, but the principle stands: this is not a paper exercise.
A practical way to work out where you stand
You do not need to start with the whole text. Work through these questions in order.
First, inventory what you build and use. List every system that involves machine learning or generative models, including features inside larger products and tools you bought. Many companies discover AI they did not think of as AI.
Second, map each one to a market. Does any customer, user or affected person sit in the EU? Is the output used there? If the honest answer is "no, and our contracts say so", you may be out of scope, and it is worth recording why.
Third, classify by purpose, not by technology. The same model is minimal risk as a spelling helper and high risk as a hiring filter. Look at what decision the output feeds and whom it affects.
Fourth, identify your role. Provider, deployer, or both. If you build on someone else's model, check what they commit to and what they leave to you.
Fifth, do the cheap things now. Document how the system works, what data trained it, how you test it and who can override it. These habits are useful commercially, and they are the foundation of any later compliance work.
The wider effect
Even companies clearly outside the Act's reach may feel it. European customers increasingly ask suppliers to confirm how their AI works and what governance sits around it. Procurement questionnaires travel. Larger partners push requirements down the chain through contracts, whether or not the law strictly demands it.
There is also a design lesson here that applies at home. Nigeria's Data Protection Act 2023 and similar laws across the continent already govern the personal data that AI systems consume, and expectations about explainability and human review are growing everywhere. A system built with documentation, oversight and clear purpose is easier to defend in any jurisdiction.
One more point on timing. The Act's dates are staged on purpose, to give organisations time to prepare, and some obligations arrived well before others. A company that waits for the last deadline will find its customers asked the questions much earlier. Building the inventory now costs a few days of someone's time. Building it under a contract deadline costs far more.
A sensible stance
Neither panic nor dismissal is warranted. Most African software companies building ordinary products will find the Act's direct demands light or absent. The ones that sell into hiring, lending, education or health in Europe, or provide models others build on, should treat it as a real obligation with a real timeline.
The cheapest compliance is a clear picture of your own systems, written down while the product is small. That is worth doing whatever the regulation turns out to require.