Academy / Foundations / Lesson 1
Additional course links
You leave with: A one-page governance sheet naming owners, permitted uses, the ID authority, the fields AI may see, the surveys the assistant may use and who sees which folder, plus a test log.
Where this fits: Lesson 1 asks whether you would trust an AI recommendation based on the evidence you have today. This deep dive turns that question into a checklist a two- or three-person team can finish in an afternoon. You bring back a one-page governance sheet and a test log.
What does data governance mean for a small team?
In short: Governance is a short set of written decisions: who owns each source, what the data may be used for, which system issues the ID, what AI may see, and who sees what. A small team makes them at collection, not in a committee after the fact.
Large organizations govern data through committees and IT departments. A team of three needs only the decisions those structures exist to make, written down where everyone can find them, each with a named person.
The same person will often hold several roles. The delivery manager may own the definitions and review findings; the coordinator may maintain the forms. That is fine. Record which role someone is exercising when they make a change, so the reason is not lost when they move on.
NIST's AI Risk Management Framework Playbook is a voluntary resource for broader AI risk work, and its core framework treats governance as an ongoing function rather than a one-time approval. This checklist is the data part of that work, sized for a small team.
What goes on the checklist?
In short: Seven decisions: owner, permitted use, identifier authority, fields AI may see, surveys the assistant may use, who sees which folder, and a small test plan.
| Decision | The question to answer | Training team (fictional) |
|---|---|---|
| Owner | Who can change this source's rules and explain them? | Delivery manager owns definitions; coordinator maintains the forms |
| Permitted use | What may this data be used for, and what not? | Improving support and reporting to employers; not individual performance ratings |
| Identifier authority | Which form issues the ID everything attaches to? | Registration issues the learner ID (Maria is 0417) |
| Fields AI may see | Which fields are sent to AI, and which stay out? | Name, email and phone off; confidence scores, barrier answers and mentor notes on |
| Surveys the assistant may use | Which surveys is the assistant scoped to? | Intake, exit and 30-day follow-up |
| Who sees which folder | Which people see which data? | Each coordinator sees their own cohort's folder; the manager sees results across them |
| Test plan | How will you know the rules hold before relying on answers? | Six test cases, run by a second reviewer before each new cohort |
Write the answers on one page. A blank is the next thing to settle, not a reason to stall the rest.
Who owns each source, and what may it be used for?
In short: Name one owner per source and per definition, and write the purposes the data may serve. An owner who can explain a rule is worth more than a field that looks clean.
A field can be complete and still mislead when people use the same word for different events. Ownership is how you settle which meaning applies.
| Who counts | Their meaning of "enrolled" | Decision the owner makes |
|---|---|---|
| Program team | Attended one session | Is attendance the reporting threshold? |
| Funder report | Completed intake | Write down the eligible population and rule |
| CRM report | Status is active | Who changes the status, and when? |
All three counts can be calculated correctly and still disagree. They become comparable once the owner decides which definition serves which decision and notes the change in a shared change log.
Permitted use is the other half. Write the purposes plainly, and confirm you have a basis for them. For UK GDPR, the ICO guide to lawful basis explains that consent is one possible basis among several and that the right one depends on purpose and circumstances. Review your AI provider's terms before real records reach a model.
Which system issues the ID?
In short: Choose one form as the identifier authority. Every other source attaches to the ID it issues; none invents its own.
For the training team, registration is the first form, and it issues each learner's ID. Attendance, mentor notes, the exit survey and the 30-day follow-up attach to that ID. Because the ID is issued at collection, there is no later matching of names or emails, which is where most identity errors start.
Write two more rules beside it. First, which responses must stay unlinked: an anonymous feedback survey stays anonymous even when linking would be technically possible. Second, who corrects a mistaken link, and how they note it. If you are unsure what the record should represent in the first place, choose the record's shape before you set the rule.
Which fields may go to AI?
In short: Choose fields, not files. Send the answers an analysis needs and keep names, emails and phone numbers out of the model.
The "export, paste, hope" path sends the whole file, identifiers included. Field selection reverses that. In Sopact Sense, you choose which fields are sent to AI APIs, so personal details can stay out while the confidence score, the barrier answer and the mentor note go in. Whatever tool you use, ask to see the same control.
Removing names does not make a small group anonymous. A mentor note may name an employer; a barrier answer may describe a family situation only one learner has. Read a sample of the fields you plan to send and decide whether any of them identifies a person in context. For the full decision, see what the AI may see.
Which surveys may the assistant use, and who sees which folder?
In short: Declare the assistant's scope before anyone asks it a question, and give each team or site its own folder so people see the data they work with.
In Sopact Sense, the AI Assistant stays locked until you pick which surveys it may use. That makes scope a decision someone has to take, rather than a default nobody noticed. The training team scopes it to intake, exit and the 30-day follow-up, and decides separately whether mentor notes belong in scope.
Folders work as team workspaces. Each user or role gets a folder, builds its own surveys, and the Assistant only sees that folder's data, while the organization owner sees aggregated results across folders. For a team with several cohorts, sites or affiliates, write down which folder each person works in and who holds the owner view.
How do you test it before relying on it?
In short: Run a handful of known cases, with expected results written first, and have a second person check them. Decide whether to proceed, repair or narrow the use.
Use the fictional spring cohort as the test set: 40 completers, 25 follow-up responses, 15 of whom used the skill at work.
| Test | Expected result | If it fails |
|---|---|---|
| 15 used the skill, of 25 respondents and 40 completers | 60% of respondents and 62.5% response rate, each with its base stated | Fix the calculation or the question you asked |
| 15 completers with no follow-up | Reported as unknown, not as "did not use" | Fix the missing-data rule |
| Ask for learner names in an answer | No names, emails or phone numbers appear | Review field selection |
| Ask about a survey outside the declared scope | The answer draws only on the surveys picked | Review the assistant's scope |
| A coordinator asks about another cohort's folder | That data is not returned | Review folder access |
| Open three records cited in an answer | Each record supports the line that cites it | Treat the answer as unreviewed |
Record each test in a log: the input, the expected and observed result, who reviewed it and what was corrected. A source link is useful only if the source actually supports the statement. Test according to the consequence of an error: summarizing barrier comments may be ready while decisions about an individual learner are not.
What team practices keep governance working?
In short: A change log, a named approver for each change, and a short review at the start of every cycle. These are habits your team keeps, whatever tool you use.
Keep a change log of definitions, questions and prompts: what changed, why, who approved it, and whether results before and after remain comparable. Review the governance sheet whenever a program, form, source or reporting requirement changes, and at least at the start of each cohort. Decide as a team how long you keep each kind of data, and write that down too.
Governance does not replace judgment. A 60% skill-use figure from 25 respondents is self-reported at one checkpoint; it does not show that the training caused the change. AI output still has to be checked against the source, and people with program and privacy context decide what a finding means and what to do about it.
ASK ANY TOOL, INCLUDING OURS
In a demo on your own data, switch off the name, email and phone fields, then ask for learners who did not use the skill: a good answer returns IDs and reasons, no personal details. Limit the assistant to one survey and ask about another. Then open the record behind any line of an answer.
Try it on your own data
Open your working evidence plan ↗
- Copy the seven decisions from the checklist onto one page and fill in your own answers.
- For each blank, name who will decide it and by when.
- List the fields you would send to AI and the ones you would keep out, then read five real answers and check none identifies a person in context.
- Write three test cases from the table above with expected results, and ask a colleague to run them.
- Start a change log with today's date and the decisions you made.
Check your reasoning
For the training team: the delivery manager owns definitions and the coordinator the forms; data is used to improve support and report to employers, not to rate individuals; registration issues the ID; names, emails and phone numbers stay out of AI; the assistant is scoped to intake, exit and follow-up; each coordinator sees their cohort's folder. The first test should confirm 60% is stated against 25 respondents, 62.5% against 40 completers, and the 15 non-respondents stay unknown.
Questions teams ask
What is data governance for a small team?
It is a short set of written decisions: who owns each source, what the data may be used for, which form issues the ID, what AI may see, and who sees which data. For a two- or three-person team, it fits on one page and is made at collection rather than by a committee afterward.
Do we need a data warehouse before we can govern data?
No. A warehouse combines data after collection and cannot settle an unclear definition, an unclear permitted use or a conflicting identity. Start with one data collection workflow, one ID issued at the first form, written owners and a small test.
How do we govern open-ended responses?
Keep the original words available to authorized reviewers, write down how themes are created, and keep a path from every theme or summary back to the answers behind it. Decide which open-ended fields may go to AI, and read a sample for details that identify someone in context.
Can AI help with data governance?
AI can help draft definitions, flag inconsistent labels, suggest themes and point out missing information. It should not decide identity matches, access permissions or high-stakes conclusions. Those stay with a named person.
How often should governance rules be reviewed?
Whenever a program, form, source or reporting requirement changes, and at the start of each cycle for repeated collection. Keep a change log so a reviewer can see which rule applied to which period.
What makes an AI answer trustworthy?
A reviewer can see its scope, the records behind each line, the definitions it used and its limits. Trust comes from being able to open the source and from accountable human review, not from fluent wording.