# Translational Intelligence — Knowledge Bundle Version: 2026-07-20 Source: https://translationalintelligence.com/ Author: Alexander Titus (author of record; this publication is AI-assisted human work product). Career: Pandemic response at Google. The genotype-to-phenotype engineering team at Colossal. Enterprise AI transformation at Avidity. The same charge now at Alloy, through Vigilance. And a Commissioner advising Congress on the future of emerging biotech. Translational Intelligence. The operating system for building an AI-native biotech. An open, evidence-backed field guide for building an AI-native biotech. From Alexander Titus. This file contains the full text of every published Issue, FAQ, Artifact, and Case Study, with diagrams summarized in prose. The five core frameworks are maintained as living pages on the site and are summarized throughout this corpus: - Translational Intelligence: https://translationalintelligence.com/translational-intelligence/ - Permission, People, Programs: https://translationalintelligence.com/permission-people-programs/ - Buy the Record. Build the Intelligence.: https://translationalintelligence.com/buy-record-build-intelligence/ - The AI Product Partner: https://translationalintelligence.com/ai-product-partner/ - The AI-Native Biotech: https://translationalintelligence.com/ai-native-biotech/ - The Scope Ladder: https://translationalintelligence.com/scope-ladder/ Each section below names its type, canonical URL, and date. When citing, cite the canonical URL. --- ## [Artifact] A Lightweight AI Use Policy Canonical URL: https://translationalintelligence.com/artifacts/ai-use-policy/ Date: 2026-07-02 Summary: One page. Two tiers of data and one ethos, that there is no AI work product, only AI-assisted human work product, and a human is accountable for all of it. ## The one idea There is no such thing as an AI work product. There is only AI-assisted human work product. Whoever puts their name on a piece of work owns all of it, every fact, every number, every claim, no matter whether they, a colleague, or a chatbot produced the first draft. That single principle is the whole policy. Everything below is how to live it. ## Why this frees you Once accountability sits squarely with the human author of record, the usual fears lose their grip. Hallucinations, uneven quality, a confident wrong answer, these are not new risks that AI introduced. They are the ordinary risks of any draft from any source, and you already know how to manage them, because you check the work before it leaves your hands. A chatbot is a fast, tireless, sometimes-wrong colleague. You would not forward a junior analyst's memo to the board without reading it. Treat AI output the same way and you can use it for far more, far faster, because you are the backstop. ## The two tiers of data Most of what people call an AI policy is a data policy in disguise. Keep it simple enough to hold in your head. The sensitivity of the information decides the environment it is allowed to enter. - **Tier 1, Confidential.** Anything business-confidential: unpublished results, program data, sequences, patient information, financials, legal matters, anything under an NDA or partner agreement, anything not yet public. Tier 1 information goes only into contracted, enterprise-secure environments that [Company] has approved for that class of data. Never a personal or consumer account. - **Tier 2, Open.** Public or non-confidential information: published literature, general knowledge, marketing copy, anything already public or that safely could be. Use any approved tool freely, and explore. The risk is low and the upside is high, so the default here is yes. If a person cannot say cleanly which tier a piece of information belongs to, that is a classification question to resolve first, not a reason to freeze. ## On trusting your contracts The hardest Tier 1 question is whether an enterprise agreement is really enough to protect your data. It is a fair question, and it deserves to be settled once, deliberately, up front, not relitigated on every use. Responsible innovation means not reopening settled debates out of principle. If [Company] has done the diligence and holds an enterprise agreement that a vendor will not train on or retain your data, then decide, and let people work. But be honest that a contract is one control, not the whole story. The full picture is the control environment around it: access controls, retention and residency, subprocessors, incident response, and monitoring. Frameworks like the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) exist to map that terrain, and for regulated records the standards below govern. If you do not trust the arrangement, you do not have a tooling problem, you have a Permission problem, and the work is on the front end, choosing vendors, terms, and controls you can stand behind. Do that once, then get out of your people's way. ## What you still owe the work Accountability is total, so a few duties come with it. - **Verify before it leaves you.** Facts, figures, citations, and quotes are yours to confirm. AI is a strong first draft, never a source of record. - **Name the human on consequential work.** For anything that becomes part of an official record, a regulatory submission, a clinical judgment, a legal position, a published result, a specific person owns the decision and a human reviews before it ships. Higher stakes, more review. - **Disclose where it is material, not everywhere.** You do not caveat every email. But where the origin of the work matters to the reader, the scientific record, a regulatory filing, be transparent about AI assistance. - **When in doubt, ask.** [Name or role] is the person to ask before, not after. Asking early is always the right call, and it is never held against you. ## What this policy is not It is not a surveillance program and it is not a ban. It is a one-page employee quick guide, the layer people actually read, and it sits inside a fuller governance architecture your quality, security, and legal functions own: provenance, access controls, retention, subprocessors, validation, incident response, and monitoring. This page makes people accountable and fast; it does not replace that control standard. The goal is more capable people doing better work, and accountable for all of it. --- *Adapt the bracketed items for [Company], approve your environments and your point of contact, and this is ready to use. Keep it to a page. If it grows, it stops getting read.* ## Sources and further reading - NIST, [AI Risk Management Framework (AI RMF 1.0)](https://www.nist.gov/itl/ai-risk-management-framework) (2023), for the fuller govern/map/measure/manage control model - FDA, [21 CFR Part 11, Electronic Records; Electronic Signatures](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11), where AI touches regulated records - EMA, [Reflection paper on the use of AI in the medicinal product lifecycle](https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline) (2024) --- ## [Artifact] The Think-Harder Writing Workflow Canonical URL: https://translationalintelligence.com/artifacts/think-harder-workflow/ Date: 2026-07-05 Summary: An eight-step method for writing with AI that sharpens your thinking instead of replacing it. Expand before you compress, decide what you believe, and keep the judgment yours. ## The principle Use AI to reach the hard part of thinking more often, not to skip it. The struggle to work out what you actually mean is the part that has to stay yours. Everything that gets you to that struggle sooner is fair game. Run a piece through these eight steps and you spend AI on friction, not on avoiding it. ## The eight steps 1. **Originate.** Start with something only you could have produced: an observation from experience, an unresolved contradiction, a voice memo from a walk, a paragraph that does not quite work, a claim you suspect is true but cannot yet defend. It should be rough. The roughness is evidence of your thinking. 2. **Interrogate.** Before you ask AI to write a word, ask it to make the problem harder. What am I assuming? What is the strongest counterargument? Where would an expert call this naïve? Which parts are genuinely mine, and which are familiar ideas in new language? What is the most uncomfortable implication if it is true? What would change my mind? These are thinking prompts, not drafting prompts. 3. **Decide.** State the thesis in your own words, before drafting. Be able to say what you believe, why, what would make it false, why it matters, and what you are asking the reader to see differently. AI can compare theses. It cannot choose the one you are willing to stand behind. 4. **Structure.** Now bring AI back in. Ask it to organize the argument, compare a few possible architectures, and flag where an example or a piece of evidence is missing. You are choosing the road; it is helping you lay it. 5. **Draft.** Write directly, collaborate paragraph by paragraph, or have AI produce a draft from the decisions you already made. The order does not matter. What matters is that the thinking happened first. 6. **De-synthesize.** Strip the tells. Not forbidden words, structural habits: the sweeping opener, the tidy rule of three, the false binary, the transition that only transitions, the uplifting abstraction where a concrete point belongs. Ask of every draft: could any competent person with the same prompt have written this? 7. **Reclaim.** Rewrite the passages that carry the most judgment yourself, the opening, the central claim, the decisive transitions, the conclusion. These are where your voice has to be unmistakable. 8. **Defend.** The test. Could you explain every major claim to a skeptical expert, name its weak points, and say where your thinking changed, without leaning on the generated text? If yes, AI accelerated your reasoning. If no, it stood in for it, and you have work to redo. --- *The blank page was never sacred. The struggle to decide what you mean is. Use this to reach that struggle more often, and never to automate it.* --- ## [Artifact] How to Write With AI Without Sounding Like It Canonical URL: https://translationalintelligence.com/artifacts/ai-writing-style-guide/ Date: 2026-07-06 Summary: A house style guide for writing with AI. Derive your voice from evidence, state the rules worth stating, and cut the structural tells that make prose sound machine-made. ## The principle AI can make any draft sound finished. That is the danger, not the promise. A style guide is not decoration; it is how you make your taste explicit, so that you, an editor, and a model all know what "good" and "sounds like us" actually mean. Written down, judgment becomes something you can repeat, delegate, and defend. ## Voice is a pattern of decisions, not a list of adjectives Everyone wants to sound clear, smart, and concise, so those words tell a model nothing. Your voice is the set of decisions you make: what you notice first, how you build an argument, where you place tension, how long you stay abstract before an example, which metaphors you reach for, what you refuse to exaggerate, and what kinds of sentences feel dishonest coming from you. So do not describe your voice from memory. Derive it from evidence. Give the model several things you actually wrote, from different contexts, and have it find the recurring patterns. Then correct it, because its first read will fixate on the surface. Your corrections are the training, even when no model is technically being trained. ## The rules worth stating, mostly negative The most useful house rules are the "do nots," because they name the defaults you want to override. Ours, adapt your own: - Do not flatter the reader. - Do not inflate an ordinary observation into a civilizational revelation. - Do not use corporate throat-clearing. - Do not manufacture false balance when the argument supports a clear conclusion. - Do not resolve every productive tension into something tidy. - Do not end every section like a keynote. - Do not explain a sentence right after writing it. - No em-dashes. Emphasis is italic, never bold. ## The tells to cut AI prose is recognizable not by a secret set of forbidden words but by structural repetition. No single habit is fatal; the accumulation is. Cut for it: - the sweeping opener about a fast-changing world; - the tidy rule of three; - the false binary, "this is not merely X, it is Y"; - headings that just restate the thesis; - "critical," "transformative," "profound," on repeat; - the uplifting abstraction where a concrete conclusion belongs; - disagreement flattened into a list of equally reasonable perspectives; - every tension closed too cleanly. The cure is texture, not a banned-word list. Human writing lingers in some places and moves abruptly through others, trusts the reader to infer, and lets a sentence stand without a gloss. ## The one test Ask it of every draft: could any competent person with the same prompt have written this? A piece can be excellent and still be generic. If it could have come from anyone, reclaim the passages that carry the most judgment, the opening, the central claim, the decisive transitions, the conclusion, and write those yourself. ## Keep exercising the taste A style guide is not a substitute for taste; it is how you scale it. So keep the muscle alive. Write the first ugly paragraph yourself. Read the primary source before the summary. The guide keeps AI on the rails. Your hand keeps the writing yours. --- *Adapt every rule to your house. The point is not this exact list. It is that you wrote one down, so that "sounds like us" stops being a feeling and becomes a standard you can hold.* --- ## [Artifact] The Build-vs-Buy Decision Framework Canonical URL: https://translationalintelligence.com/artifacts/build-vs-buy/ Date: 2026-07-12 Summary: Route any AI request through five honest options, why the line now leans toward build, and how the smallest builds win the adoption that unlocks the big ones. ## The one rule, and how it moved Buy the system of record. Build the system of intelligence. The system of record is the infrastructure everyone in your industry shares and no one wins on, so buy it. The system of intelligence is the layer that turns your data and your particular way of working into advantage, so build that. But know that the line has moved, hard, toward build. AI has made building faster and cheaper than it has ever been, so the honest default now leans toward build more than the old procurement wisdom allowed. When you catch yourself reaching for a vendor out of habit, stop and ask whether a small, sharp build would be faster than the buying cycle. ## The five routes Every AI request comes down to one of five moves. Most of the discipline is routing each request to the right one, on purpose. - **Self-serve.** Give people secure access to general-purpose tools, with education and accountability. This is where [the AI Product Partner](/ai-product-partner/) earns their keep: train for self-service, because most of the work lives here Operator heuristic (call it roughly 70%; the point is the majority, not the decimal), and a surprising amount of value arrives with no project at all. - **Buy.** License a mature capability the market already builds well, the commodity infrastructure everyone shares. This is a system of record. - **Build.** Create the capability only you can, on your data and your workflows. This is a system of intelligence, and in this era you will build more of it than you used to. - **Redesign.** Change the workflow or decision structure itself. Automate a broken process and all you get is the same breakage, faster. - **Do nothing.** Decline the weak requests. Not every problem needs AI, and saying no protects your attention and your credibility. ## Route the request Ask these in order, and stop at the first yes. 1. **Can people already do this with tools you have?** Self-serve. Train them and set guardrails, not a project. Most requests end here. 2. **Is the honest fix a different workflow, not a tool?** Redesign first. Do not automate the old shape. 3. **Is there a strong, ready vendor for a capability everyone shares?** Buy it. It is a system of record. 4. **Is it yours to build?** Build it, and see below. 5. **Is the value thin or the problem not real?** Do nothing, for now. ## Build what you can't or won't buy You build for two reasons, and the bar for both has dropped. - **You can't buy it.** The capability is genuinely unavailable, or your proprietary data and your particular workflow are the whole point and no vendor has them. This is the system of intelligence. - **You won't buy it.** It is bespoke and tailored enough that a vendor implementation would take more work, cost, and compromise than building it yourself. With AI in hand, a focused build is often faster than the procurement it replaces. The old caution was drift toward build, rebuilding commodity you should have licensed. That is still true for the system of record, so do not write your own cloud or your own lab notebook. Past that line, build more freely than you used to. ## Solve small, and they will bring you big Here is the part most frameworks miss. The temptation is to reserve "build" for the big strategic bets, to only swing for the fences. In an AI-native company that is exactly backwards, because adoption and change are the whole game. Solve one person's real problem, however small, and they come back with bigger ideas than they had before. A small build that makes a scientist's Tuesday better is not a distraction from the strategic work. It is how you earn the trust and the momentum to do the strategic work at all. Solve for the individual, and you unlock the institutional. ## Revisit the line The line is not fixed. What is a differentiating build this year can become a commodity you should buy in two, once the vendors catch up, and what was too expensive to build last year is a weekend now. Put a date on the calendar to re-route your biggest builds and your oldest buys alike. --- *Run your three loudest AI requests through this once, out loud, with the people who own them. Then run your three smallest, the ones you have been ignoring. The small ones are where adoption is won.* --- ## [Artifact] The Permission, People, Programs Scorecard Canonical URL: https://translationalintelligence.com/artifacts/ppp-scorecard/ Date: 2026-07-13 Summary: One page. Grade your company on the three pillars that decide whether AI changes how you work, and find the one to fix first. ## How to use this One rule. Score your company from 0 to 3 on each of the three pillars, using the tables below. Do it with the people who own the work, not alone at your desk, and score the company you have, not the one on the strategy slide. Then read your result by your *lowest* pillar, not your average, because [Permission, People, and Programs](/permission-people-programs/) grow together or none of them grows. ## Permission: the space to move | Score | What it looks like | | --- | --- | | **0 · Absent** | No usable policy, or a blanket ban people quietly route around. Nobody can say cleanly which data goes in which tool. | | **1 · Stated** | A policy exists on paper, but it is a data policy in disguise, and your people cannot answer the Tier 1 versus Tier 2 question without checking. | | **2 · Practiced** | Two data tiers are clear, approved environments exist for each, and accountability and decision rights are named. People know where they are allowed to move. | | **3 · Native** | You revisit permission as the capability changes. Governance creates speed instead of braking it, and you review each gate for its shape rather than freezing it. | ## People: the capacity to move | Score | What it looks like | | --- | --- | | **0 · Absent** | Access without adoption. A handful of enthusiasts, and everyone else works exactly the way they did last year. | | **1 · Stated** | Training happened, a rollout or a webinar or a license, but behavior has not moved and there is no peer anyone is copying. | | **2 · Practiced** | Respected people use it in view of others, the examples look like real work, and adoption is spreading by imitation. | | **3 · Native** | Changing how the work is done is normal. People bring their own AI ideas, and new capability turns into new habits without a program pushing it. | ## Programs: the capability itself | Score | What it looks like | | --- | --- | | **0 · Absent** | No programs, or scattered pilots that never change how the institution operates. | | **1 · Stated** | Tools get shipped, but every request defaults to the same reflex, a pilot or a purchase or a custom build, whatever the room reaches for. | | **2 · Practiced** | Requests get [routed on purpose](/buy-record-build-intelligence/), and the smallest builds are winning the adoption that unlocks the bigger ones. The learning is kept. | | **3 · Native** | You keep re-routing your builds and your buys as the line moves. The institution operates measurably differently than it did a year ago, on purpose. | ## Read your score | Pillar | Your score (0-3) | | --- | --- | | Permission | | | People | | | Programs | | Your true level is your lowest pillar. Two things are almost always true when leaders score themselves honestly. Permission comes in high, because writing a policy feels like progress and it threatens no one. People comes in low, because behavior is the hardest and least visible thing to change. If Permission is your highest score and People is your lowest, you are not behind, you are *normal*, and you now know exactly where the work is. ## The move Take your lowest pillar and raise it one level this quarter. Operator heuristic One level per quarter is a healthy default pace, not a law; a higher-risk or earlier-stage company should set its own target. Not all three, and not the one you like to show off. One level, on the pillar you are worst at. The question of [which pillar to fix first](/faqs/which-pillar-first/) has its own answer, and the full model is on [Permission, People, Programs](/permission-people-programs/). --- *Score it in the next exec meeting, out loud, before anyone has time to round themselves up. Then put a date on the calendar ninety days out, and score again.* --- ## [Artifact] The First 90 Days Canonical URL: https://translationalintelligence.com/artifacts/first-90-days/ Date: 2026-07-15 Summary: The starter plan for a sub-100-person biotech. Not a roadmap, one quarter you can run that raises your weakest pillar a level, then repeats. ## Before you start This is the quarter that follows the first move, not a replacement for it. If you have not yet picked one workflow, one owner, and two questions, [start there](/faqs/where-do-i-start/) and come back. This plan assumes you are ready to make that first move real and build a few more around it. Two rules hold the whole thing together. Give the work one owner, not a committee. And aim to raise your *weakest* pillar one level, not to touch all three. Ninety days is enough for exactly that, and no more, and that is the point. ## Days 1 to 15: Name the owner and score yourself Do not launch anything yet. Spend the first two weeks getting honest and getting an owner. - **Give it one owner.** Not a new hire. One person who already has the trust of the room and is curious about the tools, at roughly 20% of their time. The role is [a function before it is a job](/artifacts/small-team-operating-model/). - **Score the company.** Run the [Permission, People, Programs Scorecard](/artifacts/ppp-scorecard/) with your exec team, out loud. Your lowest pillar is your target for the quarter. - **Write the one page.** Put the [AI Use Policy](/artifacts/ai-use-policy/) in place: two data tiers, a few duties. Permission should take an afternoon, not a task force. ## Days 16 to 45: Ship one workflow Now make the first move real, where people can see it. - **Pick the workflow a respected person would change their Tuesday over.** Not the biggest problem. The one where a win will be noticed and believed. - **One owner, two questions.** Is this the workflow that matters, and did it actually get better. Keep it that simple. - **Open the safe door.** Give everyone secure self-serve access for Tier 2 work, with education, not a project. A surprising amount of value arrives with no program at all. ## Days 46 to 75: Turn one into a few The first win earns the next. Spend this stretch on adoption, not on scope. - **Let the person you helped bring their bigger idea.** [Solve small, and they bring you big.](/artifacts/build-vs-buy/) This is how momentum compounds. - **Recruit two ambassadors.** The respected peers in other functions who will do it in front of their teams. Behavior spreads by imitation, not by memo. - **Route new requests on purpose.** As they arrive, run each through the [five moves](/artifacts/build-vs-buy/). Resist the platform purchase. You have not earned it yet, and you may never need it. ## Days 76 to 90: Score again and set the next quarter Close the loop, then open the next one. - **Re-run the scorecard.** Did your weakest pillar move a level? If yes, the quarter worked. If no, you now know where the resistance really lives. - **Pick the next pillar.** Whichever is lowest now. Not the one you like to show off. - **Put the next 90 days on the calendar.** This is not a one-time sprint. It is the cadence, and the company that keeps running it is the one that stays [AI-native](/ai-native-biotech/). --- *Ninety days from now you will not be finished, and that is correct. You will be one level higher on the pillar that was holding you back, with an owner, a few wins, and a habit. Then you run it again.* --- ## [Artifact] The Small-Team Operating Model Canonical URL: https://translationalintelligence.com/artifacts/small-team-operating-model/ Date: 2026-07-16 Summary: How a sub-100-person biotech runs an AI transformation without a Head of AI, a platform, or a committee. The fractional version of every role and program. ## The one idea At fifty people with runway to protect, you cannot open a requisition for [an AI Product Partner](/ai-product-partner/), and you should not try. The role is a *function* before it is a job. Someone has to own permission, own adoption, and route the programs, but that someone is already on your team, at about 20% of their time. Operator heuristic The 20% is a starting figure, not a measurement; size it to your company, and watch for the trigger where the function outgrows the fraction. Naming them is the whole move. ## Give it an owner, not a hire The function has to exist. The full-time body does not, until the function outgrows a fraction of one. So do not post a job. Take one person who already has the trust of the room and a real curiosity about the tools, and give them a fifth of their week and a clear mandate. A named owner at 20% beats an unfilled requisition every quarter of the year, and it beats a committee every day of the week. ## Which of your people is the right shape The right owner is T-shaped. Deep enough in one part of the work to be respected, broad enough to see across the whole company, and genuinely curious about what the tools can now do. In practice that is often a chief of staff, a head of operations, or a sharp program lead. It is usually *not* your most technical person, because the job is translation and trust, not engineering. And it is almost never an outside hire, because the hardest part of the work is [changing how respected colleagues do their jobs](/permission-people-programs/), and that trust does not arrive with a contract. Look for the shape, not the title. You are looking for the person other people already listen to. ## What the 20% does - Runs the [Permission, People, Programs Scorecard](/artifacts/ppp-scorecard/) and names the weakest pillar. - Owns the one-page [AI Use Policy](/artifacts/ai-use-policy/), so permission is settled and out of the way. - Finds the one workflow worth changing, and makes the win visible. - Trains people to self-serve, because most of the value lives there and needs no project. - Routes every new request through the [five moves](/artifacts/build-vs-buy/) instead of defaulting to a purchase. - Recruits the ambassadors that everyone else copies. ## What not to do at your size - **Don't hire a Head of AI.** Name the function first, and hire only once the 20% is visibly, provably full. - **Don't buy a platform before you have shipped a workflow.** You have not earned the signal that tells you which one. - **Don't stand up a committee.** A committee is how a small company simulates progress. One owner outruns it. - **Don't build what you can buy, or buy what your people can already self-serve.** - **Don't wait for a strategy.** [Run a quarter](/artifacts/first-90-days/), and let the strategy be the pattern you find. ## The minimum viable institution You do not need a transformation office. You need the smallest working version of all three pillars: one page of Permission, one visible win under People, one workflow routed on purpose under Programs. That is a complete operating model, and it fits on a company under a hundred people without adding a single full-time head. --- *Before you post the job, look around the room. The person who should own this is probably already in it, doing something you value, and one honest conversation away from spending a fifth of their time on the thing that will change the other four.* --- ## [Artifact] Where AI Touches a Clinical-Stage Biotech Canonical URL: https://translationalintelligence.com/artifacts/clinical-stage-ai-map/ Date: 2026-07-17 Summary: A practical map for the company whose science is at the CROs. Where AI helps across clinical ops, regulatory, medical writing, and vendor oversight, and where the validated-environment line sits. ## Read this if your bench is outsourced Regulatory This map names where AI touches a clinical-ops company and where the validated-environment line sits, with the controlling regulations linked below. It is the shape of the constraint, not legal advice; confirm the specifics with your own quality and regulatory function. Most AI-in-biotech advice pictures a discovery lab: assay data on your servers, models trained on your own experiments. If you run a clinical-stage company, that is not your company. Your science is largely at the CROs. The part with your employees and your deadlines is clinical operations, regulatory, medical writing, safety, and vendor oversight. This map is where AI touches that work, and where the validated-environment line sits. ## Where AI helps today | Function | Where AI helps today | | --- | --- | | Medical writing and clinical study reports | First-draft narratives and summaries from structured data, consistency and style checks across a document set | | Protocol and regulatory documents | Drafting and harmonizing protocols, consent forms, and submission summaries against templates and prior filings | | Safety and pharmacovigilance narratives | Drafting case narratives from structured case data at volume, for human review before anything is filed | | Regulatory submissions | Summarizing, drafting, and QC-ing content across submission modules, checking cross-references | | CRO and vendor oversight | Synthesizing monitoring reports, surfacing signals across vendor deliverables, drafting oversight questions | | Clinical operations | Drafting queries, summarizing site performance, preparing for monitoring visits | | Medical information and literature | Searching, summarizing, and drafting responses from public and licensed sources | ## The two lines that decide the environment Two questions govern every use above, and neither is about the model. *First, what class of data.* Patient data and results you have not yet filed are Tier 1, and they belong only in a contracted, enterprise-secure environment approved for that class, exactly as your [AI Use Policy](/artifacts/ai-use-policy/) says. Public and non-confidential inputs are Tier 2, where you should push people to explore. *Second, is AI touching a validated record.* There is a real difference between AI drafting a document a qualified human owns and reviews, and AI becoming part of a system that creates or maintains a GxP record. The first is mostly a People and Programs question: the human is the author of record, and your normal quality review still applies. The second is a computer-system-validation and 21 CFR Part 11 question, and it is your quality and regulatory function's call, not something to route around. Most of the early value sits on the near side of both lines: drafting and synthesis, on non-patient data or inside your approved environment, with a human who owns the output. There is more of it than you think. ## Don't relitigate the gates. Reconsider their shape. The validated processes and review gates in a clinical-stage company were rational answers to a world where information was expensive to move and slow to trust. AI does not delete the judgment those gates protect, which is patient safety and data integrity, and you should not try. Do the Permission work once, choose controls you can stand behind, and stop relitigating settled safety debates out of principle. But do ask the [AI-native](/ai-native-biotech/) question. Is the current shape of a gate still the best way to protect what it guards, or is it a manual step that survived only because the old systems could not see each other. That is a question for you and your quality function together, answered deliberately, not a reason to wait. --- *Start where neither line bites: a first-draft narrative, a summarized monitoring report, a submission section a qualified human will own and check. Win there, bring your quality and regulatory function in early, and move the harder lines on purpose.* ## Sources - FDA and EMA, [Guiding Principles of Good AI Practice in Drug Development](https://www.fda.gov/media/189581/download) (January 2026), ten joint principles spanning the medicine lifecycle, from research through manufacturing and safety monitoring ([EMA announcement](https://www.ema.europa.eu/en/news/ema-fda-set-common-principles-ai-medicine-development-0)) - FDA, [21 CFR Part 11, Electronic Records; Electronic Signatures](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) (eCFR, current) - FDA, [Considerations for the Use of AI to Support Regulatory Decision-Making for Drug and Biological Products](https://www.federalregister.gov/documents/2025/01/07/2024-31542/considerations-for-the-use-of-artificial-intelligence-to-support-regulatory-decision-making-for-drug) (draft guidance, Federal Register, January 2025) - ICH, [E6(R3) Good Clinical Practice](https://www.ema.europa.eu/en/documents/scientific-guideline/ich-e6-r3-guideline-good-clinical-practice-gcp-step-5_en.pdf) (Step 4 reached January 2025; linked here as EMA's Step 5 implementation), on computerised systems and data integrity in trials - EMA, [Reflection paper on the use of AI in the medicinal product lifecycle](https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline) (2024) --- ## [Issue] The Biotech of Tomorrow Canonical URL: https://translationalintelligence.com/the-biotech-of-tomorrow/ Date: 2026-07-01 Summary: You cannot build the biotech of tomorrow by making the biotech of yesterday slightly more efficient. The founding argument of Translational Intelligence. Picture the biotech that did everything right. It bought the licenses. It wrote the responsible-use policy. It ran the pilots, counted the hours saved, and put the numbers in a board deck. A year later it was faster. It was also the same company it had been the year before. Faster at the same documents. Faster at the same meetings. Faster at the same decisions, in the same order, for the same reasons. That is not transformation. That is efficiency wearing transformation's clothes. Almost everyone is in this trap. The reason is the question they started with: how can AI help us do our existing work faster? Reasonable question. It also guarantees you rebuild the past at a discount. This publication starts from a different one. What would we build if today's capabilities had existed when this company, this function, this workflow was first designed? That swap is the whole game. It is the line between an AI-enabled biotech and an AI-native one. ## The wrong debate Walk into most strategy rooms and you will hear an argument about models. Which foundation model. Which vendor. Build or buy the copilot. The choices matter. But they do not decide your future, and pretending they do has a cost. It lets everyone feel busy while the company stands still. The model is not the transformation. The organization is the transformation. A frontier model behind a login is not a new company. A thousand licenses are not a new company. Three hundred pilots are not a new company. Those are inputs. The output is an institution that spots a new capability, decides where it changes the work, gives people permission to act, redesigns the workflow around it, and can do it again next quarter. That chain, from raw capability to real advantage, is the product. Everything else is a demo. > [Diagram: Inputs are not the transformation] ## Why efficiency is a dead end Efficiency is seductive because it is safe. Hours saved is a clean number. It fits in a deck. It threatens no one. That last part is why leaders reach for it. Redesigning work changes who does what, who decides, and whose job was built around a limit that no longer exists. Efficiency changes the numbers without changing the powerful. So the powerful pick efficiency, call it transformation, and wonder a year later why nothing feels different. There is a deeper problem. When you automate a process, you freeze it. You take a workflow shaped by the limits of an older technology and pour concrete around it. Faster concrete. Still concrete. The handoffs, the review gates, the separations of duty that existed because information used to be expensive to move, are now fixed in place. You made yesterday permanent and called it progress. Automating a broken process does not fix it. It gives you a faster broken process. ## The honest counterargument The sharpest person in the room will push back here, and they are half right. Efficiency and transformation are not opposites, they will say. Efficiency *funds* transformation. The hours you save pay for the redesign, and the early, visible wins buy the political capital to attempt something harder. My own [People pillar](/permission-people-programs/) concedes the point: small wins build the habit that larger change stands on. All of that is true, and none of it rescues efficiency as a destination. Efficiency is the on-ramp. The mistake is never *starting* there. The mistake is *stopping* there, banking the hours, and reporting the destination as reached. Efficiency that funds a redesign is the first move of a transformation. Efficiency that funds next year's slightly faster version of the same company is a dead end with good margins. The test is not whether you took the efficiency win. Take it. The test is what you spend it on. [Naming the size of the change](/scope-ladder/) is how you tell the two apart: a faster workflow is one honest rung, and mistaking that rung for the whole climb is the trap this whole publication is trying to help you avoid. ## What AI-native means Not a company where machines do everything. That is a boring fantasy. An AI-native biotech is built on an honest read of what people do well, what machines do well, what software can now carry, and how freely information can move when moving it costs almost nothing. It keeps asking hard questions about its own design. Should this workflow exist as it does, or only because it always has? What still needs to be separate now that one system can hold all of it at once? Which decisions could happen earlier, with better evidence, if the right person saw the right thing in time? Where does human judgment matter more, not less? None of those are questions about a model. They are questions about the institution. The technology is the catalyst. The organization is what changes. So here is Monday morning. Pick one workflow that matters. Not the easy one. Not the one with the loudest AI request. One that carries real weight for the science or the business. Ask two questions. If we designed this today, knowing what these systems can do, what would we build? And what is actually stopping us, a hard constraint or a habit we inherited? The gap between those answers is your transformation. Everything else is a purchase order. ## The map [Translational Intelligence](/translational-intelligence/) is the capacity to turn new capability into durable advantage, again and again, as the technology keeps moving. That is the whole idea in one line. This publication builds it out. The system that creates the capacity is [Permission, People, and Programs](/permission-people-programs/). Permission is knowing where you are allowed to move. People is behavior change, the hardest and most decisive part. Programs is what you self-serve, buy, build, or redesign. The role that makes it real is the [AI Product Partner](/ai-product-partner/), the person who sits where capability meets the work and turns one into the other. The destination is the [AI-native biotech](/ai-native-biotech/), the company that never stops translating, with no final form to reach. Over the coming weeks I will take each of these apart, one issue at a time, with the frameworks and the language to use them. This is issue zero. ## Why I am doing this I have spent more than a decade in AI, most of it back when biotech saw it as a lab tool and nothing more. The last five years I have spent inside organizations, rebuilding them to meet the technology of today with an operating model built for tomorrow. Pandemic response at Google. A genotype-to-phenotype engineering team at Colossal. Enterprise AI transformation at Avidity. The same charge now at Alloy, through Vigilance. Different missions. Same work. And the same lesson every time: the technology is the easy part, and the human part is most of the job, by a wide margin. People call my strategies surprisingly practical. The first time, it was a small dig, a way of saying they sounded too simple to matter. The next conversation, that person had tried it, and they had learned how hard simple is. Now we talk all the time about the human part, because that is where transformation is won or lost. I get asked how to start almost every day. I want to help all of you, but I cannot sit with everyone. So this is my answer at scale. Nothing held back, nothing confidential. The gig is up. The edge was never a secret formula. It was the willingness to do the hard, human work of change, and then to do it again. I called this translational intelligence on purpose. Because the more intelligently we all operate, the faster we translate science into therapies. --- ## [Issue] There Is No AI Work Product Canonical URL: https://translationalintelligence.com/there-is-no-ai-work-product/ Date: 2026-07-02 Summary: The first thing every leader asks is what their AI policy should be. The whole answer fits in one sentence, and it moves accountability to exactly one place. The first thing almost everyone asks me is a version of the same question. What should our AI policy be? They are bracing for a long document, a committee, a quarter of legal review before anyone is allowed to touch a tool. Here is the whole thing in one sentence. There is no such thing as an AI work product. There is only AI-assisted human work product. ## It does not matter who drafted it Read that again, because it decides everything else. The person whose name is on the work owns all of it. Every fact, every number, every claim. It does not matter whether they wrote it, a colleague wrote it, or a chatbot wrote it. The author of record is accountable, completely, for what they hand over. > [Diagram: One accountable human] ## The fear that melts This is the part that moves mountains. The moment accountability sits with the human, the fears that freeze companies lose their grip. Hallucinations. Uneven quality. A confident, fluent, wrong answer. None of these are new. They are the ordinary hazards of any first draft from any source, and you already know how to handle them, because you read the work before it leaves your hands. A chatbot is a fast, tireless, sometimes-wrong colleague. You would not send a junior analyst's memo to the board unread. Treat the machine's output the same way, and suddenly you can use it for far more, far faster, because you are the backstop, and you always were. ## Two tiers of data Everything else is logistics. Most of what people call an AI policy is really a data policy, so keep it simple enough to hold in your head. The sensitivity of the information decides the environment it is allowed to enter. Tier 1 is confidential: unpublished results, program data, patient information, anything not yet public. It goes only into contracted, enterprise-secure environments you have approved for that class of data. Tier 2 is open: anything public, or that safely could be. There the default is yes, so explore. That is the whole model, and if someone cannot say which tier a thing belongs to, that is a classification question to answer first, not a reason to freeze. ## The question you have to answer The hardest part hides inside Tier 1, and it is not technical. It is whether you trust your own contracts. If you hold an enterprise agreement that a vendor will not train on or keep your data, then you have already made the decision. Trust it, and let people work. Reopening that debate on every single use is not caution. It is paralysis dressed as diligence. Responsible innovation means you do not relitigate settled questions out of principle. And if you genuinely do not trust the agreement, then be honest with yourself: you do not have a tooling problem, you have a [Permission](/permission-people-programs/) problem, and the work is on the front end, choosing terms you can stand behind. Do that once. Then get out of the way. ## Write it on one page So write your policy, and write it short. The few duties that come with total accountability are simple: verify before it leaves you, name the human on consequential work, disclose where it is material, and ask early when unsure. You do not have to start from a blank page. > Artifact: [A Lightweight AI Use Policy](https://translationalintelligence.com/artifacts/ai-use-policy/) Here is Monday morning. Do not commission a policy. Write the sentence at the top of a blank page, there is no AI work product, only AI-assisted human work product, and then add only what you need underneath it: which data goes where, and who to ask when in doubt. If your draft runs past a page, you are writing to cover yourself, not to help your people. The shortest honest policy is the one that gets read, and the only one that lets the work move. --- ## [Issue] Stop Swinging for the Fences Canonical URL: https://translationalintelligence.com/stop-swinging-for-the-fences/ Date: 2026-07-03 Summary: In the AI era the build-versus-buy line leans toward build, and the temptation is to only build big. But adoption is the game, and the smallest builds are how you win it. You have been in the meeting. The one where a team debates a big AI platform for a year while the small, obvious win, the thing that would make one scientist's week better, sits unbuilt because it is not strategic enough to bother with. That instinct is expensive, and in the age of AI it is backwards. ## The line moved toward build Start with what changed. For most of software history the safe money said buy. Building was slow, expensive, and risky, so you bought the commodity and reserved building for the few bets that would define the company. That wisdom has not vanished, but the line it drew has moved, hard, toward build. AI made building faster and cheaper than it has ever been. A focused tool that used to be a two-quarter project is now a week. So when you reach for a vendor out of habit, stop and ask whether a small, sharp build would be faster than the buying cycle it would replace. ## The trap is only building big Here is the subtle part. Once people accept that they can build, they only want to build big. They swing for the fences. The platform. The flagship. The strategic bet that will look good in a board deck. And while they spend a year designing it, the hundred small problems people have every day go unsolved. In an AI-native company, adoption and change are the entire game. A brilliant platform nobody adopts changed nothing. A tiny tool a scientist reaches for every morning changed how the work happens. [Permission, People, Programs](/permission-people-programs/) already told you the hardest part is behavior, not deployment. This is that same truth, pointed at your build list. ## Solve for one, unlock the institution > [Diagram: Solve small, unlock the institution] So solve small, on purpose. Take the unglamorous problem one person has and fix it this week. Then something happens that no roadmap predicts. That person trusts the tool, and they trust you, and they come back with a bigger idea than they ever would have raised before, because now they believe it is possible. Solve for one individual's real need, and you unlock the larger thinking that solves the institution's. The small build is not a distraction from the strategic work. It is how you earn the trust and the momentum to do the strategic work at all. ## Which is which None of this means build everything. You still buy the commodity, the system of record no one wins on, and you do not write your own cloud or your own lab notebook. The discipline is knowing which is which, and where the line sits this year. I put it on one page. > Artifact: [The Build-vs-Buy Decision Framework](https://translationalintelligence.com/artifacts/build-vs-buy/) Forget your AI strategy for a week. Find the smallest real problem a good person on your team keeps hitting, the one too small to have made any roadmap, and solve it this week. Then watch what they bring you next. That is not a detour from transformation. That is where it starts. --- ## [Issue] Don't Automate the Struggle Canonical URL: https://translationalintelligence.com/dont-automate-the-struggle/ Date: 2026-07-05 Summary: The fear that AI will atrophy how we think is real, but only if you use it to replace the struggle. Update your mental model instead, and the same tool makes you think harder, not just write faster. I was talking with a group of academics about how I use AI to write, and their worry was not plagiarism, or disclosure, or whether the prose can be detected. It was deeper. If we let AI help us write, will we slowly lose the ability to think? It is a fair fear, and it deserves a real answer. Writing is not the packaging around a finished idea. Often, writing is how the idea comes to exist. You start with an intuition, try to explain it, find it does not quite hold, revise, hit a contradiction, and arrive somewhere you could not have named when you began. The friction is the work. An AI can erase that friction in seconds. Hand it a half-formed thought and it returns a clean thesis, three tidy arguments, and a conclusion that gestures confidently at the future. That can feel like progress. Sometimes it is. Sometimes it is only *premature coherence*, an idea made to sound finished before it has earned it. ## The fear is real, but it aims at the wrong thing Here is what the fear gets right. If you use AI to replace the struggle, the struggle atrophies. Outsource the part where you work out what you actually mean, and that muscle weakens, exactly as the academics worry. But that is a fact about a mental model, not about the tool. The atrophy comes from replacing how you think. It does not come from updating how you think. Change the model, and the same machine does the opposite. Used to finish your thought, AI makes you lazier. Used to make your thought *harder to finish badly*, it makes you sharper. The goal was never to have the machine complete your idea. It is to keep your idea from closing too soon. ## Expand the problem before you compress the answer Most people ask AI to synthesize far too early. They want the outline, the argument, the draft, before they have walked the whole terrain of the idea. That is the move that hollows out thinking. Do the opposite. Before you ask AI to write a word, ask it to make the problem harder. > [Diagram: Expand, then decide] What am I assuming? What is the strongest case against this? Where would an expert call it naïve? Which parts are genuinely mine, and which are familiar ideas in new clothes? What is the most uncomfortable implication if it is true? What would change my mind? Those are not drafting prompts. They are thinking prompts. A good model will hold several competing readings at once, generate objection after objection without getting defensive, and pull in a field you would not have thought to check, long after a human colleague would have gone home. That does not make it wiser than a person. It makes it fast, available, and relentlessly patient. Point those traits at friction instead of away from it, and you leave the conversation with a more complicated understanding than you arrived with, and a sharper claim because of the complication. ## Then choose what you believe After the terrain, one decision cannot be delegated. What do I actually believe? AI can lay out theses and tell you which is most defensible or most provocative. It cannot tell you which one you are willing to stand behind. Before you draft, say the claim in your own words: what you believe, why, what would make it false, and why it matters. Only then is drafting useful, because now the machine is building the road, not choosing the destination. ## Keep the tells out, and keep some work by hand When you do draft with AI, strip the tells. Not a list of forbidden words, the structural habits: the sweeping opener about a fast-changing world, the tidy rule of three, the false binary, the transition that only transitions, the uplifting abstraction where a concrete conclusion belongs. AI prose feels synthetic because every sentence performs its job too visibly. The cure is texture and judgment, not a banned-word list. Ask one thing of every draft: could any competent person with the same prompt have written this? A piece can be clean and still be nobody's. And keep some of the work manual, on purpose. Write the first ugly paragraph yourself. Sit with a contradiction before asking the model to resolve it. Read the primary source before you request the summary. Calculators did not end arithmetic and GPS did not end knowing where you are, but the more powerful the tool, the more deliberately you have to keep the capacity to judge what it hands you. Call it cognitive maintenance. ## The one test There is a single test for whether AI accelerated your thinking or replaced it. Could you defend every major claim to a skeptical expert, explain where the idea came from, name its weak points, and say where your thinking changed, without leaning on the generated text? If yes, the tool sharpened you. If no, it stood in for you. That is the same standard as everything else here: [there is no AI work product, only AI-assisted human work product](/there-is-no-ai-work-product/), and you own all of it. > Artifact: [The Think-Harder Writing Workflow](https://translationalintelligence.com/artifacts/think-harder-workflow/) ## Update the model, not just the tools This is the cognitive version of being [AI-native](/ai-native-biotech/). The AI-native company does not run its old assumptions faster, it asks which assumptions still deserve to exist. The AI-native thinker does the same with their own mind. Do not hand AI the struggle to work out what you mean. Hand it everything that gets you to that struggle sooner, and more often, and you will not lose your capacity to think. You will have more of it. Take an idea you have been circling, and do not ask AI to write it up. Ask it to attack it. Make it list your assumptions, argue the other side, and name the implication you have been avoiding. Then close the laptop and write the first paragraph yourself. The blank page was never sacred. The struggle to decide what you mean is. Automate your way to more of that struggle, and guard the struggle itself. --- ## [Issue] Excellent and Generic Canonical URL: https://translationalintelligence.com/excellent-and-generic/ Date: 2026-07-06 Summary: You can think hard, land a real argument, and still produce prose that sounds like a machine made it. Polish is one thing. Whether the writing could only have come from you is another. You can do everything right. Start with your own idea, think it through, pressure-test it, land an argument that is genuinely yours. And the writing can still come out sounding like a machine made it. Not wrong. Not clumsy. Just generic. Nobody's. That is the failure most people do not see coming, because it does not look like failure. It looks like a clean, competent, publishable draft. Thinking hard about what you mean is the first half of the job, and I have written about [not automating that struggle](/dont-automate-the-struggle/). This is the second half. Even when the idea is unmistakably yours, the prose can still belong to no one. ## Excellent and generic Here is the uncomfortable pair. A piece can be excellent and still be generic. Those are not opposites. Polish measures one thing. Whether the writing could only have come from you measures another entirely. > [Diagram: Excellent and generic are two different axes] The trap is the top-left corner: excellent and generic. Fluent, well-organized, and completely interchangeable with what any competent person would have produced from the same prompt. The goal is the opposite corner, and getting there is not about writing better. It is about writing like *someone*. ## Why it all sounds the same AI prose is recognizable, but not because it reaches for a secret set of forbidden words. The tell is structural. The sweeping opener about a fast-changing world. The tidy rule of three. The false binary, this is not merely X, it is Y. The heading that just restates the thesis. The uplifting abstraction where a concrete conclusion belonged. Every tension resolved a little too cleanly. No one of those is a crime, and human writers use all of them. The problem is accumulation. AI prose feels synthetic because every sentence performs its job too visibly. The transitions transition. The emphasis emphasizes. The conclusion concludes. Real writing has more variance. It lingers in some places and moves abruptly through others, and it trusts you to fill a gap now and then. ## Voice is a pattern of decisions The usual fix makes it worse. People hand the model a list of adjectives, clear, smart, conversational, concise, and wonder why the output sounds like everyone else who wanted to sound clear, smart, conversational, and concise. Voice is not an aspiration. It is a pattern of decisions. What you notice first. How you build an argument. Where you place the tension and how long you hold it. Which comparisons you reach for, and which you would never make. What you refuse to exaggerate. Which sentences feel dishonest coming from you. You cannot describe that from memory and expect a model to reproduce it. You *derive* it from evidence. Feed it several things you wrote yourself, from different rooms, and have it find the patterns. Then correct what it finds, because it will grab the surface first. Every correction, "I would never say that," "cleaner, but less true," is you making your taste explicit. That accumulated judgment is worth more than any prompt. ## The one test There is a single question that catches all of it. Could any competent person with the same prompt have written this? If the honest answer is yes, the piece is generic however polished, and the fix is not more editing. It is to reclaim the passages that carry your judgment, the opening, the central claim, the turns, the ending, and write those in your own hand. I put the rest of it, the negative rules, the tells, the way to derive a voice from evidence, on one page. > Artifact: [How to Write With AI Without Sounding Like It](https://translationalintelligence.com/artifacts/ai-writing-style-guide/) Run the one test on something you are proud of. Take a piece AI helped you write, read it, and ask whether anyone with your prompt would have produced the same thing. Where the answer is yes, that paragraph is not yours yet. Rewrite it until it could only have come from you. That is the whole difference between using the tool and being replaced by it, and it usually lives in about four paragraphs a piece. --- ## [Issue] Your Edge Was Never the Model Canonical URL: https://translationalintelligence.com/your-edge-was-never-the-model/ Date: 2026-07-07 Summary: Whichever model leads this quarter, you rent. The thing worth owning sits underneath it, the capacity to turn whatever arrives into how your company works. Every few months a new model takes the lead, and every few months a wave of companies rebuilds its AI strategy around it. Both moves are a mistake. The model that is ahead today will not be ahead for long. If your advantage is the model, you rent your advantage, and the rent resets every quarter. Whoever is on top next quarter, you will be renting from them instead. The thing worth owning is underneath. It is the capacity to take whatever new capability arrives and turn it into how your company actually works. That capacity has a name. > [Diagram: The model is rented; the capacity is owned] The capacity is [translational intelligence](/translational-intelligence/): the institutional ability to convert emerging capability into durable advantage, again and again. Read that word institutional twice. It is not a skill one brilliant person has, and it is not a team you stand up in a corner of the org chart. It is something your company can do, as a company, and keep doing as the ground shifts under everyone. The advantage is not the model. It is the capacity to keep translating. ## Why this reframes the whole conversation A frontier model behind a login is not transformation. A thousand licenses are not transformation. Between what becomes newly possible and what your institution can actually do sits a gap, and that gap is where most transformation dies. Closing it, over and over, is the entire job. The model is a catalyst. The organization is what changes. That is also why the buying question, which vendor, which model, matters less than the room thinks. You can buy every input on the market and be the same company next year, only with a larger software bill. What you cannot buy, and what compounds, is the capacity itself. ## Where it breaks The work runs along a chain, from raw capability to permission to behavior to workflow to decision to advantage. Each link is a place the translation can fail. And experience keeps teaching the same lesson: most companies break at behavior and workflow, not at capability. They have the tools. They do not have the habits or the redesigned work. So they pour money into the first link and wonder why nothing moves at the last. Stop asking which model. Take the chain and walk your own organization along it until you find the link that breaks. It is almost never the one you are spending on. Fix the real link, not the visible one. The full argument, and the whole chain, is on [Translational Intelligence](/translational-intelligence/). --- ## [Issue] The One-Lever Mistake Canonical URL: https://translationalintelligence.com/the-one-lever-mistake/ Date: 2026-07-08 Summary: A company gets serious about AI and reaches for one lever. A year later the lever moved and the company did not. It takes three pillars, and they grow together or not at all. A company decides to get serious about AI, and it reaches for one lever. It buys the licenses. Or it writes the policy. Or it ships a tool. A year later, the lever moved and the company did not. The mistake is not the lever. Each one is fine. The mistake is thinking any one of them is a strategy. > [Diagram: One lever versus three pillars] The system that builds the capacity is [Permission, People, and Programs](/permission-people-programs/). Permission is the space to move: knowing where you are allowed to act, with which data, under whose accountability. People is the capacity to move: whether anyone actually changes how they work. Programs is the capability itself: what you self-serve, buy, build, or redesign. ## They are not phases The three are easy to say in order, so people run them in order. Finish the policy, then train the people, then start the programs. That sequence fails, because these are not phases. They are dimensions of the same thing, and they mature together. Better Permission lets your people move faster and with more confidence. More capable people find and adopt better Programs, because they can see the openings in their own work. Programs surface new risks that send you back to sharpen Permission. You never finish one. You grow all three, and you grade yourself on all three. ## The pillar that decides it If you have to start somewhere, start where you are weakest, not where you like to show off. And the weak one is almost always People, because behavior is the hardest and least visible part of the whole enterprise. A license is not adoption. Someone can have the tool, the training, and the policy in front of them and still work exactly the way they did last year. That is why a clean policy on top of unchanged behavior has transformed nothing. The model is a catalyst. The organization is the transformation, and the organization is people. Grade yourself this week, honestly. Score your company on Permission, People, and Programs, and start on the one you scored worst, not the one that would look best in a deck. The full operating system is on [Permission, People, Programs](/permission-people-programs/). --- ## [Issue] Arguing About the Wrong Thing Canonical URL: https://translationalintelligence.com/arguing-about-the-wrong-thing/ Date: 2026-07-10 Summary: The meeting is about which model and which vendor. Those choices matter less than the room thinks. The scarce resource was never the technology. You have sat in this meeting. The whole argument is about tools. Which foundation model. Which vendor. Build the copilot or buy it. Everyone leaves feeling like a decision was made. The choices matter, a little. But they do not decide your future, and pretending they do has a cost. It lets a room full of capable people feel busy while the company stands still. The scarce resource was never the technology. It is the person who can hold a new capability in one hand and a real piece of work in the other and see how one should reshape the other. That person needs a name and a job. > [Diagram: The person who bridges the gap] I call the role the [AI Product Partner](/ai-product-partner/), and it exists because of exactly that gap. The people who know what AI can now do usually do not understand the work that has to change. The people who understand the work usually do not know what just became possible. Nobody who could close the gap alone is standing in it. ## Both words are chosen on purpose *Partner*, because this is not a ticket taker. The relationship is not tell me which tool to build. It is help me understand the outcome and the real work, and we will decide together what should exist. The job is one part enablement: someone who lives in the tools, carries real empathy for how hard it is to change how a person works, and spends the day teaching people to change themselves. *Product*, because a demonstration is a comfortable way to lie to yourself. A prototype proves something is possible. A product makes it a repeatable part of how the institution works. The other part of the job is translating what teaching cannot solve into clear build requirements, and handing them to a dynamic, innovative engineering team to make real. ## Not a new tool, a new seat So the first move is not a purchase. It is to put a person at that intersection, give them real standing across Permission, People, and Programs, and let them reframe the work instead of taking tickets. As capability gets cheaper and more abundant, deciding what to do with it is the scarce skill, and it will not commoditize. Where do your best people spend their days on work beneath them? Name that one function, and put a person at the seam this quarter, with the standing to change the work and not just field requests for it. The full role is on [The AI Product Partner](/ai-product-partner/). --- ## [Issue] Audit Yourself in Public Canonical URL: https://translationalintelligence.com/audit-yourself-in-public/ Date: 2026-07-11 Summary: The strongest test of a system is whether its author will use it, in the open, with the gaps left in. So I ran this publication against its own rules. The strongest test of a system is not whether it sounds good in a deck. It is whether its author will use it, on their own work, in public, where the gaps show. Most companies fail that test quietly, and for one reason: they never wrote their rules down. A rule you have not written is a rule you cannot be held to. It is a preference, and preferences bend under pressure. > [Diagram: Written rules make gaps small and findable] This publication was built on its own written rules, so I did the honest thing and audited it against them before I recommended you do the same. I found real gaps. The founding piece had no signature diagram, though the standard says every Issue carries one. And for a publication about using AI well, there was no disclosure anywhere that the work is AI-assisted, though I preach disclosing exactly that where it is material. Neither was a catastrophe. That is the point. When you hold yourself to a standard you wrote down, the gaps come out small and findable, instead of large and hidden. A company that never audits itself does not have fewer gaps. It just has not looked, and the gaps it is not looking at are the large ones. ## What a real audit looks like Take the work you are proudest of, the AI strategy you would put in front of your board, and check it against your rules, line by line. Where did you break your own standard? Then close the gap, because a rule only means something if the gaps get fixed, not just noted. And do it in the open. A case study that shows only the wins is exactly the premature coherence worth distrusting. The willingness to publish the gaps is the whole signal that the system is real. I wrote the full accounting up as the first case study, the system applied to the thing you are reading. Here is Monday morning. Write your rules down, if they are not already. Then run your loudest AI work against them and fix the smallest gap you find this week. The full self-audit is [Built by Its Own Rules](/case-studies/built-by-its-own-rules/). --- ## [Issue] There Are Only Five Moves Canonical URL: https://translationalintelligence.com/only-five-moves/ Date: 2026-07-12 Summary: Every AI request feels unique. It is not. There are only five things you can do with any of them, and most of the discipline is routing each to the right one on purpose. Every AI request that lands on your desk feels like its own special problem. It is not. Strip away the framing and there are only five things you can do with any of them. Self-serve it. Buy it. Build it. Redesign around it. Or do nothing. That is the whole menu. Most of the discipline is not deciding whether to act. It is routing each request to the right one of the five, on purpose, instead of defaulting to whichever move your culture reaches for by reflex. > [Diagram: Route each request through five moves, in order] The order matters, because the cheapest honest answer is usually near the top. Can people already do this with tools you have? Self-serve it, with training and guardrails, not a project. Is the real fix a different workflow rather than a tool? Redesign it, because speeding up a broken workflow just gets you to the wrong place sooner. Is there a strong vendor for a capability the whole market shares? Buy it, and do not rebuild a commodity out of pride. Is it genuinely yours, on your data and your workflow? Then build it. And if the value is thin or the problem is not real, do nothing, and protect your attention and your credibility. Most requests never reach build. That is the point. Build is the last stop, not the first reflex, and routing on purpose is what keeps a company from pouring its scarce engineering into the wrong four moves out of five. The failure is rarely choosing wrong. It is not choosing at all: letting every request default to a pilot, or a purchase, or a custom build, because that is what the room always does. Say the five out loud, for each request, in front of the people who own the work. > Artifact: [The Build-vs-Buy Decision Framework](https://translationalintelligence.com/artifacts/build-vs-buy/) What is the loudest AI request in your queue right now? Route it out loud through the five, in order, in front of the person who owns it. Notice how far down the list the honest answer sits. It is rarely where you started. The full discipline is on [Buy the Record. Build the Intelligence.](/buy-record-build-intelligence/) --- ## [Issue] You Can't Fix What You Won't Grade Canonical URL: https://translationalintelligence.com/cant-fix-what-you-wont-grade/ Date: 2026-07-13 Summary: Most leaders run their AI transformation on anecdote and vibes. The fix is a one-page scorecard, and the hard part is not the scoring. It is being honest about the pillar that flatters you. Ask a leadership team how their AI transformation is going and you will hear a story. A pilot that went well. A team that loves the new tool. A policy that finally got signed. What you will almost never hear is a number, because most companies are running the whole thing on anecdote and vibes, and anecdote always flatters the teller. You cannot fix what you will not grade. So grade it. Not the whole sprawling thing at once, but the three pillars that decide whether AI changes how you work: [Permission, People, and Programs](/permission-people-programs/). Score each one from zero to three, in a room, with the people who own the work. It takes fifteen minutes, and it ends the storytelling. > [Diagram: You are only as native as your weakest pillar] Here is the rule that makes the score honest. You do not average the three. Your true level is your *lowest* pillar, because the three grow together or none of them grows. A company with a signed policy and a shelf of licenses and no one changing how they work is not two-thirds transformed. It is stuck, with good governance on top. The tallest pillars do not carry the short one. The short one sets the ceiling. And the scoring is where the honesty gets tested, because two mistakes are almost universal. Leaders over-score Permission, because writing a policy feels like progress and it threatens no one. And they under-score nothing so reliably as People, because behavior is the hardest and least visible thing in the building to change. If your Permission score comes in high and your People score comes in low, you are not behind. You are *normal*. You have just found where the work is, which is the entire point of grading. The move after that is small on purpose. You do not launch a program against all three pillars. You take the lowest one and raise it a single level this quarter. Then you put a date on the calendar and grade again, and now you are running a transformation on evidence instead of on the best story someone told in the last meeting. > Artifact: [The Permission, People, Programs Scorecard](https://translationalintelligence.com/artifacts/ppp-scorecard/) Here is Monday morning. Put the three pillars on a whiteboard and have each of your leaders score the company privately, zero to three, before anyone speaks. Then compare. The spread between your highest scorer and your lowest is its own diagnosis, and the pillar you argue about most is usually the one you have been avoiding. Start there. The full model, and where to point the first move, is on [Permission, People, Programs](/permission-people-programs/). --- ## [Issue] You Don't Need a Roadmap. You Need a Quarter. Canonical URL: https://translationalintelligence.com/you-dont-need-a-roadmap/ Date: 2026-07-15 Summary: The request that kills more AI transformations than any budget line is the responsible-sounding one, bring me the roadmap. You do not need a two-year plan. You need one quarter you can run. The request that kills more AI transformations than any budget line is the one that sounds the most responsible. Bring me the roadmap. A two-year plan, phased, with milestones and a target operating model on slide fourteen. It feels like leadership, and it is mostly a way to not start, because the ground under a two-year AI plan moves faster than the plan does. By the time it clears the room, the capability it assumed is a year out of date. You do not need a roadmap. You need a quarter. Ninety days is long enough to name an owner, [score yourself honestly](/artifacts/ppp-scorecard/), ship one real workflow, spread it to a few people, and score again. It is short enough that the capability will not outrun you, and small enough that you can run it with the people and the runway you already have. > [Diagram: The first 90 days, as a repeating quarter] The quarter has a shape, and the shape matters more than the ambition. The first two weeks are for honesty and an owner, not launches: name the person who will own the work at a fifth of their time, and score the company out loud. The next month is one workflow made real where people can see it. The month after that is turning that one win into a few, by letting the person you helped bring their bigger idea and by recruiting the peers everyone else copies. The last two weeks are for scoring again and choosing the next pillar. Then you do the whole thing over. A roadmap promises you will know the entire path before you take a step. A quarter admits you will learn the path by walking it, which in a field moving this fast is the only honest promise on offer. The roadmap optimizes for the comfort of the room that approves it. The quarter optimizes for the one thing that compounds, which is *adoption*. Solve one person's real problem this quarter, and next quarter they arrive with a bigger one, and that is a company teaching itself to move. > Artifact: [The First 90 Days](https://translationalintelligence.com/artifacts/first-90-days/) So do not commission the roadmap. Name the owner today, put the [scorecard](/artifacts/ppp-scorecard/) on this week's agenda, and let your target for the quarter be a single level on a single pillar. Ninety days from now you will have moved, which is more than most roadmaps deliver in two years. That habit, run over and over, is what keeps a company [AI-native](/ai-native-biotech/). --- ## [Issue] You Already Employ Your AI Product Partner Canonical URL: https://translationalintelligence.com/already-on-your-team/ Date: 2026-07-16 Summary: Every small-company leader hits the same wall. The role sounds essential and sounds like a hire they cannot make. It is not a headcount. It is a function, and the person with the right shape is already in the building. Every small-company leader who reads about [the AI Product Partner](/ai-product-partner/) arrives at the same wall. It sounds essential, and it sounds like a hire they cannot make. Fifty people, clinical-stage, runway to protect, and no room on the org chart for a new senior role whose value they cannot yet prove to a board. So they file the idea under later, and later never comes. The wall is built from a single wrong assumption: that the AI Product Partner is a headcount. It is not. It is a function, and a function does not need its own full-time body until it outgrows a fraction of one. At your size the whole role is about 20% of a person you already employ, and the move that matters is not posting a job. It is naming the person. > [Diagram: The right owner is already on your team] The person has a shape, and the shape is not a title. They are trusted by their peers, curious about what the tools can now do, and broad enough to see across the whole company rather than down into one function. That is often a chief of staff or a head of operations, usually not your most technical person, because the job is translation and trust rather than engineering. And it is almost never an outside hire, because the hardest part of this work is changing how respected colleagues do their jobs, and that kind of trust does not transfer with an offer letter. What the 20% does is not mysterious. They score the company, own the one-page policy, find the one workflow worth changing, route new requests instead of defaulting to a purchase, and recruit the peers everyone copies. What they do *not* do matters just as much. They do not stand up a committee, buy a platform before shipping a workflow, or wait for a strategy to arrive from somewhere else. Hiring feels like commitment, and commitment feels like seriousness. But at fifty people, the serious move is the small one. Name the function, give it a fifth of the right person's week, and let it earn its way to a full-time job by outgrowing the fraction. Most companies at this size never need the hire. They need the *owner*. > Artifact: [The Small-Team Operating Model](https://translationalintelligence.com/artifacts/small-team-operating-model/) Skip the requisition. Write down the three people on your team with the right shape, and have the honest conversation with the first one this week. Give them a fifth of their time and the [scorecard](/artifacts/ppp-scorecard/) to start with. You are not adding a head. You are naming an owner who was in the building the whole time. --- ## [Issue] When Your Science Is Outsourced Canonical URL: https://translationalintelligence.com/when-your-science-is-outsourced/ Date: 2026-07-17 Summary: Most AI-in-biotech advice pictures a discovery lab. If you run a clinical-stage company, your bench is at the CROs, and your real surface area is writing, reviewing, submitting, and oversight, under rules written to protect patients. Most writing about AI in biotech, some of mine included, pictures a company with its science in the building. Assay data on the servers, models trained on your own experiments, a discovery engine to make faster. If you run a clinical-stage company, that picture is not yours. Your bench is at the CROs. Your molecule is in trials you monitor rather than run. And your company, the part with employees and deadlines and risk, is something else entirely. It is clinical operations, regulatory, medical writing, safety, and vendor oversight. That is where your people spend their days, and it is where AI actually touches your company. So the question is not how AI changes your lab. It is how AI changes a company that mostly writes, reviews, submits, and oversees, under rules written to protect patients. And that runs straight into the validated environment, which is exactly where most leaders assume AI cannot go. > [Diagram: Two lines decide where AI can help in a clinical-stage company] Two lines decide where AI can help, and neither is the wall people imagine. The first is the data class you already know from your [AI Use Policy](/artifacts/ai-use-policy/): patient data and unfiled results are Tier 1 and live only in an approved, enterprise-secure environment. The second is subtler and matters more. It is whether AI is drafting something a qualified human owns and reviews, or becoming part of a system that creates or maintains a regulated record. The first is a question about your people and your programs. The second is a computer-system-validation and Part 11 question for your quality function. Most of the early value sits where neither line bites, and there is a great deal of it. The validated gate is not there to keep AI out. It is there to protect patient safety and data integrity, and those do not get cheaper to ignore because intelligence got cheaper. So you do not relitigate the gate. You do the Permission work once, choose controls you can stand behind, and then ask the only interesting question left. Is the current shape of this gate still the best way to protect what it guards, or is it a manual step that survived because the old systems could not see each other. That question belongs to you and your quality function together, and it gets answered on purpose, not by waiting. > Artifact: [Where AI Touches a Clinical-Stage Biotech](https://translationalintelligence.com/artifacts/clinical-stage-ai-map/) Here is Monday morning. Take one document your team writes by hand every week, a safety narrative, a monitoring summary, a submission section, and place it against the two lines. If it is a human-owned draft on data you already control, you can start this week. For everything past that line, bring your quality function in early and move it deliberately. The full map is [the artifact above](/artifacts/clinical-stage-ai-map/), and the destination it rests on is [the AI-Native Biotech](/ai-native-biotech/). --- ## [Issue] An Afternoon, or a Restructure Canonical URL: https://translationalintelligence.com/an-afternoon-or-a-restructure/ Date: 2026-07-19 Summary: The word transformation hides five different sizes of change, from a habit you can build before lunch to a company you have to take apart and rebuild. Naming the size is most of the work. Someone tells you they are transforming their company with AI, and you have no idea what they mean. They might mean they built a habit last Tuesday that gives them back an hour a day. They might mean they took their whole org chart apart and rebuilt it around how the work actually happens now. Those are not the same project. They do not share a budget, a timeline, a risk profile, or even the same person's signature. But we file both under one word, *transformation*, and the word does most of the damage. It lets a drawer full of clever habits pass for a strategy, and it lets a strategy deck stand in for a drawer full of habits nobody has built yet. There are five sizes. Each one is roughly an order of magnitude more scope, more time, and more risk than the size below it. The smallest fits in an afternoon. The largest is a restructuring you will live inside for the better part of a year. > [Diagram: The five scopes nest inside each other] ## The five sizes **One. The Personal Practice.** You, one habit, one afternoon. You find a way to use a model that quietly changes how you spend an hour of your day. The productivity is almost beside the point. The real product is *belief*: you, or a respected colleague, doing the thing in front of everyone else, which is how adoption has always actually spread. A century of research on how new practices move through a group says the same thing, that it starts with a few credible people and their social proof, not with a mandate ([Rogers, *Diffusion of Innovations*](https://open.ncl.ac.uk/theories/8/diffusion-of-innovations/)). This rung looks trivial. It is the one everything else stands on. **Two. The Workflow.** One process, re-run a different way. Days to weeks. Here is the first real trap. The temptation is to bolt a model onto the process you already have and call the faster version a transformation. Michael Hammer named the mistake more than thirty years ago and it has not aged a day: [don't automate, obliterate](https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate). Speeding up a broken workflow only gets you to the wrong place sooner. The move is to ask what you would build if you designed the process today, knowing what these systems can now do, and then close the gap to that. **Three. The Amplified Role.** One person's whole responsibility stack. Weeks to months. Not one of their tasks, all of them: the regulatory lead, the head of clinical operations, the founder wearing four hats. You go deep on everything one person owns until the role itself works differently. This is the vertical move, and it is often where a small company gets its first real leverage, because in a small company one amplified role is a meaningful fraction of the whole. **Four. The Re-formed Function.** A whole team's work, all at once. A quarter. The horizontal twin of the amplified role: not one person going deep, but a function changing across the board. The entire regulatory group, all of clinical operations. This is where it stops being personal and starts being an operating decision, because now other people's work depends on the change holding. **Five. The Re-Aligned Enterprise.** The company rebuilt around how the work is actually done now. Multiple quarters. New reporting lines, new decision rights, new definitions of whose job is what. This is the rung everyone points at when they say the word, and it is the rung almost nobody reaches, because most companies announce it before they have built a single one of the rungs below it. The data is blunt: across a large annual survey, only around seven percent of organizations report AI that is fully scaled, and the blockers are not the models, they are workflow rigidity and operating-model inertia ([McKinsey, *The state of AI*](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)). ## They are not five buckets. They nest. Look at the diagram again. These are not five separate options on a menu. Each one is *built out of* the one inside it. A workflow is a bundle of habits. A role is a bundle of workflows. A function is a bundle of roles. The enterprise is a bundle of functions. The ladder is not five different projects. It is the same unit of change, composed upward. That is why the order is not optional. Rung five is *literally made of* rung four, which is made of rung three, and so on down. A re-aligned enterprise with no re-formed functions inside it is an org chart with nothing running in it. You cannot restructure your way to habits nobody has built. You compose your way up. ## The two ways to get it wrong Almost every company gets the scope wrong in one of two directions. They think too *small*: a drawer full of clever personal practices, a team that is quietly good at prompting, and nothing that has changed at the level of a process or a role. Real, useful, and invisible on any measure the board cares about. Or they think too *big*: a rung-five announcement, a transformation office, a slide that says the company will be AI-native by a date, and underneath it not one workflow that runs a new way. That is how a strategy becomes a pilot in purgatory. The discipline is to name the rung honestly, pick the largest one you can actually make real this quarter, and then climb. It is the same lesson as [solving small to unlock the institutional](/stop-swinging-for-the-fences/): the point of the small rung is not the small rung, it is that it is the only honest way to reach the big one. ## Scope is only half the question The ladder tells you *how much* has to change. It says nothing about *what kind* of win you are chasing, and there are only two kinds. You are either doing today's work faster, which is efficiency, or doing something you genuinely could not do before, which is new capability. A faster regulatory draft is efficiency. A model that reads every historical assay you have ever run and surfaces a pattern no human had time to look for is new capability. Both are worth having. But for a biotech they are not equal, because the second kind is the entire reason the field exists. Efficiency gives you back hours. New capability gives you translational science you could not otherwise do, which is the only kind of win that reaches a patient. When we start publishing real case studies against this ladder, every one of them will be tagged on both axes: which rung, and which kind. Watch which cells fill in. The efficiency-at-small-scope corner is easy and crowded. The new-capability-at-real-scope corner is where the companies worth studying actually live. One honest caveat for clinical-stage readers. Every rung here lives *inside* your company, and yet [most of your science lives outside it](/artifacts/clinical-stage-ai-map/), across your CROs and CDMOs. Changing how work flows across that boundary is a scope of its own, above the enterprise and harder than all of it, because you do not control the people on the other side. We will get there. Build the rungs inside your walls first. ## Monday morning Take the loudest AI initiative in your company right now, the one with a name and a champion. Say out loud which rung it actually is. Not which rung it was announced as, which rung it *is*: a habit, a workflow, a role, a function, or the whole company. Then ask the only question that matters. Is the rung below it real yet? If you are aiming at a re-formed function but no single role inside it has been amplified, you have found your real starting point, and it is one rung lower than you thought. Start there. That is not a retreat. That is how you build something that holds. The full framework, the five rungs and the two axes, lives on [The Scope Ladder](/scope-ladder/). --- ## [FAQ] Where do I actually start with AI at my biotech? Canonical URL: https://translationalintelligence.com/faqs/where-do-i-start/ Date: 2026-07-01 Summary: The honest first move is not a tool or a task force. It is one workflow, one owner, and one real question. I get this one almost every day, usually from a CEO who has already been pitched ten platforms and is no closer to an answer. Here is the honest version. Do not start with a tool. Do not start with a task force, a strategy offsite, or a backlog of three hundred use cases. Those all feel like progress and produce none. Start with one workflow that matters. Not the easiest one, and not the one with the loudest AI request. One that carries real weight for the science or the business. Give it a single owner whose job is the outcome, not the software. Then ask two questions about it. If we designed this today, knowing what these systems can now do, what would we build? And what is actually stopping us, a hard constraint or a habit we inherited? The gap between those two answers is your starting point. It is concrete, it belongs to someone, and it will teach you more about transforming your company than any platform demo. Do that once, learn from it, and do it again. That is the whole method, and it is why I called this [translational intelligence](/translational-intelligence/) in the first place. If you want the long version, read [The Biotech of Tomorrow](/the-biotech-of-tomorrow/) and [Permission, People, Programs](/permission-people-programs/). --- ## [FAQ] Which pillar should I fix first? Canonical URL: https://translationalintelligence.com/faqs/which-pillar-first/ Date: 2026-07-02 Summary: Not the one you like to show off. Start with the pillar you are worst at, and it is usually People. Grade yourself honestly on all three, then start with your weakest, not your favorite. Almost everyone wants to start with Permission, because writing a policy feels like progress and it threatens no one. But a clean policy sitting on top of people who work exactly the way they did last year has changed nothing. The pillar that decides the outcome is almost always People, because behavior is the hardest and least visible part. Someone can have the tool, the training, and the policy in front of them and still not change how they do the job. If your governance is tidy but adoption is flat, you have Permission without People, and no amount of new policy will fix it. So the honest first move is to find one place a respected person on your team would change their Tuesday, and make that real. Then the other two pillars have something to grow around. The full model is on [Permission, People, Programs](/permission-people-programs/). --- ## [FAQ] How do I tell a real build from rebuilding a commodity? Canonical URL: https://translationalintelligence.com/faqs/real-build-or-commodity/ Date: 2026-07-03 Summary: One test. Could you buy it, and would buying it cost you nothing that matters? Then it is a commodity. There is a single test. Could you buy this, and if you did, would you lose nothing that sets you apart? If yes, it is a commodity. Buy it, and do not let pride talk you into a custom version of software the market already builds better. You build for two reasons. You cannot buy it, because your proprietary data and your particular workflow are the whole point and no vendor has them. Or you will not buy it, because it is bespoke enough that a vendor implementation would cost more work and compromise than building it yourself. Everything else is a system of record you should license. The trap in this era is rarely too little building. With AI in hand, it is building the wrong things: rebuilding the commodity while the small, differentiating tools go unbuilt. Route each request on purpose. The whole discipline is on [Buy the Record. Build the Intelligence.](/buy-record-build-intelligence/) --- ## [FAQ] Do I hire an AI Product Partner, or grow one? Canonical URL: https://translationalintelligence.com/faqs/hire-or-grow-ai-product-partner/ Date: 2026-07-05 Summary: Usually grow one, from someone who already understands the work. The scarce half is judgment, not tools. Grow one, in most cases. The role rewards range over pedigree: product judgment, enough technical fluency to tell commodity from advantage, real curiosity about how your scientists and operators work, and the humility to discover the original problem was the wrong one. The tool fluency is the easy half to teach. The judgment and the empathy are not. So look first for someone who already knows a function well enough to see its friction, and whom people trust, then give them the AI fluency and the standing to act. Standing matters more than the reporting line. They need real authority across Permission, People, and Programs, not a seat buried in a backlog taking tickets. Where do they sit? Close to the work, not off in a central lab. The whole point of the role is to live where capability meets the work, and to change how it happens. The full role is on [The AI Product Partner](/ai-product-partner/). --- ## [FAQ] Are we AI-native, or just AI-enabled? Canonical URL: https://translationalintelligence.com/faqs/ai-native-or-ai-enabled/ Date: 2026-07-06 Summary: One question tells you. What has your company reconsidered, versus just sped up? Ask one question. What has your company actually reconsidered, versus just made faster? If your workflows, your approval chains, your job descriptions, and your measures of value are the same as before, only now with a copilot bolted on, you are AI-enabled. You are quicker at the same documents, the same meetings, the same decisions in the same order. That is efficiency, and it is the old company with better throughput. AI-native means you treated those inherited assumptions as the actual work, and asked which of them should still exist now that the constraints that created them are gone. It is not a finish line or a particular tool. It is a capacity to keep reconsidering as the ground shifts. Most companies choose efficiency and call it transformation, because efficiency threatens no one and redesign does. The tell is whether anyone has changed what they decide, not just how fast they decide it. The full picture is on [The AI-Native Biotech](/ai-native-biotech/). --- ## [FAQ] What if legal wants a longer, stricter AI policy? Canonical URL: https://translationalintelligence.com/faqs/longer-stricter-policy/ Date: 2026-07-07 Summary: A longer policy no one reads protects no one. The one-page version is not lax; it is the enforceable one. Take the question seriously, then push back on the premise. A longer, stricter policy that no one reads or can follow does not protect you. It protects the person who wrote it. The one-page version is not lax. It is the only kind that gets followed, which is what protection means. Give legal the two things that carry all the weight. First, data sensitivity decides the environment: confidential information goes only into contracted, enterprise-secure tools you have approved, and everything else is fair game. Second, accountability is total and human: there is no AI work product, only AI-assisted human work product, and the author of record owns all of it. If legal wants more, add specifics for the few genuinely high-stakes cases, regulatory, clinical, legal, and stop there. Every clause past a page trades real adoption for the feeling of coverage. Take the one-page version and adapt it: [A Lightweight AI Use Policy](/artifacts/ai-use-policy/). --- ## [FAQ] How do I run build-versus-buy in a real meeting? Canonical URL: https://translationalintelligence.com/faqs/run-build-vs-buy-in-a-meeting/ Date: 2026-07-08 Summary: Out loud, with the people who own the requests. Route the three loudest, then the three smallest. Do it out loud, with the people who own the work, not on a spreadsheet by yourself. Take your three loudest AI requests. Route each one, in front of the room, through the five options: self-serve, buy, build, redesign, do nothing. Say why out loud. If all three come back build, stop, because you are almost certainly about to rebuild a commodity you could license. Then do the harder half. Take the three smallest problems your best people keep hitting, the ones too minor to make any roadmap, and pick one to build this week. That is where adoption is won, and adoption is the whole game. Give the routing a permanent owner whose job is to know the difference, and put a date on the calendar to re-route your biggest builds, because the line moves as the market moves. The one-page tool is [The Build-vs-Buy Decision Framework](/artifacts/build-vs-buy/). --- ## [FAQ] Doesn't thinking with AI make writing slower? Canonical URL: https://translationalintelligence.com/faqs/doesnt-this-make-writing-slower/ Date: 2026-07-10 Summary: At first, and that is the point. You are buying depth, not speed. Over a few pieces it is faster. At first, yes, and that is the point. You are not buying speed. You are buying depth, and depth is the thing worth having. The fast path, hand the model a prompt and take its clean draft, feels quicker right up until you notice the argument was never yours and cannot survive a hard question. Then you rewrite it, or worse, you ship it. That is not fast. That is expensive. Used to make the problem harder before it makes the prose easier, AI gets you to a sharper claim than you would have reached alone, and it gets you there without hollowing out your own thinking. Over a handful of pieces it turns out faster, because you stop rewriting drafts that cohered before they earned it. Slower on the first draft, quicker to something true. That is a trade worth making every time. The method is on one page: [The Think-Harder Writing Workflow](/artifacts/think-harder-workflow/). --- ## [FAQ] How do I get AI to write in my voice? Canonical URL: https://translationalintelligence.com/faqs/get-ai-to-write-in-my-voice/ Date: 2026-07-11 Summary: Do not describe your voice. Show it. Feed the model your real writing and correct what it gets wrong. Stop describing it. Everyone tells the model to be clear, smart, and concise, and everyone gets back the same thing, because those words describe no one. Your voice is a pattern of decisions, not a list of adjectives: what you notice first, where you put the tension, which comparisons you reach for, what you refuse to exaggerate, which sentences feel dishonest coming from you. You cannot recite that from memory. You derive it from evidence. So feed the model several things you wrote yourself, from different rooms, and have it find the recurring patterns. Its first read will grab the surface, that you favor short sentences, say, while missing that your real signature is moving from a concrete detail to a first-principles claim. Correct it. Every correction, this is too polished, I would never say that, the argument is cleaner but less true, makes your taste explicit, and that accumulated judgment is worth more than any prompt. The full guide is [How to Write With AI Without Sounding Like It](/artifacts/ai-writing-style-guide/). --- ## [FAQ] How do I audit my own company against its own rules? Canonical URL: https://translationalintelligence.com/faqs/how-to-self-audit/ Date: 2026-07-12 Summary: Write the rules down first, most cannot, then check your loudest AI work against them, in public. Write your rules down first. Most companies cannot, and that is the first and largest gap, because a rule you have not written is a rule you cannot be held to. Once they exist, take the work you are proudest of, the AI strategy you would show the board, and check it against them line by line. Where did you break your own standard? A rule you write down only means something if the gaps get closed, not just noted. Do it in the open, gaps included. A case study that shows only the wins is exactly the premature coherence worth distrusting. The value of holding yourself to a written standard is that the gaps come out small and findable, instead of large and hidden. A company that never audits itself against its own rules does not have fewer gaps. It just has not looked. See it done, on this publication itself: [Built by Its Own Rules](/case-studies/built-by-its-own-rules/). --- ## [FAQ] What's a passing score? Canonical URL: https://translationalintelligence.com/faqs/whats-a-passing-score/ Date: 2026-07-13 Summary: There isn't one. You are only as native as your weakest pillar, so the goal is not a high number, it is a rising floor. There is no passing score, and chasing one is its own mistake. The scorecard is not a test you clear once. It is a floor you raise, and the only number that matters is your lowest pillar, because [Permission, People, and Programs](/permission-people-programs/) grow together or none of them grows. That changes what "good" looks like. A company sitting at a steady *Practiced* on all three is in far better shape than one showing *Native* on Permission, *Native* on Programs, and *Absent* on People, even though the second one has two perfect scores. The first company has a high floor. The second has a wall with a hole in it. So do not celebrate your tallest pillar, and do not try to reach Native everywhere at once. Native on every pillar is not the target, and for most functions it is not even the right ambition this year. The healthy pace is one level, on your lowest pillar, per quarter. Grade honestly, raise the floor, put a date on the calendar, and grade again. If you want the tool, it is [the Permission, People, Programs Scorecard](/artifacts/ppp-scorecard/). If you are not sure which pillar to move first, that has [its own answer](/faqs/which-pillar-first/). --- ## [FAQ] What will the first 90 days cost? Canonical URL: https://translationalintelligence.com/faqs/what-will-90-days-cost/ Date: 2026-07-15 Summary: Mostly attention, not budget. The real cost is one owner's 20% and an honest scorecard meeting. If you are writing a big check in the first quarter, you are doing it backwards. Mostly attention, not budget. The real cost of the first quarter is one owner's 20% of a week and the honesty of a single scorecard meeting. Almost everything else you need, you already have, because the licenses are usually sitting in a drawer and the point of the [first 90 days](/artifacts/first-90-days/) is to use them, not to buy more. So resist the instinct to make it expensive. Writing a big check feels like commitment, and commitment feels like seriousness, but at a sub-100-person company the serious move is the cheap one. Do not buy a platform in the first quarter. You have not yet earned the signal that tells you which one you need, and once you have shipped a workflow or two, you may find you never needed it at all. Run each request through the [five moves](/artifacts/build-vs-buy/) before any money moves. The genuinely expensive version of this is the one you are trying to avoid: buy the platform first, adopt it never, and spend the next year explaining a line item that changed nothing. Spend attention this quarter, not budget. If you want the week-by-week version, it is [The First 90 Days](/artifacts/first-90-days/). --- ## [FAQ] Who on my team should own AI? Canonical URL: https://translationalintelligence.com/faqs/who-should-own-ai/ Date: 2026-07-16 Summary: The T-shaped operator your people already trust, not your most technical person and not an outside hire. Look for the shape, not the title. Look for a shape, not a title. The right owner is T-shaped: deep enough in one part of the work to be respected, broad enough to see across the whole company, and genuinely curious about what the tools can now do. They can spend about 20% of their week on this without dropping the job you already value them for. In practice that is often a chief of staff, a head of operations, or a respected program lead. It helps to be clear about who it is *not*. It is not your most technical person by default, because the job is translation and trust, not engineering, and your best builder is often not your best persuader. It is not an outside hire, because the hardest part of the work is [changing how respected colleagues do their jobs](/permission-people-programs/), and that trust does not transfer with a contract. And it is not simply your loudest AI enthusiast, because enthusiasm is not the same as the trust of the room, and this job runs entirely on that trust. So the test is simple. Who already gets listened to, across functions, and would be curious enough to spend a fifth of their time here? That person is your owner. The full model for running it at your size is [The Small-Team Operating Model](/artifacts/small-team-operating-model/), and the role it scales down from is [the AI Product Partner](/ai-product-partner/). --- ## [FAQ] Can I use AI in a validated workflow? Canonical URL: https://translationalintelligence.com/faqs/ai-in-a-validated-workflow/ Date: 2026-07-17 Summary: Two different questions usually hide in that one. Drafting a document a human owns is not the same as putting AI inside a validated system of record, and mostly the second is where validation bites. Regulatory Two different questions usually hide inside that one, and much of the time they have different answers. What follows is the shape of the constraint, with the controlling sources linked, not legal advice. Confirm the specifics with your own quality and regulatory function. If AI is drafting a document a qualified human owns and reviews, a clinical study report, a safety narrative, a submission summary, you are mostly in People and Programs territory. The human is the author of record, your normal quality review still applies, and the main environment question is the data class from your [AI Use Policy](/artifacts/ai-use-policy/): patient data and unfiled results stay in your approved, enterprise-secure environment. That is closer to your existing accountability applied to a faster first draft than to a new regulatory frontier. It is not automatically free of validation questions, though: if that draft is generated or maintained inside a system that keeps a regulated record, the intended use, the inputs, and how the output is used can still pull it across the line. If AI is becoming part of a system that creates or maintains a GxP record, that is a different matter. Now you are in computer-system-validation and [21 CFR Part 11](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) territory, records the agency has to be able to trust, with audit trails, access controls, and validation. It is your quality and regulatory function's call, not something to route around. Do not relitigate that gate out of principle. Do the Permission work once, choose controls you can stand behind, and bring quality in early. If the AI is being used to help establish safety, effectiveness, or quality, the FDA's 2025 [draft guidance on AI to support regulatory decision-making](https://www.federalregister.gov/documents/2025/01/07/2024-31542/considerations-for-the-use-of-artificial-intelligence-to-support-regulatory-decision-making-for-drug) sets out a risk-based credibility framework tied to the model's context of use. Most of the early value sits in the first case, not the second. So start where a human owns the output and the data is already yours to use, prove it, and let your quality function help you move the harder line deliberately. The full picture is [Where AI Touches a Clinical-Stage Biotech](/artifacts/clinical-stage-ai-map/). ## Sources - FDA and EMA, [Guiding Principles of Good AI Practice in Drug Development](https://www.fda.gov/media/189581/download) (January 2026), ten joint principles spanning the medicine lifecycle, from research through manufacturing and safety monitoring ([EMA announcement](https://www.ema.europa.eu/en/news/ema-fda-set-common-principles-ai-medicine-development-0)) - FDA, [21 CFR Part 11, Electronic Records; Electronic Signatures](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) (eCFR, current) - FDA, [Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products](https://www.federalregister.gov/documents/2025/01/07/2024-31542/considerations-for-the-use-of-artificial-intelligence-to-support-regulatory-decision-making-for-drug) (draft guidance, Federal Register, January 2025) - ICH, [E6(R3) Good Clinical Practice](https://www.ema.europa.eu/en/documents/scientific-guideline/ich-e6-r3-guideline-good-clinical-practice-gcp-step-5_en.pdf) (Step 4 reached January 2025; linked here as EMA's Step 5 implementation), on computerised systems and data integrity - EMA, [Reflection paper on the use of AI in the medicinal product lifecycle](https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline) (2024) --- ## [FAQ] Which rung of the ladder should I start on? Canonical URL: https://translationalintelligence.com/faqs/which-rung-should-i-start-on/ Date: 2026-07-19 Summary: Almost always one rung lower than your instinct. Start where you can make something real this quarter, then compose upward. Almost always one rung lower than the one you want to announce. The [Scope Ladder](/scope-ladder/) has five rungs, from a personal habit you build in an afternoon to a company you re-align over a year. The instinct, especially right after a good board meeting, is to reach for the top: re-form the whole function, re-align the enterprise. The instinct is wrong, not because the ambition is wrong but because the higher rungs are *built from* the lower ones. You cannot re-form a function whose individual roles have never been amplified. You would be drawing an org chart with nothing running inside it. So here is the honest first move for most companies. Start at rung two, the [workflow](/only-five-moves/). Pick one process that carries real weight for the science or the business, not the easiest one and not the one with the loudest AI request. Give it a single owner whose job is the outcome, not the software. Rebuild it around what these systems can actually do now, rather than bolting a model onto the version you inherited. That is small enough to finish this quarter and large enough to teach you something a personal habit never will. Why not rung one? You probably already have rung one, whether you named it or not. Someone on your team is quietly using these tools well. That is worth surfacing and celebrating, because it is how belief spreads, but it is not yet a transformation of anything. Why not rung four or five? Because you have not earned the information yet. Every rung you climb teaches you what the next one costs, where your data is weak, and which habits are load-bearing. Skip that and you are budgeting a restructure on guesses. Do one workflow all the way through, learn from it, and let what you learn tell you whether the next move is a second workflow, the same person's whole [role](/ai-product-partner/), or the [function](/artifacts/small-team-operating-model/) around them. The whole method is one honest rung at a time, in order. It is the same answer as [where to start at all](/faqs/where-do-i-start/): one workflow, one owner, one real question, done before you start the next. --- ## [Case Study] Built by Its Own Rules Canonical URL: https://translationalintelligence.com/case-studies/built-by-its-own-rules/ Date: 2026-07-11 Summary: The strongest test of a system is whether its author will use it. This publication was built with the exact framework it teaches, AI-assisted and human-accountable. Here is how, including where I was breaking my own rules. The strongest test of a system is whether its author will use it. Not describe it, not sell it, use it, on their own work, in public, where the gaps show. So here is the most honest thing I can hand you: this publication, built with the exact system it teaches. Every claim in it, applied to itself. ## What this is [Translational Intelligence](/translational-intelligence/) is the capacity to turn new capability into durable advantage, again and again, as the technology moves. This site is that capacity made concrete. It has a [system](/permission-people-programs/), a [discipline](/buy-record-build-intelligence/), a [role](/ai-product-partner/), and a [destination](/ai-native-biotech/). I did not only write about them. I built the thing you are reading by their rules, and this is the accounting. ## Buy the record, build the intelligence The stack is a live example of [the discipline](/buy-record-build-intelligence/). I bought the commodity, the system of record, and I built the layer that is mine. > [Diagram: Bought the record, built the intelligence] Astro and Keystatic hold the pages. Beehiiv sends the email. Cloudflare serves it, GitHub holds the source, and the frontier models do what frontier models do. None of that is where the advantage lives, and writing my own would have been vanity. What I built is the layer that is genuinely mine: the design language, a signature diagram in every piece, the [Artifact Library](/artifacts/), the voice, and the way every page links into one connected argument instead of a feed. No vendor could sell me that, because no vendor has my problem. And it leans build more than the old wisdom would, on purpose. The [ethos](/stop-swinging-for-the-fences/) is that in this era the line has moved toward build, and that adoption is won by solving small. This site is a stack of small builds, each one shipped before the next was started. ## There is no AI work product Here is the part most publications about AI will not say out loud. This one is AI-assisted. I use AI to draft, to argue with, and to build the site itself. And [there is no AI work product, only AI-assisted human work product](/there-is-no-ai-work-product/). I am the author of record. Every claim, every number, every diagram, I own completely, whether I, a colleague, or a model produced the first version. That is not a hedge or a disclaimer. It is the standard I ask you to hold, and I am holding this publication to it in the open. A standing note now sits on the [About](/about/) page, because I preach disclosing AI assistance where it is material, and for a publication about using AI well, it is material. ## I do not automate the struggle I do not use AI to skip the thinking. I use it to reach the hard part more often. The ideas start with me: an argument I have been circling, a contradiction I cannot yet resolve, a claim I suspect is true but cannot defend. Only then do I put the model to work, and I put it to work making the problem *harder*, not finishing it. The [Think-Harder Writing Workflow](/artifacts/think-harder-workflow/) is not a theory I admire. It is the process that produced every piece here, this one included. ## Where I was breaking my own rules A case study that shows only the wins is exactly the *premature coherence* I warn about. So before I published this, I audited the site against its own written rules. Here is what I found. Every Issue is supposed to carry its own signature diagram. When I ran this audit, the founding piece was the one exception. It has one now, added the same day I wrote this. A rule you write down only means something if the gaps get closed, not just noted. I preach disclosing AI assistance where it is material, and until this study there was no disclosure anywhere on the site. That was a real gap in the thing I most insist on. It is why the [About](/about/) note now exists, and why this case study does. The cadence labels, the Tuesday and Friday stamped on everything, had drifted from useful into decorative, so I cut them back to where they inform. None of these are catastrophes, and that is the point. The value of holding yourself to a standard you wrote down is that the gaps come out small and findable, instead of large and hidden. A company that never audits itself against its own rules does not have fewer gaps. It just has not looked. ## Monday morning If you want to know whether a system is real, watch whether its author will apply it to themselves, in public, with the gaps left in. Try the thing this piece just described. Take your own AI strategy, the version you would show your board, and audit it against the rules you have written down. If you have not written the rules down, that is the first gap, and it is the biggest one. Then fix the smallest thing you find this week. That is where it starts. It is where this started too. --- ## [Case Study] Better Than a Blank Page Canonical URL: https://translationalintelligence.com/case-studies/better-than-a-blank-page/ Date: 2026-07-20 Summary: A wall of INDs and BLAs the writing team could not reach, and twelve months of no. Then three days in a room proved that a first draft at 60 to 75 percent beats a blank page, and a resistant team finally had its aha. A company had a wall coming. A stack of INDs and BLAs to file that ran well past what the regulatory writing team could physically reach in the time it had. The math did not work, and everyone could see it. The executive team wanted regulatory to trial AI for first drafts. Regulatory said no. Not once, and not briefly. For twelve months. ## Twelve months of no The resistance was not stupidity. It was a writing team that owns some of the highest-stakes documents in the company, being asked to trust a new tool with exactly the work they are most accountable for. Caution there is a feature, not a bug. But caution and a filing wall do not resolve themselves, and for a year they did not. It took a member of executive leadership to step in and mandate a trial. That is not a small thing to notice: the change did not start with the team's consent. It started with [Permission](/permission-people-programs/), used deliberately, because the stall had become more dangerous than the risk everyone was worried about. ## Three days in a room The company signed an expensive paid trial with a vendor. A six-figure trial. And then, alongside it, we ran a head to head. I sat in a room for three days with [my AI Product Partner](/ai-product-partner/), ChatGPT, and NotebookLM, and we drafted first-draft sections of an upcoming IND. Not a demo document. Real sections the team would not otherwise have reached for six months or more, buried under the backlog. Two things came out of that room. First, our drafts, produced with nothing but our standard enterprise agreements and no six-figure vendor, were far superior to what the paid trial produced. Second, and this was the one that mattered, several members of the writing team were dumbfounded. The drafts were not perfect. They were roughly 60 to 75 percent of the way to a usable first draft. But 60 to 75 percent is not the number that matters. The number that matters is that it is not zero. > [Diagram: An AI first draft clears the blank page; human authors do the decisive work] ## The aha A blank page is the most expensive thing in regulatory writing. It is where the backlog lives. Handing a writer a section that is already 60 to 75 percent of the way there does not replace them. It starts them far past the hardest part, and it gives them their time back for the judgment that actually needs a human. The team saw that, in their own document, in real time. That was the aha, and after twelve months of no it arrived in an afternoon. The momentum after it was enormous, and it did not come from the mandate. The mandate only bought the demonstration a chance to happen. The demonstration is what changed minds, because a regulatory writer watching a real draft of their own work appear is worth more than any number of assurances that the tool is safe. ## What it actually was Be precise about this, because in regulated work the precision is the whole point. *No AI-generated text went to the FDA.* None of it. The first drafts were used as framing and ideation, a running start on structure and language, and then the team did the hard work themselves: the sourcing, the argument, the precision, the review, the rewriting. The draft was scaffolding, taken down once the building stood. Every section went through the standard writing process, and the [author of record was human](/there-is-no-ai-work-product/) from start to finish. What the tool removed was the busywork at the front of the job. What it never touched was the work that reaches a regulator. In regulated documents that line is not a nicety, and it did not move an inch. ## What does not transfer Copy the lesson, not the setup. The trial only happened because an executive spent real capital to force it after a year of stall. Without that Permission, the wall just gets closer. A demonstration nobody will authorize never converts anyone. The six-figure vendor was not the villain, but it was the wrong first move. The capability we needed was already inside tools we already paid for, and nobody had tested that baseline before signing the check. That is the whole point of asking [whether to self-serve before you buy](/buy-record-build-intelligence/): sometimes the honest answer is that you already own it. This is not a rule that vendors never add value. It is a rule that you test your own baseline first, because a paid trial is a strong claim to make before you have proven you cannot do it yourself. And a 60-to-75-percent draft is a starting point, not a submission. Treating it as finished, especially in regulated work, is how you turn a good tool into a real liability. AI-drafted regulatory content has to go through your full human writing, review, and quality process, and what that process must include is a question for [your own quality and regulatory function](/artifacts/clinical-stage-ai-map/), not for a case study. The win here was escaping the blank page. It was never skipping the work. ## Monday morning Find the workflow that is drowning in backlog, the one where the team is underwater and everyone can see the wall. Before you sign a large vendor trial, run a real head to head with the tools you already own, on a real document, with someone credible in the room. Keep humans as the authors of record and route every draft through your normal process. Then let the demonstration do what twelve months of argument could not. This is rung two on the [ladder](/scope-ladder/), a single workflow re-run a new way. But watch what it starts, because a team that has felt the blank page disappear rarely stops there. --- ## [Case Study] The Task Was Never the Point Canonical URL: https://translationalintelligence.com/case-studies/the-task-was-never-the-point/ Date: 2026-07-20 Summary: A junior analyst automated one repetitive task in an afternoon. The hours saved were trivial. What it started was not. One convert became an AI Ambassador, and a whole department began to reimagine its work. "Start small" is easy to say and hard to believe, because the smallest starts look too small to matter. Here is one that looked like nothing and turned into a department. ## The task beneath everyone's notice On the procurement team at a clinical-stage biotech, a junior analyst had a job he did on autopilot. Every time the company onboarded a new vendor, he drafted the same email, attached the same four PDFs, and sent it. Same words, same files, every time. It was not hard. It was not interesting. It was just there, a small tax on every new vendor, paid by hand. He was also, by the org chart, nobody's priority. Too junior to command an engineering team's attention, too small a problem to carry a business case. In most companies that is the whole story: the irritation is real, the person is willing, and the system never connects the two. The work stays manual because nobody with the tools ever sits with the person who has the problem. ## We only found it because we went looking low The AI team ran what we called 20% time on lifestyle improvements: a standing invitation to bring us the small, personal, unglamorous friction in your day. Not the strategic initiative. The thing that annoys you every Tuesday. He brought the vendor email. The fix was, honestly, trivial. A small automation assembled the standard message, pulled in the same four attachments, and produced a finished draft in one click. It eliminated the task, permanently. Measured in hours saved it was a rounding error, the kind of thing a transformation office with a business-case template would never green-light. > [Diagram: One small win compounds into an organizational shift] ## Governed from the first line And it was governed from the start. The tool could only ever *draft*. It never sent. He stayed the author of record: he read every draft, approved it, and hit send himself. That was not a control we bolted on later. It is [the standard the whole company runs on](/there-is-no-ai-work-product/), and it applied to a four-PDF onboarding email exactly as it applies to a regulatory submission. A machine drafting the words did not move his accountability by an inch. ## Where the rounding error stops being a rounding error The analyst did not just get his afternoon back. He became a believer, because the thing worked and it was *his*. He joined the AI Ambassador program, the distributed network of non-experts who carry capability into their own functions, which is [the People pillar](/permission-people-programs/) in motion. He became the person in procurement who had actually done it, standing in front of his peers as social proof no central team could manufacture. Then it compounded. Through his coaching, his teammates stopped asking "can you automate this one email?" and started asking the bigger question: how would we run this whole process if we designed it today, knowing what these tools can do? One eliminated task became a function learning to interrogate its own workflows. The change moved up the [Scope Ladder](/scope-ladder/) on its own, from a personal practice toward a function beginning to reimagine itself, because one credible person had felt what was possible and would not stop talking about it. ## Why the smallest rung was the right start This is the whole argument for starting at the individual level, and it is not the automation. The hours saved were never the point. The product was *belief*, and belief travels through people, not licenses. A respected peer who has done the thing, in the open, outweighs any all-hands slide. That is exactly what the [Personal Practice rung](/scope-ladder/) is for: its real output is not productivity, it is a convert who becomes a change agent. ## What does not transfer Do not copy the automation. It is worthless to you, because your tasks are different. What transfers is the sequence, and it has failure modes worth naming. It only worked because someone with the tools sat with someone who had the problem, on time the company had deliberately set aside. Cut the 20% time and this never happens; the analyst keeps sending the email by hand for another three years. It only compounded because there was an [Ambassador program](/permission-people-programs/) to catch the convert and hand him a role. A win with nowhere to go stays a private win. And it would have died in a spreadsheet if anyone had graded it on ROI. Measured as efficiency, it was nothing. Its entire value was in what it started, which no hours-saved metric will ever show you. A company that funds only what pencils out will never fund the thing that shifts its culture. You also cannot manufacture an acolyte. You can only build the conditions: dedicated time, genuine listening, a real win, and a path for the person to become a teacher. Then you let a true thing do what true things do. ## Monday morning Find your most junior person's most repetitive task. Not the one with the biggest return. The one that is beneath everyone and quietly annoys someone every week. Eliminate it, with someone who has the tools sitting beside the person who has the problem, and keep the human as the author of record. Then watch what the convert does next, and make sure you have somewhere for them to go. It is the smallest rung on the [ladder](/scope-ladder/). It is also where more transformations should start than do. ---