A phased checklist for safe AI deployment covering security configuration, governance sign-off, testing gates, and post-deployment monitoring. Tied to real incident types from the topaithreats database and EU AI Act Article 9 requirements.

Who this is for: ML engineers, DevOps/MLOps teams, product owners, and risk officers responsible for deploying AI systems. Applies to both initial deployments and significant updates to existing systems.

AI deployment failures are a documented cause of AI incidents. Misconfigured deployment and insufficient safety testing together account for a significant share of entries in the topaithreats incident database—including cases where default settings left systems open to exploitation, where excessive permissions enabled unauthorized data access, and where untested edge cases caused harm at scale in production. This checklist operationalizes the controls that prevent these failures across three phases: pre-deployment security and safety, pre-deployment governance and compliance, and post-deployment verification.

Why Deployment Configuration Causes Incidents

Default settings in AI systems are optimized for ease of use, not for security. Out-of-the-box configurations typically include: verbose error messages that expose system internals, permissive CORS policies, no rate limiting, default API key scopes that grant more access than necessary, and no content filtering.

Each of these defaults has been the proximate cause of documented AI incidents:

Verbose error messages exposing system prompts in production
Absent rate limiting enabling prompt injection probing at high volume
Default embedding API scopes granting access to all documents regardless of tenant
No content filtering allowing policy-violating outputs to reach users

The checklist below treats defaults as guilty until proven innocent: every default setting should be reviewed and explicitly configured for production.

Phase 1: Security and Safety (Pre-Deployment)

Threat model and red team

Threat model completed and documented (threat surface, attack vectors, highest-risk output categories) Red team conducted covering all threat categories in the threat model (see AI Red Teaming) Zero unmitigated critical-severity red team findings Zero unmitigated high-severity red team findings, or each has documented residual risk with sign-off Red team findings register stored and linked to this deployment record

Prompt injection and input security

Privilege separation implemented between system instructions and untrusted content Input length limits enforced on all user-facing input fields Encoding normalization applied (unicode, base64) RAG pipeline: injection scanning applied at indexing stage All tool outputs treated as untrusted; validated before use

Output and content safety

Output format validation enforced before downstream use Content classifiers applied for harmful content, PII, and policy violations Action allowlist in place for any agentic tool calls Human approval gates implemented for all irreversible actions

Access control and permissions

Authentication required on all model inference endpoints Rate limiting applied per user and per IP Agent tool permissions scoped to minimum required for task (least privilege) Session-scoped credentials used for agent tool access (not persistent API keys) Tenant-scoped retrieval enforced at database level in multi-tenant deployments

Default settings audit

All default API key scopes reviewed and restricted to required access only Verbose error messages disabled in production configuration CORS policy restricted to required origins Debug endpoints and admin interfaces disabled or access-restricted No hardcoded secrets, API keys, or credentials in application code or configuration files

Secrets management

All model API keys and credentials stored in secrets manager (not environment variables in code) Secrets rotation policy documented and enforced Third-party connector credentials scoped to minimum required access

Phase 2: Governance and Compliance (Pre-Deployment)

Risk classification

AI system classified by risk tier (EU AI Act classification, or internal risk framework) For high-risk AI: technical documentation prepared per EU AI Act Annex IV requirements Named AI risk owner assigned for this system Risk register entry created for this system

Bias and fairness

Fairness criteria defined and documented before testing (demographic parity / equal opportunity / individual fairness) Disparate impact testing completed across all relevant protected characteristics Training data representation audit completed and findings documented Bias testing results documented in model card

Documentation

Model card or system card prepared documenting: intended use, known limitations, bias testing results, and safety mitigations Data sheet prepared for training data sources (provenance, collection date, known limitations) System prompt and configuration version-controlled and documented

Regulatory compliance

Applicable regulations identified for this system and deployment context DPIA (Data Protection Impact Assessment) completed if system processes personal data at scale Legal review completed for high-risk use cases (employment, credit, healthcare, law enforcement) Incident reporting obligations documented (EU AI Act Article 62, GDPR Article 33 timelines)

Sign-off

Engineering sign-off: security and safety checks complete Product owner sign-off: risk posture accepted Risk officer or compliance sign-off (required for P1-risk systems) Residual risks documented and accepted with named approver

Phase 3: Deployment Configuration

Deployment execution

Deployment performed via automated pipeline (not manual configuration) to reduce configuration drift risk Model version pinned in production (not tracking a mutable "latest" tag) System prompt version recorded and linked to deployment record Deployment performed in a maintenance window with rollback plan ready

Rollback readiness

Previous stable configuration documented and accessible Rollback procedure documented and tested Rollback decision criteria defined (what threshold triggers rollback without escalation)

Phase 4: Post-Deployment Verification

Smoke tests

Functional smoke tests passed (system behaves as expected for intended use cases) Security smoke tests passed (injection probes, authentication checks, rate limiting verification) Content safety checks passed (harmful content probes produce refusals, not harmful outputs)

Monitoring activation

Behavioral monitoring active and alerting configured Injection attempt indicator tracking live Agent tool call audit log active Error rate and latency monitoring active On-call rotation updated with this system's incident runbook

Incident response readiness

Incident response plan reviewed and incident owner assigned Escalation path documented (who to call for P1, P2 incidents) Evidence preservation procedure reviewed by on-call team

Phase 5: Ongoing Maintenance

After deployment, re-run relevant checklist sections when:

Change	Sections to Re-run
Model version update (provider-side)	Phase 1 security + Phase 4 smoke tests
Fine-tuning or model retraining	Phase 1 full + Phase 2 bias testing
System prompt change	Phase 1 injection security + red team targeted scope
New tool or data source integration	Phase 1 full + Phase 4 full
New deployment region / regulatory context	Phase 2 full
Significant traffic increase	Phase 3 (capacity and rate limiting) + Phase 4 monitoring

For public-facing systems with high-risk capabilities, run a full red team quarterly regardless of whether changes have occurred. New attack techniques emerge continuously.

Common Deployment Failures and Their Causes

Failure	Root Cause	Checklist Gate That Prevents It
System prompt exposed via API error	Default verbose error messages	Phase 1: Default settings audit
Prompt injection via RAG document	RAG scanning only at query time	Phase 1: RAG pipeline injection scanning at index stage
Cross-tenant data exposure	Application-layer-only tenant filtering	Phase 1: Tenant-scoped retrieval at DB level
Agent exfiltrates data via email	Excessive agent permissions	Phase 1: Agent tool permissions (least privilege)
Discriminatory hiring decisions	Bias testing skipped or done after deployment	Phase 2: Disparate impact testing
No rollback after model regression	Model version not pinned	Phase 3: Model version pinned

AI Security Best Practices — detailed guidance on each security control
AI Red Teaming — the testing methodology that feeds Phase 1 sign-off
How to Build an AI Incident Response Plan — for when Phase 4 monitoring detects a problem
Misconfigured Deployment — incident cases caused by deployment configuration failures
Insufficient Safety Testing — incident cases caused by skipped pre-deployment testing

AI Deployment Checklist: Pre- and Post-Deployment Verification