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.
Compliance is complex
Mapping many frameworks at once, from the EU AI Act to ISO 42001 and GDPR, is hard.
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.
The AI risk landscape is being regulated
Auditors and regulators now demand evidence for AI and its risks. Recent milestones make compliance non-optional, especially in the EU.
-
Feb 2025
EU AI Act: prohibited practices and AI literacy in force
-
Aug 2025
Obligations for general-purpose AI (GPAI) models
-
Aug 2026
Transparency duties for generative AI, plus market surveillance
-
2026 to 2028
Phased compliance timeline for high-risk AI systems
EU AI Act
The world's first extensive law related to AI. The Digital Omnibus package proposes amendments to it.
Upcoming national regulations
With the Turkish AI Action Plan, legal and administrative structures gain momentum.
GDPR
Right to explanation for automated decisions.
A risk-based rulebook for AI
The EU AI Act classifies every AI system into one of four tiers. Obligations scale with the risk the system poses.
-
Unacceptable
Prohibited
Social scoring, workplace emotion recognition, untargeted face scraping
-
High risk
Strict obligations
Credit scoring, CV screening, biometric ID, essential services
-
Limited risk
Transparency required
Chatbots, deepfakes and AI-generated content must be disclosed
-
Minimal risk
Largely unregulated
Spam filters, recommendation engines, workflow automation
Enforcement Up to €35M or 7% of global turnover for prohibited uses · €15M or 3% for high-risk and transparency breaches · €7.5M or 1% for false information
What high-risk AI requires, and how OverAI delivers it
Providers of high-risk AI must meet six core obligations under Articles 8 to 17 and 72. OverAI turns each one into a repeatable workflow.
-
Risk management
Art. 9
Continuous risk identification and mitigation grounded in the MIT AI risk taxonomy.
-
Data governance
Art. 10
Surfaces data-quality and bias risks for each system during guided discovery.
-
Technical documentation
Annex IV
Auto-generated, exportable conformity records and audit-ready evidence.
-
Human oversight
Art. 14
Human review and owner sign-off at every step: risks, harms and mitigations.
-
Accuracy and robustness
Art. 15
NIST-based controls including robustness testing, prioritized by impact.
-
Post-market monitoring
Art. 72
Ongoing Health Score, immutable audit trail and real incident intelligence.
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
800+
NIST-based controls
The NIST-mapped mitigation catalogue every recommendation is selected from, each with its action identifier.
CSET
Harm taxonomy
Tangible and intangible consequences are classified separately and scored separately.
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 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.
Health Score
The project reduces to a single number. As tasks complete the score is recalculated and every snapshot is kept.
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.
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.
A score that is honest by design
The Health Score is not a vanity number. It moves only as real controls are completed, which is what makes it worth showing to a board or an auditor.
Health Score = 100 − Σ(w × Risk score × (1 − Coverage)) / Σw
- One formula, no hidden coefficients. The weight comes from the severity band, and coverage is the share of harm score closed by completed controls.
- Work in progress is not credit. An in-progress control shows as potential gain. The points land only when the task is actually done.
- Every calculation is stored. When the score moved and which change moved it can be read from the history.
- Rejected controls are not deleted. They stay on record with their reason and timestamp, and can be restored within five minutes.
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.
- Organization Health Score. A single, unified score across the whole AI portfolio, calculated the same way for every project.
- Live risk summary. Active risks broken down by critical, high and medium, updated as reviews progress.
- Compliance rate. The share of identified risks that already carry an active control, tracked against your selected framework.
- Pending actions. Assigned tasks and upcoming deadlines, with the overdue ones surfaced first.
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.
Law as code
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
Built for the regulations that matter
OverAI maps your AI systems to the obligations that apply and generates the evidence auditors ask for.
EU AI Act
Continuous risk management, human oversight, transparency and technical documentation for high-risk AI.
GDPR
Lawful processing, purpose limitation and the right to explanation for automated decisions.
ISO/IEC 42001
An AI management system with defined roles, traceability and continual improvement.
NIST AI RMF
Controls are drawn from a catalogue mapped to the NIST AI RMF, so every recommendation traces back to a published action.
Sector rules
Model risk management, explainable credit decisions and stress-test evidence, alongside standards such as BCBS 239 in banking.
National data laws
Extensible to national data-protection regimes, including Turkey's KVKK. Consent, access and objection rights are modelled as requirements like any other.
How we help you comply
- Continuous risk management
- Explainability evidence
- Immutable audit trail
- Human oversight
- Auto-generated reports
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.
Enterprise requirements
Multi-tenancy, authorization and the audit trail are not features added later. They are defined in the data layer itself.
Multi-tenant isolation
Every record is separated by tenant. Filtering is enforced at the data access layer, not left to business logic.
Role-based authorization
Eight roles and more than fifty permissions, with per-user grants and revocations supported.
Immutable audit trail
Every insert, update and delete is recorded automatically with a before and after diff.
Your own infrastructure
Installed with Docker. The database, object store and vector store stay in the environment you choose.
English and Turkish
Interface, notifications and API messages in both languages, selected per user rather than per deployment.
Personal data in scope
Intake captures the personal data categories a system touches, and that answer stays attached to the risk records it produced.
Frequently asked questions
For questions that need more technical detail, ask during the demo and we will walk through the chain on your own project.
How does OverAI find risks?
Your project description is matched semantically against the subdomains of the MIT AI Risk Repository. Each matching subdomain becomes a risk. The harm type and the control that answers it come from rule tables, so the language model only performs the association.
How is the severity score calculated?
The risk score is the product of an imminency coefficient, a harm-type coefficient and the project context coefficient. Context is the normalized average of the project's four context variables, which are derived from documented incidents rather than estimated. The result falls into five fixed bands: 76 and above is critical, 51 high, 26 medium, 11 low, and below that negligible.
What happens if the AI produces an irrelevant risk?
No risk proceeds without human approval. Records that do not match the taxonomy are marked as awaiting classification and no severity band is shown for them. A rejected risk keeps its number, which is never reused, so the numbering in an older report stays valid.
Which compliance frameworks are supported?
Harm classification follows CSET and control labels follow the NIST AI RMF functions. EU AI Act, ISO/IEC 42001 and GDPR requirements are met on the documentation and audit-trail side. Further frameworks are defined in the data model and are being enabled in turn.
What does deployment require?
It runs on Docker Compose. The relational database, cache, message queue, object store and vector database are all included. For the language model you can use your own API key or connect a local model.
Where does our data go?
The application and the data layer run in the environment you choose. The only traffic that leaves it is the calls to the language model provider you configure. With a local model even that connection disappears.
Can the methodology follow our own risk framework?
Yes. The scoring chain is table-driven, so it can be adapted to a bespoke enterprise framework or aligned with ISO 31000 without changing how the evidence is produced.
Let's turn AI into a managed, auditable asset
Bring one AI system and we will take it end to end, from the first conversation to a Health Score, with your own data and your own sector context.