LLaManchaAI Enablement
Checking access…
← All modules
Module 8Audience: admin

Business AI policy path

Starts a company-specific AI policy process built for workplace adoption, governance, and risk management.

Outcomes

What you will be able to do

  • Distinguish a technology policy from a use policy.
  • Name the seven components of a workplace AI use policy.
  • Map intake to the NIST AI RMF and ISO/IEC 42001 functions.
  • Produce a policy-readiness brief that is input to legal, not a substitute.
Completion check

How this module is approved

Complete the sanitized policy-readiness brief: all seven components with current state, owner, open question, and NIST AI RMF tag, under the input-not-policy disclaimer.

Pass criteria

  • • All seven components present
  • • Each component has a named owner
  • • Each component has at least one open question
  • • NIST AI RMF or ISO/IEC 42001 mapping applied
  • • Input-not-policy disclaimer present
  • • Sanitized (categories and tool types only)
Loading personalization context…
Lesson40–50 minutes self-guided, or 60–75 minutes with a sponsor working session

What you should take away

By the end of this module, as a program lead or sponsor you will have a structured policy-readiness brief you can hand to legal, security, and HR to seed a formal AI use policy — clearly framed as input to that work, not a replacement for it.

Prerequisites: Complete Module 3 · Complete Module 7

Part 1

Use policy or technology policy? Two sentences, two jobs

These two sentences both appear in 'AI policies', but they answer different questions. Telling them apart is the whole job of this module.

  • Technology policy: 'Approved AI services are the enterprise tiers of Tool X and Tool Y, provisioned through IT with SSO and data-processing terms in place.'
  • Use policy: 'Employees may use approved AI to draft and summarize sanitized internal work; they may not enter regulated or customer data, and any external-facing output requires named human review.'
  • The technology policy governs what is procured and configured. The use policy governs what people may do. A company needs both; this module produces the intake for the use policy.

Quick check · <30 sec

'Customer records may never be pasted into a consumer AI tool' belongs in which policy?

  • A. Technology policy
  • B. Use policy
  • C. Neither
  • D. Both, identically
Show answer
It governs employee behavior with data, so it is a use-policy rule. The technology policy would instead say which tools are procured and how they are configured.

Part 2

The seven components of a workplace AI use policy

A workable use policy has seven components. Most draft policies are strong on the first three and weak on the last four — and the last four are where incidents actually happen. Your readiness brief should have something concrete for all seven.

  • Approved tools and tiers · Sensitive-data rules · Prohibited uses
  • Review and disclosure requirements · Incident response · Vendor management · Training requirements
  • The four commonly-thin ones: review/disclosure, incident response, vendor management, training.
  • Each component should be specific enough that an employee could act on it without asking — or it is not done.

Quick check · <30 sec

Which set of components is most often underdeveloped in draft AI policies?

  • A. Approved tools and sensitive-data rules
  • B. Review/disclosure, incident response, vendor management, training
  • C. Prohibited uses
  • D. The title and scope
Show answer
Policies tend to nail tool lists and data rules but go vague on what to do when something goes wrong, how vendors are vetted, and how people are trained — exactly where real incidents land.

Part 3

Aligning to a recognized framework

You do not need to invent governance from scratch. Two recognized references let legal and security slot your brief into something they already trust. The NIST AI Risk Management Framework organizes work into Govern, Map, Measure, and Manage. ISO/IEC 42001:2023 is the international AI-management-system standard. You are not certifying anything here — you are showing your brief maps to a known structure.

  • NIST AI RMF — Govern (roles, policy), Map (context, risks), Measure (assessment), Manage (response). Map each policy component to one of these.
  • ISO/IEC 42001:2023 — the management-system framing security/legal teams may already recognize for audit alignment.
  • Mapping is for traceability and credibility, not compliance theater. One tag per component is enough.
  • If your org already uses a data-classification scheme, anchor the sensitive-data component to it rather than inventing categories.

Quick check · <30 sec

Under the NIST AI RMF, an incident-response procedure for AI-caused problems maps most naturally to which function?

  • A. Govern
  • B. Map
  • C. Measure
  • D. Manage
Show answer
Manage covers responding to and recovering from identified risks. (Govern would hold the policy/roles; Map identifies risks; Measure assesses them.)

Part 4

Who owns what: coordinating security, legal, and HR

A program lead does not write the policy alone, and should not. The readiness brief's job is to arrive at the table already structured so security, legal, and HR can each act on their part. Name the owner for each component; an unowned component is an unfinished one.

  • Security: approved tools/tiers, data flows, incident response, vendor security review.
  • Legal: contractual terms, regulated-data rules, disclosure obligations, vendor contracts.
  • HR: training requirements, acceptable-use acknowledgement, consequences and support.
  • Program lead: assembles the brief, holds the through-line, schedules the working session — does not adjudicate legal questions.

Quick check · <30 sec

A draft component reads 'we'll figure out disclosure later.' What is the correct fix in the readiness brief?

