{
  "video": {
    "id": "3ZlQk4-knWM",
    "title": "Deploying AI Inside a Bank Is Not an Engineering Problem — Paden Gayle, Applied AI Engineers",
    "duration": 907,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": ""
  },
  "analysis": {
    "video_id": "3ZlQk4-knWM",
    "title": "Deploying AI Inside a Bank Is Not an Engineering Problem — Paden Gayle, Applied AI Engineers",
    "one_liner": "An AI demo can work and still never ship in a bank. In week one, find the owners behind data, model risk, third-party risk and audit, so the design is built around the decisions it depends on.",
    "summary": "Paden Gayle (spelled 'Payeyton Gail'/'Peyton Gail' in the auto-transcript) argues that bank AI deployments stall because nobody brought in the people who own the deciding approvals early enough. Using a hypothetical 'document exception assistant' that reviews client documents and drafts exceptions for an analyst, the talk covers: mapping owners through the org chart; scoping with 'shadow, draft, and shrink'; starting at the lowest useful step of an autonomy ladder; and building a five-file evidence pack the risk team can use. The theme is 'discovery is the engineering.'",
    "key_points": [
      "Four decisions a deployment depends on, each needing a named person who can explain it, the evidence they need and the next step: data (who owns the source, grants access and approves this use), model risk (which review applies; what a previous submission looked like; who owns the system after launch), third-party risk (draw the real dependency chain: model provider, host arrangements and your role in the operating service) and audit (what someone needs to reconstruct a consequential action: input, configuration, what the reviewer saw, who approved).",
      "'Every data set has an owner.' From his Bloomberg data-platform work: building LLM infrastructure meant knowing which data sets could be used and who could approve that use. Being able to query a data set does not settle how the application may use it.",
      "Discovery-call questions: where the data lives and who approves reading it; who has stopped a similar project before and why; which existing controls could cover the workflow; where production runs and who administers it; who signs the risk review and what they've signed before; and what obligation the sponsor is personally worried about. Leave with names, decisions or next conversations, and by Friday make sure each owner knows the project exists.",
      "Scoping without a spec uses 'shadow, draft, and shrink': sit with an analyst and record the systems they open, where they make judgments and when they ask permission. Then draft three lines (review documents, draft exceptions, analyst submits), make each one specific, and let the sponsor and control owners cross things out.",
      "Scope grows as a series of approval questions: summarize a document the analyst already has, then read from a second system (a new data path), then draft content a customer sees, then send automatically (who owns it, and how do you stop and recover). That is four different engineering scopes.",
      "Autonomy ladder, read from the bottom up: Suggest, Draft, Acts with approval, Acts. Start at the lowest step that creates value, then use evidence such as override rates, recurring failures and recoverability to decide whether to give the system more authority. Applied to the example: keep the model but move the action boundary, so the flow becomes model, human, submit instead of auto-filing exceptions.",
      "Evidence pack of five files: intended use (users, boundaries, prohibited actions), data lineage (each source and its use approval), failure modes (detection and fallback), results by segment (coverage and errors) and controls (reviews, thresholds, stopping rules, owners). Each evaluation run preserves the input, prompts, model version, configuration, output and reviewer action, because calling the model again may give a different answer.",
      "Segment the results (clean documents, scans, rare exceptions, new document types) and lead with the weakest one. The Friday heuristic asks five yes/no questions: 4-5 yeses suggests a credible path, 3 means unresolved decisions need owners and dates, and 0-2 means resolve them, or shrink or redefine scope, before committing to delivery."
    ],
    "takeaways": [
      "In week one, build an org-chart map under the architecture diagram: data owner, platform owner, risk reviewer. Turn every question-mark owner into a task with a named person responsible for resolving it, and confirm the proposed use directly with each owner.",
      "When there's no spec, shadow the real workflow, draft a short concrete proposal with success criteria (e.g. less review time with no increase in missed exceptions, measured against the current workflow), and let the control owners shrink it.",
      "Ship at the lowest useful autonomy step, such as a draft inside the analyst's existing workflow with source evidence and visible uncertainty. Only expand authority based on observed overrides, failures and recovery.",
      "Build the evidence pack in sprint one. For each failure mode, name the detection path, fallback and owner, and log inputs, model version, config, output and reviewer action so past decisions can be reconstructed.",
      "Score the five Friday questions (data owner engaged, production environment and admins named, sponsor can describe the workflow without saying 'AI', smallest scope fits existing confirmed controls, risk signer known along with what happened to the last one) and use the score to decide where to spend next week."
    ],
    "topics": [
      "enterprise ai deployment",
      "financial services",
      "governance",
      "model risk",
      "human-in-the-loop",
      "evals",
      "discovery",
      "forward deployed engineering"
    ],
    "tools": [
      "Accenture",
      "Bloomberg",
      "Google",
      "O'Reilly",
      "LinkedIn"
    ],
    "quotes": [
      {
        "text": "And here discovery is the engineering.",
        "at": "02:39",
        "url": "https://www.youtube.com/watch?v=3ZlQk4-knWM&t=159s"
      },
      {
        "text": "A model does not become more capable by itself.",
        "at": "09:59",
        "url": "https://www.youtube.com/watch?v=3ZlQk4-knWM&t=599s"
      },
      {
        "text": "An average can hide a serious gap in one segment.",
        "at": "13:21",
        "url": "https://www.youtube.com/watch?v=3ZlQk4-knWM&t=801s"
      },
      {
        "text": "The demo worked. The model was fine. It still did not ship. So what do we do? We go find the people.",
        "at": "14:34",
        "url": "https://www.youtube.com/watch?v=3ZlQk4-knWM&t=874s"
      }
    ],
    "words": 3287
  },
  "summary_url": "/#3ZlQk4-knWM",
  "transcript": {
    "html": "/transcripts/3ZlQk4-knWM.html",
    "txt": "/transcripts/3ZlQk4-knWM.txt",
    "vtt": "/transcripts/3ZlQk4-knWM.vtt"
  }
}