AI success isn’t a hiring strategy, it’s a capability you build across the organization.
The previous article described the architecture operating model banks need. That model requires people — specific people with specific skills that most banking organizations do not currently have. This is not a hiring problem. It is a capability-building problem. The distinction matters because the solution is fundamentally different.
The talent required to build and operate an AI-ready bank is genuinely different from what banks employed five years ago. The market does not have enough of it. The enterprise architect who understands both banking and AI system design is the hardest profile to hire — typical searches run six to nine months and often end in compromise on one domain or the other. Model operations specialists are nearly as scarce, with every institution from regional banks to global technology companies competing for the same small pool. Banks that plan to solve this through hiring alone will find themselves in a permanent bidding war for talent that does not exist at scale.
The answer is deliberate upskilling of existing bankers into new roles. Not wholesale replacement of the technology organization. Not outsourcing to consultants who leave when the engagement ends. Building the capability inside the institution where it compounds over time.
AI capability isn’t hired, it’s built through structured upskilling and role evolution.
Enterprise Architects Who Speak Both Languages
The most critical and rarest role is the enterprise architect who understands both the banking domain and AI system design. Most architects know one or the other. Banking domain architects understand deposit operations, lending workflows, regulatory requirements, and payment processing. They can design systems that run a bank. They often have limited understanding of how AI systems consume data, how models are deployed and monitored, or what architectural properties an AI orchestration engine requires.
AI-native architects understand model deployment pipelines, feature stores, vector databases, and agent orchestration frameworks. They can design systems that support intelligence. They often have limited understanding of banking regulatory requirements, core system constraints, or the operational realities of running a financial institution.
The bank needs architects who hold both domains simultaneously. Finding these profiles on the open market is nearly impossible. Building them from within — taking experienced banking architects and deliberately training them in AI systems design — is the only scalable approach.
Data Engineers Who Build for AI
Data engineering in the AI era is not the same as data warehousing. Traditional bank data teams built ETL pipelines that moved data from source systems into a warehouse on a nightly batch schedule. That skill set is necessary but insufficient. AI requires data engineers who can build and govern data products — curated, quality-controlled, semantically consistent data sets designed for consumption by AI models and agents.
We have seen what happens when banks assign traditional data warehouse engineers to AI data work without upskilling. The engineers build what they know: batch pipelines that land data in a warehouse twelve hours after it was generated. The AI team then discovers it cannot run real-time fraud inference because the data is always half a day old. The feature store the data scientists need does not exist because the data team has never built one. The result is a parallel data infrastructure — the official warehouse and a shadow pipeline the AI team built on its own — that no one governs and everyone depends on.
Data products are different from data pipelines. A data pipeline moves data from point A to point B. A data product is a managed asset with a defined schema, quality guarantees, access controls, and a published contract that consumers can rely on. Banks need data engineers who can build these products: engineers who understand streaming data as well as batch, who can implement data quality checks at ingestion rather than after the fact, who can govern the data ontology at the engineering level.
Model Operations Specialists
Model operations — MLOps — is a discipline that barely existed five years ago. It is now critical. Model operations specialists manage the deployment, monitoring, and lifecycle of AI models in production. They build and maintain the CI/CD pipelines for models. They operate the model registry. They configure the drift detection and performance monitoring systems described in the earlier article on operational resilience. They manage the rollback procedures when a model degrades.
This is not a data science role. Data scientists build models. Model operations specialists run them in production. The distinction is the same as the distinction between software development and site reliability engineering. Both are essential. Neither can substitute for the other. Banks that expect their data scientists to also manage production model operations will get neither done well.
AI Risk Professionals
The fourth critical role is the AI risk professional — someone who can evaluate model risk without deferring entirely to the model builders. Traditional model risk management teams understand statistical models. They can validate a logistic regression or a scorecard. AI risk professionals must evaluate models that are fundamentally more complex: deep learning models with millions of parameters, large language models with emergent behaviors, agent systems that chain multiple models into autonomous workflows.
These professionals need enough technical depth to challenge the model builders and enough risk management discipline to identify failure modes the builders did not anticipate. They need to understand explainability techniques, fairness metrics, adversarial attack vectors, and the specific risks of agentic AI systems where models take actions rather than merely producing scores.
Where this role sits in the organization matters. Our view, informed by watching both models succeed and fail, is that AI risk professionals belong in the risk function, not in technology. The moment model risk evaluation reports to the same leader who is incentivized to deploy models quickly, the independence of the validation is compromised. The risk function provides the organizational distance that credible model challenge requires. The technology team provides the technical access. Both are necessary, but the reporting line must protect independence.
The Upskilling Imperative
Each of these roles requires banking domain knowledge that takes years to acquire combined with AI and data engineering skills that are evolving rapidly. A data scientist hired from a technology company can build excellent models but does not understand lending regulation, BSA/AML requirements, or the operational constraints of core banking systems. A veteran banker understands all of those things but cannot design a feature store or configure a model monitoring system.
The fastest path is to take the domain knowledge that already exists within the bank and add the technical skills on top. A lending operations manager who learns data engineering principles will be more effective than a data engineer who learns lending. A risk analyst who learns AI model evaluation will be more effective than an AI specialist who learns risk management. The domain knowledge is the harder asset to acquire. The technical skills, while demanding, can be taught.
The domain knowledge is the harder asset to acquire. The technical skills, while demanding, can be taught.
What a real upskilling programme looks like: a six-month structured curriculum anchored to a live project. Month one covers foundations — AI system architecture, data product principles, model lifecycle basics. Months two through four pair the banker with the AI team on an active initiative — not as an observer but as a contributor with defined deliverables. Months five and six shift ownership: the banker leads a workstream with mentorship from the technical team. By the end, the bank has not just trained a person. It has built institutional knowledge that stays when the consultants leave.
Banks that invest in this deliberately will build the talent they need. Banks that wait for the market to supply it will wait a long time.
AI talent isn’t found, it’s built through structured learning, collaboration, and ownership.
What Comes Next
Building the talent stack is one dimension of the operating model challenge. The other is organizational ownership. Architecture decisions are no longer purely technical decisions — they determine business outcomes, risk exposure, and regulatory posture. The next article examines why architecture can no longer sit only in IT and what cross-functional architecture ownership looks like in practice.
Where to Start
If your bank is deploying AI and the talent conversation has not moved beyond “we need to hire data scientists,” the gap is wider than a single role. The four-role framework in this article — enterprise architects, data engineers, model operations, and AI risk — is the minimum viable talent stack for AI-era banking.
The CSP Transformation Readiness Scorecard includes a talent and capability assessment that maps your current team against these four roles, identifies where upskilling can close the gap versus where external hiring is required, and provides a practical sequencing recommendation. Leadership teams get a structured view in under an hour, with clear prioritization of where to invest first.
If your organization has enterprise architects but not data engineers, or data engineers but not model operations specialists, the talent stack has gaps that your AI roadmap is already running into.
If your institution is ready to move from awareness to action, visit coresystempartners.com/contact to start the conversation.
Next article in the series: Why Architecture Can No Longer Sit Only in IT
Return to: Why AI makes modern core banking architecture non-negotiable
#CoreBankingTransformation #CoreBankingArchitecture
