Governance for small teams: one page per AI use case instead of corporate formalism

A small organisation does not have to choose between two poor pictures. The first says that using generative AI becomes responsible only with a large governance programme, a committee, a policy manual, and specialist software. The second says that a text generator is merely a writing tool and therefore needs no special decision. Neither picture fits working life. A five-person business cannot reproduce corporate formalism. It can, however, decide what a specific service is used for, what information may enter it, who reviews a draft, who can raise an objection, and when the trial ends.

This article proposes a small, visible form for doing so: one Use-Case-Card per AI use case. It is not a general permission for a tool or a label for “ethical AI”. It is a short working agreement for one precisely bounded activity. The focus is a wholly fictional case: a small building-services business considers using generative AI for first drafts of internal work reports. Only general, non-personal work notes may be used as input. Before a report enters the business record, a responsible person reviews and edits it. The AI sends nothing, makes no decision about people, and is not treated as a source of facts.

The case is deliberately unremarkable. Habits arise precisely where an activity appears minor: a note is copied too broadly, a draft is adopted too quickly, or review is skipped for lack of time. Good governance does not prevent every wrong decision. It makes the decision, the control, and the stopping point concrete enough for a small team to carry them out in daily work.

The starting point: not permission for a tool, but a question about an action

The question is not, “May we use this AI tool?” A service can be suitable for a harmless writing sketch and unsuitable for processing a customer record. The card therefore begins with a sentence in this form: “For [clearly described task], [clearly described role] may use [clearly described data zone], provided that [review and limits] are met.”

For the fictional building-services business, the sentence could be:

For the first draft of an internal work report, operations may use an approved generative text system with general, non-personal work notes, provided that a competent person reviews, corrects, and approves every draft before it is filed as a work report.

That sentence already leaves important questions open: What counts as “general”? Who is competent? What happens when notes conflict? This openness is not a defect. The card need not guess every possible risk. It must mark the points at which the team decides or stops.

A non-AI way of working therefore belongs on the same card. In the example, operations writes the report from a standard template or has a colleague proofread it. This comparison is not a symbolic duty. Without a realistic alternative, “time savings” quickly becomes a mere assertion. Before the Pilot, the team should record which work actually disappears and which work is added: cleaning notes, reviewing output, correcting errors, and filing the version. If review takes more time than a good template, choosing not to use AI is a sensible result.

The fictional case: drafts, not automatic records

The fictional building-services business maintains smaller commercial properties. After a visit, the responsible specialist may note: “Filter replaced; visual inspection completed; material stock checked; next appointment according to plan.” These notes are to become an internal report that clearly records completed work and open points.

Names, contact details, access codes, precise property addresses, photographs, free-form customer messages, employee information, health data, disputes, and contract documents must not be entered. Nor should the system invent facts, interpret deadlines, bill services, or place a report in a customer portal itself. These limits do not follow from a claim that the service is “safe”. They follow from a chosen task boundary: generic notes are sufficient for a generic draft.

A plausible workflow looks like this:

1. Operations transfers the permitted notes into a defined input form. 2. The system produces a draft in an internal structure: work completed, open points, unresolved information. 3. A named reviewing specialist compares every statement with the notes and deletes or adds material. 4. Only the reviewed version is filed as an internal report. The draft does not accidentally remain the authoritative record. 5. When something is unclear, nobody keeps prompting until something plausible appears. The specialist clarifies the matter with the responsible person or records it as open.

The workflow does not take responsibility away from the AI; it never had it. It assigns responsibility to people and roles. The person who creates the note is responsible for its technical basis. The reviewer is responsible for releasing the report. Management is responsible for whether the bounded use continues at all. A person who notices an error needs a way to report it without first having to prove that an algorithm caused it.

Data zones: keep them small and make them visible

“No sensitive data” is too imprecise for daily work. Small teams work better with a few data zones and clear examples. Four zones are enough for this case:

The zones do not replace a data-protection analysis or contract review. They are a practical preliminary sorting step. Their strength is that they apply before input: a person can recognise “red” before copying a text. Their limit is equally clear: a seemingly general sentence can be identifiable in context. The rule “if in doubt, do not enter it; clarify first” therefore matters more than the illusion of a complete list.

The card should also record what happens to drafts. Is the Prompt logged? Are outputs stored by the provider? Are there administrative or training settings? Which internal retention period applies? These questions change with the contract, configuration, and provider. A card must therefore not turn one day’s state into permanent approval.

A philosophical lens: responsibility is shared, not diluted

In Responsibility for Justice, Iris Marion Young describes a social connection model. It directs attention to structural relationships: harm and unfair consequences often arise through many ordinary actions, rules, and divisions of labour; responsibility is then not exhausted by looking backwards for one guilty person. As a lens for the fictional AI use case, it helps pose a different question. Not: “Who is at fault when the text generator makes a mistake?” But: “Which roles, incentives, and routines connect us to the possibility of this mistake, and what can we change about them?”

