Policies, in any field, are a response to the existence of a problem or potential problem. They are broadly prompted by the following triggers:

1. Something went wrong.
2. Something could go wrong.
3. External pressure.
4. Internal growth.
5. A new capability.

(1) Something went wrong

This is the most common trigger, often some sort of failure resulting in an incident. These include demonstrably dangerous situations; harm coming to a person or property, data breaches, etc. For example: after multiple incidents of people tripping on unmarked curbs in their parking lot, the school created a policy that all curbs shall be painted yellow.

This trigger produces a reactive policy.

Often, reactive policies are only developed after multiple incidents have occurred, and are frequently combined with the eternal pressure trigger. Staying with our previous example, let's say that the school only changed the policy after multiple injuries, on separate occasions, several of which resulted in lawsuits against the school. If reactive policies are instituted too soon, without multiple instances demonstrating the problem, these policies are often too narrow and fail to address the systemic conditions responsible.

(2) Something could go wrong.

Risk analysis is critical in policy development.

The identification and acceptance of a potential risk combine to trigger an anticipatory policy. This sort of policy is both rarer and harder to form. It requires institutional buy-in based on hypoethical harm. Without demonstrable, certain harm, it is difficult to garner support for anticipatory policies. This difficulty is magnified in resource-intensive development.

Although more difficult, policy triggered by risk analysis is where the best governance work lives. Particularly when confronting unprecedented or large-scale risks.

(3) External pressure.

In policy development, external pressure can include new laws, client demands, public scrutiny, or other reputational risks. These policies tend to be compliance-oriented; the goal is to satisfy the external requirement. Often, external pressure is a secondary or tertiary trigger prompting a policy change.

The policies stemming from this trigger sometimes align with actually solving the problem... and sometimes don't.

(4) Internal growth.

Another form of responsive policy is prompted by internal growth. When an organization scales, new terms form, responsibilities blur. Informal norms and unspoken rules that used to function without issue are no longer functional. Now, explicit rules must be created in order to maintain the original standard. Shared context must be manufactured. Decisions must be governed by internal frameworks to distill noise.

This is especially relevant to companies scaling quickly.

(5) A new capability.

A new capability introduces a novel condition that challenges existing governance structure. If no relevant anticipatory policy was created in preparation for a certain capability, there is simply no structure whatsoever, which triggers a reactive game of catch-up.

This trigger is particularly relevant to AI development. When an organization develops or deploys a model with emergent capabilities (for instance, a system that can autonomously browse the internet, generate convincing synthetic media, or interface with external tools) the policy question is left open. The rules must be written from scratch under conditions of uncertainty about how the capability will behave at scale.

For example: a company fine-tunes a model and discovers it can now reliably generate functioning code that interacts with live APIs. No existing internal policy governs autonomous code execution, because the capability didn't exist six months ago. The organization must now retroactively define acceptable use boundaries, access controls, and monitoring requirements for a behavior that was not accounted for when the previous policy suite was written.

The challenge with capability-triggered policy is that it demands both speed and humility.

The Six Phases of Policy Creation

Regardless of which trigger initiates the policy development process, the development follows a consistent lifecycle. Note that the lifecycle is not a checklist; it is live. Interactive. Responsive. It's a sequence of interdependent phases, each with a distinct purpose, output, and decision point that determines whether the process moves forward, loops back, or ends entirely.

A policy is a hypothesis. Monitoring tests it. The results of the test stimulate the system, sometimes sending it all the way back to the beginning.

Phase 01 — Signal Detection & Triage

As noted above, every policy begins with a trigger: an incident, a risk assessment, a regulatory development, organizational growth, or a new capability.

At this point in the lifecycle, policies are not even in mind yet. This stage is solely about recognizing a problem.

This is the most frequently skipped phase in organizational governance, and skipping it is the most common cause for policy failure. If a policy is not rooted in understanding of the problem it is written to solve, it does not accomplish its purpose.

The acknowledgement of the problem, whatever it may be, triggers a triage question:

Is this a...

• policy problem,
• enforcement gap,
• or a product design issue?

