Building and Backing AI Startups Responsibly Across Africa

Our nine-week AI Foundry programme at Ventures Platform brought many lessons and insights, both for the founders who attended and for us. AI is significantly changing how companies are built. Founders have to think about what to automate and what to hold off on, what to verify, and what should happen when an AI system gets it wrong. But beyond changing how these companies are built, AI is also changing how they should be reviewed and backed.

In 2025, AI companies captured close to half of global venture funding. Crunchbase puts the figure at $202.3 billion, up 85% from $114 billion in 2024. A lot of that money went to a relatively small number of model companies through very large funding rounds. But the direction is clear: AI has become a major part of where venture capital is going.

There is nothing inherently wrong with capital moving into AI; some of the most important companies of this period will be built around it. The problem is that investment and adoption are moving faster than the work needed to use AI well.

Founders are under pressure to move quickly, show that they are keeping up, and avoid being left behind. Investors face a similar pressure, as nobody wants to miss the next company that defines the market. The result can be a poor trade-off, where a startup "adds AI" before they have really worked out why they need it, and an investor excitedly accepts and applauds the AI label without looking critically at what is actually being built underneath it.

At Ventures Platform, our responsibility is to find and support companies capable of producing both meaningful impact and strong economic returns. That requires enthusiasm for what AI makes possible, but it also requires us to be more careful about how we assess a company's technical choices, operating risks, and ability to earn trust.

We do not have all the answers; the field is moving too quickly for anyone to honestly claim that they do. However, we do believe the standard has changed: safety, security, and governance now need to be part of the ordinary work of building and backing technology companies, not things that only become necessary after a breach, a harmful decision, or a regulator's letter. 

However, the first step is to recognise that AI exposure extends well beyond companies that describe themselves as AI businesses.

(Nearly) Every startup now has an AI exposure

That exposure usually appears in three forms.

An AI-native company builds models, infrastructure, or products where AI is central to what the company does. Take the AI away, and you no longer have the same product. For these companies, diligence needs to go the deepest: What data are they training on? How are they evaluating the model? Where and how is it being deployed? How does the model behave in the real world? And does the underlying business make economic sense?

An AI-enabled company uses AI as part of a larger product or workflow. A lender might use a model to support underwriting. A health platform might use it to help triage cases. A logistics company might use it to predict routes or automate customer support. Here, the bigger question is how much control the AI has and what happens when it gets something wrong.

An internally exposed company may not sell an AI product at all. Its employees might still be using third-party AI tools for coding, research, customer support, recruitment, or document analysis. Customers may never interact with an AI system, but company data can still end up in tools that leadership has not approved or, in some cases, even knows are being used.

A startup can also fall into all three categories at once. A payments company, for example, might use a machine-learning model for fraud detection, add a generative AI support agent, and have employees pasting internal documents into public AI tools. So the starting point for diligence is simple: understand where AI is actually being used and what the exposure looks like.

The African context changes the questions

Mapping the exposure is a good start, but the conditions in which a system operates determine how serious that exposure becomes. Most African startups will not train frontier models, but they will build at the application layer, using models and infrastructure from global providers. In many cases, that is simply the sensible choice. These tools are capable, widely available, and often much cheaper than building the same systems in-house.

Founders need to know what data leaves their environment, where it is processed, whether the provider retains it, and what protections are in place. They also need to think about what happens when a provider updates its model. They should understand how a model update can change product behaviour and how difficult it would be to switch providers. How difficult would it be to move to another provider if the need arises? Investors should be asking these questions too. Cost matters as well, especially when a startup earns revenue in local currency but pays its model and cloud bills in dollars.

Performance also has to be tested in the environment where the product will actually be used. A model that performs well in standard English may behave differently with Pidgin, code-switched French, Yorùbá, or a regional accent. Then there are the less obvious realities of building for African markets: unreliable connectivity, shared devices, and customer support channels that were never designed for long, polished text. These are product conditions that should shape evaluation before launch.

Regulation adds another layer. A startup operating across African markets is rarely dealing with one legal regime. Data protection, automated decision-making, and cross-border processing requirements vary from country to country. 

This was part of the thinking behind Ventures Platform's recent AI Foundry. The nine-week programme supported portfolio and non-portfolio companies working to build production-ready AI products. A lesson was that production readiness does not begin with model selection. It begins with the user problem, the best non-AI alternative, the value at stake, understanding the constraints, the cost of failure, and knowing when to stop. Those choices determine whether an AI limitation remains manageable or becomes a wider company risk.

