AI Adoption Needs Governance That Works
I believe we need more pace. Getting there requires clear ownership, usable controls, and evidence that a system is ready for the responsibility we give it.
My work connects AI security, engineering, and compliance. From that perspective, a process earns its place when it helps someone make a better decision or prevents a concrete failure. A review that identifies an unsafe permission boundary has value. Repeated reviews that cannot name the decision they own deserve scrutiny.
AI adoption can expose this difference. Giving a team a coding assistant or an agent does not resolve unclear ownership, conflicting requirements, or an approval process with no defined end. Those problems remain even when implementation becomes faster.
Give the team a boundary it can work within
Consider an internal document assistant. Before expanding its access, I would want answers to a few specific questions: whose documents may it retrieve, how are permissions enforced, what reaches an external model, and what happens when retrieved text contains instructions?
Those questions lead to engineering work: access checks at retrieval, deliberate tool permissions, adversarial tests, and a record of what the system actually did. A policy becomes useful when a team can implement it and a reviewer can examine the result.
This is an illustrative design approach, not a description of a client deployment. The exact controls depend on the data, the actions available to the system, and the consequences of failure.
Match review effort to the decision
A prototype using synthetic documents and no external actions has a different risk profile from an agent that can modify production records. I want teams to be able to explore the first quickly and to know what evidence they need before moving toward the second.
Some review should be deliberately independent. A builder can miss a failure precisely because they understand the intended behavior so well. Security review, legal interpretation, and operational approval can bring different information to the decision. Removing them indiscriminately would make the team less informed.
The waste starts when the same decision is passed between groups without anyone taking responsibility, or when every small change restarts a review whose assumptions have not changed. Clear ownership and explicit review triggers give teams a more usable path.
Make evidence part of development
In my inference-correctness investigation, a passing perplexity comparison missed a state bug. A different test exercised the transition that mattered. That experience is relevant beyond inference: evidence is only useful if it addresses the failure you are trying to prevent.
For an AI system, I would ask the team to connect each important claim to a test or observable control. Then record the configuration, result, and unresolved limitation. When the model, permissions, or deployment context changes, revisit the claims affected by that change.
That is the kind of governance I want to build: specific enough to test, clear enough to act on, and integrated early enough that the team can keep moving. Pace and accountability can reinforce each other when we do the engineering.