The Production Safety Framework
The PSF defines the domains of practice a production AI deployment must address to be considered safe, responsible, and professionally maintainable. It is model-agnostic, cloud-agnostic, and applies to any organisation deploying AI in a production environment - regardless of which models, platforms, or vendors they use.
Connect system controls to organisational governance.
The Framework defines what teams implement across a production AI system. PAI-8 defines what organisations govern, evidence, audit, and report. The two standards are parallel layers of the same operating model.
Read the PAI-8 standard →
Model the PSF in WorkflowOS
The standard is text. WorkflowOS is the working artifact — design workflows, run PSF analysis, simulate runs, and export evidence. Free on the web, or fork the MIT-licensed source and self-host for clients.
View on GitHubThe PSF is free to read, cite, and apply.
Use it to interpret the public record, review your own deployment, and name the controls in your documentation.
Interpret the record
See the standard applied to live evidence.
Public records on incidents, disclosures, and policy changes are mapped to the PSF domains they implicate.
Open record explorer →Review a deployment
Check a live system against the eight domains.
Run the readiness check to separate implemented controls from assumed ones before an incident does it for you.
Run readiness check →Map your vendors
See which controls your stack covers.
Map vendors and tools to PSF domains to find the controls that remain your responsibility.
Map a vendor →Cite the standard
Use the PSF in your own documentation.
The framework is open and citable in policies, reviews, and research. Version history is published.
How to cite →Why this standard exists
Major cloud platforms document how to configure their own products. What they do not provide is a common safety standard for the moments when the underlying model changes, a vendor's service goes down, or a use case involves personal data the system was not designed to handle.
Production AI deployment is a discipline - not a vendor configuration exercise. The same principles of input governance, output validation, data protection, observability, deployment safety, human oversight, security, and vendor resilience apply whether you are running GPT-4o through OpenAI's API, Claude through AWS Bedrock, Llama on your own infrastructure, or Qwen through a European hosting provider.
The Production Safety Framework was developed to fill this gap. It describes the eight domains of practice that any serious production AI deployment should address, in terms that are independent of any specific vendor, platform, or model family.
The framework is published openly and free to reference. It gives deployment reviews, Lab scorecards, incident analysis, and procurement teams a shared language that is independent of any vendor's product.
Eight domains of production AI practice
Each domain contains practical control areas that can be used in deployment reviews, evidence checks, incident analysis, and Lab assessments.
Input Governance
Every input reaching an AI model must be validated, sanitised, and treated as untrusted.
- ›Sanitise user input and detect injection before any model call
- ›Validate input schemas (type, length, structure) at the boundary
- ›Log inputs with PII redacted for auditability
- ›Rate-limit AI endpoints with alerting on abuse patterns
- ›Treat the system prompt as a non-overridable security boundary
Output Validation
Raw model output is never trusted. Every output is validated before it acts on any system.
- ›Enforce structured output schemas on every response
- ›Define fallbacks when validation fails — never fail open
- ›Apply semantic checks beyond structural schema where feasible
- ›Never pipe raw model output straight to data stores, APIs, or UIs
- ›Sample-based quality scoring with trending over time
Data Protection
Personal and sensitive data is protected throughout the AI pipeline, not just at rest.
- ›Redact or tokenise PII before external model APIs except where strictly justified
- ›Document legal basis for processing; map EU AI Act data roles where applicable
- ›Minimise data in prompts, retrieval, and logs; enforce retention and purge
- ›Apply lifecycle and access controls to vector stores like primary databases
- ›Schedule PII purge from AI logs per policy
Observability
You cannot manage what you cannot measure. Every AI system in production must be observable.
- ›Log each inference with IDs, model/version, tokens, latency, outcome; correlate multi-hop chains
- ›Automated output quality sampling with stored trends
- ›Drift and quality alerts, including per-stage signals in multi-model pipelines
- ›Capture user feedback and correlate with outputs
- ›Operational health dashboards for on-call without raw-log access
Deployment Safety
Every model change is a risk. Production AI deployments require the same rigour as critical software.
- ›Pipeline with evaluation gates for every model, prompt, or config change
- ›Canary or shadow for material changes before full cutover
- ›Documented, tested rollback within 15 minutes
- ›Automated eval suites block regressions
- ›Reconstruct model version and prompt hash for any logged output
Human Oversight
Automation does not mean unaccountable. High-stakes AI decisions require human checkpoints.
- ›Classify decisions by stakes and reversibility
- ›Mandatory HITL for high-stakes / irreversible paths; bounded autonomy for agentic flows
- ›Escalate to named humans instead of silent failure
- ›Log and review human overrides for systematic issues
- ›Transparent AI use where the law or materiality requires it
Security
AI systems introduce new attack surfaces. Standard security practices must extend to cover them.
- ›Secrets manager for keys; no credentials in repos
- ›Per-environment keys with spend controls
- ›Document and review model calls, data sources, and tools
- ›Treat prompt injection as a vulnerability class with testing
- ›Minimal authority for agents; validate tools; confirm irreversible actions
Vendor Resilience
A production AI system that only works with one vendor is a liability, not an asset.
- ›Abstract providers behind an internal API; configuration-level switching
- ›Test at least one alternative model; assess prompt portability
- ›Document dependencies with contingencies
- ›Avoid vendor lock-in in core logic without justification and migration plan
- ›SLAs, DPAs, and regulatory role mapping on file and reviewed when vendors change
How the PSF is used
Licensing and citation
The Production Safety Framework is published under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence. You may freely share, adapt, and build on the framework for any purpose, including commercial use, provided you attribute the Production AI Institute.
If you are referencing the PSF in a job description, procurement document, research paper, or internal policy, see our citation guidance for the recommended attribution format.
Keep your AI map current
Tool policy changes, new incident records, disclosure signals, and practical next steps. Public evidence, plain English, no hype.