Working at BMO, one of Canada's Big Five banks, while also being someone who follows the AI development space closely has put me in an interesting position. I care deeply about using modern tools to build better software faster. And banking is an environment where every tool, every data flow, and every external service is expected to go through layers of security review, compliance validation, and risk assessment before it touches production.
These two realities are not incompatible, but reconciling them takes a clear-eyed view of where the lines sit and why. What follows is not a defense of enterprise caution and not a complaint about it. It is what I found useful inside the constraints.
The Fundamental Constraint: Data Confidentiality
The most important thing to understand about using AI in banking is that the constraint is not about being anti-technology. It is about data. Banks hold some of the most sensitive personal and financial data in existence: account numbers, transaction histories, credit profiles, business financials, personally identifiable information across millions of customers. The frameworks governing that data in Canada, PIPEDA and the OSFI guidelines among them, are not optional and are not abstract.
When you paste code into a commercial AI chat tool, that code carries context. Variable names, API endpoints, database column names, business logic that hints at product structures. Even if you are not pasting actual customer data, you are revealing confidential system architecture. This is a real concern, and I say that as someone who wants to use these tools as much as possible.
What You Cannot Share With AI Tools
This is my practical working list of what absolutely does not go into any external AI tool in a banking context:
- Any real customer data, even 'anonymized' samples. The risk of re-identification is real
- Internal API endpoint URLs or schemas that are not publicly documented
- Database table and column names from production systems
- Authentication flows, token structures, or security middleware logic
- Business logic that reveals unreleased product features or pricing strategies
- Compliance workflows, audit trail implementations, or regulatory reporting code
- Anything marked confidential, proprietary, or internal in your organization's classification system
- Code from repositories with restricted access
This is not a comprehensive legal list. That is your organization's security team's job. This is my personal operating heuristic. When in doubt, I strip context aggressively before prompting.
What You Can Do With AI in Banking
The list above sounds limiting. The majority of the hard problems in enterprise Angular development are not specific to banking. They are problems of scale, patterns, testing, and architecture. And AI is extremely useful for all of those.
- Generating boilerplate for components, services, and tests using generic or anonymized schemas
- Explaining concepts, patterns, and Angular APIs you know less well
- Debugging TypeScript compilation errors by pasting sanitized error messages
- Refactoring logic using abstract data structures (replacing real field names with generic ones)
- Writing utility functions: date formatters, validators, string transformers. These carry no sensitive data
- Reviewing accessibility: ARIA patterns, keyboard navigation, focus management
- Drafting documentation, comments, or PR descriptions from scrubbed code
- Learning about RxJS operators, signal patterns, or Angular internals
The key skill is abstraction. I have gotten good at translating a real problem into a structurally equivalent but data-neutral version of the same problem. The banking-specific details live in my head and in our internal systems. The AI helps me solve the structural challenge.
A Concrete Example of Safe Abstraction
Here is what the abstraction looks like. The system below is invented for this post, because the real one is not mine to publish, but the shape of the mistake is identical. Say a component polls an endpoint and renders a number from the response, and I want help with the reactivity pattern. This is the version I would never send:
// DON'T DO THIS
Here is our FleetStatusComponent that pulls from the /api/v2/fleet/summary endpoint.
It reads from fleetState.activeVehicles and needs to refresh every 30s...
[actual internal code pasted here]Instead I abstract it completely:
// DO THIS INSTEAD
I have an Angular component that polls a REST endpoint every 30 seconds and displays
a numeric value from the response. Using signals, I need to handle:
1. A loading state on initial fetch
2. A silent background refresh (no loading spinner on re-poll)
3. An error state that doesn't clear the last known good value
The endpoint returns { value: number; lastUpdated: string }.
What's a clean signal-based pattern for this?The second prompt gives me everything I need to solve the real problem and reveals nothing about the system it came from. The technical challenge is identical. The data is generic. That translation step is the whole skill.
Enterprise Approval Processes for AI Tools
Beyond data concerns, enterprise AI use goes through procurement and security review. If your organization is evaluating an AI tool, a code assistant IDE plugin, an enterprise LLM subscription, a GitHub Copilot Business license, expect this process to take months, not days. It involves vendor security assessments, data processing agreements, review of where your data is stored and whether it is used for training, and sign-off from multiple stakeholders.
This is frustrating from a productivity standpoint. By the time a tool clears review, the version you evaluated may be outdated. I have also come to respect why this process exists. A data breach involving a bank's development toolchain is not a hypothetical scenario. It has happened to financial institutions globally. The caution is calibrated to actual risk.
My advice for navigating this: push early and provide evidence. If you want a tool approved, build a business case that includes security documentation, use case specifics, and comparable institutions that have already adopted it. Internal champions who can articulate the risk controls alongside the productivity benefit move faster than pure enthusiasm.
Internal AI Tools: The Better Path
The real answer is not a safer way to use an external commercial tool. It is a model that runs where the data already lives. The free version of that is closer than most people assume. Open-weight models served locally with Ollama or llama.cpp cost nothing beyond hardware you already own, make no network calls at all, and are good enough for the boilerplate, explanation and test-writing work that is most of the daily use anyway. You can prove the idea on a laptop before anyone signs a contract, and a working local demo is a far better argument in a procurement conversation than a slide.
The paid upgrade is the same idea with someone else's GPUs and a signed agreement: a managed deployment inside your own cloud tenancy, where prompts and outputs stay within the organization's boundary. Either way the tradeoff is the same. These models are weaker than the frontier ones you use personally, and you can give them full context. A weaker model with the real problem in front of it beats a stronger model you had to abstract everything for.
If you can influence the decision, argue for the deployment you control over the subscription you do not. The capability gap narrows every few months. The compliance gap does not.
What Productivity Looks Like in Practice
Given all the constraints, what does my actual AI-augmented workflow look like at work? At BMO, the team uses an approved assistant, GitHub Copilot Business, which I configured with guardrails. Within that setup, I use AI for roughly these things, roughly in this order of frequency:
- 1. Generating component and service boilerplate from sanitized specs. This is where the time savings are most obvious
- 2. Writing test cases from described behavior. The scenario-driven prompt pattern I use gets me most of the useful test cases without any sensitive code
- 3. Explaining unfamiliar APIs or Angular internals I encounter in existing code
- 4. Drafting PR descriptions from sanitized diffs
- 5. Refactoring abstract versions of performance problems. Then applying the pattern manually to the real code
I do not use AI for: anything touching authentication, anything that would require sharing internal schemas, any task where the context itself is sensitive. For those, I work the traditional way. Which is still perfectly fast when you have more than a decade of experience.
There is an obvious tension in all of this and it is the first thing a careful reader should ask. If nothing internal goes to an AI tool, what is an IDE assistant doing with the repository open in front of it? They are not the same channel. Copilot Business reads the open workspace under a contract: prompts and suggestions are not retained and are not used to train models, and administrators can exclude paths so the assistant never sees them. That is a reviewed channel with a paper trail. A consumer chat window is not. The abstraction discipline in this post is about the second channel and about anything the contract does not cover. The first is governed by the content exclusion list and by which repositories the license is turned on for, and if you do not know what is on that exclusion list for your own repo, that is the thing to go and find out today.
The Cultural Side: Peer Attitudes
One thing I did not expect is how far apart attitudes toward AI tools sit inside a large organization. Skepticism is common, sometimes about output quality and sometimes about data risk, and both versions are reasonable positions held by good developers. What surprised me more is how many people treat it as binary: either the tool is approved for everything or it is off limits entirely. It is neither. The useful conversation only starts once that assumption is gone.
I try to hold a specific position: enthusiastic about the productivity, rigorous about the constraints, and vocal about better internal tooling. I am not the person telling colleagues what they cannot use. I am the person saying here is how to use this so it does not become your problem six months from now.
What I Would Tell My Past Self
If I could give one piece of advice to someone joining a large financial institution with an AI-forward mindset: do not arrive expecting to plug in your personal workflow directly. The tools you love outside of work may not be approved. The data you would normally give for context is off-limits. That is real, and adjusting takes time.
But the underlying skills of prompt engineering, knowing what to ask and how to structure the question, are fully transferable. You just redirect them. Instead of prompting with full context, you learn to prompt with precise abstractions. Instead of getting a complete solution, you get a structural pattern you apply with your internal knowledge. It is a different rhythm, but not a less productive one once you adjust.
The constraint is not the enemy of productivity. The constraint is the parameter you design around. Engineers do that every day.
References
- Ollama, for running open-weight models locally. https://ollama.com
- Azure OpenAI Service. https://azure.microsoft.com/en-us/products/ai-services/openai-service
- AWS Bedrock. https://aws.amazon.com/bedrock/
- PIPEDA. https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/