AI Governance
Last reviewed: April 30, 2026 · Reviewed quarterly, or after any material change to AI features
Scope: all AI features in the ShowOps.AI platform — 15 AI agents across LLD, staffing, sales, dispatch, budget, logistics, and chat surfaces.
Audience: customer security teams, procurement, audit. This is the canonical reference for how we govern AI; full pillar narrative is at /safety and operational controls are at /legal/security.
Contact: security@showops.ai
ShowOps.AI's AI features are designed to be ethical, responsible, secure, and private. These are brand-level commitments — they override convenience and velocity. When a proposed feature conflicts with a commitment below, we escalate to the founder before implementation; we do not ship around them. Every commitment is traceable to code and CI guardrails, not just to policy.
1.The Four Pillars
- Ethical. No surveillance features; surface bias in ranking; label AI output explicitly; no autonomous decisions that meaningfully affect people without human approval.
- Responsible. Human-in-the-loop by default. Every consequential agent action produces a proposal, not a mutation. Autonomy is earned per-capability, not granted by default.
- Secure. 3-layer RBAC, least-privilege context, prompt-injection defense, audit logs on every mutation. Security boundaries enforced at the database (RLS), not the UI.
- Private. Per-tenant learning, no pooled training. Your data trains your system, never anyone else's. Data minimization: only collect what the feature needs. 24-month retention default on mutations; no indefinite stores. Learned patterns are deletable on request within 24 hours.
2.Ten Commitments with Traceability
Each commitment below is paired with the code-level mechanism that enforces it. If you're running a security review and want the underlying file paths or PR numbers, email security@showops.ai and we'll provide them under NDA.
- Per-tenant learning; no pooled training. Your data adapts ShowOps.AI for your organization only — never trains a cross-tenant model, never pooled with another tenant's data. Vendor LLM API calls run under commercial no-training terms. Enforced by an SDK choke point (only one file in the codebase imports the LLM SDK), a CI lint that blocks training-mode flags, and a learning-scope CI lint that prevents code outside the learning layer from touching per-tenant adaptation tables.
- Human-in-the-loop by default. Every consequential agent action creates a proposal in a proposals table for human approval, not a direct mutation. Proposals expire automatically.
- Least-privilege context. Agents receive only the data their role and scope allow. A 3-layer RBAC system gates every agent invocation: role tier → agent type → venue scope → data filtering. Chat context depth is also role-gated.
- Prompt injection defense. Untrusted input (user text, imported files, vendor data) is sanitized at the input boundary. CI requires every LLM-calling file to either use the sanitizer or carry an explicit safe-input annotation with rationale.
- Traceable reasoning. Every agent invocation is logged with inputs, outputs, model identifier, prompt version, and token counts. Outputs link back to the source data they cited. Audit logs retained for 24 months.
- Explicit AI labeling. Anything written by an agent is visibly labeled in the UI. A shared
AILabelprimitive is used across all agent-output components, enforced by a contract test that prevents drift. - No autonomous financial decisions. Budget commits, SOW signatures, work-order dispatch, and change-order approvals all require human sign-off. Agent routes are CI-blocked from directly mutating financial-state tables.
- Bias awareness and transparency. Ranking features expose the signals driving the result, not just a scalar score. Vendor scoring exposes its driver fields; ranking agents return findings or recommendations alongside any score. Enforced by a contract test that fails if any ranking surface returns a bare scalar.
- No surveillance of workers. Staffing tracks certifications, availability, and costs — not location, keystrokes, or behavioral patterns. CI lint blocks any new staffing migration whose column patterns match surveillance (location, GPS, screenshot, keystroke, active-window, productivity-score).
- Reversibility. Every agent-initiated mutation has an undo path: revert action, audit-log-backed manual reversal, or explicit out-of-band process. Audit logs capture before/after snapshots on every mutation.
3.CI Guardrails Inventory
The commitments above are enforced by CI checks that run on every pull request. A change that violates one fails the merge gate; merging requires explicit waiver review. The current inventory:
- SDK choke point — blocks any file outside the centralized LLM client from importing the language-model SDK.
- No-training mode — asserts the LLM client uses no custom base URL, no training-beta headers, and no training flags.
- Learning scope — prevents code outside the per-tenant learning layer from touching adaptation tables, structurally preventing cross-tenant data flow.
- Org scoping — every query against tenant schemas must filter by
organization_id; covers all 13 tenant schemas. - Prompt injection — every LLM-calling file must use the sanitizer or carry an explicit annotation.
- Client query ban — client components may not perform anon-key Supabase data queries; allowed uses are auth and Realtime only.
- RLS on migrations — every new table must enable Row-Level Security in the same migration.
- Surveillance columns — staffing migrations cannot introduce columns matching worker-monitoring patterns.
- Agent route contracts — every agent route must use the agent-RBAC helper or document a waiver.
- Agent-budget mutation block — agent routes may not directly mutate the budget schema.
- Ranking explainability — every ranking surface must emit an explainability array, not a bare scalar.
- AI-label coverage — every agent-output component must import the AI label primitive or carry a parent-rendered annotation.
4.Sub-processors and No-Training Status
Customer data is processed by the following sub-processors. Each operates under terms that prohibit use of customer data for training their models. Full DPA at /legal/dpa.
| Sub-processor | Purpose | No-training |
|---|---|---|
| Anthropic, PBC | Language model API for AI agents | Commercial API terms — no training on inputs |
| Supabase, Inc. | Managed PostgreSQL, authentication | Standard DPA · SOC 2 Type 2 |
| Vercel, Inc. | Application hosting, edge runtime | Standard DPA · SOC 2 Type 2 |
| Google Cloud LLC | Optional Sheets sync (customer-enabled) | Workspace API terms — not used for training |
| Sentry | Error and performance monitoring | Standard DPA · PII scrubbed pre-submission |
| Resend, Inc. | Transactional email delivery | Standard DPA |
We provide thirty (30) days' written notice prior to engaging any new sub-processor that processes customer data, and will not engage one whose terms permit use of customer data for model training.
5.Per-Tenant Learning Architecture
ShowOps.AI adapts to each tenant's preferences, operational patterns, and signal thresholds — but only within that tenant's boundary. This is a binding architectural contract, not a policy preference.
- Tenant-scoped at the schema layer. Per-tenant adaptation tables carry an
organization_idcolumn with row-level security, just like every other tenant table. Cross-tenant reads are blocked at the database level. - Layer isolation. Code outside the learning layer cannot read or write per-tenant adaptation state. Enforced by a CI lint that blocks imports of the learning module from non-learning paths.
- Vendor LLM isolation. Every API call to the language-model provider runs under commercial no-training terms. The provider does not train on inputs.
- Tenant-controlled deletion. An admin endpoint resets adaptive state for the calling tenant within 24 hours, with one audit-log row per reset. Coverage extends as additional learned-state tables ship.
- No fine-tuning pipeline. ShowOps.AI does not operate a fine-tuning pipeline that aggregates customer data. Adding one would violate this commitment and require a brand-level decision to change.
6.Data Subject Rights
Customer-administrator self-service flows are live for export and deletion. Engineering involvement is not required for routine subject rights requests. See Privacy Policy §6 for retention details and DPA §8 for processor-level retention.
- Export. Customer admins can export their organization's data on demand.
- Deletion. Deletion requests honored within 30 days, with backups purged according to standard rotation schedules (typically 30–90 days).
- Learned-pattern reset. Adaptive state reset within 24 hours.
- Audit-log access. Customer admins have read access to their own audit logs without engineering involvement.
7.Honest Residuals
We deliberately disclose what we cannot yet claim, to avoid surprises in audit. These map to the same residuals tracked at /legal/security §7.
- No SOC 2 attestation today. Type I engagement targeted Q3 2026; Type II observation begins immediately following.
- No third-party penetration test. Targeted post-Type-I.
- Single-pager on-call today. Documented 15-minute acknowledgement SLA; second-pager handover post-first-hire.
- First disaster-recovery drill not yet executed. Procedure documented; first run scheduled pre-enterprise-go-live.
- RLS policy hardening in progress. Some policies use a degrade-to-permissive form for the post-rollout safety window; tightened to strict equality once all live sessions have refreshed.
8.Where to Escalate
The four pillars are brand-level commitments. A proposed feature that conflicts with any of them — a telemetry pipeline that leaves our infrastructure, an agent that mutates without proposal, a ranking feature without explainability, a dataset that could train an external model, a cross-tenant learning signal — goes to the founder before implementation begins. Changing a commitment is a brand decision, not a product decision.
For questions, audit requests, or governance inquiries, email security@showops.ai. We respond within two business days.