Deploying AI Inside a Bank Is Not an Engineering Problem — Paden Gayle, Applied AI Engineers

Paden Gayle argues that deploying AI, particularly within a banking context, is fundamentally not just an engineering problem. A convincing demo with a functional model often fails to ship due to missing decisions from non-engineering stakeholders like security, data owners, and risk reviewers. He emphasizes that early discovery is paramount, stating, “Discovery is the engineering.” This approach shifts focus from solely technical implementation to organizational integration and risk mitigation.

Uncovering Crucial Decisions in Week One

To establish a credible route to production, it’s essential to uncover critical decisions early. Gayle proposes identifying specific individuals for four key areas:

• Data: Who owns the data source, grants access, and approves its use in the workflow? (e.g., Bloomberg’s data platform experience highlighted that “every data set has an owner”). Being able to query a dataset doesn’t settle all questions about its application.
• Model Risk: Who defines the applicable review for intended use, owns the system post-launch, and what evidence is needed for maintenance? This involves understanding previous submission formats and ongoing ownership responsibilities.
• Third-Party Risk: Mapping the actual dependency chain, including model providers and hosting arrangements, to identify relationships already reviewed and those requiring new decisions.
• Audit: What records are needed to reconstruct a consequential action (input, configuration, output, reviewer action, approval) to ensure accountability and reproducibility. These records affect what must be captured from the beginning.

Bringing these decision-makers into the design process early helps define what can actually be operated, avoiding costly redesigns after significant development. Gayle stresses the importance of making dependencies visible when the design is still pliable. Key questions for discovery include: “Where does the data live and who can approve reading it?”, “Which existing controls could cover this workflow and who owns them?”, and “Who signs the relevant risk review and what have they signed before?” The goal is to leave discovery meetings with names, decisions, or next conversations, confirming needs directly with owners.

Scoping Work: Shadow, Draft, and Shrink

When customer specifications are incomplete, Gayle advocates a “shadow, draft, and shrink” approach:

1. Shadow: Observe the actual work process (e.g., following an analyst, watching systems they open, judgments they make, permissions they seek). Document the actual sequence as the initial specification.
2. Draft: Propose a concrete, simplified workflow. For a document exception assistant, this might be: “Review the documents,” “Draft the exceptions,” and “Analyst submits.” This creates a clear initial boundary.
3. Shrink: Make each step specific (e.g., “Which documents?”, “What should the model produce?”, “Who checks the draft?”). Take this draft to the sponsor and control owners to solicit corrections, which define decision boundaries and buildable requirements. Each correction represents a decision around which the system can be built.

This iterative process helps grow the system incrementally, confirming approvals at each stage. For instance, starting with summarizing documents an analyst already has, then reading from a second system, drafting a customer-facing response, and finally, automatic sending. Each step introduces new risk considerations and requires re-confirmation with decision-makers. The objective is to identify the “smallest useful version” (MVP) with a credible path to approval, ensuring existing controls fit and create useful value.

Gradual Autonomy and Evidence

Gayle advises starting with the least authority necessary to solve the problem, then collecting evidence to justify granting more. He outlines a ladder of autonomy:

• Suggest: Analyst receives recommendations and chooses.
• Draft: System prepares content; analyst checks and submits. This is often a starting point to gather evidence.
• Acts with Approval: A person authorizes each action before it happens.
• Acts: System operates within pre-approved limits.

Each step up the ladder changes the consequences of error, the required controls, and the level of reviewer conviction needed. The “draft” stage is often a good starting point, allowing the collection of evidence on overrides, recurring failures, and recovery mechanisms without full automation risk. Observations from real use inform subsequent decisions about granting further authority.

The Evidence Pack

For robust evaluation and review by risk teams, an “evidence pack” with five crucial files is recommended:

1. Intended Use: Records users, boundaries, and prohibited actions.
2. Data Lineage: Traces each example’s source and use approval.
3. Failure Modes: Documents detection mechanisms and fallback plans, including naming who receives alerts and can stop workflows.
4. Results by Segment: Measures coverage and errors, explicitly highlighting weak segments (e.g., clean documents vs. scans, rare exceptions, new document types). This prevents average performance from masking critical gaps, advocating to “lead with the weakest result” and restrict use where evidence is scarce.
5. Controls: Records reviews, thresholds, stopping rules, and owners.

This pack supports reconstructing historical decisions by preserving inputs, model versions, configurations, outputs, and reviewer actions. “Calling the model again later may produce a different answer,” so preserving what actually happened is crucial.

Week One Deployment Checklist

Finally, Gayle provides a heuristic checklist for deployment readiness by Friday of the first week, based on five key questions:

• Is the data owner engaged and aware? (Yes/No)
• Are the production environment and its administrators named? (Yes/No)
• Can the sponsor describe the workflow without saying “AI”? (Yes/No)
• Does the smallest useful scope fit existing controls, confirmed by their owners? (Yes/No)
• Do we know the risk signer and what happened with previous signings? (Yes/No)

This checklist serves as a planning aid: 4-5 “yeses” suggest a credible path; 3 means unresolved decisions need owners and dates; 0-2 indicates significant issues requiring scope redefinition or resolution before committing to delivery. “This score does not predict approval, but it does tell us where to spend the next week.” The core message remains: “The demo worked. The model was fine. It still did not ship. So what do we do? We go find the people.”

• Tags:
• Enterprise AI
• MLOps
• Risk Management
• System Design
• Change Management
• Regulatory Compliance
• Stakeholder Management
• Project Management
• Data Governance
• AI Deployment
• Organizational Friction
• Discovery Engineering
• Autonomy Ladder
• Evidence Pack