- An honest survey of the AI tools people already use, including personal accounts — expect surprises
- Each tool's current terms on data retention and training-on-inputs, read rather than assumed
- A data classification, even a rough one: what counts as CUI, export-controlled, or customer-sensitive
ATL-029WORKSHEETEDITORIAL REVIEW COMPLETE
AI Use-Case and Data-Handling Worksheet
A register of every AI tool and use case actually in play — with data classes, account models, vendor retention terms, approvals, and exception expiries — anchored by one standing prohibition: CUI and export-controlled data go into no tool that has not been explicitly approved for them.
Using this artifact
Purpose, inputs, and completion
Purpose. AI tools are already in your building, whether or not anyone approved them — and the risk is not the tools but the data walking into them. This worksheet registers every tool and use case in actual play, records what each vendor does with inputs, and draws one bright line: sensitive defense information goes only where it has been explicitly approved to go. The register replaces a policy nobody reads with a page everybody can check.
When to use it. Start with an amnesty-flavored survey — the goal of the first pass is truth, not enforcement, because a register missing the unofficial tools manages nothing. Then work the rows: settle the account model, read the vendor terms with a date, and record an approval, conditions, or a migration path with an exception expiry. Review quarterly and at every new tool request, running section two's checklist before any new tool earns a row.
- Register what is actually in use first, including personal accounts; a register of only sanctioned tools is a wish list.
- Record the account model per tool — SSO with MFA under company control, or personal accounts you can neither see nor revoke.
- Read each tool's retention and training-on-inputs terms and record what they say today, with the date you read them — terms change quietly.
- Hold the NEVER line: CUI and export-controlled data go into no tool not explicitly approved for that data class — no exceptions by convenience.
- Give every exception an expiry date; an exception without an expiry is a policy you did not mean to write.
Keeping it honest
Evidence, validation, and failure modes
- A dated register of AI tools, use cases, and data classes in actual use
- Recorded vendor terms (retention, training-on-inputs) per tool with read dates
- An exception list with expiry dates and owners
- Compare the register against the identity provider's application sign-in report and recent expense reports; tools appearing there but not here are the finding.
- Pick one approved tool and re-read its current terms; if they no longer match the register, the review cycle is not operating.
What looks done but is not
- The register lists sanctioned tools while the actual usage — personal accounts pasting into free tiers — stays invisible and unmanaged.
- 'Approved' is recorded without data-class limits, and approval for meeting notes is read as approval for everything.
- Vendor terms are recorded once; a quiet terms change flips training-on-inputs from off to on and nobody notices for a year.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain superseded registers; the record of what was approved when — and which exceptions expired on schedule — is the story of AI adoption a reviewer will want told.
Full document
Preview — exactly what prints
WORKSHEET · SECURE DEVELOPMENT & AIv1.0 · REVIEWED 2026-08-06
AI Use-Case and Data-Handling Worksheet
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
AI tools are already in your building, whether or not anyone approved them — and the risk is not the tools but the data walking into them. This worksheet registers every tool and use case in actual play, records what each vendor does with inputs, and draws one bright line: sensitive defense information goes only where it has been explicitly approved to go. The register replaces a policy nobody reads with a page everybody can check.
How to use it
Start with an amnesty-flavored survey — the goal of the first pass is truth, not enforcement, because a register missing the unofficial tools manages nothing. Then work the rows: settle the account model, read the vendor terms with a date, and record an approval, conditions, or a migration path with an exception expiry. Review quarterly and at every new tool request, running section two's checklist before any new tool earns a row.
Use-case register
One row per tool and use case. The NEVER row is permanent — it is the line the rest of the register exists to defend.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Tool | Use case | Who uses it | Data classes involved | Account model (SSO / MFA?) | Retention / training-on-inputs terms | Approved? / conditions | Exception expiry | Owner |
|---|---|---|---|---|---|---|---|---|
| NEVER: CUI or export-controlled data in any tool not explicitly approved for that data class | Standing prohibition — applies to every row and every tool | Everyone | CUI / export-controlled | — | — | No exceptions by convenience; approval for these classes is an explicit, documented decision | None | Executive sponsor |
| EXAMPLE: Business AI assistant (company tenant) | Drafting proposals; summarizing internal, non-sensitive documents | Office staff (14) | Internal business only — no CUI, no export-controlled | SSO + MFA, company tenant | Enterprise terms: no training on inputs; 30-day retention — read 2026-07-10 | Approved with data-class limits | — | IT leader |
| EXAMPLE: Free-tier code assistant (personal accounts) | Snippet help on internal tooling | Two developers | Internal source code | Personal accounts — no company control | Free-tier terms permit training on inputs — read 2026-07-10 | Not approved — migrating to company tenant | Exception ends 2026-09-30 | Engineering lead |
New-tool review checklist
Run this before any new AI tool earns a register row. Every unanswerable question is itself an answer.
Questions to settle before approval
- Where do inputs go?
- Which vendor, which jurisdiction, which subprocessors — and does the tier you are buying differ from the free tier everyone tried first?
- Are inputs used to train models?
- Find the sentence in the current terms, quote it in the register, and date it. 'Probably not' is not a sentence in the terms.
- Is our data isolated from other tenants?
- Can anything entered by your users surface, in any form, to another customer?
- Is there an audit log an admin can read?
- Someone must be able to answer 'who put what in?' after the fact — without that, the data-class limits are unenforceable.
- What happens at offboarding?
- Deletion of your data on exit, committed in writing — not a support ticket you hope ages well.
- What account model will we run?
- SSO with MFA under company control, or it does not get company data — personal accounts cannot be revoked when someone leaves.
Exceptions and expiry
Exceptions are honest admissions that migration takes time. Each one carries conditions, an owner, and an expiry that is enforced — an expired exception is a decision due, not a date to move.
Exception record
| Exception (tool and usage) | Why granted | Conditions while open | Expiry date | Owner |
|---|---|---|---|---|
Expiry is the mechanism
The difference between an exception and a shadow policy is the expiry date. On the date, the exception either closes because the migration finished, or it is re-decided in writing by the same authority that granted it — silence is not renewal.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader |
| Approval authority | Executive sponsor |
| Review frequency | Quarterly, and at every new tool request or vendor terms change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain superseded registers; the record of what was approved when — and which exceptions expired on schedule — is the story of AI adoption a reviewer will want told. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.