This answer dictates the next phase in the lifecycle.

A policy problem means that there is no existing rule governing the behavior or condition in question. An enforcement gap means the rule exists but is not being applied (in the legal field, unenforceable laws are referred to as being "without teeth"). A product design issue means the behavior should be made technically impossible rather than merely prohibited.

For example: a model produces outputs that violate an existing acceptable use policy. The instinct is to write a new, more specific policy. But if the existing policy already covers the behavior and the issue is that the safety filter failed to catch it, the correct response is engineering, not governance. Writing a second policy to cover a behavior already addressed by the first does not solve the problem. It creates redundancy, lacks enforceability, and obscures the mechanism of failure.

Correct diagnosis is the key to effective policy.

Once the problem is diagnosed and it is determined that a new policy is warranted, we move into Phase 02 of the lifecycle.

Phase 02 — Problem Scoping & Root Cause Analysis

The next phase is to distill the problem, conceptualizing it separately from the symptom that caused it.

At this point, policy writers endeavor to reach the root of the problem by repeatedly asking why. The standard "5 Whys" developed by Sakichi Toyoda asks a single causal chain. (E.g., Problem: The case won't start. 1. Why? The battery is dead. 2. Why? The alternator isn't working. 3. Why? The alternator belt is broken. 4. Why? The alternator belt was old. 5. Why? The car had not been properly maintained.)

In sociotechnical contexts, such as AI policy development, the chain branches. Technical failures and misalignment have organizational causes, organizational causes have structural causes, and structural causes often have cultural causes.

For example: a company discovers that a deployed model is being used by customers for a purpose that was not anticipated, one that raises safety concerns. The surface-level problem: the model is being misused.

• Why? Because the acceptable use policy did not explicitly prohibit this use case.
• Why? Because the team that drafted the acceptable use policy did not consult with the customer-facing team.
• Why? Because the policy development process had no requirement for cross-functional team input.
• Why? Because the organization treated policy drafting as a legal exercise rather than a diagnosis and systems design prompt.

Here, we find the root cause: a gap in the policy development process.

A policy that simply adds a new prohibited use case to the existing list addresses the symptom. A policy that restructures how acceptable use policies are developed (like who is consulted, what inputs are required, and what review points exist) addresses the cause.

The required output of this phase is a problem definition document that identifies both the presenting problem and the root cause (and, in AI development, specifies which layer of the sociotechnical ecosystem failed). If the root cause analysis reveals that the problem is not actually addressable by policy, we loop back to Phase 01 and redirect accordingly.

Phase 03 — Policy Design & Drafting

This is the phase most people think of when they think of policy creation. In practice, it's only about 20% of the work.

At this point, policy writers must define the bounds of the policy (this can be intentional, but is more often inadvertent). At one end, a policy that is maximally restrictive, the tightest possible interpretation of what the policy should govern, with the most conservative boundaries. At the other, a policy that is maximally permissive, the least possible change that still addresses the root cause.

Author's note: In my experience, there is a direct correlation between resistance to change and problems caused by outdated, ineffective systems.

Depending on a number of factors (internal/external pressure, resources, resistance to change, etc.), the level of restriction is determined. This process forces explicit confrontation with tradeoffs. What flexibility does the restrictive version eliminate? What risks does the permissive version leave open? Where do the edge cases cluster?

Every sentence in the final policy should perform one of three functions: define a boundary, assign responsibility, or specify an action. Sentences that do not perform one of these functions are aspirational language and therefore cumbersome; they should be edited out.

Once the policy is drafted, much like the process of red-teaming in AI development, it is stress-tested.

• If someone wanted to technically comply with this policy while violating its intent, how would they do it?
• If a bad actor wanted to exploit ambiguity in the language, where would they find it?
• If an AI system were given this policy as a constraint, where would it misinterpret the intent or apply the rule too broadly?

These scenarios reveal what needs to be revised.

In AI governance specifically, adversarial testing should include prompt injection scenarios, edge cases in model behavior, and situations where the policy interacts with other existing policies in unintended ways.

