AI policy development
Decide which policy decisions need explicit rules, owners, and enforcement routes
When existing policies do not explain how agent use should be governed, this area becomes relevant. For the AI policy owner, the concern is specific: a broad principle cannot be translated into a decision by an engineer or manager. The governance implementation design starts from that consequence and follows the relevant evidence through the customer workflow. Policy development should expose unresolved management choices rather than conceal them in aspirational language. Each material rule needs an affected audience, a practical action, and a route for handling cases that do not fit.
Connect the operating question to inspectable evidence
- AI policy owner
- Owns the bounded decision and the consequence of acting.
- Current policies
- Defines the starting context for the proposed work.
- Policy applicability
- Exposes the first material uncertainty to examine.
- Exception and review provisions
- Carries unresolved conditions into an accountable next action.
Decision at stake
Decide which policy decisions need explicit rules, owners, and enforcement routes
Make the decision explicit
- AI policy owner
- Existing policies do not explain how agent use should be governed.
- Decision
- Which policy decisions need explicit rules, owners, and enforcement routes.
- Policy applicability
- Use current policies to establish the relevant starting condition.
For the AI policy owner, this becomes relevant when existing policies do not explain how agent use should be governed. The immediate decision is which policy decisions need explicit rules, owners, and enforcement routes. The scope should be narrow enough that the governance owners can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that a broad principle cannot be translated into a decision by an engineer or manager. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Coverage
Examine policy applicability alongside operational feasibility
Keep the review distinctions visible
- Policy applicability
- Connect each policy statement to the agent uses it governs.
- Operational feasibility
- Check whether the named owner can apply the rule in real work.
- Links to controls and evidence
- Specify the operating control and artefact that would evidence the policy.
Policy applicability
For this scope, policy applicability should be examined alongside current policies. State which systems, people, and decisions each policy rule covers. Use contrasting examples to expose ambiguity. The proposed policy should distinguish mandatory actions from recommendations and should identify unresolved management choices instead of hiding them behind broad language about responsible AI.
Operational feasibility
For this scope, operational feasibility should be examined alongside agent use cases. Test whether an engineer or manager can act on the rule using available processes and tools. A practical rule names the triggering situation, required behaviour, and accountable owner. Where the organisation cannot implement it yet, the gap should be visible rather than implied away by publication.
Links to controls and evidence
For this scope, links to controls and evidence should be examined alongside decision and exception authorities. Connect each material rule to implementation evidence and an exception route. The policy owner should know how a departure is reviewed and when a rule is reconsidered. A policy document is a design artefact; evidence of its use must come from the organisation’s actual operating decisions.
Prerequisites
Start with current policies
Give each input a specific job
- Current policies
- Defines the operating boundary.
- Agent use cases
- Examine operational feasibility.
- Decision and exception authorities
- Shows conditions affecting links to controls and evidence.
- Policy or risk owner
- Confirm access and a reviewer who can resolve gaps.
The starting material is current policies, agent use cases, and decision and exception authorities. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include an accountable policy or risk owner, relevant system owners, and qualified legal or domain reviewers when interpretation is needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Follow the requirement into an accountable operating practice
Follow the evidence through the work
- Policy applicability
Use current policies to define the decision criteria.
- Operational feasibility
Inspect agent use cases and retain observations that challenge the expected result.
- Links to controls and evidence
Use decision and exception authorities to identify unresolved conditions and a responsible owner.
- Exception and review provisions
Link the recommendation to its evidence, remaining limits and next validation condition.
Draft policy rules around decisions people must make. For each rule, identify the triggering situation, required action, evidence, owner, and exception route. The proposed development process should test examples with affected users and control teams so ambiguous language is corrected before it is treated as an enforceable expectation.
A practical first slice would focus on policy applicability and then follow its consequences into operational feasibility. Keep links to controls and evidence visible as a separate review question rather than assuming it is satisfied by the first result. The governance owners should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefacts
Use exception and review provisions to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- AI policy draft
- Boundary — current policies.
- Implementation responsibility map
- Findings about operational feasibility.
- Exception and review provisions
- Action on links to controls and evidence.
Indicative outputs include AI policy draft, implementation responsibility map, and exception and review provisions. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Drafting and external action: specific operating rules
Examine the constructed decision boundary
Illustrative scenario
- Drafting and external action
An organisation needs rules for agents using business data and tools.
- Policy distinction
Apply the draft to internal writing and an externally acting workflow.
- Specific operating rules
If one blanket rule obscures the difference, revise it and reserve qualified-review questions.
Consider an illustrative situation in which an organisation needs rules for agents that use business data and initiate tool actions. This is a constructed example, not a client engagement or an observed Softlander outcome.
For agents using business data, an illustrative policy workshop would compare internal drafting with an externally acting workflow. A single blanket rule may be too vague for both. The resulting draft should make the relevant distinctions visible and reserve unresolved legal or professional questions for qualified review.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves links to controls and evidence unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and authority
Governance evidence supports decisions within defined professional limits
Keep analytical work separate from decision authority
- Operating requirements and evidence mapping
- Can include AI policy draft.
- Policy or risk owner
- Authorised policy owners decide; qualified specialists interpret professional requirements.
- Legal conclusions and certification decisions
- Cannot be inferred from implementation responsibility map.
This work supports governance preparation and operating evidence. It does not provide legal advice, determine regulatory compliance, award certification, or replace a formal audit. Authorised customer owners retain policy, release, and residual-risk decisions.
Ways to engage
Related engagement scopes
AI Privacy Engineering Review
Trace personal data through your agent workflow. Examine collection, memory, retrieval, tool access and retention against your agreed requirements.
AI Governance Operating System
Make AI oversight part of daily operations. Connect inventories, accountable owners, change decisions and evidence into a workable governance process.
Continue exploring
Related insights and resources
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Protecting agent data and memory
An agent's information footprint extends beyond the conversation. Map the copies, derived records and retrieval paths that influence future actions, then connect each to purpose, access, retention and verifiable handling.
AI agents in legal operations: assistance without invented authority
Legal agents can organize evidence and prepare work, but professional judgement, client authority and verified legal positions cannot be delegated by interface.