Methodology · v1.1
The OPERA Methodology
How Ramya Amballa turns AI and technology governance requirements into operational decisions, at every AI for U&I engagement.
Most organisations do not struggle with AI frameworks. They struggle with operationalising them. OPERA provides a structured pathway from business use case through ownership, risk assessment, governance decisions and ongoing assurance.
OPERA is not a framework for sale or a certification standard. It is the working method Ramya Amballa built from advising on AI, digital, cyber and technology risk governance, and the structure behind every engagement she runs.
Five Stages
Opportunity, People, Evaluation, Response, Assurance
Each stage answers a specific governance decision, produces named artefacts, and delivers one business outcome.
Opportunity
Core Question
Why are we using AI, and what outcome are we seeking?
Governance Decision
- What business problem are we solving?
- What AI capability is proposed?
- Who owns the business outcome?
- What regulatory context applies?
Activities
- Use case intake
- Business objectives
- Stakeholder identification
Produces
Use case record, Governance track, Business owner
Approved use case
People
Core Question
Who owns the system and the governance decisions?
Governance Decision
- Who is accountable for this AI system?
- Who approves governance decisions?
Activities
- Ownership assignment
- Accountability model
- Governance roles
Produces
Ownership matrix, RACI, Escalation framework
Named ownership
Evaluation
Core Question
What are the risks, and what level of exposure is the organisation prepared to consider?
Governance Decision
- What is the risk exposure?
- What is the business impact of getting this wrong?
Activities
- Risk assessment
- Control analysis
- Regulatory mapping
Produces
Risk assessment, Impact assessment, Regulatory mapping
Risk visibility
Response
Core Question
What controls and actions are required, and who is authorised to accept the residual risk?
Governance Decision
- What controls are required?
- What decisions must be approved, and by whom?
Activities
- Decision process
- Documentation
- Evidence generation
Produces
Decision log, Approvals, Evidence register
Controlled deployment
Assurance
Core Question
How do we demonstrate that the controls are working?
Governance Decision
- How do we know it is working?
- What does leadership need to see?
Activities
- Monitoring
- Metrics
- Governance review
Produces
KRI dashboard, Audit pack, Board briefings
Audit-ready assurance
v1.1 Clarifications
What v1.1 Changes
v1.1 clarifies responsibilities within the existing five stages. It adds no stages, renames no stages and does not change the purpose of any stage. It settles three points: where risk acceptance sits, where incident management sits and where regulatory mapping sits.
Risk exposure and risk acceptance
Evaluation and Response handle two different things. Evaluation determines the level of exposure the organisation is prepared to consider and proposes a treatment. It does not accept risk. Response is where the authorised executive makes the formal residual-risk acceptance decision, and where that decision is recorded. In practice: the appetite position and the proposed treatment come out of Evaluation. The signed acceptance, its scope and its expiry come out of Response.
Incident management
Incident management spans two stages. The incident playbook, escalation arrangements and kill switch are designed under Response, because they are required actions. They are tested under Assurance, and the evidence of their effectiveness is retained there. A kill switch that exists but has never been drilled is a Response output without an Assurance output.
Regulatory mapping
Evaluation is where applicable regulatory obligations are determined and compliance exposure is assessed. Opportunity and People still identify the business context and the accountable stakeholders, which often point to the regulatory regime in play. The obligations themselves are settled in Evaluation.
Retired Terminology
An earlier version of OPERA used the stage names Ownership, Planning, Evaluation, Review, Assurance. That terminology is retired and is not an alternative definition of OPERA. Historical posts that use it remain as dated historical versions. Current methodology pages, diagrams and case studies use Opportunity, People, Evaluation, Response, Assurance only.
Operational Workflow
From AI Governance Requirements to Operational Decisions
How a single AI use case actually moves through OPERA, from submission to evidence and assurance.
- 01
AI Use Case Submission
Business need identified
- 02
Business & Stakeholder Intake
Objectives, stakeholders, context
- 03
Ownership Assignment
RACI, accountability, governance roles
- 04
Risk & Control Assessment
Impact, risk classification, regulatory mapping
- 05
Governance Review Decision
Approval, conditions, exceptions
- 06
Evidence & Assurance
Evidence register, monitoring, reporting
What the Workflow Produces
- Approved use case
- Named ownership
- Risk visibility
- Governance decision record
- Audit-ready evidence
Designed for regulated and high-assurance environments, including energy, critical infrastructure, financial services, enterprise SaaS and government.
OPERA is developed and run by Ramya Amballa. Engaging AI for U&I means engaging the person who built it, not a team applying it on her behalf.
Apply OPERA to a real governance decision
See how the methodology maps to a specific engagement area, or start a conversation about your own use case.