Five questions an owner answers about every AI system before it goes live.
The gap
Open any AI governance content: the NIST AI Risk Management Framework, ISO 42001, the cheat sheets, the roles maps. All of it assumes a governance function exists. Someone owns the register. Someone runs the committee. Someone writes the policy.
A 20-person startup has none of that. It has a founder, a CTO, and a deal that just stalled on a security questionnaire. What it needs is not an enterprise framework at one-tenth scale. It needs five questions it can answer about every AI system before that system goes live, and enough evidence to prove the answers were real.
Governance is real when you can produce the decision, the evidence, the owner and the stop condition before a customer, an auditor or an incident forces the question.
The five questions
Ask them about every AI system: the product features, the internal copilots, the agents. If a system cannot get five real answers, it is not governed. It is only described. Each answer produces one record; five questions produce the whole system.
One named person owns the outcome. "Engineering" is not an owner. "The AI team" is not an owner. If two people own it, nobody does. The owner approves release, accepts the residual risk, and gets woken up when it breaks.
producesOne named owner in the AI inventory.
List what the system is built from and what it can reach: models, retrieval and training data, tools, APIs, other agents. The OWASP AIBOM Foundations Guide (v1.0, September 2026) makes the same point from the supply-chain side: an AI system is not just code, so a software bill of materials alone cannot describe it. You cannot bound what you cannot list. Then the named owner approves the access, in writing, at least privilege: the least data, permissions, tools and transaction value the job needs.
producesThe access and tool list, with the approver’s name.
Define acceptance tests and monitored indicators before launch, not after the first incident. Log decisions, overrides, drift and near misses. The test: what evidence would convince a skeptical customer that this system is controlled today, not at launch?
producesAcceptance tests and monitored indicators, defined before launch.
Someone can stop the system before it acts again, and the mechanism sits outside the model. A prompt that says "do not do X" is not a stop condition. Deterministic authorization, an approval gate or a kill switch is. Name the person. Test the switch.
producesA tested stop mechanism outside the model, and the person who owns it.
When the system hurts a customer or a deal, a named person owns the incident: containment, rollback, the customer answer, the regulator answer if one is needed. Rehearse it once. An untested incident path is a hope, not a control.
producesA rehearsed incident path with a named owner.
Agents raise the stakes
When the system can act, output quality is only half the risk. The other half is what it can do with a bad instruction or a false belief.
ENISA’s Technical Advisory on AI-assisted software development (September 2026, still a formal draft at v0.4) states it plainly: functional correctness should not be confused with security. Code an agent writes can work exactly as asked and still ship vulnerabilities. The same advisory describes coding agents that inspect repositories, run commands, install dependencies and prepare pull requests. That is authority, and authority needs boundaries.
Identity is the other boundary. NIST IR 8587, finalized in September 2026 with CISA, is a full interagency report on one problem: keeping identity tokens and assertions from being forged, stolen or misused. When NIST and CISA need an entire report for token protection, “the agent acts under a real, scoped identity” is engineering work, not a checkbox.
❯ What is the maximum blast radius of one compromised instruction?
❯ Can the agent act on content supplied by the same party affected by the action?
❯ Can the system fabricate or ingest an “approval” as plain text?
❯ Can operators stop, roll back and reconstruct the action chain?
Three tiers, not one control stack
Match the weight of control to the consequence of failure. Apply the stricter tier whenever the signals conflict.
T1
Typical use
Drafting, summarization, internal search
Signal
Human checks output; easy reversal
Minimum decision
Owner approval and inventory entry
T2
Typical use
Customer support, code, recommendations, workflow decisions
Signal
External impact, sensitive data, reliance at scale
Minimum decision
Risk register, release evidence, monitoring
T3
Typical use
Eligibility, money, safety, agents that transact or change systems
Signal
Rights or safety impact, privileged tools, limited human recovery
Minimum decision
Leadership acceptance, independent testing, explicit stop authority
No low-risk shortcut. Tier 1 means a smaller control set, not no control set. Inventory, ownership, approved data use and human checking still apply.
Five records carry the system
A startup does not need forty templates. It needs five living records with evidence attached, kept where the team already works. The five questions produce them.
❯ ls records/
01 ai-inventory # every material use case, its named owner, its tier, what it touches
02 risk-register # cause, event, impact - scored before and after controls, owner, review date
03 decision-log # what was approved, by whom, on what evidence, residual risk
04 vendor-access # what external models may do with your data, who approved that access
05 test-incidents # acceptance tests, monitored indicators, overrides, incidents, near misses
5 files, 0 templates. total: the whole system.
How it runs
One monthly review, 45 minutes: new and changed use cases, top risks, monitor breaches, vendor changes, decisions and owners. Everything else is event-driven. A new use case, a new data source or supplier, a release, or a material change reopens the questions. No committees.
Where this sits against the standards
The Pre-flight is an operating translation, not a claim of equivalence or conformity. ISO 42001 builds a management system. The NIST AI RMF runs a Govern-Map-Measure-Manage lifecycle. Both assume someone has time to run them. This framework is what a small company does before that someone exists, and the records it creates are the same evidence a certification effort will ask for later. The EU AI Act and sector rules can add legal duties; this framework flags where to look and does not determine them.
Monday morning
Block one working session this week. Ninety minutes, the founder and the CTO.
List every AI system that is live, in pilot, or quietly used by employees. Shadow AI is an inventory failure, not a discipline problem.
Ask the five questions about each one. Write the answers down. That is your first inventory and your first decision log.
Where answers live in people’s heads, assign the named owner. Where nobody can answer question 4, pause that system’s autonomy until the boundary exists.
That session is the framework running. Everything after it is iteration.
Do not start here. Do not begin with a 40-page AI policy, a steering committee charter or a certification claim. Start with the live systems, the real decisions and the missing evidence.
Sources