Operational Handbook

Document Control

Legal and Reliance Notice

© 2026 ODA3 Pvt Ltd. Published market-facing by ODA3 Institute.

GAISSF™ is used as a framework mark. Third-party names and marks remain the property of their respective owners.

This handbook does not constitute legal, regulatory, safety, engineering, certification or audit advice. It does not create a legal safe harbour, establish a legal standard of care, or determine statutory compliance in any jurisdiction.

Operational monitoring reduces uncertainty but cannot prove the absence of unknown threats, emergent behavior, rare failures or harmful outcomes.

Foreword

Deployment is the beginning of operational assurance, not its conclusion. AI systems, data, suppliers, users, threats and legal obligations change continuously. This handbook defines a practical operating rhythm for control health, monitoring, incident response, evidence maintenance, management review and improvement.

1. Purpose and Scope

This handbook applies to AI systems in pilot, limited-production and general-production states. It covers daily operations, control monitoring, service management, change detection, incidents, exceptions, supplier oversight, evidence refresh, assurance, management review and retirement.

Organizations should tailor the operating model according to system criticality, autonomy, physical consequences, data sensitivity, user population, regulatory exposure and conformance profile.

2. Operational Objectives

3. Operational Governance Model

4. Operating Cadence

5. Operational Inventory and Baseline

Run-state operations require an authoritative baseline describing what is approved and currently deployed.

6. Control-Health Monitoring

6.1 Control-health record

7. Monitoring Architecture

7.1 Alert design

1. Define the risk condition represented by each alert.
2. Specify source, threshold, severity, owner and response time.
3. Distinguish informational signals from actionable alerts.
4. Test alert generation, routing, acknowledgement and escalation.
5. Monitor false positives, false negatives and unreviewed alerts.
6. Retain alert decisions and closure evidence.

8. Model and Data Operations

8.1 Re-evaluation triggers

• Model or provider version change
• Material prompt, orchestration or policy change
• New data source or material data distribution change
• New agent, tool or external action
• New jurisdiction, user group or high-impact use
• Incident, near miss or repeated harmful output
• Supplier notification or assurance deterioration
• Material threat-intelligence update

9. Agentic AI Operations

10. Physical AI Operations

11. Incident and Near-Miss Operations

11.1 AI-specific incident categories

• Prompt injection, model extraction or model compromise
• Data poisoning, unauthorized retrieval or sensitive-data leakage
• Harmful, discriminatory, deceptive or materially incorrect output
• Agent action outside approved authority
• Unapproved model, prompt, data or supplier change
• Loss of human oversight or override capability
• Unsafe physical actuation or safety-envelope breach
• Evidence integrity failure or monitoring blind spot

12. Exception and Residual-Risk Operations

13. Supplier Operations

14. Evidence Operations

14.1 Evidence freshness classes

15. Change and Configuration Operations

1. Maintain an approved baseline for model, data, prompts, tools, policies and infrastructure.
2. Detect configuration drift and unauthorized changes.
3. Assess GAISSF control and evidence impact before material change.
4. Use tested rollback or safe-state capability.
5. Refresh affected evidence after deployment.
6. Update inventory, risk, SoA and public claims where necessary.

16. Operational Metrics and Indicators

17. Management Review

18. Continuous Improvement

Continuous improvement should be evidence-driven and linked to risk outcomes.

18.1 Corrective-action quality criteria

• Addresses root cause rather than only the visible symptom
• Has an accountable owner and target date
• Includes interim containment where needed
• Defines validation and closure evidence
• Assesses recurrence across other systems and controls
• Updates procedures, training and monitoring where appropriate

19. Operational Assurance

20. Service Degradation, Suspension and Retirement

20.1 Retirement checklist

☐ Users and integrations identified

☐ Processing and physical actions stopped

☐ Credentials, tools and supplier access revoked

☐ Data retained, returned or disposed appropriately

☐ Models, prompts and configurations archived where required

☐ Evidence and incident records preserved

☐ Public claims and inventories updated

☐ Residual obligations assigned

21. Operational Anti-Patterns

22. Limitations

• Operational metrics cannot capture every failure mode or emerging risk.
• Monitoring may be constrained by privacy, supplier opacity, system design or physical conditions.
• Thresholds require system-specific validation and may change over time.
• Absence of alerts does not establish absence of compromise or harm.
• Continuous monitoring does not eliminate the need for periodic independent assurance.

23. Notably Absent

• No universal operational threshold for every AI system.
• No assumption that service availability demonstrates security or safety.
• No permission to suppress failed, negative or inconclusive evidence.
• No automatic acceptance of supplier attestations as complete assurance.
• No guarantee that monitoring will detect every novel attack or emergent behavior.
• No substitution for sector-specific safety, quality, privacy or incident obligations.

Annex A — Daily Operations Checklist

