Read the opening of chapter 1
The opening of chapter 1, exactly as printed.
Chapter 1: The Translation Layer, One Week at a Time
You already know the pitch: AI Governance Specialists sit between engineers, legal, and executives, translating regulatory obligation into buildable requirement and buildable requirement into a plain-language risk verdict. That framing gets you through a first interview. It does not tell you what fills a Tuesday. And the gap between the two is exactly where a lot of people who take this job discover, three months in, that they signed up for something they only understood at the level of a mission statement.
The honest version is less romantic and more mechanical. The translation layer isn't a skill you exercise once and check off. It's a cadence — the same four or five activities recurring on a loop, each one producing a specific document that someone else in the organization is going to act on. Miss the cadence and the framework you built in your first quarter quietly stops meaning anything, because nobody's actually running it against real systems anymore. This chapter is about what that cadence looks like once you're past the point of learning what a risk tier is, and into the point of actually operating one.
Every organization that takes AI governance seriously eventually builds some version of an intake gate: a checkpoint a new AI system has to clear before it reaches production, where someone confirms its risk classification, its required documentation, and its approval path. At a 101 level, that gate looks like a sorting exercise — high-risk bucket, limited-risk bucket, minimal-risk bucket, done. In practice, the gate spends most of its time on the systems that refuse to sort cleanly, and learning to sit with that discomfort instead of forcing a premature answer is most of what separates a specialist who's actually good at the job from one who's just fast.
Keep readingShow less
Take a proposal that shows up more often than you'd expect: an internal generative-AI assistant, built on a licensed foundation model, that lets employees search past performance-review language, project retrospectives, and manager feedback notes when they're prepping for a promotion cycle. Nobody on the team that built it thinks of it as an employment-decision system. It's pitched as a search tool — faster retrieval of information that already exists, nothing the tool itself decides. And on a narrow reading, that's defensible: it doesn't score anyone, rank anyone, or recommend a promotion outcome.
Sit with it another five minutes and the picture gets messier. The tool surfaces excerpts selectively, ranked by a relevance model nobody outside the vendor has visibility into. A manager preparing a promotion case pulls three flattering quotes and skips two unflattering ones the tool ranked lower — not because the manager is acting in bad faith, but because the tool decided what surfaced first. That's an AI system materially influencing an employment decision, which is precisely the kind of function the EU AI Act's Annex III employment category is written to catch, even when the system's own designers never framed it that way. The honest classification memo doesn't say "high-risk, obviously" or "minimal-risk, obviously." It says: this system's stated purpose is search, its practical effect touches an employment decision, and the deciding factor is whether its output materially shapes who gets promoted or just helps someone find a document faster. You write down the reasoning, not just the label, because six months from now, when someone asks why this system got the classification it did, "I made a judgment call and here's the reasoning" is the only defensible answer that exists. A raw verdict with no reasoning attached is worthless to an auditor and worthless to your own memory in six months.
This is where the intake gate actually earns its keep, and where it differs most from a 101-level treatment of the job. Two governance specialists looking at the same borderline system can land on different classifications and both be operating in good faith, because the EU AI Act's Annex III language was written to cover categories of harm, not an exhaustive list of product types. Your job isn't to find the one correct answer buried in the regulation. It's to produce a classification that's defensible under scrutiny, consistent with how you've classified comparable systems before, and documented well enough that a different governance specialist reviewing your file a year later can reconstruct your logic without calling you. That consistency requirement is its own discipline — if the search tool above gets classified high-risk, then the next promotion-adjacent generative tool that lands in your queue needs the same reasoning applied, not a fresh coin flip. Keeping a running classification log, not just individual case files, is what keeps a governance function from contradicting itself across a portfolio of forty or fifty systems.
Escalation works the same way. Most governance operating models define, up front, which classifications a specialist can finalize alone and which require a second reviewer or a governance committee sign-off — typically tied to a RACI-style decision-rights map built when the governance function itself was designed. A borderline high-risk call on an employment-adjacent tool is exactly the kind of decision that gets routed to committee rather than closed solo, not because you're not trusted to make the call, but because a documented second opinion is part of what makes the classification defensible later. Knowing when to route a decision upward instead of closing it yourself is a judgment call in its own right, and getting it wrong in either direction costs you: escalate everything and the committee stops trusting your triage; escalate nothing borderline and you're the single point of failure for a call regulators will eventually ask about.
Bias audits land mid-week for a mundane reason: that's usually where fairness testing sits in a development timeline, late enough that there's a real model to test, early enough to still change something before launch. The mechanics of running one — coordinating with data science, confirming which demographic groups get tested, checking the results get written down somewhere auditable — are groundwork you should already have from watching one happen. What doesn't show up until you're actually running audits at volume is what happens when the metrics disagree with each other, because they will, regularly, and picking which one governs the decision is a judgment call with real consequences.