Where AI risk becomes company risk

Safety is about the harm a system can cause, including when it simply gets something wrong. Security is about deliberate attempts to manipulate a system, steal information, or misuse its access. Governance determines who is accountable, how decisions are documented, and what rules control the system over time.

Safety is about the cost of being wrong

Probabilistic systems will get things wrong sometimes, and no amount of prompt engineering changes that. What matters is where the system is allowed to operate, how its output is checked, how much damage a wrong answer could cause, and when it must defer to humans. 

Founders must own this responsibility intentionally, and investors should examine whether it has been taken seriously and help close gaps that are reasonable for the company's stage.

Security is part of product design now

AI introduces attack surfaces that conventional application security may not cover, creating new ways for systems to be manipulated, from prompt injection and malicious content in retrieved documents to tools that give an AI system more access than it should have. OWASP's Top 10 for LLM Applications covers many of these risks, including sensitive information disclosure, supply-chain weaknesses, improper output handling, and excessive agency. The risk also exists inside companies where employees may use AI tools without formal approval or oversight. Shadow AI refers to employees or teams using AI tools without formal approval or oversight from the company’s security, data-protection or technology functions. IBM's 2025 breach study found that one in five organisations with high levels of this "shadow AI" reported higher average breach costs.

Check Point’s July 2026 threat intelligence recorded an average of 3,237 cyberattacks per week for each African organisation, compared with a global average of 2,336. Africa ranked third among the regions tracked, despite recording a 5% year-on-year decline.

The basic protections are familiar, but they matter even more when AI can act on a company's behalf. Access should be limited, sensitive data should not be sent to third-party models unnecessarily, and inputs, retrieved content, and model outputs should be treated as untrusted until checked. Before an AI agent is given meaningful authority, companies should have the ability to test attacks, log what happens, limit what the system can do, and respond when something goes wrong.

Governance means being able to show your work

A governance policy is only useful if it changes decisions, assigns responsibility, and gives people a clear way to respond when things go wrong.

NIST's Generative AI Profile treats risk management as work that spans the design, development, use, and evaluation of an AI system. That lifecycle view is useful for startups. 

Governance should be proportionate. An early-stage company does not need the bureaucracy of a bank. It does need a named owner, documented intended use, known limitations, a record of material model or threshold changes, and a workable incident path. A company making high-impact automated decisions will need more, including stronger explanations, legal review, and independent testing where the risk justifies it.

Investors should resist compliance theatre. A certification should not replace an understanding of how the product behaves. The better test is whether the company has a working standard that guides day-to-day decisions.

A minimum working standard for founders

Start with the job

Write down the user problem before choosing a model. Estimate the revenue gained, operating cost removed, risk reduced, or time saved. Compare the AI approach with a rules engine, conventional software, or a process change. Use a non-AI option if it solves the problem more reliably and cheaply.

Map every exposure

Keep a current inventory of the models, APIs, plugins, and employee tools that touch company or customer information. Record the owner, purpose, data categories, and permissions for each. This should cover core products and internal work. An unknown AI tool is an unmanaged data route and a risk.

Build the evaluation set early

An evaluation set is a fixed collection of real-world examples used to test whether the system produces acceptable results. Build it with verified answers and difficult cases that reflect the product’s actual users and markets. Run the tests again whenever the model, prompt, data source or workflow changes.

Control data and vendor dependency

Confirm the right to use the data for the intended purpose. Minimise what is sent to external services. Review retention, model-training terms, subprocessors and storage locations. Where practical, build the product so that its underlying model can be changed without rebuilding the entire system. A provider’s price increase, service disruption, or decision to retire a model should not become a company emergency.

Design the uncertain moment

Decide in advance when the system must follow a fixed rule, choose the safest available option, or send a case to a person. When the system is uncertain, tell the user what could not be determined and what they can do next. Preserve the context when a person takes over. Where connectivity matters, the degraded experience should still provide useful information rather than disappear.

Monitor the whole system

Track product quality and business outcomes, not only model accuracy. Measure cost per resolved task (what each successful outcome costs), latency (how long users wait), and escalation rate (how often a person must step in). Watch for drift, or declining performance over time, and signs of misuse. These can reveal problems that benchmarks miss. Set alerts that warn the team when costs rise unexpectedly, or product quality begins to fall. This gives the company time to respond before the problem drains its cash or affects thousands of users.

