Event-driven governance patterns

Traditional governance is form-based and periodic — someone fills in a template once a quarter. Saidot supports a different model: governance actions triggered automatically by events in your AI development and production environment. This page documents the most useful event-driven patterns and how to implement them.

Prerequisites
This page assumes you have read How Saidot governance works. Some patterns require the Webhooks and Incidents features — documentation for those is forthcoming. Patterns that depend on those features are marked accordingly.

API vs MCP — choosing the right channel

Most event-driven integrations use the REST API. It is the right choice for machine-to-machine calls: CI/CD pipelines, data pipelines, monitoring webhooks, and any server-side automation where there is no human in the conversation. Full API documentation is available at app.saidot.ai/api.

MCP servers are the right choice when an AI assistant or agent is the actor — reasoning over governance data, drafting evaluations, or carrying out multi-step workflows on behalf of a user. Most organisations will use both: REST API for automated pipeline steps, MCP for agent-assisted and human-in-the-loop workflows.

Saidot Webhooks work in the other direction — they push events from Saidot out to your systems when governance state changes (a risk is escalated, a review is completed, a system changes lifecycle stage).

When to use event-driven governance

Event-driven governance is the right approach when:

• A governance action is reliably triggered by a specific technical event (deployment, data refresh, incident alert)

• The action is well-defined and low-ambiguity (register this system, link this model, create this incident record)

• Speed and consistency matter — human-initiated workflows introduce lag and variation

• You want governance to be invisible to engineers: it just happens as part of the CI/CD pipeline

Event-driven governance complements, rather than replaces, human judgement. Use it for the data entry and routing steps; keep humans in the loop for risk treatment decisions and sign-offs.

Pattern 1: New model deployment → register and inherit risks

Trigger: A new model version is promoted to production (CI/CD pipeline, model registry webhook)
Channel: REST API

Goal: Ensure the model is registered in Saidot, linked to the relevant systems, and risk inheritance is current before the model is serving traffic.

Steps:

1. CI/CD pipeline calls the Saidot REST API to create or update the Model record with version, provider, and deployment metadata

2. Link the model to the relevant systems

3. Saidot triggers risk inheritance automatically — risks on the Model propagate to linked Systems

4. Notify the System owner via your notification tool (Slack, email) that new inherited risks may need review

5. Optionally: ask an AI agent connected to Saidot to run a risk gap analysis on the updated system

Implementation note: Model registration is idempotent if you use the model's unique identifier as the key — re-running the pipeline for the same version will update rather than duplicate the record.

Pattern 2: Dataset update → refresh data governance record

Trigger: A training dataset or RAG knowledge base is updated (data pipeline completion, scheduled refresh)
Channel: REST API

Goal: Keep the Dataset record in Saidot current so that data-related risks remain accurate.

Steps:

1. Data pipeline calls the Saidot REST API to update the Dataset record with new version, row count, schema changes, or sensitivity reclassification

2. If schema or sensitivity changed, trigger a re-review of data-related risks on linked Systems

3. Link any new data sources to the Dataset record

Pattern 3: Production incident → create incident record and link to system

Trigger: An alert fires in your monitoring stack (PagerDuty, Datadog, custom alert)
Channel: REST API + Webhooks (requires the Incidents feature)

Goal: Ensure every production AI incident is captured in Saidot with context, linked to the affected system, and routed to the right owner.

This pattern requires the Incidents feature. Full documentation is being prepared. The pattern is described here for planning purposes.

Steps:

1. Monitoring alert fires → webhook calls the Saidot REST API to create an Incident record with severity, description, and timestamp

2. Link the Incident to the affected System(s)

3. Saidot notifies the System owner and governance lead via configured notification channels

4. Post-incident: update the Incident record with root cause, affected users, and resolution; link to any new or updated risks created as a result

Pattern 4: Scheduled governance audit

Trigger: Scheduled job (weekly, monthly, quarterly)
Channel: MCP / AI agent

Goal: Proactively surface stale risks, controls without evidence, systems without owners, and other governance gaps — before they become audit findings.

Steps:

1. Scheduled job invokes an AI agent with access to the Governance MCP

2. Agent reviews the system inventory and checks for: missing owners, overdue risk reviews, controls in planned status for more than 90 days, systems without a transparency report

3. Agent compiles a summary and posts to a shared channel or creates tickets in your issue tracker

4. Optionally: generate an HTML governance dashboard for the team

Implementation tip: Use a standard cron job or your organisation's task scheduler to run this automatically. Pin the generated report to a shared channel so the governance team has a standing weekly digest.

Pattern 5: New system registered → trigger onboarding checklist

Trigger: A new System record is created in Saidot (via API, MCP, or UI)
Channel: Webhooks (outbound) + MCP / AI agent

Goal: Ensure every new system moves through a consistent governance onboarding sequence rather than sitting incomplete in the inventory.

Steps:

1. System creation triggers a Saidot outbound webhook

2. Agent checks required fields: owner, description, intended purpose, industry classification — flags any gaps

3. Agent suggests Library risks appropriate for the system type and routes them to the System owner for review

4. Governance lead is notified that a new system needs classification review

Pattern 6: CI/CD gate — block deployment if governance incomplete

Trigger: Pull request merge or deployment pipeline step
Channel: REST API

Goal: Prevent a system from reaching production if its governance record is below a defined completeness threshold.

Steps:

1. CI/CD pipeline step calls the Saidot REST API to retrieve the System record and check governance completeness

2. If completeness is below the defined threshold (e.g. no owner, no risks assessed, no controls linked): fail the pipeline step with a descriptive message

3. If completeness meets the threshold: pass; optionally update the system lifecycle stage to Deployment

Implementation note: Define the completeness threshold in your pipeline configuration, not in Saidot. A common minimum bar: system owner set, at least one risk assessed, lifecycle stage current.

Designing your own patterns

Any repeatable sequence of "external event → Saidot action" can become a governance pattern. When designing one:

• Identify the trigger clearly — what system fires it, how reliably, and what data it carries

• Choose the right channel — REST API for machine-to-machine steps, MCP for agent-driven reasoning and human-in-the-loop workflows

• Keep write operations minimal — create or update only what the event tells you; don't infer fields you don't have data for

• Handle failures gracefully — log failures and alert; don't silently skip governance steps

• Route review requests, don't auto-approve — use agents to draft and route; keep humans in the decision loop for risk and control sign-offs