Move fast and break things does not work with AI. The stakes are too high.
AI systems can discriminate, hallucinate, leak data, and cause real harm. Governance is not bureaucracy. It is the framework that lets you ship AI confidently.
This post provides a practical governance framework for engineering teams.
| Category | Description | Examples |
|---|
| Safety | Physical or psychological harm | Medical advice, self-harm |
| Fairness | Discrimination or bias | Hiring, lending, content |
| Privacy | Data exposure or misuse | PII leakage, profiling |
| Security | System exploitation | Prompt injection, jailbreaks |
| Reliability | System failures | Hallucinations, outages |
| Transparency | Unexplainable decisions | Black box decisions |
| Impact | Low Likelihood | Medium Likelihood | High Likelihood |
|---|
| High | Medium risk | High risk | Critical risk |
| Medium | Low risk | Medium risk | High risk |
| Low | Minimal risk | Low risk | Medium risk |
Diagram
flowchart TB
subgraph Assessment["Risk Assessment"]
A[New AI Feature] --> B{High Impact<br/>Decision?}
B -->|Yes| C{Affects<br/>Sensitive Data?}
B -->|No| D[Low Risk Path]
C -->|Yes| E[High Risk Path]
C -->|No| F[Medium Risk Path]
end
subgraph LowRisk["Low Risk"]
D --> G[Self-Review]
G --> H[Standard Deploy]
end
subgraph MedRisk["Medium Risk"]
F --> I[Peer Review]
I --> J[Eval Suite]
J --> K[Staged Deploy]
end
subgraph HighRisk["High Risk"]
E --> L[Ethics Review]
L --> M[Full Audit]
M --> N[Approval Board]
N --> O[Monitored Deploy]
end
style E fill:#ef4444,color:#fff
style F fill:#f59e0b,color:#fff
style D fill:#22c55e,color:#fff
| Question | Low Risk | High Risk |
|---|
| Who are the users? | Internal, technical | Public, vulnerable |
| What decisions does it inform? | Suggestions | Automated actions |
| What data does it access? | Public | Sensitive, PII |
| What happens if it is wrong? | Inconvenience | Harm, legal liability |
| Is it reversible? | Yes | No |
| Tier | Risk Level | Examples | Governance |
|---|
| 1 | Minimal | Internal tools, suggestions | Light review |
| 2 | Low | Customer-facing, reversible | Standard review |
| 3 | Medium | Automated decisions, sensitive data | Enhanced review |
| 4 | High | High-stakes, vulnerable users | Full review + audit |
| Requirement | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|
| Self-assessment | Yes | Yes | Yes | Yes |
| Peer review | No | Yes | Yes | Yes |
| Ethics review | No | No | Yes | Yes |
| External audit | No | No | No | Yes |
| Ongoing monitoring | Basic | Standard | Enhanced | Continuous |
| Characteristic | Description |
|---|
| Users | Internal employees |
| Decisions | Suggestions only |
| Data | Non-sensitive |
| Reversibility | Fully reversible |
| Example | Code completion, internal search |
| Characteristic | Description |
|---|
| Users | Public, potentially vulnerable |
| Decisions | Automated, consequential |
| Data | Sensitive, PII, protected |
| Reversibility | Difficult or impossible |
| Example | Credit decisions, medical triage |
| Section | Content | Purpose |
|---|
| Overview | What the model does | Clarity |
| Intended use | Target use cases | Scope |
| Limitations | Known weaknesses | Risk awareness |
| Training data | Data sources, biases | Transparency |
| Evaluation | Test results, metrics | Performance |
| Ethical considerations | Potential harms | Responsibility |
| Document | Content | Update Frequency |
|---|
| Architecture diagram | System components | On change |
| Data flow | How data moves | On change |
| Risk assessment | Identified risks | Quarterly |
| Incident log | Past issues | Continuous |
| Change log | System changes | On change |
| Element | Purpose | Example |
|---|
| Context | Why this decision | Business need |
| Options considered | Alternatives | Model A vs B vs C |
| Decision | What was chosen | Model B |
| Rationale | Why this option | Best accuracy, acceptable cost |
| Trade-offs | What was sacrificed | Higher latency |
| Owner | Who is accountable | Engineering lead |
| Check | Question | Pass Criteria |
|---|
| Need | Is AI the right solution? | Clear benefit over alternatives |
| Risk | What tier is this? | Risk level identified |
| Data | What data is needed? | Data legally available |
| Scope | What are the boundaries? | Clear use case definition |
| Check | Question | Pass Criteria |
|---|
| Testing | Has it been tested? | Evaluation suite passed |
| Bias | Has bias been assessed? | Fairness metrics acceptable |
| Security | Has it been secured? | Security review passed |
| Privacy | Is data handled properly? | Privacy review passed |
| Documentation | Is it documented? | Required docs complete |
| Phase | Duration | Purpose |
|---|
| Overview | 5 min | Present system |
| Risk discussion | 15 min | Review risk assessment |
| Mitigation | 10 min | Discuss controls |
| Decision | 5 min | Approve, conditional, reject |
| Action items | 5 min | Document next steps |
| Source | Description | Mitigation |
|---|
| Training data | Historical biases | Diverse data, debiasing |
| Labeling | Annotator bias | Multiple annotators, guidelines |
| Model | Learned patterns | Fairness constraints |
| Deployment | Usage patterns | Monitoring, feedback |
| Metric | Description | When to Use |
|---|
| Demographic parity | Equal outcomes across groups | General |
| Equal opportunity | Equal true positive rates | Classification |
| Predictive parity | Equal precision across groups | Prediction |
| Individual fairness | Similar individuals treated similarly | Any |
| Test | Frequency | Threshold |
|---|
| Demographic analysis | Pre-deployment | Under 5% disparity |
| Slice analysis | Pre-deployment | No significant gaps |
| Ongoing monitoring | Continuous | Alert on drift |
| Level | Examples | Handling |
|---|
| Public | Product info, marketing | Standard |
| Internal | Business data, analytics | Access control |
| Confidential | Customer data, PII | Encryption, logging |
| Restricted | Health, financial, children | Special controls |
| Requirement | Implementation | Verification |
|---|
| Minimization | Only collect needed data | Data audit |
| Purpose limitation | Use only for stated purpose | Process review |
| Retention limits | Delete after period | Automated deletion |
| Access controls | Limit who can access | Access logs |
| Consent | Obtain where required | Consent records |
| Risk | Mitigation |
|---|
| Prompt leakage | Input sanitization |
| Training data exposure | Avoid fine-tuning on sensitive |
| Logging sensitive data | Redaction, encryption |
| Third-party API sharing | Data processing agreements |
| Severity | Description | Response Time |
|---|
| Critical | Active harm, data breach | Immediate |
| High | Significant risk, compliance | 4 hours |
| Medium | User impact, quality issue | 24 hours |
| Low | Minor issue, no harm | 1 week |
| Step | Action | Owner |
|---|
| 1. Detect | Identify incident | Monitoring system |
| 2. Assess | Determine severity | On-call engineer |
| 3. Contain | Stop ongoing harm | Engineering team |
| 4. Communicate | Notify stakeholders | Incident commander |
| 5. Remediate | Fix root cause | Engineering team |
| 6. Review | Post-mortem | All involved |
Post-Incident Review
| Element | Content |
|---|
| Timeline | What happened when |
| Impact | Who was affected |
| Root cause | Why it happened |
| Response | What was done |
| Lessons | What we learned |
| Actions | What we will change |
| Check | Automation | Frequency |
|---|
| Model performance | Evaluation pipeline | Daily |
| Bias metrics | Fairness tests | Weekly |
| Data quality | Validation rules | Continuous |
| Security scan | SAST/DAST | On deploy |
| Documentation | Completeness check | On PR |
| Metric | Target | Alert |
|---|
| Documentation coverage | 100% | Under 95% |
| Review completion | 100% | Under 100% |
| Incident response time | Within SLA | Over SLA |
| Bias metrics | Within threshold | Over threshold |
- 1Tier your systems - Not everything needs heavy governance. Match process to risk.
- 2Document decisions - Future you will thank present you. Record why, not just what.
- 3Automate where possible - Manual governance does not scale. Build checks into CI/CD.
- 4Review before deployment - Catching issues in review is cheaper than catching them in production.
- 5Monitor continuously - Governance is not a one-time event. Systems drift, data changes, risks evolve.
- 6Build a culture - Process without buy-in creates workarounds. Make governance part of how you work.
Governance enables speed by creating confidence. When you know your systems are reviewed, tested, and monitored, you can ship faster, not slower.