Prepare for the bad day

Maintain a threat model that identifies how the system could fail or be attacked, alongside an incident runbook that sets out how the team should respond. Keep enough logs to investigate important decisions without retaining unnecessary sensitive data. Record known limitations and how they were tested. Before a higher-risk system is allowed to make more consequential decisions, subject it to adversarial testing or review by an independent party.

What investors should ask before the cheque

For us as investors, AI diligence should sit beside commercial, financial, legal and technical diligence. It should not be a specialist exercise that appears only when a company describes itself as AI-native.

The questions should include:

• What user or business problem requires AI, and what is the strongest non-AI alternative?
• Where does AI sit in the company today, including internal tools that do not appear in the product?
• What data is used, where did it come from, and does the company have the right to use it this way?
• How is performance evaluated on the people, languages, and operating conditions the product will encounter?
• What is the cost of a wrong output, and when does a human or deterministic control take over?
• How has the team tested for manipulation, leakage, excessive permissions, and abuse?
• What does the system cost per useful outcome at current volume, and how does that change as usage grows?
• Who is accountable for the system, and what evidence exists of incidents, user complaints, or material model changes?

The expected evidence should match the company's stage and the consequence of the use case. A pre-seed team may have limited production data. It should still be able to name likely failure modes, explain its architecture, and show how it plans to test. A scaled company making decisions that affect money, health, or access should have operating evidence.

Investors also need to examine defensibility. If the product depends on the same third-party model available to every competitor, the moat may sit in distribution, workflow integration, proprietary data, customer trust, or a cost advantage. Any of these can form a credible moat.

Support should continue after the cheque

Pre-investment diligence only captures the company at one moment. As the company and product evolve after investment, investor support has to continue with them.

Investors can help founders set a realistic plan and prioritise the controls that matter most. A portfolio can be risk-tiered so that a customer-support assistant does not receive the same treatment as an autonomous credit engine. Shared templates, expert office hours and practical programmes can reduce the cost of doing the work well. Collective negotiations with infrastructure providers may improve commercial terms and data protections.

Our AI Foundry was one attempt to provide this kind of support. Subject matter experts taught on product strategy with data readiness, model economics, production architecture, user experience, safety, security and operating governance. We learned alongside the participating teams. The work also reinforced that a founder cannot solve every issue at once. The useful question is what must be true before this system receives more users, more data or more authority.

For higher-risk portfolio companies, relevant AI performance and incidents should enter board conversations. Investors should be ready to fund security work, specialist reviews and product changes that reduce material risk. Pressing a founder to ship faster while refusing to support the controls required for safe scale is not responsible portfolio support.

Trust is part of the business model

Founders and investors rely on each other. A founder cannot build durable systems in an environment that rewards speed alone. An investor cannot diligence a company into safety if the team will not expose how its system works.

The strongest AI companies will not be the ones that use the most advanced model in every workflow. They will be the ones that know when a simpler tool is enough. Their systems will be able to defer, recover, and improve without leaving the user to carry the cost of uncertainty. They will understand the economics well enough to keep the product alive.

None of us can describe the final shape of artificial intelligence with confidence. We can still choose how we build and invest now. At Ventures Platform, we believe safety, security, and governance should develop at the same pace as AI adoption. That standard applies to founders. It also applies to the investors asking them to move quickly.

‍

About Collins Gilbert

Collins Gilbert is an Associate at Ventures Platform, a pan-African venture capital fund that invests early in mission-driven founders who are building capital-efficient platforms that democratise prosperity, plug infrastructural gaps, connect underrepresented communities, solve for non-consumption, and improve livelihoods in Africa.

As a member of the Platform and Networks team, he designs and develops initiatives, processes, tools, guides, and partnerships to support the Ventures Platform portfolio of over 55 active companies excellently, efficiently, and at scale.

Before now, he worked with the non-profit arm of the organisation, where he helped design and execute startup support programs such as incubation and acceleration programs.

Beyond his role at Ventures Platform, Collins advises founders on go-to-market strategy, fundraising, and investor relations.

Collins strongly believes that entrepreneurship is one of the most sustainable paths to creating prosperity on the African continent. Therefore, he spends most of his time sourcing and supporting the best founders and companies.