--- title: "A Policy Is Not a Control " id: "3447" type: "insight" slug: "a-policy-is-not-a-control" published_at: "2026-08-14T20:11:22+00:00" modified_at: "2026-08-14T20:11:23+00:00" url: "https://jetstream.security/insights/a-policy-is-not-a-control/" markdown_url: "https://jetstream.security/insights/a-policy-is-not-a-control.md" excerpt: "Approval happens in a moment, but the system keeps moving. Design control is the artifact that makes every AI change visible and every deviation provable, which is exactly what the standards (and auditors) ask you to produce." taxonomy_insight_category: - "AI Advisory" taxonomy_insight_type: - "Editorial" --- AI Advisory # A Policy Is Not a Control Approval happens in a moment, but the system keeps moving. Design control is the artifact that makes every AI change visible and every deviation provable, which is exactly what the standards (and auditors) ask you to produce. Rusty PerryvCISO & Advisory Board Member Editorial *This is installment three of seven in the AI risk management series. [Previously: continuous discovery gives you a living inventory of the AI you run.](https://jetstream.security/insights/ai-visibility-inventory/) This installment: an inventory lists the parts; approval needs a design.* Somewhere in your environment, an agent that was approved in the spring is running on a different model this summer. Nobody signed off on the swap. Nobody logged it. The first time an auditor asks you to show that the live system still matches the one you approved, they find that unlogged change. [The thesis of this series](https://jetstream.security/insights/audit-the-evidence-ai-policy/) is that the standards (NIST, ISO etc.) don’t grade your policies: they grade your evidence. Design control is the stage where that starts to bite. It is where the distance between what you approved and what is actually running either stays closed or quietly opens. Most programs are the thinnest right here. ## **Approval is a moment. The system keeps moving.** An agentic system is not a document you file once. It is reassembled continuously by the people using it and by the components underneath it: a model version moves, a tool API changes, a data source shifts, and no one on your side touched a thing. That is not a knock on your team. It is how the technology works. The consequence is uncomfortable: an approval captured at a point in time describes a system that may not exist a week later. That means the control was never the approval. The control is whatever keeps the approved design and the running system in agreement over time. That is a different discipline from the inventory problem. Finding your AI tells you the system exists. Design control tells you what the system is supposed to be, precisely enough that a change to it is visible and a deviation is provable. ## **Why your old controls do not fit** I ran model risk for a good part of my career, in settings as different as trading floors and plant floors. The regulator and the stakes changed at every stop, but the playbook didn’t. Let me be blunt about the tools most of us are reaching for: the frameworks I used assumed a model was a thing you could pin to a page, documented once, validated on a schedule, changed through a release nobody could skip. Legacy governance, risk, and compliance controls make the same assumption. They govern a static artifact, a document, a model file, a policy statement, reviewed at intervals. Agentic systems break every one of those assumptions. The system changes behavior with no release, and the artifact you documented is not the artifact running. A control designed to inspect a thing that holds still cannot govern a thing that reassembles itself between reviews. This is why lifting your model-risk binder onto AI feels like it should work but does not. The discipline is right. The controls were built for the wrong kind of object. ## **What the standards actually ask you to produce** Read the requirements (jump to the table below) and none of them are satisfied by a policy document. ISO/IEC 42001 places the AI risk assessment, the risk treatment, and the AI system impact assessment in its planning clauses (Clause 6), and its Annex A controls expect the AI system to be documented and managed across its life cycle. NIST’s Govern function is not asking whether a policy exists: it is asking whether that policy has been translated into controls that actually operate. The EU AI Act requires technical documentation for high-risk systems (Article 11, detailed in Annex IV) thorough enough that a regulator can reconstruct how the system was built and how it is meant to behave. Every one of those standards assumes an artifact most organizations do not keep current, which is a precise description of the real system, not a statement of intent about it. Gartner puts it plainly: AI policy has to be translated into governance controls. The policy is the easy part. The translation is the work. ## **The design of record** What closes the gap between approved and running is a single artifact, and it is not a slide deck. Think of it as the design of record for each AI system, and it has a specific shape. It names the parts: the models, tools, data sources, and identities the system uses. Just as important, it records how they connect. It’s [those connections](https://jetstream.security/insights/governing-mcp-sprawl/) where the risk you did not plan for lives. When a design records its connections, two things become knowable that an inventory can never tell you. The first is inherited risk: a weakness in one tool is inherited by every agent that calls it, and you cannot see that chain from a list. The second is blast radius: when something changes or breaks, you know what it touches, because the design says so. An inventory gives you a roster. A design of record gives you the graph. Security teams will recognize the shape: a software bill of materials for a system that rewires itself, plus the change control an SBOM never carries. It is also versioned, so every material change produces a new version, and the description never drifts away from reality. It carries change control, so altering the system is a reviewable event with an owner and a sign-off rather than a silent edit. And it is the artifact you actually hand to an examiner. When they ask how the system is built and how it should behave, the design of record answers, and it matches what is live. This is what JetStream means by AI “design control.” Control the design of the AI. One more thing rides on the design, and the standards are explicit about it. The risk assessment for a use case is not a form you file at launch. ISO ties the impact assessment to the system itself (Clause 6.1.4), and the EU AI Act runs risk management across the whole lifecycle (Article 9). Both mean the same thing: the assessment lives with the design and is refreshed when the design changes. Assess the use case, attach it to the design of record, and let a change to the system trigger a fresh look. The manufacturing world has run this discipline for decades as management of change: nothing modifies a validated process without the safety case being reexamined. This is AI’s version of it. A risk assessment that is true only on the day it was written is not a control either. The narrative names no product on purpose. Where the product comes in is the exhibit below: it shows how one platform implements each check, and which clause of each standard the test answers. In practice, design control boils down to five checks you can actually test, and each one is written into the standards. ## Design control from standard to test | Design-control check | NIST AI RMF | EU AI Act | ISO/IEC 42001 | JetStream test | | --- | --- | --- | --- | --- | | A named, accountable owner for every system | GOVERN 2.1 | Art. 17 | A.3.2, Clause 5.3 | Every blueprint must have an owner | | Guardrails on a design before it is published | GOVERN 1.4 | Arts. 9, 15 | A.6.1.2, A.6.1.3, A.6.2.2 | Published blueprints must have guardrails | | A drifted design forces a review | GOVERN 1.5 | Art. 72 | A.6.2.4, A.6.2.6, Clause 9.1 | Published blueprints that have drifted require review | | The design records its parts: models, tools, data, identities | MAP 4.1, 4.2 | Art. 11, Annex IV | A.4.2, A.4.3, A.4.4, A.4.5, A.6.2.3, and A.6.2.7 | A blueprint records the system’s models, tools, data, and identities | | A material change produces a new, reviewable version | GOVERN 1.5 | Art. 17(1)(a), Art. 17(1)(b), Annex IV(1)(a), Annex IV(6) | Clause 8.1, A.6.2.3, A.6.2.4, A.6.2.6, and A.6.2.7 | Blueprint changes are versioned and reviewable | Answer yes to all five for any system in production and you have design control. Answer no to any of them and you have a design on paper. ## **The objection worth answering** If you build software for a living, this is the point where you tense up, because it sounds like the review board that turns a two-day integration into a two-week wait. It should not, and the difference is entirely a matter of where the design of record lives. If it lives in a document, it is a ticket queue, and your teams will route around it, which means it governs nothing. If it lives in the platform, expressed as code or configuration that travels with the system, then owner, version, guardrail, and change control run as infrastructure, not as a meeting. [Get the governance into the platform](https://jetstream.security/insights/the-security-agent-deployment-trap/) and the two-week wait never shows up. The same artifact quietly answers two other people at the table. For the leader who owns the AI program, the design of record is where policy stops being a PDF and becomes something a running system can honor, so it is built right on the way in rather than reconstructed under an examiner’s deadline later. And for privacy and legal, it does double duty: the approved data-flow and purpose, recorded and kept current, is the living version of the impact assessment they are asked to sign. A data protection impact assessment written at launch and never touched is a liability, and a design of record the runtime keeps honest is a defense. ## **Why this is the unglamorous work that decides audits** Design control does not photograph well. It is version numbers, approval trails, and someone owning the answer to a single question: what changed and who approved it. That is also exactly the line between a policy and a control. The organizations that clear the next audit will not be the ones with the thickest binder. They will be the ones where changing an AI system is an event that leaves a record every time, so the design they approved and the system they are running are never more than one logged version apart. *Next installment: a design you approved is only true if something keeps proving it while the system runs. Next, proving it continuously.* ## Stay ahead with our newsletter Stay informed on industry trends, expert analysis, and product updates. #### Explore more insights [See all Insights](/insights) [https://jetstream.security/insights/mcp-vs-skills/](https://jetstream.security/insights/mcp-vs-skills/) Aug 18, 2026 ###### MCP vs. Skills: A False Debate MCP gives an agent its tools and Skills give it the instructions. The teams winning with Claude run both, and governance is what keeps the pairing safe. [https://jetstream.security/insights/mcp-vs-skills/](https://jetstream.security/insights/mcp-vs-skills/) [https://jetstream.security/insights/leaked-api-key-what-to-do/](https://jetstream.security/insights/leaked-api-key-what-to-do/) Aug 11, 2026 ###### Burt has a key problem. Make sure that you don't. One leaked API key shouldn't be able to stop your business. With a virtual key, it can't. [https://jetstream.security/insights/leaked-api-key-what-to-do/](https://jetstream.security/insights/leaked-api-key-what-to-do/) [https://jetstream.security/insights/ai-visibility-inventory/](https://jetstream.security/insights/ai-visibility-inventory/) Aug 7, 2026 ###### You Can’t Govern the AI You Can’t See Every AI standard starts with an inventory. Here's how to build the one your governance program depends on. [https://jetstream.security/insights/ai-visibility-inventory/](https://jetstream.security/insights/ai-visibility-inventory/) ## Top Articles 01 Press Release ### [JetStream Security Achieves FedRAMP Class D (High) Certification Through Second Front](https://jetstream.security/insights/jetstream-security-fedramp-high-certification/) July 22, 2026 02 Press Release ### [JetStream Releases ‘AI Kill Switch’ to Shut Down Individual Agents](https://jetstream.security/insights/jetstream-ai-kill-switch-agents/) July 27, 2026 03 Press Release ### [JetStream Announces Verified MCP Governance Layer for Enterprise AI Agents](https://jetstream.security/insights/jetstream-verified-mcp-governance-layer-for-enterprise-ai-agents/) July 13, 2026 ## Featured Experts [https://jetstream.security/author-bio/patrick-zeller/](https://jetstream.security/author-bio/patrick-zeller/) ### [Patrick E. Zeller](https://jetstream.security/author-bio/patrick-zeller/) General Counsel, Legal and Compliance Patrick has spent over twenty years advising Fortune 100 companies on privacy, cybersecurity, and data protection — including... [https://jetstream.security/author-bio/keith-weisman/](https://jetstream.security/author-bio/keith-weisman/) ### [Keith Weisman](https://jetstream.security/author-bio/keith-weisman/) Head of Forward Deployed Engineering Keith brings thirty years of hands-on cybersecurity and services leadership, beginning with enterprise security consulting at Accenture and... [https://jetstream.security/author-bio/tommy-hui/](https://jetstream.security/author-bio/tommy-hui/) ### [Tommy Hui](https://jetstream.security/author-bio/tommy-hui/) Head of Sales Engineering Tommy Hui has spent more than a decade leading sales engineering at security companies, including six years at...