# G‑14 Regulated AI Action Review Console

Updated: 2026-05-14

Canonical: https://g14.ai/regulated-industries

Capability, evidence, and integration framing for regulated AI action control. Private scoring logic, exact enforcement implementation, customer-specific topology, and protected IP are controlled during access review.

## What this route helps a buyer do
- Identify the action boundary for one regulated AI workflow.
- Map the evidence a buyer, architect, consultant, or auditor needs before live enforcement.
- Inspect proof receipt fields and API/Test Lab request shapes.
- Route qualified buyers into SDK access or regulated deployment review.

## Deployment modes
- **Replay**: Run G‑14 against historical or synthetic action records to expose authority gaps, missing evidence, and proof requirements.
- **Shadow**: Evaluate live proposals without intervening, producing a side-by-side record for governance, security, and operations.
- **Assist**: Recommend hold, correction, block, or release decisions to a human or host workflow with evidence attached.
- **Control**: Enforce the release decision before action reaches the tool, robot, workflow, or downstream system.

## Regulated verticals

### Pharmaceuticals & Life Sciences

Primary buyer: Quality, validation, lab automation, manufacturing, and regulated-document owners

Outcome: Govern AI-assisted lab, quality, manufacturing, and regulated-document actions before they become record, release, or patient-impacting consequence.

Action to govern: A model or agent proposes a lab step, batch-record update, deviation triage, pharmacovigilance routing, SOP change, training material, CAPA effectiveness review, validation protocol language, change-control rationale, or manufacturing release-related action.

Workflows:
- Batch-record update or review step
- SOP authoring or controlled-procedure change
- Training material generation
- CAPA effectiveness review
- Validation protocol drafting
- Change-control documentation
- Deviation or quality-event triage
- Lab automation and sample-handling action
- Pharmacovigilance case routing

Buyer questions:
- Which AI actions can touch GxP records, quality events, samples, release decisions, or regulated documents?
- Which AI actions author the procedural evidence used to prove the quality system operated correctly?
- Does the criticality matrix treat AI-authored procedural evidence as lower-stakes than the downstream operation it governs?
- Where does recommendation become operational instruction, record change, or workflow release?
- Who has authority to admit, hold, deny, or escalate the action?
- What proof survives for quality, validation, supplier, and inspection review?

Evidence matrix:
- **21 CFR Part 211 / CGMP procedural evidence**: Can we show who admitted AI-assisted SOP, training, CAPA, validation, or change-control evidence before it became part of the quality record? G‑14 evidence: Procedural action receipt with proposal, boundary, authority route, evidence references, decision, and final outcome.
- **21 CFR Part 11 / EU Annex 11**: Can we prove who admitted a record-affecting action, when, and from what evidence? G‑14 evidence: Proof receipt with proposal, authority, timestamp, decision, evidence references, and audit binding where configured.
- **GAMP 5 / CSV**: Can validation teams review one workflow before live enforcement? G‑14 evidence: Replay or shadow packet showing expected action path, hold behavior, release rules, and verifier output.
- **Quality system review**: Can a held or blocked AI action be routed to the right quality owner? G‑14 evidence: Authority context, reviewer custody, hold resolution, risk event, and final outcome.
- **FDA AI/drug development review support**: Can the organization explain how AI-assisted actions were controlled in a regulated process? G‑14 evidence: Boundary map, evidence matrix, proof packet exports, and deployment-mode history.

Proof receipt:
- Receipt: G14-PHARMA-REVIEW-042
- Proposal: AI agent proposed a controlled batch-record update.
- Boundary: GxP record-affecting workflow.
- Authority: Quality owner review required before release.
- Decision: Held for authorized review.
- Evidence: Batch record, SOP version, user role, workflow state.
- Timing: Policy-only local gate: sub-ms to low-ms target. Evidence-bound review: 6 configured checks.
- Risk: Record mutation without authorized admission.
- Outcome: Action not released; review packet exported.

