Board oversight of autonomous systems that can cause physical harm
A board can review an AI governance policy annually and still be unable to answer the question that matters after an incident: who was responsible for the parameters that were in effect at the time, and what did they know?
What changes when an autonomous system can cause physical harm?
The question stops being about data and starts being about whether a named person owned the safety envelope. Investigators look for who set the limits, who was told when they were exceeded, and who had the authority to stop it — and most governance records answer none of those.
- Oversight duties are generally assessed by whether a monitoring system existed and functioned, not by outcomes.
- For systems with physical consequences, the operative records are about safety parameters: who set them, when, and on what basis.
- A board's practical question is whether it can obtain those records on demand, rather than whether a policy exists.
Part of AI oversight and regulation
What oversight duties generally require
Across jurisdictions, directors' oversight obligations tend to be framed around process rather than outcome: whether the board established a system to surface material risks, and whether it attended to what that system reported.
A board is not usually expected to prevent every failure. It is expected to be able to show that it had a mechanism and used it.
Why physical systems change the calculus
| Dimension | Data-affecting system | Physically-affecting system |
|---|---|---|
| Worst outcome | Breach, regulatory penalty, remediation | Injury or death |
| Reversibility | Partial | None |
| Investigating authority | Privacy and sector regulators | Safety regulators, potentially prosecutors |
| Personal exposure for executives | Rare | Possible in some jurisdictions |
| Evidence examined | Policies, logs, breach response | Safety parameters and who set them |
The last row is where governance practice is thinnest. Boards review AI policies; safety investigators ask who authorised the operating envelope in effect at 14:22 on the day of the incident.
The records an investigation will look for
- The safety parameters in effect at the time of the incident, as configured rather than as documented.
- Every change to those parameters, with who made it and what approval it had.
- Any override of a safety interlock, with who authorised it and why.
- Whether alarms or degraded conditions were acknowledged, and by whom.
- The scope of autonomous operation — what the system was permitted to do without human involvement, and who decided that.
Most organisations can produce the first from configuration and struggle with the rest, because change records identify accounts and tickets rather than people and reasons.
What a board can reasonably ask for
Not a policy. A demonstration.
- For system X, show the current safety envelope and who last changed it
- Show the last five overrides of a safety interlock, with the authorising individual
- Show the approval record for the current scope of autonomous operation
- Show what would be produced if a regulator asked for this tomorrow
The fourth question is the useful one. It is answerable in a meeting, it is not adversarial, and it surfaces the gap without requiring the board to understand the technology.
The artefact that answers it
{
"system": "line-4-autonomous-handling",
"change": "safety_envelope.max_velocity",
"from": 1.2, "to": 1.8, "units": "m/s",
"basis": "[engineering assessment reference]",
"risk_assessment": "RA-2025-0231, reviewed 2025-11-02",
"authorised_by": "[named engineer, role]",
"countersigned_by": "[named safety officer]",
"effective": "2025-11-24T06:00:00Z",
"signatures": [ "...", "..." ]
}Two signatures, from two named individuals in different roles. That structure is standard in safety-critical engineering and is frequently absent once the parameter lives in software configuration rather than on a form.
Where this fits in existing practice
It is not new governance. Safety-critical industries have management-of-change processes that require exactly this: assessment, authorisation by competent persons, and a record.
What has happened is that as control moved into software, some of these parameters migrated into systems that use ordinary change control — a ticket and a deployment — rather than safety change control. The remedy is to recognise which configuration values are safety parameters and apply the existing discipline to them.
A note on scope
This applies to a narrower set of organisations than most AI governance discussion. If your systems affect data and decisions but not physical objects, the personal-exposure dimension largely does not arise and the ordinary governance apparatus is adequate.
If your systems move things, cut things, dispense things or control access to physical spaces, the question is worth putting on an agenda before someone else puts it there.
This describes governance principles at a general level and is not legal advice. Directors' duties and personal liability vary substantially by jurisdiction; take specifics to counsel.
A worked example: three records, three outcomes
| Record available | How it reads |
|---|---|
| Board minutes noting AI adoption | Awareness without ownership |
| A policy document with no named owner | A control on paper |
| An automated alert nobody acknowledged | Notice that reached no person |
| A signed envelope approval by a named director | Ownership, with a date and a scope |
| A signed acknowledgement of a breach alert | Notice that demonstrably reached a person |
The difference between the middle rows and the last two is not diligence, it is whether a person's signature exists over the specific thing. Everything else is an inference someone else will draw.
Objections and honest limits
“The board cannot approve every parameter.” It should not. It approves the envelope — the outer limits within which the system may act — and delegates inside it. That is one signature a quarter, not a workload.
“This creates personal exposure for directors.” The exposure exists whether or not the record does. What a signature changes is whether the director can show what they approved and when, rather than having it reconstructed by someone else.
This describes governance practice generally and is not legal advice. Duties and liability vary by jurisdiction and turn on specific facts.
Board-level questions worth asking
- Which autonomous systems can cause physical harm? Start with an inventory, not a policy.
- Who owns the safety envelope for each? A named person, not a committee.
- How is a breach escalated to a human? And can you show they received it.
- Who can stop the system, and how fast? Measure the kill time.
- Is the approval signed or minuted? A minute records discussion; a signature records commitment.
Terms used here
- Safety envelope
- The outer limits within which an autonomous system may operate without further human authorisation.
- Named ownership
- Assignment of a specific responsibility to an identified individual rather than a function.
- Kill time
- Elapsed time from a decision to stop a system to the system actually stopping.
Frequently asked questions
Does this apply to all AI systems? Primarily to systems with physical consequences. Where the effects are limited to data and decisions, the personal-exposure dimension largely does not arise.
What should a board ask? Not for a policy. Ask to see the current safety envelope for a named system, who last changed it, recent interlock overrides, and what would be produced if a regulator asked tomorrow.
Is this new governance? No. Safety-critical industries have management-of-change discipline already. The gap is that some safety parameters migrated into software change control.
Why two signatures? Authorisation by competent persons in distinct roles is standard safety practice. It tends to be lost when a parameter becomes a configuration value.
Does the board approve technical parameters? No. It approves the envelope and delegates inside it — roughly one signature a quarter.
Why does a signature beat a minute? A minute records that something was discussed. A signature records that a named person committed to a specific scope on a specific date.
Is this legal advice? No. Oversight duties and liability are jurisdiction-specific and fact-dependent.
Where this fits in Manav
Manav turns an envelope approval into an artefact: a named director's hardware signature over the limits they approved, and over each alert they were shown.
Sources and further reading
- Published guidance — directors’ duties and oversight (Cornell LII, corporations)
- IEC 61511 / OSHA process safety management
- Occupational and industrial safety regulator guidance on autonomous equipment.
- CISA — known exploited vulnerabilities and incident reporting
- ISO/IEC 42001 — AI management systems