AI Governance for Builders: Making Sense of the EU AI Act, NIST AI RMF and Responsible AI in Practice

For years, conversations about AI ethics lived mostly in policy circles. Engineers would hear about fairness and transparency at conferences, nod along, and go back to tuning hyperparameters. That separation no longer holds. As of 2025, the European Union has adopted the EU AI Act, the United States National Institute of Standards and Technology maintains the AI Risk Management Framework (AI RMF), and international bodies such as the OECD and UNESCO have published principles that many national strategies borrow from.

What changed is not only the volume of rules but their target. These frameworks increasingly ask for evidence: documented data sources, test results, human oversight procedures, incident logs. Evidence is produced by systems and processes, which means it is produced by engineers. If your pipeline cannot tell you which dataset version trained the model currently in production, no policy document will rescue you during an audit.

I have worked across health tech, climate tech and geospatial systems, and the pattern is consistent: the teams that handle governance well treat it like security or reliability. It is not a gate at the end; it is a set of properties you design in from the start.

The EU AI Act takes a risk-based approach. Rather than regulating "AI" as a single category, it sorts uses into tiers and attaches obligations proportionate to the potential for harm.

• Prohibited practices: a short list of uses considered unacceptable, such as certain forms of manipulative systems and social scoring by public authorities.
• High-risk systems: uses listed in the Act's annexes, including areas like employment, education, access to essential services and critical infrastructure, as well as AI that is a safety component of regulated products. These carry the heaviest obligations: risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, and accuracy and robustness requirements.
• Transparency obligations: systems that interact with people or generate synthetic content must, in many cases, disclose that they are AI or label their outputs.
• General-purpose AI models: providers of foundation models face their own documentation and copyright-related duties, with additional obligations for models deemed to carry systemic risk.

The obligations phase in over several years rather than all at once, so teams should check the official timeline on the EU AI Act resource site rather than relying on blog summaries, including this one. The key point for builders outside Europe is extraterritorial reach: if your system is placed on the EU market or its outputs are used in the EU, the Act can apply to you. A Lagos startup selling an HR screening tool to a company in Berlin is very much in scope.

Where the EU AI Act is law, the NIST AI RMF is a voluntary framework. Its value is that it gives teams a shared vocabulary and structure. It organises activities into four functions:

1. Govern: establish policies, roles, accountability and a culture that takes risk seriously.
2. Map: understand the context, intended use, stakeholders and potential impacts of a system.
3. Measure: assess, analyse and track identified risks with quantitative and qualitative methods.
4. Manage: prioritise risks and act on them, including deciding not to deploy.

NIST also describes characteristics of trustworthy AI, such as being valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. I find this list useful as a checklist during design reviews: for each characteristic, ask what could go wrong and how you would know.

For organisations that want a certifiable management system, ISO/IEC 42001 defines requirements for an AI management system, in the same spirit as ISO 27001 for information security. NIST, ISO and the EU Act are not competitors; mature teams map controls across all three so that one piece of evidence satisfies several requirements.

The gap between "be transparent" and a Jira ticket is where most governance efforts stall. The fix is to translate each principle into a concrete artefact that your tooling produces automatically.

• Model and data cards: a short, versioned document per model describing intended use, out-of-scope uses, training data provenance, evaluation results and known limitations. Generate the skeleton from your training pipeline so it cannot drift from reality.
• Dataset lineage: store dataset hashes and versions alongside model artefacts. Tools like DVC or a disciplined object-storage layout make this cheap.
• Evaluation reports: run fairness, robustness and performance tests in CI, sliced by relevant subgroups, and keep the reports with each release.
• Decision logs: for consequential decisions, log inputs, model version, output and any human override, with retention rules that respect data protection law.
• Human oversight design: document who can override the system, what information they see and how quickly they can intervene.
• Incident process: define what counts as an AI incident and route it through the same on-call channels as outages.

If an auditor asked you tomorrow why your model made a specific decision last month, could you reconstruct it? That single question exposes most governance gaps.

In health tech, I have seen how much easier conversations with clinicians and regulators become when you can show a clear record of what a model was trained on and how it was tested. The documentation is not bureaucracy; it is a trust-building tool.

Governance has costs, and pretending otherwise does not help anyone. Small teams can be overwhelmed by compliance work designed with large enterprises in mind. There is also a real risk that rules written in Brussels or Washington become de facto global standards without reflecting African realities: informal economies, multilingual users, patchy connectivity and limited local datasets.

At the same time, the African policy landscape is maturing. The African Union has endorsed a continental AI strategy, and in Nigeria the Nigeria Data Protection Commission oversees the Nigeria Data Protection Act, which already governs much of the personal data that AI systems consume. Data protection law is often the first place AI governance bites in practice, long before AI-specific statutes arrive.

Some honest limitations of current frameworks:

• Fairness metrics can conflict with one another, and choosing between them is a value judgement, not a technical one.
• Documentation can become theatre if nobody reads it or acts on it.
• Risk tiers based on use cases struggle with general-purpose models that can be adapted to almost anything.
• Many frameworks assume access to demographic data for bias testing, which may be unavailable or legally sensitive to collect.

When I mentor developers through BuildWithMMO, I encourage a proportionate approach. You do not need a chief AI ethics officer to start doing this well.

1. Inventory your AI: list every model, API and automated decision in your product, including third-party LLM calls. You cannot govern what you have not mapped.
2. Classify by impact: use the EU AI Act tiers as a rough lens even if you are not in scope. Anything touching health, money, jobs, education or legal status deserves extra care.
3. Assign an owner: every system needs a named person accountable for its behaviour in production.
4. Automate evidence: make model cards, evaluation reports and lineage outputs of your CI pipeline rather than manual documents.
5. Review before launch: a one-hour structured review using the NIST functions catches a surprising number of problems.
6. Monitor and revisit: drift, new user groups and new regulations all change the risk picture. Schedule reviews rather than waiting for incidents.

Treat governance as a product capability. Enterprise and government buyers increasingly ask for this evidence in procurement, so teams that can produce it quickly have a commercial advantage, not just a compliance one.

• AI governance has shifted from principles to evidence, and evidence is produced by engineering systems.
• The EU AI Act is risk-based and can apply to teams outside Europe whose systems reach the EU market.
• The NIST AI RMF's Govern, Map, Measure and Manage functions offer a practical structure for any team, regulated or not.
• Translate principles into automated artefacts: model cards, dataset lineage, evaluation reports and decision logs.
• In Nigeria and across Africa, data protection law is often where AI governance applies first; build for it now.
• Start proportionate: inventory, classify, assign owners, automate evidence and review regularly.

1. The EU Artificial Intelligence Act — Future of Life Institute (EU AI Act resource site)
2. AI Risk Management Framework — National Institute of Standards and Technology
3. OECD AI Principles — OECD.AI Policy Observatory
4. Recommendation on the Ethics of Artificial Intelligence — UNESCO
5. ISO/IEC 42001: Artificial intelligence management system — International Organization for Standardization
6. Nigeria Data Protection Commission — NDPC

Cover image: original illustration created for this article. Cited works remain the property of their respective authors and publishers.