☐ Critical alerts reviewed

☐ Red and unknown control-health states assigned

☐ Incidents and near misses triaged

☐ Unauthorized changes investigated

☐ High-risk agent and physical actions reviewed

☐ Supplier notifications checked

☐ Evidence pipeline operating

☐ Escalations completed

Annex B — Monthly Control Review Template

Annex C — Operational Dashboard Template

Annex D — Management Review Record

Annex E — Source Traceability

Annex F — Publication Record

Controlled Profile Reconciliation Notice

The Foundational profile comprises 52 controls across all nine domains, as enumerated in the controlled conformance profile. Seven controls are excluded from that profile; the exclusions are not equivalent to excluding the D9 domain.

Any earlier wording that described the Foundational profile as D1-D8 only or treated the entire D9 domain as excluded is superseded by this statement and the controlled conformance profile.

Detailed Run-State Procedures

Severity and Escalation Model

Operational Runbooks by Domain

KPI, KRI and KCI Catalogue

Shift and On-Call Handover

• Open critical/high alerts and incidents
• Red/unknown control states
• Temporary restrictions and active exceptions
• Recent model, data, supplier or configuration changes
• Pending evidence preservation or notification
• Named decision owners and next checkpoints

Continuous Improvement Program

Improvement should operate as a closed loop: identify signal, assess systemic cause, prioritize by risk, implement change, validate effectiveness, update documentation and monitoring, and review for recurrence across other systems.

Completed Example: Monthly Control Review

Example: D3 agent tool authorization is rated Amber after two denied actions were not logged. The owner confirms the authorization control still blocked the actions, but the evidence pipeline was incomplete. A seven-day corrective action is opened to repair logging, backfill available records, test alert routing and verify no other tools are affected. The control remains Amber until the retest passes; certification evidence notes the limitation.

Publication Completeness and Intended Use

This full publication edition of GAISSF-IMP-014 is designed to stand on its own for its stated role: comprehensive run-state operations, monitoring and continuous-improvement handbook. It includes purpose, scope, governance, operating guidance, evidence expectations, limitations, decision criteria and reusable records appropriate to that role.

Completeness does not mean that the document replaces the normative control statements, applicable law, sector-specific engineering, organizational procedures or professional judgement. Cross-referenced GAISSF documents remain part of the controlled document system.

Legal and Regulatory Integration

GAISSF provides an operational security, safety, governance and evidence framework. It does not determine which laws apply, establish statutory compliance, create a legal safe harbour, define a legal standard of care, replace competent legal advice, or guarantee that evidence collected for GAISSF purposes will satisfy a regulator, court or other authority. Organizations should maintain a jurisdiction-specific legal and regulatory obligations register and map applicable obligations to their GAISSF scope, controls, evidence, reporting processes and decision authorities.

Legal and regulatory interface requirements

• Identify applicable jurisdictions, regulators, sector rules, contractual duties and internal legal authorities before relying on this guide.
• Maintain a controlled obligations register, reporting-clock register, retention schedule, legal-hold process and conflicts-of-obligation procedure.
• Treat statutory, regulatory and contractual analysis as a parallel workstream to GAISSF implementation and assurance.
• Record the legal basis, responsible owner, scope, decision, evidence, deadline and review date for each material obligation.
• Do not represent GAISSF conformance, maturity or certification as legal approval, permission to operate, immunity from enforcement or proof that harm cannot occur.

How to use this document

See Also

• GAISSF-IMP-016 for troubleshooting.
• GAISSF-IMP-017 for evidence preservation.
• GAISSF-IMP-018 for improvement.

Operations-specific regulatory enhancements

Statutory reporting and legal-response track

1. Open a legal and regulatory assessment in parallel with technical containment.
2. Identify each potentially applicable reporting regime and start its clock register.
3. Preserve facts supporting materiality, risk, harm and notification decisions.
4. Coordinate initial, supplemental and final reports with authorized legal and regulatory owners.
5. Document the basis for notification or non-notification and subsequent changes.

Legal hold and preservation override

Regional telemetry architecture

• Classify telemetry before collection.
• Keep sensitive telemetry regionally where required or approved.
• Use minimized, pseudonymized or aggregated cross-region feeds.
• Control support access, replication, retention and incident transfer.
• Document regional blind spots and compensating controls.

Operational runbook and handover enhancements

Runbooks should cover detection, containment, preservation, investigation, recovery, validation, communication, legal escalation and recurrence prevention. Shift handover should review new red states, critical alerts, open incidents, active holds, regulatory clocks, degraded controls and pending approvals.

Notably Absent — legal and regulatory boundary

• No universal reporting clock for every incident.
• No assumption that centralized telemetry is legally permissible in every region.
• No universal operational metric threshold; thresholds are risk- and context-specific.

Publication revision record