Section 1
Convert each principle into a default
Take the usual principles and force each one into something a system does or refuses to do. Fairness becomes: outcomes are sliced by group on a schedule, and a widening gap blocks the next release. Transparency becomes: every customer-facing automation opens by saying what it is and how to reach a person. Privacy becomes: identifiers are stripped before the model call by default, and including them requires a documented reason. Human oversight becomes: this list of decisions cannot be executed without a named approver, enforced in permissions rather than in a wiki. If a principle cannot be expressed as a default, a permission, a test, or a log, it will not survive a busy quarter.
Section 2
Keep a register, or you are guessing
You cannot govern a set of systems you cannot enumerate. The single highest-yield artefact in a small company is a register of every live automation with seven fields: what it does, what data it touches, what it can change without a human, who owns it, what it must never decide alone, when it was last reviewed, and how to turn it off. Make the register a gate. Nothing goes live without a row. This sounds bureaucratic and takes about ten minutes per system. The alternative is discovering, during an incident, that an automation built by someone who has since left is writing to your billing system. Review the register monthly and retire aggressively. Automations accumulate advocates while they are new and lose them over time, so nobody proposes shutting one down unless the process forces the question.
Section 3
Practices that hold under pressure
Ground rather than recall. Where a system states facts about your business, have it quote retrieved documents instead of relying on model memory. This removes a large share of confident errors at a stroke. Pin versions. Silent model updates change behaviour. Pin what you can, monitor what you cannot, and re-run your evaluation set after any change. Build the evaluation set from real cases, including the awkward ones you would rather forget. Twenty real examples with known correct answers is worth more than a benchmark score. Cap actions, not conversation. Let systems draft widely and act narrowly. Design the abstention. Every system needs a way to say it does not know, and a route for what happens next. Content systems have their own version of this discipline: [AI-Powered Content Generation: Tools and Best Practices](/blog/ai-powered-content-generation-tools-and-best-practices).
Section 4
Incidents, before you have one
Responsible practice is largely about what happens on a bad day. Decide now, while nothing is on fire, who has authority to stop a system, how they do it without a deployment, who is told, and within what time. Write the customer notification path down. If an automation sent wrong information to a hundred people, you want a decision tree, not an improvised committee. Then run a post-mortem format that asks about the system rather than the person. What made the failure possible, what made it invisible, what would have caught it, and what changes as a result. Log the answer somewhere the next person will find it.
Section 5
Governance sized for a small company
NIST frames AI risk management around trustworthiness, design, evaluation, and use. The useful reading for a team of twenty is that governance is a set of repeatable actions, not a committee. The minimum viable version: one owner per automation, one register, one release checklist, one monthly review, one incident path, one evaluation set per system. That fits on a page and it survives growth better than a policy nobody reads. Name the failure modes you are accepting, in writing, and where the costs land, including the roles affected, which [AI Automation and Job Displacement: What Founders Should Know](/blog/ai-automation-and-job-displacement-what-founders-should-know) covers. Being explicit that you have chosen to accept a small error rate in a low-stakes summariser is responsible. Being silent about it is how a known limitation becomes a surprise.
Section 6
What to measure
Register completeness. The age of the oldest unreviewed automation. Reviewer override rate and the reasons behind it. Evaluation pass rate after each model or prompt change. Incident count and time to containment. The number of systems with an untested kill switch, which should be zero. The honest test of a responsible AI programme is whether anything has ever been blocked, delayed, or switched off because of it. A programme that has never said no to anything is a programme that has never been consulted. Communicating all of this without overstating it is its own discipline: see [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation).