Kill-switch and circuit breaker
The Kill-switch is the containment control of last resort. When a Bizzi AI feature is leaking sensitive data, behaving erratically, or absorbing an active attack, the operator takes the AI offline without taking Bizzi offline. Manual workflows continue. ERP sync continues. The customer’s accounting operations continue. Slower, more manual, but uninterrupted. The Kill-switch exists so that “pause the AI” is a one-click decision, not a multi-hour negotiation with engineering.
The principle
Section titled “The principle”When the switch is activated, the platform reroutes user flows away from AI paths (OCR, AI assistant, auto-matching) toward manual paths (direct entry, manual match). ERP sync, which is not AI, is unaffected. Status pages and in-app banners explain what is happening.
Architecture
Section titled “Architecture”- Notify Status page + in-app banner (always)
- Normal AI path below
- Activated Manual path below
Activation criteria
Section titled “Activation criteria”Five conditions justify activation. The on-call engineer escalates to the CPTO for SEV1 cases before flipping the switch globally.
- Cross-tenant data leak confirmed. SEV1 by default.
- Active prompt injection attack that rate limits do not contain.
- Anomalous AI behaviour. Widespread hallucination, output corruption, or persona drift across multiple features.
- Vendor LLM outage affecting a critical path when the failover model also fails.
- Customer request. Enterprise customers request a pause for internal review or incident handling on their side.
The switch is granular by design. We do not have only a global setting.
- Feature-level. Disable the AI assistant while keeping OCR running, or vice versa.
- Tenant-level. Disable AI for a single tenant when the incident is isolated to them.
- Global. Disable all AI features across the platform.
Defaults map to severity. SEV1 cross-tenant leak goes global. SEV2 feature-scoped issues go feature-level. Customer-requested pauses go tenant-level.
Activation procedure
Section titled “Activation procedure”The end-to-end flow is designed to be measured in minutes, not hours.
- Detection. Alert from DevSecOps or customer report (Pillar I §11).
- Decision. On-call engineer for SEV2 and below. CPTO concurrence required for SEV1 global activation.
- Activate. One-click toggle in the admin dashboard. The action is written to an immutable audit log.
- Notify. Status page updates immediately, affected customers receive a notification within 15 minutes, Sales and Customer Success are paged.
- Investigate. Root cause analysis begins in parallel. Containment does not wait for it.
The internal SLA target is “activation possible within minutes of decision.” The exact public SLA is pending leadership confirmation for inclusion in customer commitments.
User experience while the switch is on
Section titled “User experience while the switch is on”The platform stays operationally usable. AI features display a maintenance banner. Auto-fill becomes manual entry, clearly labelled. The HITL approval queue shifts from “auto-suggest then approve” to “manual entry then approve”. ERP sync continues to process whatever invoices the user enters by hand. Service availability for non-AI surface stays at 100%.
Recovery
Section titled “Recovery”Re-enabling is not a single toggle in reverse. Recovery has four required steps. Verify the fix in staging. Phased re-activation by traffic share (10% then 50% then 100%). Close monitoring for 24 to 48 hours after full restoration. Post-incident review delivered within 7 to 14 days per §12.
Customer communication
Section titled “Customer communication”Customers affected by an activation receive: an initial notification within 15 minutes of activation, situation updates every two hours during the incident, a resolution notification when AI features are restored, and a post-mortem summary within 30 days. The same cadence applies whether the Kill-switch was triggered by Bizzi or requested by the customer.