API start: `POST /v1/regulated/actions/evaluate`

Boundary honesty: G‑14 does not replace a QMS, CSV program, validation owner, clinical judgment, regulatory submission duty, or required human release authority.

### Healthcare

Primary buyer: Clinical governance, compliance, security, revenue cycle, and care operations

Outcome: Control AI action paths touching patients, records, claims, care operations, and administrative decisions.

Action to govern: A model or agent proposes a triage routing, patient-record update, claim action, scheduling escalation, care-management task, or clinical-workflow handoff.

Workflows:
- Patient-record update or summary writeback
- Claim action or payment hold recommendation
- Care-management task routing
- Clinical workflow handoff
- Patient communication or scheduling escalation

Buyer questions:
- Which actions touch protected health information, care delivery, patient communication, or operational commitments?
- Which actions require licensed review, policy review, or patient-safety escalation?
- Can the organization prove what the AI proposed and what was actually allowed?
- Can the action be held or blocked without breaking the workflow?

Evidence matrix:
- **HIPAA Security Rule**: Can we show access, audit, and risk handling for AI-assisted actions involving PHI? G‑14 evidence: Action packet with role context, evidence references, decision state, and audit export.
- **Clinical governance**: Which actions require licensed or policy review before they affect care operations? G‑14 evidence: Boundary classification, hold route, reviewer custody, and final release outcome.
- **NIST AI RMF**: Can AI actions be governed, measured, and reviewed after execution? G‑14 evidence: Runtime decision record, risk event, evidence used, and proof receipt.
- **Vendor risk review**: Can a buyer inspect what the AI was allowed to touch? G‑14 evidence: Workflow map, proof-packet fields, deployment mode, and export path.

Proof receipt:
- Receipt: G14-HEALTH-REVIEW-018
- Proposal: AI system proposed a patient-record writeback.
- Boundary: PHI and clinical documentation workflow.
- Authority: Licensed or delegated reviewer required.
- Decision: Held before writeback.
- Evidence: Role context, encounter state, policy reference.
- Timing: Policy-only local gate: sub-ms to low-ms target. Evidence-bound review: 5 configured checks.
- Risk: Unauthorized clinical record change.
- Outcome: No writeback released; review packet retained.

API start: `POST /v1/healthcare/actions/evaluate`

Boundary honesty: G‑14 does not replace clinical judgment, medical-device regulatory analysis, HIPAA compliance programs, EHR controls, or required licensed review.

### Financial Services & Insurance

Primary buyer: Model risk, operations risk, claims, payments, trading support, and compliance

Outcome: Govern AI actions before they touch money movement, customer commitments, trading systems, claims, credit, fraud, or model-risk workflows.

Action to govern: A model or agent proposes a claim decision, payment hold, trade support action, customer commitment, credit workflow step, fraud queue action, or production operational change.

Workflows:
- Claims decision or payment hold
- Fraud queue action
- Customer commitment or refund path
- Credit workflow step
- Trading support or production operations action

Buyer questions:
- Which AI outputs can create financial, legal, market, or customer consequence?
- Which actions require supervisory review, segregation of duties, or model-risk evidence?
- Can the organization reconstruct the proposal, authority, evidence, and result?
- Can controls fail closed when evidence, authority, or downstream state is missing?

Evidence matrix:
- **SR 11-7 model risk**: Can model-driven actions be reconstructed and challenged? G‑14 evidence: Proposal, evidence, authority context, decision reason, and verifier receipt.
- **Operational risk**: Can controls fail closed when evidence or authority is missing? G‑14 evidence: Hold/block event, reason code, custody record, and final outcome.
- **SEC Regulation SCI where applicable**: Can covered technology actions support incident and control review? G‑14 evidence: Action packet, release state, timing, risk event, and export bundle.
- **Customer dispute review**: Can the institution prove what was proposed and what was authorized? G‑14 evidence: Proof receipt with proposal, decision, evidence, reviewer custody, and outcome.

