Most AI projects fail not because of bad code.
They fail because of bad planning.
Teams rush to pick a model, spin up infrastructure, and start training before they’ve answered the most basic governance questions. Then they’re surprised when the system produces biased outputs, violates a regulation they didn’t know applied, or gets flagged in an audit they weren’t prepared for.
Here is a six step framework to use as a checkpoint, not a formality.
Step 1: Define the business context and use case
AI governance starts before the first line of code. It starts with a clear answer to a simple question: what problem are we actually solving?
This sounds obvious. It almost never gets done properly.
Problem formulation means documenting the exact use case, the expected business benefit, and the operational environment where the system will run. Not in vague terms. Specifically.
And here is the question too few teams ask: is AI even the right solution? Could a non-AI or semi-automated approach achieve the same outcome with less risk? That question belongs on the record before anything else happens. If you cannot justify why AI is necessary, you should not be building it.
Step 2: Perform an AI impact assessment
An AI Impact Assessment (AIIA) is where responsible development separates from reckless development.
This step formally weighs the potential benefits of the system against its potential harms across three categories: ethical, technical, and operational. It answers: even if this system works, should we deploy it?
For organizations operating under the EU AI Act, high-risk systems also require a Fundamental Rights Impact Assessment (FRIA)—examining non-discrimination, privacy, and consumer protection. Not every jurisdiction mandates it, but the discipline itself is worth its weight in hindsight.
The output here is a documented risk posture. If you skip it, you are making decisions without knowing what you are deciding.
Step 3: Identify the laws that apply to your model
The legal landscape for AI is not one-size-fits-all. Which laws apply depends on your sector, where you deploy, and what data you process.
At minimum, your legal review should cover:
- Data privacy – How does GDPR apply? Are you processing personal data? Does the system make automated decisions that require human review under Article 22? What data minimization requirements affect your training set?
- Intellectual property – What are the IP implications of your training data sources? Are you potentially reproducing copyrighted material?
- Anti-discrimination and sector laws – Depending on your use case, you may fall under EEOC guidelines, the Fair Credit Reporting Act (FCRA), the Americans with Disabilities Act (ADA), or consumer protection rules. These are not optional considerations. They are legal requirements that AI systems have already been found to violate.
Skipping the legal mapping step is how organizations end up with compliance failures that could have been caught at design time.
Step 4: Apply policies, ethical principles, and operational controls
Abstract ethics do not govern AI systems. Concrete controls do.
This step translates principles like fairness, transparency, and accountability into actual design decisions.
Model selection matters for governance. Choosing between a classic decision tree and a proprietary large language model is not just a technical decision. If transparency is a priority, an interpretable model may be the right choice even if it performs slightly worse on benchmarks. Vendor lock-in and explainability trade-offs are governance concerns, not just engineering ones.
Human-in-the-loop design is not optional for high-stakes systems. Human overseers need to understand what the AI is doing, interpret its outputs, and intervene when something goes wrong. If the system is too opaque or too fast for meaningful human oversight, that is a design failure. Automation bias—humans deferring to AI without critical review—is a documented risk you must design against.
Diverse stakeholder engagement surfaces problems early. Requirements should come from interdisciplinary teams that include domain experts, social scientists, legal, and where possible, representatives from affected communities. Developers alone will miss the socio-technical risks that come back to cause problems in production.
Step 5: Identify and manage internal and external risks
Once you know what you are building and which laws apply, you need a structured way to think about what could go wrong.
Risk scoring using a probability-and-severity matrix is the standard starting point. You calculate risk as the product of how bad the outcome would be multiplied by how likely it is to happen. Most governance frameworks use qualitative scales like Red-Amber-Green matrices for speed, or quantitative models like FAIR when financial exposure needs precise calculation.
Once risks are scored, you need a documented response for each one. The standard hierarchy: mitigate (reduce likelihood or severity), transfer (insurance or contract language), avoid (do not build that feature, or stop the project), or accept the residual risk with sign-off from appropriate stakeholders.
Pre-deployment testing is non-negotiable. This includes benchmarking against human performance, running controlled pilots before full release, and red-teaming—having adversarial teams stress-test the system specifically looking for bias, failure modes, and exploitable vulnerabilities. If your team has never done a red-team exercise on an AI system, put that on the roadmap now.
Step 6: Document the design and build process
Documentation is not bureaucracy. It is the primary mechanism for proving compliance, establishing traceability, and protecting your organization from legal, regulatory, and reputational risk.
Data lineage tracking is foundational. You need to be able to show where every piece of training data came from, how it was transformed, and why it was included. That paper trail is what lets you prove the data was accurate, representative, and unbiased when an auditor or regulator asks. And they will ask.
Two governance artifacts every AI team should produce:
- An AI system inventory – a living record of every AI system the organization operates, its purpose, risk classification, and ownership.
- A model card – a standardized document that travels with the model, summarizing its performance metrics, known limitations, intended use cases, and conditions under which it should not be used. Model cards are increasingly expected by regulators, enterprise procurement teams, and audit functions. If you are not producing them, start now.
The bottom line is that these six steps are the practical scaffolding that responsible AI deployment requires.
Top comments (0)