The output of this phase is a final draft (not the final policy). Sometimes, also included are a tradeoff documentation record or an adversarial testing log.

Phase 04 — Cross-Functional Review & Alignment

A policy that has been reviewed only by the team that wrote it is not ready for implementation.

This phase elicits a structured cross-functional review by groups that the policy will affect. There is a deliberate emphasis on collaborative, parallel review. Sequential review, where legal reviews first, then engineering, then product, then leadership, creates a fundamental problem: each reviewer assumes the previous reviewer caught the issues in their domain. Parallel review forces each function to engage with the policy independently, without that assumption. Collaborative review not only stimulates new ideas by translating between systems, it forces groups to consider perspectives outside of their own. Those effects will ripple outward entirely independent of this policy, and create a positive feedback loop of consideration.

Each reviewer evaluates the policy against different criteria according to the system they represent.

• Engineering asks whether the policy is technically feasible.
• Product asks whether it is compatible with the product roadmap.
• Legal asks whether it creates liability.
• Public policy asks whether it aligns with the external regulatory environment.
• Leadership asks whether it aligns with organizational strategy and resource availability.

It is important during this phase to track disagreements and attempt to determine their root cause. A well-designed policy creates friction because it is making real tradeoffs.

• Someone in engineering will object that the policy creates technical constraints that are expensive to build.
• Someone in product will object that the policy limits a feature they planned to ship.
• Someone in legal will flag liability exposure.

These objections are the point. They surface the tensions that, if left unresolved, will cause enforcement failures later.

It is also important to take note of which tensions remain unresolved. Those unresolved tensions become monitoring priorities in Phase 06.

The output of this phase is a revised draft incorporating reviewer feedback (and a sense of the disagreement discourse).

Phase 05 — Implementation & Rollout

Enforcability is critical.

A policy that cannot be enforced is a suggestion, not a policy. The central question of this phase is not "What is the right rule?" (as we already answered in Phase 03). The question is: "Can we enforce this rule with the governance structure we currently have?"

• If enforcement requires someone to personally review a volume of activity that exceeds their (human) review capacity, the policy is not enforceable.
• If monitoring requires access to data that the organization does not collect, the policy is not enforceable.
• If compliance depends on a team that does not yet exist or a system that has not yet been built, the policy is not enforceable.

Implementation has four components. First, build the technical controls. If the policy restricts a behavior, the system should make that behavior difficult or impossible through technical means, not just prohibited through written rules. Second, train the enforcement team. The people responsible for applying the policy must understand not only what the policy says but why it says it, including the tradeoffs documented in Phase 03. Third, deploy the monitoring infrastructure. Define the metrics that will indicate whether the policy is working, whether it is being circumvented, and whether it is producing unintended consequences. Fourth, launch.

At this point, if implementation is faster than drafting, the policy may not change anything meaningful.

The output at this phase is a deployed policy with active monitoring and a trained enforcement team.

Phase 06 — Monitoring, Evaluation & Iteration

A policy is a hypothesis about what rules will produce the desired outcomes in a given system. Monitoring is the experiment that tests that hypothesis.

This phase is ongoing.

The moment an organization treats a policy as finished is the moment that policy begins to degrade.

Monitoring should track compliance rates, circumvention tendencies (intentional and inadvertent), enforcement, and unintended consequences. Each of these stimulates a corresponding trigger.

If compliance rates are low, revisit Phase 05; the implementation may be insufficient. If circumvention patterns emerge, revisit Phase 03; the policy design may contain exploitable ambiguity. If enforcement actions cluster in one area disproportionately, revisit Phase 02; the problem scoping may have been too narrow or the root cause analysis incomplete. If unintended consequences appear (for instance, the policy creates perverse incentives or disproportionately burdens one group); revisit Phase 03 to redesign the tradeoffs.

Each iteration trigger feeds back to a specific earlier phase, making the entire framework cyclical. The policy is never done. The system it governs is constantly changing, and governance that does not change with it becomes governance in name only.

The output at this phase is documented metrics and a record for each stimulant that triggers movement between phases.

Thus, policy is implemented.