Sheet 12
How I would operate
Eight principles, each paired with the practice that makes it more than a statement. A principle without a practice attached is a preference; the practice is the part you could hold me to.
Operating principles
- 01
Start with the problem and the people affected.
Intake asks for the business problem before it asks for the tool. A request that cannot name the problem is not ready for review, and saying so early saves everyone a review cycle.
- 02
Make ownership and decision rights explicit.
Every record carries a business owner and a named decision owner. If nobody will own the outcome, the pilot does not start.
- 03
Match review effort to risk.
Three pathways, not one queue. Summarizing an internal meeting should not wait behind a recruiting workflow, and a recruiting workflow should never move at the speed of a meeting summary.
- 04
Document decisions and the reasoning behind them.
The decision log records what was considered and rejected, not just what was approved. That is what makes a program defensible a year later when the person who decided has moved on.
- 05
Keep humans accountable for consequential outcomes.
Oversight is written as a named role performing a specific check on a specific frequency, not as a general instruction to review the output.
- 06
Design governance so responsible ideas move faster.
Published timelines per pathway, a standing agenda, and pre-review office hours. Most of a review's delay is waiting for a meeting, not thinking.
- 07
Measure whether the work produced value.
Every pilot defines its measures before it starts, and self-reported benefits stay labeled as self-reported until something validates them.
- 08
Revise the program based on evidence and feedback.
Recurring questions become guidance. Repeated exceptions become a policy conversation. A pathway that catches nothing gets loosened.
Who is proposing this
Nicholas Vidal
Nicholas Vidal is a technology and governance program leader who helps organizations turn complex security, risk, and AI requirements into practical programs people can understand and use. His background spans enterprise technology operations, cross-functional leadership, responsible AI adoption, governance, training, and audit readiness.
He is not an AI developer or data scientist. His work is connecting strategy, governance, technology, risk, and the people who have to live with the result.
What I would want to talk about
This site is a proposal made from the outside, and the most useful conversation would be about where it is wrong. Three things I would want to know first:
- 01
Which of the assumptions on the discovery sheet do not hold, and what changes as a result.
- 02
What already exists that this model should sit underneath rather than replace — existing governance bodies, policy, and the AI work already underway.
- 03
What leadership currently sees, and which of it they actually act on. That determines what the first real report should contain.
Contact
- [add email]
- Phone
- [add phone]
- [add LinkedIn URL]
Placeholder contact details — replace in src/lib/data/site.ts before sharing.
If you read one more sheet
- Reading the roleNine themes from the posting, and where each one is demonstrated here.
- What I’d need to learnThe questions that would have to be answered before any of this applies, and what the playbook assumes until they are.
- End-to-end scenariosThe same program handling a request in nine days and another in seventy-five, and why.