Consider an illustrative Nairobi-based software team that adds a generative AI assistant to a recruitment platform used by a European customer. The model is purchased through an API. The team builds the interface, selects the information the assistant can retrieve, sets the prompts, chooses which suggestions reach the hiring manager and deploys the feature. Six months later, a client asks for the technical documentation, the intended-use description, the process for reporting a serious malfunction and an explanation of how applicants are told about the system.
The immediate temptation is to pass the request to the model provider. That misses where the product has changed. The EU Artificial Intelligence Act, consolidated as of 27 July 2026 distinguishes among actors in the AI value chain, and its obligations depend on the role an organisation actually performs. A company that builds and places an AI-enabled system on the EU market cannot assume that using a third-party model removes its own responsibilities. For African software firms serving European users, the AI Act makes the product boundary wider: the system includes the model, data flow, user interface, human decision and operational evidence around it.
The Regulation entered into force on 1 August 2024 and its general application date remains 2 August 2026, with staged exceptions. The enacted Digital Omnibus on AI, Regulation (EU) 2026/1744 entered into force on 27 July 2026 and changed the high-risk timetable. Under amended Article 113, Chapter III Sections 1–3 apply from 2 December 2027 for Article 6(2)/Annex III high-risk systems and from 2 August 2028 for Article 6(1)/Annex I high-risk systems. General-purpose AI (GPAI) model rules started applying on 2 August 2025, and Article 50 transparency rules generally apply from 2 August 2026, with specific transitions. These dates do not regulate every African company in the same way. They make role, intended purpose and market exposure questions that product teams need to answer precisely.
Territorial reach is a product question
The AI Act’s scope is not limited to organisations established in the European Union. Article 2 includes providers placing AI systems or general-purpose AI models on the Union market, whether or not those providers are established in the Union. It also covers providers and deployers outside the Union where the output produced by the system is used in the Union. The detailed application depends on facts, role and use case; businesses should seek legal advice for their particular circumstances.
For a product leader, the important point is practical rather than abstract. A Ugandan, Kenyan, South African or Ghanaian software company may develop in one jurisdiction, host in another, use a model API from a third, and serve an EU-based client or end user. The commercial contract may name only one customer, but the architecture can still place the firm within an EU-facing AI value chain.
This is not a reason to avoid European markets. It is a reason to stop treating regulatory exposure as a late-stage legal issue. The choices that shape an AI system’s purpose, user interaction, evidence and control are usually made by product, engineering, data and operations teams long before a contract is reviewed.
Location does not settle the question; function does. A team that merely integrates a tool for internal support will face a different analysis from a team that offers an AI feature to EU clients, modifies a model for a particular task, or determines how an AI recommendation influences employment, credit, education or access to essential services. Lumping these cases together produces either false alarm or false comfort.
Buying a model is not outsourcing the system
The Act separates a general-purpose AI model from an AI system that incorporates it. Under Article 53, GPAI-model providers must supply specified information and documentation to downstream system providers, subject to the limited open-source exception in Article 53(2). Models placed on the market before 2 August 2025 have a compliance transition to 2 August 2027 under Article 111(3). Using a model API does not, by itself, turn an application builder into the provider of that GPAI model; it may still leave the builder responsible as provider of the resulting AI system.
That information is useful, but it cannot document decisions made by the application builder. A model provider cannot know which internal knowledge base a customer-support assistant is allowed to search, whether a hiring tool ranks candidates, how a user can contest an outcome, or what happens when the application’s confidence checks fail. Those are system-design choices.
This is especially important for firms working with constrained data and operationally uneven environments. A product that retrieves from a client’s records needs permissions, tenant isolation, logging and a process for correcting source material. A local-language interface needs task-specific evaluation, not a generic claim about multilingual capability. A tool that can send a message, approve a request or change a record needs explicit authority limits and a way for a person to intervene. The system’s risk is created by the combination, not by the model alone.
Keep the supplier boundary visible. Procurement should establish what the model supplier documents, what restrictions apply, where data is processed, how updates are communicated and which safety controls are available. Product documentation should then record what the firm has added: intended use, users, retrieval sources, tool permissions, human oversight, known limits, tests and incident routes. This is good engineering even where a use case falls outside the Act’s high-risk categories.
Classification cannot be guessed from a feature name
A chatbot, scoring tool or image-analysis feature is not automatically high-risk. Conversely, an innocuous label does not settle the matter. The Act identifies both prohibited practices and high-risk categories, including certain uses in employment, education, access to essential private and public services, law enforcement, migration, justice and democratic processes. The Commission’s overview provides examples such as recruitment CV-sorting and credit scoring that can affect access to a loan.
The classification under Article 6 and Annex III depends on intended purpose and the way the system is placed on the market or put into service. A general writing assistant may have a very different profile from a feature used to rank job applicants. A software firm should therefore avoid a superficial inventory that simply asks, “Do we use AI?” It needs a system register that asks what decision the feature influences, who may be affected, what input and output it uses, whether a person can meaningfully override it, and which market receives the outcome.
The AI Act also contains specific transparency obligations in Article 50. These include informing people when they interact directly with AI unless that is obvious in the relevant context, machine-readable marking of specified synthetic outputs by providers, and disclosure duties for certain uses by deployers. Article 111(4) gives providers of synthetic-content-generating systems already on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2). Other requirements and exceptions need separate consideration. A generic “AI-powered” badge is not a reliable compliance strategy.
Interface design carries legal and operational weight. A notice that appears after a user has acted, or a label that cannot be understood on a small screen, does not give people useful information. Product teams should decide where disclosure belongs in a journey, how a person can seek clarification or assistance, and how a human decision-maker is prevented from treating an uncertain output as an unquestionable recommendation.
Evidence must survive the release cycle
For high-risk AI systems, the Act sets requirements covering risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness and cybersecurity. The amended Article 113 timetable distinguishes Annex III systems from Article 6(1) product-related systems rather than giving all high-risk AI one deadline. Product-sector scope limitations and Article 111’s transitions for systems already on the market also matter. A firm should not misstate a forthcoming requirement as a present duty for every AI feature, or assume that postponement removes obligations already applicable to its role.
Nevertheless, the underlying discipline cannot be bolted on the week before a customer or regulator asks for it. AI systems change through model upgrades, prompt revisions, new data sources, altered thresholds and new tools. If a team cannot identify which version produced an output, which information it accessed, or what test supported its release, it cannot reliably investigate a complaint or compare performance before and after a change.
A proportionate evidence trail does not require a large compliance platform. For many teams, it begins with version-controlled system descriptions, a decision on approved models and uses, release notes, representative evaluations, access logs, clear owners and an incident process. The detail should rise with the consequence of the use case. A marketing-writing aid and a system shaping access to employment should not receive the same level of assurance.
Evaluation belongs beside delivery. The relevant test set reflects the work the product actually performs: representative inputs, vulnerable cases, local languages where used, retrieval failures, unsupported requests, security attacks and human-review scenarios. Success measures should include task accuracy, factual grounding, schema compliance, latency, cost, rate of escalation and the burden placed on reviewers. A polished demonstration is not evidence that a system is ready to influence a consequential decision.
The strongest response is a lightweight baseline the company can maintain: name each feature owner, separate supplier from application evidence, define the intended use and test material changes before release.
Start with the product that crosses the boundary
The first step is not a company-wide policy written in isolation. Select the AI-enabled product or feature already used by, offered to, or planned for an EU customer. Trace its lifecycle from model choice to user outcome. Identify the organisation’s role, the system’s intended purpose, the affected users, the data and tools it can access, the human decision that remains, and the evidence already available.
Discover the real system. Include the interface, retrieval layer, integrations and support process, not only the model endpoint. This prevents a narrow technical inventory from overlooking the feature that actually changes a user’s outcome.
Design the accountable boundary. Document supplier responsibilities and the firm’s own responsibilities. Set permissions, retention, disclosure, escalation and incident paths that fit the use case. Where a decision is consequential, make human intervention possible in practice rather than merely naming a reviewer.
Build the release evidence. Test representative work, record material limits and review changes that could alter behaviour. Measure how the system performs after launch, especially where users depend on languages, devices or connectivity conditions different from those used in development.
Xelius supports software firms and institutions through AI readiness, workflow design, evaluation, data governance and platform engineering. For an export-facing product, a practical engagement can begin by mapping the EU-facing feature whose current documentation does not yet match the system users actually experience.
The AI Act does not make every AI feature high-risk, and it does not make legal compliance a substitute for good product practice. It does make one lesson unavoidable: a firm cannot govern an AI system if it has drawn the system boundary too narrowly.