This is not validation of the proposed model by Young. Her theory supplies neither a Use-Case-Card nor an approval formula. It does, however, prevent two evasions. One says that the AI acted, so nobody is responsible. The other says that only the final reviewer is responsible, even though other people set data rules, time targets, procurement, and filing arrangements. The social connection distributes duties by role and influence without leaving them vague.

For the fictional business, this means management must not require review while providing no time for it. Operations must not be left alone with a vague data rule. The reviewing specialist must be able to ask a critical follow-up question without being treated as an obstacle. An affected person or colleague must be able to report errors and objections. Shared responsibility means that each role has a concrete, achievable task; no role can hand its task away by referring to the tool.

This lens also reveals a conflict of aims. Faster reports may improve internal overview and free time for technical work. More review costs time, and small businesses have little of it. Yet time pressure is not neutral when management receives the economic benefit while the risks of wrong documentation remain with customers, employees, or individual reviewers. A bounded Pilot with an understandable stopping rule is therefore not bureaucratic decoration. It makes this distribution visible and open to change.

K as the core: four steps that support a card

K is the central, user-developed consultation and Governance model in this article. Its core cycle has four steps: Exploration → Reflection/Analysis → Decision/Recommendation → Feedback/Evaluation. It is neither a certified control system nor proof that a decision is ethically or legally correct. It creates a repeatable form for discussion and decision.

In Exploration, the team should demystify terms. A “work report” can be a purely internal reminder or a basis for invoices, liability questions, and customer communication. The card question must name the actual route of use. In the fictional Pilot, only the internal draft is expressly permitted. If a report is later used for an invoice, contract, or dispute clarification, a new assessment begins; the old card does not extend to it.

Reflection/Analysis contains no calculation that weighs values against one another. It does require the strongest counter-position to be stated fairly: small teams can scarcely afford long debates and duplicate documentation. Making every writing aid carry extensive records either encourages abstention or hidden, shadow use. This criticism makes a real point. A card that no one reads and that exists only for appearances worsens practice.

The answer cannot be to omit review. Documentation must serve a decision that occurs in the work process. One page per use case contains only the information a role needs in order to act. It does not replace a committee with a miniature imitation. In a small team it often names the same people in several roles. What matters is not an impressive organisation chart, but that “procure the tool”, “approve input”, “review output”, and “stop in a conflict” do not collapse invisibly into one another.

The Decision/Recommendation in the case is not “AI permitted”. It could be: a six-week Pilot, at most ten report drafts per week, Green data only, no external communication, always specialist review, and a short weekly review meeting. Management provides time for review. Operations may stop when uncertain. The reviewing specialist may reject a draft. A named contact role collects objections from employees. These rules are reviewable because they are concrete.

Feedback/Evaluation asks about use, not abstract “AI quality”. Were the data zones observed? How many statements needed correction, and what kind of errors were they? Did reviewers actually read the draft or merely confirm it? Was a rule bypassed because it was impractical? Did the time saving plausibly outweigh the added review? A small error count alone does not answer this, but it can prompt professional review. The team records counterexamples and complaints as well as successful drafts.

Separate: the five-step K case-scenario extension

For more detailed case work, K has a five-step scenario extension: Exploration, Reflection, Decision, Implementation/Pilot, Final Evaluation/Optimisation. It is not the four-step core. Its extra value is that starting a trial and carrying out final review become distinct work stages.

In building services, the extension separates decision from the Pilot. First the team sets data zones, review steps, access, and stop rules; then it tries the workflow under those conditions. Final evaluation decides whether the card is changed, the Pilot is extended, or the use ends. The separation prevents “let’s try it” from becoming silent permanent approval.

The Use-Case-Card: one page used in daily work

The following structure fits on one page. It is deliberately neither a template for every organisation nor a complete checklist for every jurisdiction. It is a working object for a bounded decision.

Use-Case-Card UCC-01: internal report drafts (fictional example)

The card must be accessible: where input is prepared and in a version employees understand. One person may change it, but changes require a date, reason, and renewed approval. Otherwise, after a provider update or quiet process change, an old card becomes false reassurance.

The log is deliberately narrow. It should explain which workflow ran in which version and what happened to the draft. It should not create a shadow archive of Prompts, staff behaviour, or customer data. “What must we know to understand an error?” is a better question than “What can we record?”

Objection, feedback, and decision-making power

For small teams, an objection channel need not be anonymous or technically elaborate; it must be reachable and usable without adverse consequences. In the fictional business, every employee may report an error or concern to operations, the reviewing specialist, or a designated contact role. The report receives a date, short description, and a decision: pause immediately, handle at the next review, or refer as a specialist question. A person responsible for the workflow may not declare their own decision settled alone when the report concerns the quality of their review. Management decides on continuation and resources, but not on the technical correctness of an individual report.

External affected persons likewise need no access to the tool to be heard. If a customer later finds an error in a filed report, the report is corrected as a work product, the cause is examined, and the Pilot card is reassessed if appropriate. The procedure promises no conflict-free solution; it prevents feedback from being lost between a “technical problem” and a “human error”. A team should also record which feedback leads to immediate correction, which triggers a pattern review, and who decides to end the Pilot. This makes the right to object a work task rather than a friendly footnote.