Proof receipt:
- Receipt: G14-FIN-REVIEW-091
- Proposal: AI system proposed a claims payment hold.
- Boundary: Customer-impacting financial decision.
- Authority: Supervisor or policy owner required.
- Decision: Held pending review.
- Evidence: Claim record, fraud indicator, notice policy.
- Timing: Policy-only local gate: sub-ms to low-ms target. Evidence-bound review: 7 configured checks.
- Risk: Unreviewed customer-impacting hold.
- Outcome: Action not released until authority resolves hold.

API start: `POST /v1/financial/actions/evaluate`

Boundary honesty: G‑14 does not replace regulated supervisory duties, BSA/AML programs, model validation, trading controls, core banking controls, or legal review.

### Manufacturing, Robotics & OT

Primary buyer: Robotics, OT, plant operations, safety, quality, and industrial engineering

Outcome: Gate robot, AMR, manufacturing, inspection, and industrial workflow actions before commands reach the execution channel.

Action to govern: A robot policy, AMR system, vision model, planning agent, or industrial workflow proposes a route, manipulation step, quality action, or downstream control handoff.

Workflows:
- Robot manipulation or assembly step
- AMR route or zone authorization
- Quality inspection disposition
- Industrial task permit
- Operator instruction or maintenance action

Buyer questions:
- Which model outputs can become motion, machine action, line change, quality disposition, or operator instruction?
- Which commands should be preserved, corrected, blocked, or routed to an operator?
- Can the system prove why an action moved, changed, stopped, or escalated?
- Can private deployments avoid public-cloud dependency where required?

Evidence matrix:
- **ISA/IEC 62443-aligned review**: Can the control boundary be scoped around OT connectivity and downstream egress? G‑14 evidence: Deployment boundary, connector review, command custody, and evidence export.
- **Safety case support**: Can unsafe or unauthorized robot commands be stopped before execution? G‑14 evidence: Blocked/corrected command path, runtime evidence, risk event, and outcome.
- **NIST CSF / AI RMF**: Can physical AI actions be governed and reviewed after the fact? G‑14 evidence: Proposal, zone state, decision, release path, and proof receipt.
- **Private deployment review**: Can the deployment avoid public-cloud dependency where required? G‑14 evidence: Infrastructure boundary, private networking plan, and evidence-retention design.

Proof receipt:
- Receipt: G14-OT-REVIEW-147
- Proposal: AMR route entered a temporary human-work zone.
- Boundary: Physical execution channel.
- Authority: Operator rule permits route correction.
- Decision: Corrected and released.
- Evidence: Zone state, mission packet, robot status.
- Timing: Policy-only local gate: sub-ms to low-ms target. Evidence-bound review: 8 configured checks.
- Risk: Robot route through constrained work zone.
- Outcome: Alternate route released; original command suppressed.

API start: `POST /v1/industrial/permits/evaluate`

Boundary honesty: G‑14 does not replace certified safety systems, PLCs, interlocks, low-level motion controllers, risk assessments, or required plant safety approvals.

### Energy, Utilities & Infrastructure

Primary buyer: Critical operations, infrastructure security, field operations, and resilience teams

Outcome: Control AI-assisted operational actions where availability, safety, cyber posture, and public trust matter.

Action to govern: A model or agent proposes a maintenance dispatch, grid-support workflow, operator note, field-work action, anomaly response, or operational escalation.

Workflows:
- Maintenance dispatch or field-work action
- Anomaly response escalation
- Operator note or control-room support action
- Asset inspection workflow
- Public-service commitment or outage communication

Buyer questions:
- Which AI actions can touch critical operations, dispatch, safety workflows, or public-service commitments?
- Can proposed actions be held until the right operator or authority admits them?
- Can evidence survive incident review and regulator-facing inquiry?
- Can the deployment stay within the required infrastructure boundary?

