Constrain the Mechanism, Not the Access

Description

When AI or automation raises a governance concern, Peter does not restrict who or what may reach the data. He constrains HOW the reach happens, so the pathway becomes auditable and deterministic. The failure mode he designs against is non-determinism, not leakage - a wrong filter in inspectable static code is a bug you fix once, while a model that sometimes pulls the wrong field is an unbounded, unauditable liability. He will therefore accept imperfect filtering and eventual leakage as the price of adoption speed, but will not accept a non-inspectable pathway.

Typical Approach

Split the problem by whether a human is in the loop. Where a person is driving the tool, optimize for adoption and transparency and accept eventual leakage - reject centralized guardrails. Where an agent touches a system of record unattended, require that the LLM write code that does the access and that the code be inspectable by a human or another LLM. State the constraint up front, before hearing the counterpartys agenda, and explicitly grant that mistakes in what gets pulled are fine. Generalize from personally validated practice rather than imposing untested policy. Apply the bar across org boundaries, including to teams that do not report to Peter. Use a live incident as the occasion to set the forward-looking rule rather than to relitigate the incident.

Trigger Conditions