Overview
This framework defines how OpsRabbit turns responsible-AI principles into repeatable decisions, approvals and evidence. It applies a proportionate lifecycle to material OpsRabbit AI systems, features, customer configurations and internal AI tools.
The framework is approved as version 1.0, effective 24 June 2026, and is reviewed at least annually and after material legal, product, architecture or risk change. Customer-specific agreements and deployment records establish any more specific responsibilities or requirements.
No material AI use case proceeds solely because it is technically possible. It must have an approved purpose, accountable owner, documented risk assessment, acceptance criteria, appropriate human and technical safeguards, explicit release approval, monitoring and a path for suspension or retirement.
Governance outcomes
- Each material AI use case has a named owner and an approved purpose.
- Risk is assessed before release and after material change.
- Privacy roles and processing responsibilities are documented for each deployment.
- Models, providers, data flows, tools and permissions remain traceable.
- Testing, approval, monitoring, incidents and exceptions produce auditable evidence.
- Prohibited use cases and unacceptable residual risks do not proceed.
Inventory and intake
Every material AI use case begins with an intake record and an entry in the AI inventory before customer data is connected, model access is enabled or a material feature is released. The record covers purpose, owner, intended users, affected parties, lifecycle status, customer context, model and provider, data sources and categories, processing locations, tools, permissions, credentials, external endpoints, human approvals, initial risk tier and review date.
An incomplete intake may proceed only to limited discovery that does not expose customer data or create operational authority. It may not proceed to activation until required facts, evidence and reviewers are identified.
Governance structure
| Role | Decision authority | Expected evidence |
|---|---|---|
| Executive approver | Approves policy and accepts material residual or high risk. | Approval record and risk acceptance. |
| AI governance lead | Classifies risk, convenes reviews and approves low or medium risk within delegated authority. | Inventory, assessment and review record. |
| Product owner | Defines intended use, customer value, limitations and accountable ownership. | Use-case record and system description. |
| Engineering lead | Approves architecture, model, data, tool and change implementation. | Design, code review and release evidence. |
| Security and privacy | Reviews security, data flows, privacy roles, providers and incidents. | Threat model, privacy review and contractual mapping. |
| Quality assurance | Determines whether evaluation evidence meets release criteria. | Test plan, results and defect record. |
| Customer owner | Approves data sources, identities, model endpoint, actions and operational responsibility. | Deployment approval and responsibility record. |
AI lifecycle
| Gate | Required decision | Minimum evidence |
|---|---|---|
| 1. Intake | Is the purpose defined and allowed? | Owner, users, intended use and prohibited use. |
| 2. Classify | What is the initial risk tier? | Data, autonomy, impact, sector and legal screen. |
| 3. Design | Are safeguards built into the architecture? | Data flow, threat model, permissions and human gates. |
| 4. Validate | Does the system meet acceptance criteria? | Evaluation, adversarial, privacy and security results. |
| 5. Approve | Is residual risk acceptable? | Decision record, limitations, exceptions and rollback. |
| 6. Deploy | Is the deployment configured as approved? | Architecture, shared responsibility, logging and runbook. |
| 7. Monitor | Does live behavior remain acceptable? | Quality, security, incident and usage indicators. |
| 8. Change | Does the change require reassessment? | Change classification and regression evidence. |
| 9. Retire | Have data and access been closed safely? | Access removal, return or deletion and archive record. |
Risk classification
| Tier | Typical criteria | Required treatment |
|---|---|---|
| Prohibited | Unlawful use, uncontrolled high-impact action, evasion of safeguards, unauthorized surveillance or re-identification. | Must not proceed. |
| High | Production write access, critical-infrastructure action, material safety or security impact, significant decisions about individuals, or sensitive regulated data. | Executive, security, privacy or legal and customer approval as applicable. |
| Medium | Operational recommendations using customer data with human review, external model inference, connectors or persistent evidence. | Governance, product, security and customer approval as applicable. |
| Low | Non-sensitive drafting, summarization or analysis without material operational action. | Responsible-owner approval under established standards. |
Risk is determined by the actual use case, data, permissions, autonomy and consequence of failure—not by deployment label alone.
Assessment requirements
A material AI assessment records:
- Purpose, accountable owner, intended users, affected persons and foreseeable misuse.
- Model and provider, data categories, provenance and provider data-use terms.
- Applicable privacy roles, processing purpose, retention and rights handling.
- Architecture, trust boundaries, subprocessors, processing locations and external endpoints.
- Tools, credentials, permissions, autonomy and human-approval points.
- Accuracy, hallucination, prompt-injection, data-leakage, excessive-agency and operational-failure risks.
- Acceptance criteria, test evidence, known limitations, residual risk and review date.
Model and provider governance
Only approved models and endpoints may be used. The responsible owner records the provider, model family or version where available, hosting, processing location, retention, training settings, known limitations and change process. Customer data is not used to train or fine-tune a shared model without explicit written customer authorization.
A provider or model change is material when it may alter output quality, data use, processing location, retention, security, explainability or legal obligations. Material changes require reassessment and regression testing before promotion.
Testing and release governance
- Representative cases with expected evidence, conclusions and safe responses.
- Cases with missing, inconsistent, stale or malicious information.
- Direct and indirect prompt-injection and data-exfiltration attempts.
- Unauthorized tool requests, permission bypass and approval-bypass attempts.
- Sensitive-information, secret and cross-context disclosure tests.
- Regression against accepted behavior after model, prompt, connector or permission changes.
Release evidence identifies the evaluation set, test version, result, defects, accepted limitations, approver and rollback method. Unresolved high-severity findings block release.
Deployment monitoring and change
Each customer deployment maintains a record covering architecture, identity, data sources, model endpoint, external egress, logging, retention, support access and shared responsibilities. Monitoring covers availability, errors, quality degradation, denied actions, unusual tool use, approval events and security alerts.
Deployments are reviewed on the cadence established by their risk approval and after incidents or material changes. Changes to models, prompts, tools, permissions, providers, data flows or hosting are classified and receive proportionate reassessment and regression testing.
When evidence is unavailable, permissions are insufficient, a tool response is inconsistent or an approval condition is not met, the system should fail safely by withholding consequential action, presenting the limitation and escalating to an authorized person.
Incident and exception governance
AI, privacy and security incidents follow the Incident Response Plan. An exception requires a defined scope, reason, risk owner, compensating controls, expiration date and approval. An exception cannot authorize unlawful conduct or breach a customer agreement.
Governance records and evidence
| Record | Purpose or trigger |
|---|---|
| AI inventory | Updated at intake, material change and retirement. |
| AI risk assessment | Completed before release and after material change. |
| Model and provider record | Completed before use and after provider change. |
| Evaluation and release record | Completed for every material release. |
| Customer deployment record | Completed before activation and after material configuration change. |
| Incident and corrective-action record | Completed for every qualifying incident. |
| Governance review record | Documents periodic oversight, decisions and follow-up actions. |
Customer-safe evidence may be provided through controlled review. Customer-specific records, security findings and internal deliberations are not published on this page.
Personnel and contractors performing in-scope work must follow this framework. Undisclosed material changes, circumvention of controls or activation without required approval may result in access removal, suspension, corrective action or other measures consistent with applicable agreements and personnel processes.
Release decision
Before a material release, the decision record confirms:
- Intended and prohibited uses are documented.
- Privacy and security reviews are complete.
- Model and provider data use is approved.
- Prompt-injection and data-leakage tests meet acceptance criteria.
- Permissions and human approvals match the risk assessment.
- Monitoring, incident contacts and rollback are ready.
- Customer approval and shared responsibilities are recorded where applicable.
- Residual risks and exceptions have named approvers and expiration dates.