Policy-as-code means expressing governance rules in a machine-readable form that can be version-controlled, reviewed, tested and enforced automatically — rather than in a document that describes what people are supposed to do. The policy becomes an artifact in the same system as the software it governs: it has an author, a history, a diff, and a rollback.
The distinction that matters in practice is between a policy that is written and a policy that is enforced. Most AI governance programs have the first. A written policy is evidence of intent; an enforced policy is evidence of control, and the two are not interchangeable to an examiner who asks what actually stopped the request.
How it differs from a policy document. A document is read by people and applied by judgement. Policy-as-code is applied by a system on every request, identically, whether or not anyone is watching. The document explains why; the code decides.
How it differs from infrastructure-as-code. Infrastructure-as-code declares what should exist. Policy-as-code declares what is permitted at runtime, evaluated per request against the identity and content of that request. They share the review workflow and solve different problems.
Where it meets the CISO. Policy-as-code is the artifact both a platform team and a risk function can read. The platform team gets something testable; the risk function gets something auditable with a change history. That shared object is usually where AI governance stops being a negotiation.
Maestro is Smartflow's policy engine, with versioning and rollback.
What versioned policy buys at examination time
The value of versioning shows up in a specific question: what rule was in force at 14:07 on a Tuesday in March, and who changed it. A document cannot answer that. A policy with a commit history can, and if the version identifier is written into every enforcement record, the answer is a lookup rather than an investigation.
That is what makes policy-as-code an evidence mechanism rather than an engineering convenience. Maestro holds the rules with versioning and rollback, tamper-evident audit logs bind each decision to the version that produced it, and the examination readiness suite assembles the result into what a supervisor actually asks for. The compliance retrospector runs the same records against a named framework such as the NIST AI RMF. Where the policy decision sits in the wider architecture is covered in the AI control plane guide.
Related terms
NIST AI RMF · Information barrier · A2A (agent-to-agent protocol) · Runtime governance · Model allowlist and deny-list · Full glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs