Intake
The AI system is clarified through conversation with the Risk Agent, or built automatically from your project documentation.
Catalogued risks. Every discovered risk resolves to a subdomain of this tree.
AI risk management platform · ISO/IEC 42001
Manage your AI risks with confidence
Observability · Verification · Explainability · Risk assurance
Turn AI from a possible unmanaged liability into a managed, auditable asset.
Grounded in
- EU AI Act
- ISO/IEC 42001
- NIST AI RMF
- MIT AI Risk Repository
- CSET
- GDPR
In most enterprises, AI is becoming an unmanaged liability
AI adoption is racing ahead of risk and governance. These are the six places teams get stuck, and every one of them is a question an auditor will ask.
No visibility
Which AI systems carry which risks is unknown across the organization.
No audit evidence
The documents auditors want are built by hand, scattered, and re-done each time.
Multiple frameworks
Mapping many frameworks at once: CSET AI Harm Analysis, ISO 42001, NIST AI RMF and the MIT AI Risk Database.
Fragmented ownership
Risks fall between departments, and actions are not tracked to completion.
Unclear priorities
With limited resources, which risk to tackle first is not obvious.
Vendor lock-in
Assessments are tied to a single AI vendor and are not portable.
AI risks are no longer theoretical
Common AI harms are grounded in documented, real-world incidents. OverAI draws this knowledge from authoritative public sources rather than from opinion.
1,600+
MIT AI Risk Repository
CSET
Harm taxonomy
Tangible and intangible consequences are classified separately and scored separately.
800+
NIST-based controls
The NIST-mapped mitigation catalogue every recommendation is selected from, each with its action identifier.
Real cases
AI Incident Database
Risks are matched against documented incidents rather than estimated by a model.
The most common AI risk types
Bias and discrimination
Unfair outcomes for sub-groups.
Hallucination and wrong output
Untrue, unreliable decisions.
Privacy breach
Improper handling of personal data.
Unexplainable decisions
Automated decisions no one can audit.
From discovery to defensible proof
One guided workflow turns any AI project into identified risks, prioritized fixes and audit-ready evidence, summarized in a single Mitigation Progress Score.
What the platform does
Risk identification
The project description is matched against the MIT AI Risk Repository.
Risk classification
Every risk lands in a domain and a subdomain, with a severity band.
Harm identification
Each risk is mapped to the real-world harm it could cause.
Impact assessment
Harm is scored so the list can be ordered by what actually matters.
Mitigation planning
Controls are selected for each risk and harm pair, then prioritized.
Mitigation execution
Controls become owned tasks, and completion is what moves the score.
The risk methodology is adaptable to tailor-made enterprise frameworks and to the ISO 31000 standard set.
Layer 1 · the risk
MIT AI Risk Repository, identifying the risk
The foundation layer. The MIT AI Risk Repository identifies and classifies the underlying AI risk, and it is continuously updated.
Risk identification
The underlying risk is identified across 7 domains, 24 subdomains and 1,600+ catalogued risks. Risks come in scored.
Causal taxonomy
Each risk is classified by its cause: the entity, intent and timing behind it, following the MIT repository structure.
Domain taxonomy
Risks are organised across 7 domains and 24 subdomains, giving every project a consistent classification.
Continuously updated
MIT refreshes the repository continuously, so we extend our own systematic layer and feed the risk agent as it evolves.
ISO standards mapped to our identification logic
Three ISO/IEC standards shape the pipeline, each with a defined scope and a clear place in it. ISO/IEC 42001 is the framework the platform runs against today. ISO/IEC 23894 and 42005 are on the roadmap.
-
ISO/IEC 23894
Guidance on AI-specific risk management: identifying, analysing and evaluating risks across the AI lifecycle.
Risk identificationAligns with the MIT risk taxonomy layer.
-
ISO/IEC 42005
AI system impact assessment: how AI systems affect individuals, groups and society, and how to document it.
Harm identificationAligns with the CSET harm-mapping layer.
-
ISO/IEC 42001
AI management system (AIMS): governance, controls and continual improvement for responsible AI.
Mitigation and controlAligns with the NIST AI RMF control layer.
Causal taxonomy, how, when and why a risk occurs
The MIT causal taxonomy classifies each AI risk along three factors. Used together, they describe the circumstances in which a risk arises.
Entity
Whose decision or action caused it?
- AI
- A decision or action made by an AI system.
- Human
- A decision or action made by humans.
- Other
- Some other reason, or ambiguous.
Intent
Was the outcome expected?
- Intentional
- An expected outcome from pursuing a goal.
- Unintentional
- An unexpected outcome from pursuing a goal.
- Other
- Intentionality not clearly specified.
Timing
When did it occur?
- Pre-deployment
- Before the AI is deployed.
- Post-deployment
- After the model is trained and deployed.
- Other
- No clearly specified time of occurrence.
Domain taxonomy, 7 domains and 24 subdomains
The MIT domain taxonomy classifies AI risks into seven domains and 24 subdomains, giving every project a consistent, shared classification.
13 subdomains
Discrimination and toxicity
Unfair treatment, harmful content and unequal performance across groups.
22 subdomains
Privacy and security
Leaked or inferred sensitive data and exploitable system vulnerabilities.
32 subdomains
Misinformation
False information and erosion of a shared, consensus reality.
43 subdomains
Malicious actors and misuse
Disinformation, fraud, cyberattacks and weapon development at scale.
52 subdomains
Human-computer interaction
Overreliance, unsafe use and loss of human agency and autonomy.
66 subdomains
Socioeconomic and environmental
Power concentration, inequality, devaluation of effort and environmental harm.
76 subdomains
AI system safety and limitations
Misaligned goals, dangerous capabilities, lack of robustness or transparency.
Layer 2 · the harm
CSET, mapping the harm
The harm layer. CSET, the Center for Security and Emerging Technology at Georgetown University, and its AI Harm Framework map each identified risk to its potential real-world harm, linking AI behaviour to tangible and intangible impact.
Harm identification
Each identified risk is mapped to its potential harm, so the impact is made explicit rather than assumed.
Consequence mapping
A harm taxonomy links AI behaviour to concrete real-world consequences for people and organisations.
Tangible and intangible
Captures both measurable and non-measurable impact, so the picture is complete rather than only what is countable.
Grounded and defensible
Grounded in CSET's public harm framework, so every harm mapping stays defensible and auditable.
Layer 3 · the control
NIST AI RMF, structuring the control
The control layer. The NIST AI Risk Management Framework turns each identified risk into practical, testable controls, fed by the MIT mitigation database.
Govern, map, measure, manage
Each risk becomes practical, testable controls, organised by the functions of the NIST AI RMF.
MIT mitigation database
Controls are fed by the MIT mitigation database, which MIT keeps up to date and which we extend ourselves.
Mitigation from zero
Mitigation starts at 0 for every risk and rises only as real controls are actually completed.
Audit-ready evidence
Every control is backed by audit-ready evidence at every step of the pipeline.
How mitigations are distributed
Across the mitigation library, 831 controls fall into five types. The mix is weighted toward procedural and governance controls, not just technical fixes.
- Procedural and operational process controls 297 35.74%
- Administrative and governance controls 250 30.08%
- Policy, documentation and transparency controls 171 20.58%
- Technical and security controls 102 12.27%
- Complementary and supporting controls 11 1.32%
- Total 831 100%
Evidence
AI Incident Database, grounded in real incidents
AI risks are not theoretical. The AI Incident Database documents real-world AI incidents, and MIT places them into the risk taxonomies.
3,000+ real cases
The public database documents more than three thousand real-world AI incidents, evidence that these risks actually occur.
Taxonomy-aligned
MIT places each incident into the risk taxonomies, so cases line up with the domains we identify.
Evidence link
Matched incidents turn an abstract risk into evidence, and they are what the project context variables are derived from.
Public source
Drawn from the open AI Incident Database at incidentdatabase.ai, a public and continuously growing source.
Roadmap Each risk will be linked to concrete examples of real incidents from the AI Incident Database, in line with the roadmap.
From discovery to proof, in seven guided steps
You describe the project. The platform advances each step, grounded in authoritative sources, and the whole chain stays on record and traceable back to its origin.
Identify risks
The project description is matched to subdomains of the MIT AI risk taxonomy. Every risk arrives with a code and a severity band.
Map harms
For each risk the possible consequences are bound to CSET categories, with the causal pathway and reversibility written out.
Generate controls
Controls matching the risk and harm pair are selected from the rule tables, each carrying the identifier of the NIST action it comes from.
Incident intelligence
Context is derived from documented real-world cases rather than estimated, so two analysts scoring the same system land in the same place.
Assign owners
Accepted controls become tasks with an owner and a status. A rejected control stays on record with its reason.
Mitigation Progress Score
The project reduces to a single number. As tasks complete the score is recalculated and every snapshot is kept.
The result: a single Mitigation Progress Score. It rises only as real mitigations are completed, which is what honest by design means here.
Severity, harm type and control matching are bound to rule tables. The language model relates your project to those tables, it does not decide the score on its own. The methodology is adaptable to bespoke enterprise frameworks and to ISO 31000.
Organization-wide risk posture at a glance
One project is a start. The portfolio view is what the board actually asks about, and it is built from the same numbers rather than assembled for the meeting.
- Live risk summary. Active risks broken down by critical, high and medium, updated as reviews progress.
- Mitigation Progress Score. Trace how mitigations are progressing and how they move the overall picture, across the whole portfolio.
- Pending actions. Assigned tasks and upcoming deadlines, with the overdue ones surfaced first.
Describe the project, then sign off
There is no form to learn. The agent asks what it needs, and every answer it collects stays attached to the record it produced.
- Risk Agent chat. The AI system is clarified through conversation, or built automatically from an uploaded project document.
- Automatic risk discovery. Risks are tagged against the MIT taxonomy, each with its subdomain code.
- Evidence linked to source. Each answer is tied to the risk record it informed, so the chain is readable backwards.
- Mitigation assistance. Control planning is generated from the priorities that came out of the analysis.
- Queue to planner. Selected controls flow into the implementation planner with an owner and a due date.
Why OverAI is different
Most tools either govern AI generically or perform AI tasks. OverAI grounds every result in authoritative, public standards, which is what makes the output defensible.
Grounded in public standards
MIT AI Risk Repository, CSET harm taxonomy, NIST AI RMF and the MIT mitigation database.
Real incident intelligence
Every risk is matched to documented cases in the AI Incident Database.
Unique mapping algorithm
The core intellectual property is legal expertise expressed as a mapping algorithm.
SaaS and on-premise
A low-cost, flexible subscription rather than an expensive, rigid deployment.
One platform
A unified agentic platform covering risk discovery, harm identification, mitigation planning, task management and audit-ready reporting.
Capability
- Framework-grounded taxonomy
- Harm and consequence mapping
- NIST-based mitigations
- Real incident evidence
- Single platform
- Cost and flexibility
Where the stakes are highest
OverAI applies across regulated industries: telecom, banking, healthcare, media and beyond.
Telecom
Churn and credit or fraud scoring, generative customer assistants and network optimization, governed for fairness, privacy and explainability.
Banking and finance
AI credit scoring and limit decisions, with bias testing and a human appeal path built in.
Healthcare
Diagnostic AI monitored for accuracy, sub-group fairness and human oversight.
Media
Generative content with fact-checking, plagiarism and reputational controls.
Sample use cases and industries where OverAI can perform. The list is illustrative, not exhaustive.
Let's turn AI risks into a traceable and managed business process
Bring one AI system and we will take it end to end, from the first conversation to a Mitigation Progress Score, with your own data and your own sector context.