A vendor you reviewed six months ago may not be the same vendor you are relying on today.
The company name may be the same. The contract may be the same. Your primary contact may even be the same.
But the technology underneath the service may have changed.
A software provider may have added an AI assistant. A service platform may now connect to a third-party large language model. A vendor may have introduced new subprocessors, expanded what its system can access, or changed how customer information moves through its environment.
None of those changes automatically means the vendor has become unsafe.
But they can mean the risk has changed.
And that creates a problem for banks whose vendor risk process still revolves primarily around an annual questionnaire or a due diligence package completed when the relationship began.
The better way to think about vendor risk today is as an ongoing lifecycle.
That is not an anti-AI position.
It is basic stewardship.
Why Does AI Change Third-Party Vendor Risk for Community Banks?
AI can change vendor risk because it may alter what data a vendor accesses, how that information is processed, which third parties participate in the service, what actions software can perform, and how failures could affect the bank.
Those changes can happen after the original due diligence is complete.
Imagine a vendor that provides a routine business application to your bank.
When you approved it, the application stored a defined set of information, used known infrastructure, had documented access permissions, and relied on an established group of service providers.
Then the vendor adds an AI feature.
Now several questions appear.
Does the AI see customer information?
Does data leave the vendor's original environment?
Is another AI provider processing it?
Is information retained?
Can it be used to improve or train a model?
Can the AI simply summarize information, or can it take actions?
Those are not questions about whether AI is good or bad.
They are questions about whether the activity you originally assessed is still the activity being performed.
That distinction matters.
Federal banking regulators already frame third-party risk management as a lifecycle rather than a one-time exercise. The Federal Reserve, FDIC, and OCC's interagency guidance identifies planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination as stages of third-party risk management.
AI simply makes that lifecycle thinking more important.
Your Annual Vendor Review May Still Be Necessary. It Just May Not Be Enough.
I am not suggesting community banks throw out their existing vendor review schedules.
The question is simpler:
What happens when the vendor changes before the calendar says it is time to review the vendor again?
Traditional processes can unintentionally create a snapshot mentality.
The bank completes due diligence.
The contract gets signed.
Documents are collected.
The vendor receives a risk rating.
Someone puts a reminder on the calendar for the next formal review.
That process creates order, and order is valuable.
The weakness appears when the process assumes the underlying service remains substantially unchanged between those checkpoints.
Federal interagency guidance points in another direction. It says effective third-party risk management includes ongoing monitoring throughout the relationship and that monitoring may be periodic or continuous depending on the risk and complexity involved.
For community banks trying to formalize that process, broader compliance and risk management support can help connect vendor oversight, IT risk assessments, governance, and examination readiness.
An annual review is a date.
Risk management is a process.
Has Your Vendor Introduced AI Since Your Last Review?
This may be the most useful question to add to a bank's vendor conversations:
“Have you introduced, materially changed, or expanded any AI capabilities since our last review?”
Do not limit the question to products marketed as “AI platforms.”
AI may appear inside software the bank has used for years.
It might be a customer-support assistant, document summarization tool, automated call analysis capability, fraud or anomaly analysis engine, employee productivity feature, software development tool, workflow recommendation engine, or AI agent capable of initiating actions in another system.
The point is not to produce a longer inventory of shiny features.
The point is to understand whether the technology has changed the bank's exposure.
What Information Can the Vendor's AI Access?
Once AI is present, data access should be one of the first conversations.
Ask the vendor what the AI can see.
That may include customer records, account-related information, employee information, internal bank documents, tickets, emails, call transcripts, system configurations, security information, or metadata.
Then go one step further.
Ask what the AI actually needs to see to perform its function.
Those are not always the same thing.
Access should make sense in light of the business purpose.
This is where identity and access management becomes especially important. The same principles banks use to control employee and administrator access should also apply when AI-enabled systems can reach sensitive information or systems.
Federal banking guidance makes clear that using a third party does not remove the bank's responsibility to manage the risks associated with that relationship.
Is Bank Data Retained or Used for AI Model Training?
“Does the AI use our data?” is usually too broad a question.
A more useful conversation separates several issues:
What information is sent to the AI system?
Where does it go?
How long is it retained?
Who can access it?
Is it used only to provide the bank's service, or can it be used to train, tune, improve, or evaluate an AI model?
The answers may differ from vendor to vendor and even from one product tier to another.
That is why assumptions are dangerous.
A policy statement saying a vendor “protects customer data” does not by itself tell you how a newly introduced AI feature handles that data.
You need to understand the actual data flow.
Are Additional AI Providers or Subprocessors Involved?
One vendor relationship can quietly become several technology dependencies.
Your direct vendor may rely on an AI model provider.
That provider may rely on cloud infrastructure.
Other service providers may participate in logging, monitoring, storage, support, or data processing.
This is not unique to AI. Modern technology services have relied on subcontractors for years.
What AI can do is add another layer quickly.
Federal banking guidance specifically calls on banks to consider a third party's reliance on subcontractors, how those subcontractors are selected and monitored, and whether those arrangements introduce additional risks.
For a community bank, the practical question is:
Do we know who is actually involved in providing this service today?
If the answer has changed since due diligence was performed, it may be time to revisit the risk assessment.
What Permissions Does the AI Have?
There is a significant difference between AI that can read and AI that can act.
An AI tool that summarizes a document presents one type of risk.
An AI capability that can create accounts, change configurations, move information, communicate with customers, approve workflows, initiate transactions, modify records, or trigger other systems presents another.
That does not automatically mean the second use should be prohibited.
It means permissions deserve attention.
A sensible review should establish what systems the AI can reach, what information it can read, what information it can create or modify, what actions it can initiate, and what limits prevent it from going beyond its intended role.
The same principle banks already apply to people and traditional systems remains useful here:
Give technology the access it needs for its job - not simply the access it is capable of using.
How Are the Vendor's AI Activities Logged and Monitored?
If something goes wrong, can the vendor explain what happened?
That question becomes especially important when an AI system participates in a business process.
Banks should understand what activity is logged, how long records are maintained, whether significant actions can be reconstructed, how anomalous behavior is detected, and how issues are escalated.
That also creates a natural connection to the bank's broader security monitoring and incident response strategy. AI activity should not live in a separate governance silo if it can affect access, data, security, or operations.
NIST's AI Risk Management Framework provides a voluntary framework for managing AI risk across the AI lifecycle. Its focus includes governance, measurement, and ongoing management of AI risk rather than treating AI evaluation as a one-time event.
For banks, that lifecycle idea fits naturally beside existing third-party risk management.
You want to know not just how the AI was approved.
You want to know how it is being watched.
Where Should Human Approval Remain in the Process?
One of the most useful governance questions is also one of the simplest:
“What happens automatically, and what still requires a person to approve it?”
Not every AI-assisted activity needs the same level of human involvement.
The answer should depend on what is at stake.
A low-risk drafting tool is different from a system that could materially affect customers, security, compliance, financial activity, or bank operations.
For higher-impact uses, bank leaders should understand where human review exists, who has authority to intervene, how exceptions are handled, and whether actions can be stopped or reversed.
Good AI governance is not about keeping a person involved merely for appearances.
It is about putting meaningful oversight where the consequences justify it.
Will the Vendor Tell You When Its Use of AI Changes?
This may eventually become one of the most important contract questions.
A bank cannot reassess a material change it never hears about.
Consider whether your vendor agreements, change-management process, or ongoing monitoring program gives the bank enough visibility when a provider changes something significant about the service.
Federal banking guidance discusses contract provisions that provide notice of significant strategic or operational changes, including the use of subcontractors and other initiatives that could affect the activity being provided.
For AI-enabled services, banks may want to determine whether their own definition of a meaningful technology change includes issues such as introducing AI into a service that did not previously use it, connecting a new AI model provider, materially expanding the information available to an AI capability, giving an AI system new permissions, changing data retention or model-training practices, or introducing new subprocessors that handle bank information.
The important word is material.
You do not need an emergency risk committee meeting every time a vendor adjusts a feature.
You do need a reliable way to recognize changes that alter your risk.
AI Vendor Risk Is Also an Operational-Resilience Issue
Cybersecurity is part of this conversation.
It is not the whole conversation.
Suppose an AI dependency fails.
Could the vendor still provide its service?
If the AI produces unreliable results, can the function be performed manually?
If an upstream AI provider becomes unavailable, does your vendor have an alternative?
If inappropriate data exposure occurs, who identifies it?
Who contacts the bank?
What evidence will be available?
Does the bank's incident response plan account for this vendor and its dependencies?
Would the event affect customer service, business continuity, regulatory reporting, or another critical bank operation?
That is why vendor AI risk belongs alongside the bank's broader data backup and recovery and business continuity planning.
Federal third-party guidance specifically addresses operational resilience, incident management, disaster recovery, business continuity, recovery capabilities, and a vendor's ability to respond to disruptions.
That is why I would not put AI vendor risk in a box labeled simply “AI.”
It belongs in the larger conversation about how the bank keeps operating when technology does something unexpected.
A Practical AI Vendor Review for Community Banks
You do not necessarily need an entirely separate vendor-management program for AI.
In many cases, the better answer is to strengthen the program you already have.
Start with your higher-risk and critical vendors.
Then ask:
1. What changed?
Has the vendor added or materially expanded AI since the last risk assessment?
2. What does the AI touch?
Identify systems, bank information, customer information, and integrations.
3. Where does the information go?
Understand retention, processing locations, AI model providers, and subprocessors.
4. What can the AI do?
Separate read-only capabilities from systems that can create, change, approve, communicate, or initiate actions.
5. What controls surround it?
Review permissions, logging, monitoring, testing, escalation, and human oversight.
6. How will we know when something changes?
Review vendor notification procedures and relevant contractual language.
7. What happens when it fails?
Connect the AI dependency to incident response, cybersecurity, business continuity, and operational resilience.
Then document what you learned.
The goal is not more paperwork.
The goal is fewer surprises.
Vendor Risk Should Move at the Speed of Material Change
Community banks do not need to chase every new AI announcement.
They do need a process that recognizes when technology changes the nature of a third-party relationship.
That distinction matters.
The federal banking agencies describe third-party risk management as proportional to the risk, complexity, size of the institution, and nature of the relationship. Not every vendor deserves identical oversight. Higher-risk and critical activities generally warrant more rigorous monitoring.
That approach fits community banks well.
Focus attention where failure would matter most.
Watch for meaningful changes.
Ask plain questions.
Document the answers.
And update the risk picture when the facts change.
Banks with small internal technology teams do not necessarily need to hand over control to get more support. A co-managed IT services approach can add cybersecurity, compliance, and strategic expertise while the bank maintains governance and decision-making authority.
Where AvTek Solutions Fits
This is where cybersecurity, vendor risk management, AI governance, compliance, and technology strategy begin to overlap.
A bank may have each discipline covered individually and still have gaps between them.
The vendor management team may know the contract.
IT may understand the integration.
Cybersecurity may understand access.
Compliance may understand the regulatory implications.
Operations may understand what happens if the service goes down.
AI governance requires those views to come together.
AvTek Solutions helps community and regional banks connect vendor and third-party risk oversight, IT risk assessments, cybersecurity, compliance governance, and strategic technology planning so important changes do not remain isolated inside separate checklists.
That work can fit within a broader managed IT services strategy or support an existing internal IT team.
The purpose is not to slow innovation.
It is to help the bank adopt technology with its eyes open.
Because good governance should make responsible innovation easier - not harder.
Frequently Asked Questions About AI Vendor Risk for Community Banks
Does a Community Bank Need to Reassess a Vendor Every Time the Vendor Adds AI?
Not necessarily.
A risk-based approach is more practical. The bank should determine whether the AI changes the vendor's access to data, subprocessors, permissions, operational dependencies, customer impact, security exposure, or other material aspects of the relationship.
Significant changes may justify a targeted reassessment rather than waiting for the next scheduled review.
Federal banking guidance supports tailoring third-party oversight to the risk and complexity of the relationship and adjusting monitoring as risks change.
What Should a Bank Ask a Vendor About Artificial Intelligence?
Start by asking whether AI is being used in the service and what has changed since the last review.
Then determine what bank or customer information the AI can access, whether information is retained or used for model training, which AI providers or subprocessors are involved, what permissions the AI has, how activity is logged, where human approval is required, and how the bank will be notified of material changes.
The objective is to understand the actual service being delivered - not simply whether the vendor says it “uses AI.”
Is AI Vendor Risk Only a Cybersecurity Issue?
No.
AI vendor risk can involve cybersecurity, privacy, compliance, operational risk, strategic risk, third-party concentration, business continuity, customer impact, and governance.
For example, an AI service does not have to suffer a cyberattack to create an operational problem. An upstream provider outage, inappropriate automated action, inaccurate output, or unavailable AI capability could affect the vendor's ability to perform its service.
Should Banks Ask Whether Vendor Data Is Used to Train AI Models?
Yes.
Banks should understand whether their information or customer information is retained, reused, or used for model training, tuning, evaluation, or other purposes beyond providing the contracted service.
The appropriate answer will depend on the service, the information involved, contractual terms, applicable requirements, and the bank's risk appetite.
The important point is that the bank should know rather than assume.
How Does AI Affect a Bank's Business Continuity and Incident Response Planning?
If an AI capability has become important to a vendor's service, the bank should consider what happens if that capability fails, becomes unavailable, behaves unexpectedly, or contributes to an incident.
That may include determining whether manual processes are available, understanding upstream dependencies, confirming escalation and notification procedures, and considering how the event would fit into the bank's existing incident response and business continuity plans.
Federal third-party guidance specifically addresses vendor incident management, operational resilience, disaster recovery, and business continuity as part of sound risk management.
What Is the Biggest Change Banks Should Make to Vendor Risk Management Because of AI?
The biggest change may be a change in mindset:
Stop treating vendor risk as a photograph. Start treating it as a moving picture.
Formal reviews still matter.
Due diligence still matters.
Contracts still matter.
But when vendors can change technology, integrations, data flows, subprocessors, and automation between review dates, banks need a way to recognize material changes while the relationship is active.
That is what lifecycle vendor risk management is designed to do.
The Question to Take Back to Your Team
You do not need to decide whether AI is good or bad.
That is the wrong question.
Ask this instead:
If one of our important vendors materially changed how it uses AI tomorrow, would our current vendor risk process catch it?
Would you know what changed?
Would you know what information was involved?
Would you know who else had access?
Would you understand the operational impact?
And would the right people inside the bank know soon enough to make a sound decision?
If the answer is unclear, that is a useful place to start.
AvTek Solutions can help community and regional banks evaluate whether their vendor risk, cybersecurity, AI governance, compliance, and technology-risk processes have kept pace with the technology their institutions now depend on.
No panic.
No rush toward the latest tool.
Just a clearer view of the risk - and a better process for managing it.
Primary Sources
Federal Reserve, FDIC, and OCC — Interagency Guidance on Third-Party Relationships: Risk Management
https://www.federalreserve.gov/supervisionreg/srletters/SR2304.htm
Federal Reserve — Third-Party Risk Management: A Guide for Community Banks
NIST — AI Risk Management Framework
https://www.nist.gov/itl/ai-risk-management-framework
NIST — Generative Artificial Intelligence Profile
