When I look at vendor risk programs, one question matters more than it did a few years ago:
Is the vendor you reviewed last year still the same vendor today?
The legal entity may be the same. The contract may still be in force. The product name may not have changed.
But the technology underneath that product may have.
A vendor can add an AI assistant. It can connect its application to an outside AI model. It can introduce another service provider into the delivery chain. It can give an AI feature access to customer records or internal bank information that the original product never needed.
Each change can affect risk.
And none of those changes necessarily waits for your next annual review.
For community and regional banks in Northeast Arkansas, that creates a practical vendor-management problem. A process built mainly around onboarding and periodic questionnaires may give management a good picture of a vendor at one point in time. AI makes that picture easier to outgrow.
The answer is not to resist AI. Banks and their vendors will continue finding useful applications for it.
The better response is to make sure vendor oversight keeps pace with the technology being used.
Third-party risk has always been a lifecycle
Federal banking regulators already give banks a useful starting point.
The Federal Reserve, FDIC, and OCC describe third-party risk management as a lifecycle covering planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. The agencies also make clear that using a third party does not remove a bank's responsibility to operate safely and soundly and comply with applicable laws and regulations. See the Interagency Guidance on Third-Party Relationships: Risk Management.
That matters when AI enters an existing vendor relationship.
The interagency guidance treats ongoing monitoring as a core part of the relationship lifecycle. Monitoring can include changes in a third party's business arrangements, subcontractor use, security posture, controls, incidents, and other conditions that could affect risk.
In other words, the regulatory concept is already broader than an annual questionnaire.
AI simply makes that distinction harder to ignore.
The agencies' Third-Party Risk Management: A Guide for Community Banks reinforces the same lifecycle approach. The guide explains that community banks may adjust their third-party risk-management practices according to their size, complexity, risk profile, and the risk presented by each relationship.
For a bank executive, I would translate that into plain language:
A completed vendor review tells you what you knew when you completed it. Ongoing monitoring tells you whether that answer is still good.
Banks that want more structure around this process can also look at AvTek's vendor and third-party risk oversight support. AvTek's Compliance as a Service offering includes IT risk assessment support, vendor and third-party risk oversight guidance, governance support, documentation, and ongoing compliance monitoring
AI can change the relationship without changing the vendor
Traditional vendor due diligence often begins with fairly stable questions.
Where is our data stored?
Who has access?
Which subcontractors are involved?
What controls protect the environment?
What happens during an outage?
Those questions still matter. AI adds another layer because a feature introduced inside an existing product can alter several answers at once.
Suppose a software vendor adds an AI tool that summarizes customer interactions.
The bank may now need to understand whether customer information is being passed into that AI system, where the processing occurs, whether prompts or responses are retained, whether an outside model provider receives the information, and whether the model can take actions inside the application.
The vendor itself has not changed.
The bank's exposure may have.
NIST's AI Risk Management Framework and Generative AI Profile provide a useful risk-management lens for these questions. NIST addresses third-party AI systems, data use, privacy, security, traceability, and governance. These resources are voluntary and cross-industry, but they can help banks structure conversations about AI-related risk.
Questions worth adding to vendor monitoring
A bank does not need to turn every vendor meeting into a technical interrogation. The goal is to identify changes that could affect the bank's risk assessment, controls, contracts, incident planning, or business continuity assumptions.
For vendors that handle sensitive information, support critical functions, or introduce AI into material workflows, I would want clear answers to questions such as:
- Has the product introduced or materially changed any AI capability since our last review?
- What bank information, customer information, credentials, documents, communications, or other data can the AI access?
- Are prompts, inputs, outputs, or other bank data retained, and can any of that information be used to train or improve a model?
- Does the vendor rely on outside AI model providers, hosting providers, or additional subprocessors to provide the feature?
- What systems, records, functions, or permissions can the AI use?
- Are AI requests, outputs, administrative changes, and actions logged in a form that can be reviewed?
- Does a person have to approve sensitive decisions or actions before they take effect?
- Will the bank receive notice when the vendor materially changes its use of AI, data handling, model provider, or subprocessors?
- If an AI-related failure, data exposure, or service interruption occurs, how does that fit into the vendor's incident response process and the bank's own incident response and business continuity plans?
The answers do not all carry the same weight.
An AI feature that helps draft marketing copy has a different risk profile from one that can access customer records, initiate workflow actions, affect lending activity, or interact with a critical banking process.
The point is to know which one you have.
Data access deserves special attention
One of the first things I would want documented is the AI system's access.
A bank may approve a vendor based on one expected flow of information. An AI feature can create another.
Management may need to know whether the AI sees only the information entered into a prompt or whether it can search a larger repository. It may have access to email, documents, CRM records, support tickets, transaction information, internal knowledge bases, or other connected systems.
Permissions matter just as much.
An AI system that can read information presents one set of concerns. An AI system that can create records, send communications, modify information, trigger workflows, or take other actions requires a different level of review.
That makes cybersecurity and access controls part of the AI vendor-risk conversation. AvTek's Cybersecurity Services include managed detection and response, security monitoring, incident response support, endpoint protection, and network security.
Good vendor oversight makes those capabilities visible.
For a bank, AI-related access questions fit naturally beside existing access control, change management, information security, and third-party oversight practices.
Your vendor may now have vendors you never reviewed
AI also makes subcontractor visibility more important.
A familiar banking technology provider may not build its own AI model. It may connect its software to an outside model provider or another technology company.
That additional dependency can matter because the bank is no longer evaluating only the controls of the vendor named on the contract.
The Interagency Guidance on Third-Party Relationships specifically addresses a third party's use of subcontractors as part of third-party risk management and ongoing monitoring.
AI gives banks another reason to ask for that information.
I would want to understand who is actually involved in delivering a material AI capability and which party is responsible for each part of the service.
Clear ownership matters even more when something goes wrong.
For banks already relying heavily on outside technology providers, managed IT services can also help maintain visibility across systems, vendors, support responsibilities, and day-to-day technology operations.
Change notification may belong in the contract discussion
One weakness in a periodic review process is that the bank may learn about a material technology change only after it has happened.
That puts the risk team in a difficult position. You cannot assess a change you do not know about.
For important vendor relationships, banks may want legal counsel and the appropriate risk owners to consider whether contracts and related agreements provide adequate notice of material changes involving AI functionality, data use, subprocessors, security controls, or the way services are delivered.
The exact contract language will depend on the relationship.
The broader principle is simpler: material changes in risk deserve a reliable way to reach the people responsible for overseeing that risk.
That also creates a cleaner record.
When an examiner, board member, auditor, or senior executive asks when the bank learned about a change and what management did about it, the answer can be supported with evidence rather than recollection.
AI vendor risk belongs in incident response and business continuity planning
Vendor AI discussions can easily become focused on privacy and model behavior. Operational resilience deserves equal attention.
If a critical vendor becomes dependent on an external AI service, what happens when that service becomes unavailable?
Can the vendor continue operating without it?
Can the bank?
If an AI system produces an unauthorized action, exposes information, or behaves unexpectedly, will the vendor recognize the event? Will the relevant activity be logged? Who investigates it? When does the bank receive notice?
FFIEC guidance on outsourced technology services has long emphasized that reliance on third-party providers does not remove a financial institution's responsibility for resilience and continuity. Its guidance also emphasizes due diligence, contract management, ongoing monitoring, recovery capabilities, and testing with technology service providers. See FFIEC Appendix J: Strengthening the Resilience of Outsourced Technology Services.
AI does not replace those operational-resilience principles.
It adds another dependency to account for.
For critical vendors, an AI-related scenario may be worth including in incident response exercises, tabletop discussions, vendor continuity reviews, and data backup and recovery planning when the risk warrants it.
AvTek's Data Backup and Recovery services include backup monitoring, verification, recovery support, secure storage practices, documentation, and compliance-focused data protection planning.
The goal is to know ahead of time which services the bank depends on, how operations continue when those services fail, and which recovery steps have actually been tested.
Annual reviews still have a place
I would not throw away the annual vendor review.
Formal reviews give a bank a useful point for deeper documentation, risk scoring, control review, contract assessment, and management reporting.
The issue is what happens during the other eleven months.
A practical lifecycle approach may include triggers that cause the bank to reassess a relationship before the next scheduled review. A new AI feature could be one trigger. A new subprocessor, expanded data access, a significant security event, a major product change, or a change in how a critical service is delivered could be others.
That approach fits the principles in the Federal Reserve's community bank third-party risk management guide, which recognizes that not every third-party relationship presents the same level of risk and that risk-management practices can be adjusted accordingly.
For a small bank with a lean IT and risk team, the goal is not constant paperwork.
It is reliable visibility into changes that matter.
AI governance and vendor management are starting to meet
Banks sometimes treat AI governance and vendor management as separate projects.
In practice, they meet quickly.
A bank can have a thoughtful internal AI policy and still have AI enter the organization through software that employees already use. Productivity systems, security platforms, customer-service applications, financial software, and other vendors may add AI capabilities over time.
That means an AI inventory based only on tools purchased specifically as "AI products" may miss part of the picture.
Vendor management can help close that gap.
When the bank knows which vendors use AI, what information those systems can access, what outside providers are involved, and which functions can be performed, management gets a clearer view of the bank's actual AI exposure.
That information can then support cybersecurity risk management, access reviews, policy decisions, incident planning, business continuity work, and board reporting.
For community banks in Northeast Arkansas, I find this especially important because the people responsible for technology risk often wear several hats. A COO, IT manager, compliance officer, and risk officer may all touch the same vendor relationship from different directions.
A good process gives them one defensible picture instead of four partial ones.
How AvTek helps Northeast Arkansas banks manage changing technology risk
At AvTek Solutions, we work with community and regional banks in Northeast Arkansas on cybersecurity, vendor and third-party risk oversight, risk assessments, compliance support, governance, and strategic technology risk management.
Those areas increasingly overlap.
A change inside a vendor product can affect information security. It can affect compliance. It can change business continuity assumptions. It can create new third-party dependencies. It can also change the bank's understanding of where AI is being used.
My view is that these questions are easier to manage when they are handled as part of the bank's existing risk processes instead of creating an entirely separate bureaucracy for AI.
The goal is a process management can explain, evidence, and maintain.
That is what gives a bank confidence when the technology changes before the calendar says it is time for another review.
FAQ: AI vendor risk management for Northeast Arkansas banks
How does AI change third-party vendor risk for a community bank?
AI can change what information a vendor accesses, how that information is processed, which outside providers are involved, what actions software can perform, and how heavily a critical service depends on other technology providers.
Those changes can alter the risk profile of an existing vendor relationship even when the bank has not selected a new vendor or signed a new contract.
Should Northeast Arkansas banks ask existing vendors whether they use AI?
For vendors whose services create meaningful operational, information-security, compliance, customer, or strategic risk, asking about AI use can help the bank determine whether the relationship has changed since the last assessment.
The level of review can remain risk-based. A low-risk application does not necessarily require the same scrutiny as a vendor supporting a critical activity or handling sensitive customer information.
Does federal banking guidance require an annual AI vendor questionnaire?
The Interagency Guidance on Third-Party Relationships does not prescribe an annual AI questionnaire.
The guidance describes third-party risk management as a lifecycle that includes ongoing monitoring. It also makes clear that supervisory guidance does not itself impose new legal requirements.
Banks can determine how AI-related questions fit into their existing risk-based vendor management processes.
What information should a bank request about a vendor's AI system?
Useful information may include the purpose of the AI, the information it can access, how data is retained and used, whether outside models or subprocessors are involved, the permissions the system has, available logs, human approval controls, security and incident procedures, and the vendor's process for notifying customers about material changes.
The depth of the request can be adjusted to the risk presented by the product and activity.
Should vendor AI be included in a bank's incident response plan?
When a vendor's AI capability could affect sensitive information, critical operations, security controls, or important business processes, it makes sense to evaluate how an AI-related vendor event would fit into existing incident response procedures.
The bank may need to understand notification paths, evidence and logging availability, service dependencies, recovery options, and who has authority to disable or restrict an AI capability during an incident.
How often should a Northeast Arkansas community bank review vendor AI risk?
There is no single cadence that fits every relationship.
Federal banking guidance supports risk-based ongoing monitoring, with more rigorous oversight for relationships supporting higher-risk activities, including critical activities.
A practical bank process can combine scheduled reviews with event-based reassessment when a vendor introduces a material technology, data, subcontractor, security, or service change.
Is your vendor risk process keeping pace with your vendors?
Most banks already have much of the structure they need.
The question is whether that structure can see a meaningful change before the next questionnaire arrives.
If AI has changed what your vendors can access, who they depend on, or what their systems can do, it may be time to look at whether your vendor risk process has changed with them.
AvTek Solutions helps community and regional banks in Northeast Arkansas evaluate technology risk, cybersecurity, third-party oversight, AI governance, and compliance readiness in a way management can document and defend.
A useful place to begin is simply comparing today's vendor environment with the assumptions behind your last risk assessment.