Show answer
Name the owner and the open question explicitly — e.g., 'Disclosure: OWNER = Legal; OPEN = whether customer-facing AI-assisted content requires a disclosure line.' The brief's value is surfacing and routing open questions, not answering legal ones.

Part 5

Incident response and vendor management — the thin spots

These two components fail most often because they feel hypothetical until they are not. Incident response answers: what does an employee do in the first hour after AI output causes a problem? Vendor management answers: how is a new AI tool evaluated before anyone trusts it? Both should be concrete enough to follow under stress.

  • Incident response: who to tell, what to preserve, what to stop doing, and the no-blame framing that makes people actually report.
  • Vendor management: data handling and training-on-input terms, tier/enterprise controls, security review, and an approval owner — before adoption, not after.
  • A near-miss reported is a healthy signal; design both so reporting is easy and safe.

Quick check · <30 sec

Why design incident response with explicit no-blame framing?

  • A. To reduce paperwork
  • B. Because people only report near-misses if reporting is safe — unreported incidents are the dangerous ones
  • C. To satisfy auditors
  • D. It is optional
Show answer
The incidents you never hear about are the ones that hurt. No-blame framing maximizes reporting, which is the entire point of the component.

Part 6

The readiness brief is input to legal, not a policy

This is the hard line of the module. What you produce is a structured intake that makes legal, security, and HR faster and better — it is explicitly not a policy and not legal advice. Every readiness brief states that on its face. The value is a well-organized starting point, not a shortcut around counsel.

  • The brief is labeled as input to a future policy authored and approved by the appropriate owners.
  • It surfaces open questions and routes them; it does not answer legal or regulatory questions.
  • It is sanitized: it describes data categories and tool types, never real credentials, contracts, or customer data.
  • Sign-off remains with legal/security/HR; the program lead does not approve the policy.
Activity · ~15 minpolicy intake

You are the program lead preparing a policy-readiness brief for a working session with security, legal, and HR. You will run the structured intake. Keep everything at the category level.

  • Scope: Your real org context, described generically (industry, rough size, data types)
  • Rule: Every component gets a named owner and at least one open question

Your task

Walk the seven components and capture, for each: (1) the current state in one sanitized sentence, (2) the owner (Security / Legal / HR / Program lead), (3) the top open question for the working session, and (4) a NIST AI RMF tag (Govern / Map / Measure / Manage). Then write the one-sentence disclaimer that will sit at the top of the brief.

Show a hint
If a component has no open question, you have not interrogated it. Even mature components have an edge case worth raising.
Compare with a strong answer
Approved tools: state = enterprise tier of two tools via SSO; owner = Security; open = do contractors get the same tier?; NIST = Govern. Sensitive data: state = anchored to existing 3-tier data classification; owner = Legal; open = is 'internal-confidential' allowed in approved tools?; NIST = Map. Incident response: state = none yet; owner = Security; open = first-hour steps and no-blame wording; NIST = Manage. ... Disclaimer: 'This brief is structured input to a future AI use policy owned and approved by Legal, Security, and HR; it is not a policy and not legal advice.'

Why this matters: Forcing an owner and an open question per component converts a vague 'we should have a policy' into a concrete, routable agenda — which is the only thing a sponsor can actually act on.

Quick check · <30 sec

True or false: a strong readiness brief can serve as the company's interim AI policy until legal finishes.

  • A. True
  • B. False
Show answer
False. The brief is explicitly input, not a policy. Treating intake as interim policy is exactly the failure this module is designed to prevent.

End-of-module quick check

Five short retrieval questions. Answer from memory first, then reveal each explanation.

  1. 1. A use policy primarily governs…

    • A. Which tools are procured and configured
    • B. What employees may and may not do with AI
    • C. The cloud architecture
    • D. The training budget
    Show answer
    The use policy governs employee behavior. The technology policy governs procurement and configuration. A company needs both.

  2. 2. How many components does the workplace AI use policy have in this module?

    • A. Four
    • B. Five
    • C. Seven
    • D. Ten
    Show answer
    Seven: approved tools/tiers, sensitive-data rules, prohibited uses, review/disclosure, incident response, vendor management, training.

  3. 3. Incident response for AI-caused problems maps to which NIST AI RMF function?

    • A. Govern
    • B. Map
    • C. Measure
    • D. Manage
    Show answer
    Manage — responding to and recovering from identified risks.

  4. 4. True or false: the policy-readiness brief can stand in as an interim policy.

    • A. True
    • B. False
    Show answer
    False. It is explicitly structured input to a legally-owned policy, never a substitute for one.

  5. 5. Which four components are most commonly underdeveloped in draft AI policies?

    Show answer
    Review/disclosure, incident response, vendor management, and training — the ones where real incidents tend to land.

Further reading

Worked examples by role

Software developer

Readiness brief context: a SaaS company