Evidence matrix:
- **NIST CSF 2.0**: Can AI-assisted operational actions be governed and reviewed inside the cyber boundary? G‑14 evidence: Action packet, boundary context, decision, custody, and audit export.
- **NIST AI RMF**: Can the organization measure and review AI action risk over time? G‑14 evidence: Risk events, deployment mode, proof receipts, and final outcomes.
- **Critical infrastructure review**: Can evidence survive incident, regulator, or board review? G‑14 evidence: Verifier-ready packet with timing, authority, evidence, and outcome.
- **Private infrastructure**: Can the path be scoped around residency, network, and operational requirements? G‑14 evidence: Deployment boundary review, private path, and evidence-retention plan.

Proof receipt:
- Receipt: G14-INFRA-REVIEW-063
- Proposal: AI agent proposed field dispatch for anomaly response.
- Boundary: Critical operations workflow.
- Authority: Operations center review required.
- Decision: Held before dispatch.
- Evidence: Asset state, incident ticket, crew state.
- Timing: Policy-only local gate: sub-ms to low-ms target. Evidence-bound review: 6 configured checks.
- Risk: Operational commitment without admission.
- Outcome: Dispatch held; review packet exported.

API start: `POST /v1/infrastructure/actions/evaluate`

Boundary honesty: G‑14 does not replace utility compliance programs, grid-control systems, certified safety controls, NERC obligations, or operator authority.

### Government, Defense & Public Sector

Primary buyer: Mission owners, public-sector CIOs, oversight, procurement, security, and program leaders

Outcome: Create a governed action boundary for AI systems that touch mission workflows, public services, records, benefits, procurement, or operational commitments.

Action to govern: A model or agent proposes a case action, procurement workflow step, operational recommendation, records change, mission support action, or citizen-facing decision support output.

Workflows:
- Case action or benefits workflow step
- Public-record update
- Procurement or contract workflow action
- Mission support recommendation
- Citizen-facing decision support output

Buyer questions:
- Which actions can affect rights, benefits, mission operations, public records, or institutional commitments?
- What authority admits the action, and what must be escalated?
- Can the record prove what was proposed, admitted, denied, or changed?
- Can private deployments align with security, residency, and assessor review requirements?

Evidence matrix:
- **NIST SP 800-171 / CMMC paths**: Can controlled information and action evidence stay inside the scoped boundary? G‑14 evidence: Deployment boundary, evidence-retention plan, access context, and verifier output.
- **FedRAMP path where scoped**: Can cloud or private deployment review receive proof of action control? G‑14 evidence: Control mapping, packet export, audit binding, and access separation.
- **EU AI Act / public-sector oversight analogs**: Can high-impact decisions be traced from proposal through authority and proof? G‑14 evidence: Proposal, authority context, evidence used, decision, custody, and outcome.
- **Procurement and mission assurance**: Can evaluators inspect the action boundary without receiving protected implementation? G‑14 evidence: Controlled route pack, redacted proof receipt, and governed evaluation path.

Proof receipt:
- Receipt: G14-PUBLIC-REVIEW-025
- Proposal: AI agent proposed a case-record status update.
- Boundary: Public authority and records workflow.
- Authority: Authorized official required.
- Decision: Held before record update.
- Evidence: Case state, policy rule, user role.
- Timing: Policy-only local gate: sub-ms to low-ms target. Evidence-bound review: 5 configured checks.
- Risk: Public-record change without admission.
- Outcome: Action held; oversight packet retained.

API start: `POST /v1/public-sector/actions/evaluate`

Boundary honesty: G‑14 does not replace agency authority, legal determinations, accreditation packages, classified-system controls, human rights review, or procurement obligations.

## Controlled next step

Use https://g14.ai/sdk#sdk-request for SDK access or regulated deployment review. NDA available upon request.

## Related public assets

- JSON route pack: https://g14.ai/regulated-industries.json
- GxP procedural layer brief: https://externalcontrollayer.ai/gxp
- SDK access: https://g14.ai/sdk