Recognition signal
AI use is expanding before the rules are clear
Use cases, input boundaries, output review, records, responsibility, and management explanation need to be clarified.
AI useGovernanceResponsibility
Cases
The situations people bring — as they arise in practice.
Each pattern starts from situations that commonly arise in advisory work, then shows what was unclear, what was structured, and how the work could proceed. If one sounds close to what you are carrying, that is enough to start — no polished brief needed.
Patterns are generalized from recurring themes across advisory work; no client-confidential information is disclosed. Client names, engagement-specific details, and unverified outcomes are not shown.
Recognition signals
Signs this support may fit.
Support may fit when the issue is already moving, but the decision criteria, review points, roles, explanation material, or next actions are still unclear.
Recognition signal
AI, people, and external support need clearer roles
The team needs to clarify what AI supports, what people review, and where vendors or advisors fit.
Role designHuman reviewExternal support
Recognition signal
Security policies or risk assessments need review before the next phase
Policies, risk material, controls, assumptions, residual risks, or handoff points need to be organized.
Security reviewRiskHandoff
Recognition signal
Rules or requirements are becoming hard to operate
Internal rules, external requirements, review points, evidence, ownership, or update cycles need clearer structure.
RulesRequirementsReview points
Recognition signal
An external scheme or standard needs an internal response
Scope, applicable requirements, decision criteria, ownership, and the response plan need to be worked out before anything is committed.
Scheme responseDecision criteriaResponsibility
Recognition signal
Continuity planning has to hold up as a decision, not a document
IT-BCP and cyber-incident continuity need priorities, roles, escalation, and recovery conditions that people can actually decide on.
IT-BCPBusiness continuityRoles
Support patterns
Look for the closest situation.
Each pattern shows what was unclear, what kind of structuring helped, what material remained, and where that material could be used.
Pattern 01 / Generative AI governance
Structuring rules and responsibility boundaries for expanding AI use
For organizations where generative AI use is already starting or expanding, but use cases, input boundaries, output use, human review, approval, records, and responsibility boundaries are still unclear.
AI governanceUse casesResponsibility
01
Before
What was unclear
- Generative AI use had started, but the line between acceptable and unacceptable use was unclear
- Legal, IT, security, risk, and business teams needed shared material for discussion
02
Work
What was structured
- Clarified use cases, input information, output use, human review, approval, records, and responsibility boundaries
- Separated what could move now from what should be handled through later governance or roadmap work
03
Output
What remains
- AI-use rule and governance direction
- Use-case / risk / control matrix
- Responsibility-boundary and review-point memo
04
Used for
Where it helps
- Management reporting
- Stakeholder explanation
- AI-use expansion planning
Where this stopped
Fragment Practice prepared the rules, matrix, and responsibility boundaries. Applying them to systems, and running the checks day to day, stayed with the internal teams that own them.
If the job is to work through use cases, information boundaries, human review, and responsibility inside your own organization first:
See the AI Governance Readiness KitPattern 02 / Governance and control
Turning outdated rules and controls into review points and update issues
For organizations where existing policies, internal rules, guidelines, or external requirements have become outdated, fragmented, or dependent on a few people.
Governance / controlRequirementsReview points
01
Before
What was unclear
- Rules or guidelines created years ago no longer matched AI, cloud, external-service, or current security use
- Questions from business teams and requirement decisions depended on a small number of people
02
Work
What was structured
- Reviewed current rules, related documents, external requirements, and recurring questions
- Clarified gaps, overlaps, review points, ownership, responsibility boundaries, and update issues
03
Output
What remains
- Governance / control and requirement mapping memo
- Gap and unresolved-area list
- Review-point and responsibility-boundary proposal
04
Used for
Where it helps
- Rule and control updates
- Requirement response
- Stakeholder explanation
Where this stopped
The mapping and proposals were handed over. Rewriting the official rule set, approving it, and maintaining it remained with the internal owners.
Pattern 03 / Third-party review
Third-party review of critical systems, security policy, or risk material
For situations where existing security policy, system-renewal material, risk assessments, control assumptions, or next-phase plans need an independent review perspective. This is review support, not audit assurance or certification.
Third-party reviewSecurity policyRisk assessment
01
Before
What was unclear
- Security policy, risk assessment material, or system-renewal assumptions already existed
- Residual risks, open questions, evidence expectations, and handoff points needed clearer structure before the next phase
02
Work
What was structured
- Reviewed policies, risk material, assumptions, controls, evidence, residual risks, and operating implications
- Organized review comments, unresolved points, assumptions, and recommended next actions
03
Output
What remains
- Third-party review comments
- Residual-risk and assumption memo
- Recommended next actions and handoff points
04
Used for
Where it helps
- Pre-next-phase confirmation
- Risk assessment refinement
- Stakeholder or vendor discussion
Where this stopped
A review returns findings and open questions. It is not audit assurance or certification, and deciding how to act on the findings stayed with the organization.
Pattern 04 / AI-enabled security service
Viability and operating model for AI-enabled security services
For teams planning AI-enabled security services or specialist support services that need to clarify customer value, AI-use scope, external partners, provider responsibility, cost drivers, and viability conditions.
AI-enabled serviceSecurity serviceOperating model
01
Before
What was unclear
- The service concept had potential, but customer value, delivery model, and operating assumptions were mixed
- Roles across AI, internal teams, external SOCs, partners, or vendors were not yet clear enough for planning
02
Work
What was structured
- Compared service patterns, AI-use scope, provider responsibilities, partner roles, and operating assumptions
- Clarified cost drivers, delivery constraints, transparency requirements, and conditions for phased expansion
03
Output
What remains
- Service viability conditions
- Operating model options
- Cost-driver and responsibility structure
04
Used for
Where it helps
- Service planning
- Investment or proposal discussion
- Next-phase design
Where this stopped
The viability conditions and operating options were the deliverable. Building the service, contracting partners, and running it were the provider team’s own work.
Pattern 05 / Practical AI-use rules
Turning AI-use rules into practical review points for teams
For organizations that need to turn AI-use policies or high-level rules into practical criteria that business teams can use without getting stuck on every case.
AI-use rulesReview pointsPractical guidance
01
Before
What was unclear
- High-level AI rules existed or were being discussed, but business teams still needed practical guidance
- It was unclear what information could be entered, how outputs could be used, who should review, and what should be recorded
02
Work
What was structured
- Clarified allowed / restricted use, input boundaries, output handling, human review, approval, records, and FAQ themes
- Separated what should be handled by rules, what should be reviewed by people, and what should be escalated
03
Output
What remains
- AI-use review-point checklist
- Input / output handling guidance
- FAQ and escalation-point draft
04
Used for
Where it helps
- Business-team guidance
- Training or FAQ preparation
- Practical AI-use rollout
Where this stopped
Fragment Practice set the criteria and escalation points. Publishing them internally, training teams, and answering day-to-day cases stayed in-house.
If the job is to turn AI-use rules into review points your own teams can apply, without engaging anyone:
See the AI Governance Readiness KitPattern 06 / After a proof of concept
Deciding whether a proof of concept should become real adoption
For organizations where technical validation has progressed, but the scope of use, responsibility boundaries, review method, conditions for pausing, and operating structure are not settled, so there is not enough material to decide on full adoption.
Post-PoCAdoption decisionOperating structure
01
Before
What was unclear
- The proof of concept produced results, but not an answer to whether it should be rolled out
- Scope of use, who approves, and what has to keep being checked once it runs were undecided
02
Work
What was structured
- Separated what the validation actually demonstrated from what it did not
- Clarified the scope of use, responsibility boundaries, review points, conditions for pausing, and the operating structure adoption would require
03
Output
What remains
- Adoption decision material
- Scope-of-use and responsibility-boundary memo
- Review points, pause conditions, and operating requirements
04
Used for
Where it helps
- Adoption or rollout decision
- Management and stakeholder explanation
- Handover to the implementing team
Where this stopped
The decision material and operating requirements were prepared so the adoption decision could be made and handed on. The build, the rollout, and the running of it belonged to the implementing team.
What remains
Practical material for decisions and explanation.
The exact artifact depends on the issue, but the work is designed to leave behind material for reporting, explanation, review, operation, handoff, or the next phase.
Governance Brief
Material for explaining what should be promoted, controlled, reviewed, or moved into the roadmap.
Contains
Current stateUse classificationsReview conditionsResponsibilityRoadmap
Example use
What this helps answer
- What can move now?
- What belongs in the roadmap?
Used before management reporting, policy discussion, AI-use expansion, or governance planning.
Role / Operating Memo
Material for clarifying what AI supports, what people review, and how the work should continue.
Contains
Human / AI rolesWorkflowReview pointsOwnersNext actions
Example use
What this helps answer
- What should AI support?
- Where should people review?
Used when AI adoption or recurring work needs to become a practical operating model.
Rule / Requirement Memo
Material for connecting rules or requirements to review points, records, ownership, and handoff items.
Contains
RequirementsAssumptionsReview pointsRecordsHandoff items
Example use
What this helps answer
- Which requirements matter?
- What should be reviewed or recorded?
Used before rule updates, stakeholder explanation, security review, or handoff.
Review / Assessment Note
Material for documenting review observations, residual risks, assumptions, and recommended actions.
Contains
Review scopeAssessment basisObserved issuesResidual risksRecommended actions
Example use
What this helps answer
- What was reviewed?
- Which risks remain?
Used when policies, risk assessments, or control designs need independent review input.
Next step
If one of these patterns feels close, start with a conversation.
Start from Contact with the situation you recognize here. Services covers how the work is scoped.