Sensitive-data rule anchored to the existing repo/data classification; prohibited uses forbid proprietary source and secrets in non-approved tiers; vendor management requires training-on-input terms reviewed by Security before any IDE assistant is approved; incident response defines first-hour steps for a leaked-secret scenario. Owners: Security (tools, incident), Legal (vendor terms), HR (training). NIST tags applied per component.

Training manager

Readiness brief context: a professional-services firm

Client-confidential material is the dominant sensitive category; disclosure component addresses whether AI-assisted client deliverables need a disclosure line (open question routed to Legal); training requirement ties to the enablement program completion. Owners named per component; ISO/IEC 42001 referenced because the firm's clients ask about management-system alignment.

Operations manager

Readiness brief context: a regulated-industry operations group

Regulated personal data is in scope, so the sensitive-data component anchors to the existing compliance classification and the prohibited-uses component is the strictest; incident response is heaviest here, with explicit preservation and notification steps; vendor management requires a documented security review. Framed end-to-end as input to Legal and Compliance, not a substitute.

Before / after

Policy-readiness artifact: aspiration vs. routable brief

Before: 'We need an AI policy. It should cover what tools people can use and remind them to be careful with data. Legal will write it up.'

After: Seven components, each with a one-sentence current state, a named owner, a top open question, and a NIST AI RMF tag, under a disclaimer that the brief is input to a legally-owned policy.

What changed: The 'after' can be walked in a 60-minute working session and produces routed actions. The 'before' produces another meeting about having a meeting.

Completion artifact

Submit a sanitized policy-readiness brief covering all seven components, each with a current-state sentence, a named owner, a top open question, and a NIST AI RMF tag, headed by the input-not-policy disclaimer.

ExercisePilot-ready artifact

Produce a sanitized policy-readiness brief for your organization. Walk all seven components. Categories and tool types only — no real contracts, credentials, or customer data.

Participant template

  • Disclaimer (input to a legally-owned policy, not a policy / not legal advice):
  • Org context (industry, rough size, dominant data types — generic):
  • Approved tools & tiers — state / owner / open question / NIST tag:
  • Sensitive-data rules — state / owner / open question / NIST tag:
  • Prohibited uses — state / owner / open question / NIST tag:
  • Review & disclosure — state / owner / open question / NIST tag:
  • Incident response — state / owner / open question / NIST tag:
  • Vendor management — state / owner / open question / NIST tag:
  • Training requirements — state / owner / open question / NIST tag:
  • Top three questions for the security/legal/HR working session:

Example submission

Disclaimer: this brief is input to a future AI use policy owned and approved by Legal, Security, and HR; not a policy, not legal advice. Org: ~250-person professional-services firm; dominant data = client-confidential. Approved tools: enterprise tier of two tools via SSO; owner Security; open = contractor access; NIST Govern. Sensitive data: anchored to existing classification; owner Legal; open = is internal-confidential allowed in approved tier; NIST Map. Prohibited uses: client-confidential into consumer tools; owner Legal; NIST Map. Review/disclosure: client deliverables need named reviewer; open = disclosure line?; owner Legal; NIST Govern. Incident response: none yet; owner Security; open = first-hour steps + no-blame wording; NIST Manage. Vendor management: open = training-on-input terms; owner Security; NIST Map. Training: tied to enablement completion; owner HR; NIST Govern. Top session questions: contractor tiering, disclosure obligation, incident first-hour playbook.

Role-flavored variants

Same exercise, framed for different roles. Use the one closest to your work.

Front office coordinator

Frame for an administrative function inside a regulated-adjacent org. The sensitive-data and prohibited-uses components should be the most developed; anchor sensitive data to an existing classification scheme rather than inventing one.

See a sample submission
Regulated-adjacent admin brief (excerpt): Sensitive data: anchored to the existing 3-tier classification; tier-3 (regulated personal) prohibited in all external tools; owner = Legal; open = is tier-2 allowed in the approved enterprise tier?; NIST = Map. Incident response: owner = Security; open = first-hour preservation steps; NIST = Manage. Disclaimer present.

Sales coordinator

Frame for a customer-data-heavy commercial org. The review/disclosure component must address customer-facing AI-assisted content; vendor management must address CRM-integrated AI tools.

See a sample submission
Commercial org brief (excerpt): Review & disclosure: state = none; owner = Legal; open = does AI-assisted customer-facing copy need a disclosure line and named human reviewer?; NIST = Govern. Vendor management: open = training-on-input terms for the CRM's AI add-on; owner = Security; NIST = Map. Disclaimer present; sanitized throughout.

Learner checklist

Use this as a final check before submitting. Program leads use a separate review guide when they approve or coach submissions.

  • • All seven components present
  • • Each component has a named owner
  • • Each component has at least one open question
  • • NIST AI RMF or ISO/IEC 42001 mapping applied
  • • Input-not-policy disclaimer present
  • • Sanitized (categories and tool types only)
Loading your module status…

Previous module

← Team adoption and working agreement

Review the prior step in the path.

Next module

Advanced AI-assisted software delivery →

Keep momentum with the next completion check.