The Manager's New Brief

14.1

Ch. 14 — Governance, Ethics, and Trust in Automated Work

Part IV — Management in the AI era

💡 Core idea

Speed without agreed rules creates silent risk. Governance should be light, clear, and actually used — and the manager is an ethical role model, not a spectator of “the company’s AI policy.”

A long corporate policy that nobody has translated into daily habits is not a policy. Your team needs a one-page rule they can find, plus your example.

Accountability is the root. Camille Fournier again: it cannot be assigned to a model (Chapter 1). If a decision needs an owner who can be held responsible, a tool cannot be that owner.

What may leave the team, and what may not

Write down approved tools, data classes (public, internal, confidential, restricted) with examples from your actual work, and what must never be pasted where. This is dull. It is also how you avoid the well-meaning incident in which someone puts customer or employee data into a public system to save time.

Google DeepMind has published a defense-in-depth posture toward capable, imperfectly aligned agents. Use it at the level of principles — assume failure, layer controls, do not trust a single safeguard — not as a copied enterprise catalog you do not understand.

Brad Menezes, after conversations with CIOs, CISOs, and heads of AI, describes a model now showing up in enterprises: “centralize the platform and governance, embed internal FDEs in the business.” The platform team sets an approved path to production; embedded forward-deployed engineers turn it into delivery in the line. This is a practitioner synthesis, not a survey with published methods. The useful split is still the one in this chapter: centralize the rules and the paved road; do not centralize all the work.

Ethan Mollick is useful here as in Chapter 12: unauthorized initiative by an agent is a governance incident, not a demo. If a tool can act, say who may authorize the action, and how you learn after the fact.

When not to use AI

Personnel decisions, legal or medical advice, anything you cannot review, anything that requires a confidence you cannot justify, and any call that needs a responsible human owner. When in doubt, do not.

Jurriaan Kamer argues that an honest policy names what you are willing to lose, not only what you hope to gain. Write the downgrade: speed may cost privacy, quality, or a learning path. A rule that only lists benefits will not be trusted, and will not be complete.

Do not become a proxy for a model

Attribution and honesty matter when machine assistance affects quality or credit. Niklas Gruhn puts it plainly: do not relay “the model said…”; read, validate, then answer in your own words. not-an-llm sharpens the warning: humans who silently pass through model output become “meat-based” proxies. No Meat Proxy states the same line as a slogan: AI is a tool; you should not become one.

This is a red line for trust (Chapter 4) and for formal records (Chapter 10). It is also a red line for your own voice (Chapter 17). The same pattern shows up as over-reliance in a consulting experiment: Dell’Acqua and colleagues found that when the task sat outside the model’s frontier, AI users were 19% less likely to produce correct solutions than people working without AI. Passing through fluent output is not a small manners problem. It is how a wrong answer reaches the client with your name on it. In the language of Chapter 2, that is treating the AI assistant as Release it (mode 3).

The same pattern appears when the “wrong answer” is not an error but a judgment call. In Herdagdelen, Joren, and Tamkin (Anthropic, 2026), professional analysts using a coding agent followed the agent’s hidden lean on open analytical choices 86% of the time, often reused its arguments, and still often rated the recommendation as their own (Chapter 6). A human sign-off is not an independent check if the judgment has already been borrowed. The authors themselves note that they strengthened the lean and that everyday effects may be smaller.

A different, explicit integrity line appears in The Gospel Coalition: a faith-informed refusal to call generated text “writing.” You do not need that theological frame for this book. You do need an explicit standard for attribution and authorship on your team. Write yours.

Incidents, flourishing, and fear

Keep a short incident log: what happened, impact, fix, what changed in the workflow. Without a log, you will repeat the miss and call it bad luck.

Harvard’s AI and Flourishing Initiative is a reminder to put tools in the service of human flourishing rather than treating technology as an autonomous force. The Guardian asks, in public language, what is lost when decisions — and even companionship — are delegated to tools. You do not need to settle those essays to do the local job: notice what the team is handing over, and whether that handoff is still a human choice.

Psychological safety amid automation is part of governance, not a soft add-on (Chapter 11). Invite fears about job change into 1:1s and team meetings. Uncertainty that cannot be spoken turns into rumor. Do not hide the roadmap for tool use. Do not punish the question.

Blake Crosley, reviewing more than 500 of his own unsupervised agent sessions (single rater, no inter-rater check), reports that seven recurring patterns accounted for 94% of the failures that needed human intervention, including skipped review steps, confidence without verification, and claims that tests passed when they had not been run. Treat this as one practitioner’s observation, not a published study. The managerial use is narrow: name the failure modes you will actually check for, and do not leave an agent unsupervised without a review rule.

Roman Nikolaev’s Cambri account (Chapter 12) is a practice form of the same rule: “The verdict stays human.” “The agent can never move a ticket to Done, and never files a bug without approval.” That is one company’s self-report, not a general law. It is also a reminder that a human sign-off has to remain a real check, not a rubber stamp.

Follow your organization’s rules and the law where you work. This chapter is practice, not legal advice.

Tools

🤖 AI-era tip: Write the rules with the team, in plain language

A policy no one can find is not a policy. Draft the one-pager with the people who do the work, walk through two or three realistic examples, and review it quarterly. Be explicit about monitoring: if work is logged or sampled, say so. Invite fears about automation into ordinary conversations. Follow the same rules yourself.

Takeaways

Evidence