Guides

Guide: Vibe Coding for Banks & Credit Unions

How to assess, build and manage software that employees create with AI.

Vibe Coding for Banks and Credit Unions. Printable edition.

Summary

A useful application can arrive before anyone has decided who owns it. This guide explains how to assess software employees have already built, give new builders workable boundaries, and choose an operating arrangement the institution can fund and support.

Assess the application and its use

AI-generated software applications are tools whose code is produced in whole or in part by an AI assistant. In this guide, vibe coding means building and revising that software by describing what you want in prompts and trying the results, potentially without being able to inspect the underlying code.

Using AI to build an application does not necessarily make AI part of the finished product. A vibe-coded calculator might run fixed formulas without using AI at all. Another application might use an AI model to summarize documents, classify information or answer questions as part of its core functionality. Assess both how the software was built and whether it uses AI when it runs.

Banks and credit unions can use and support AI-built software when they can verify that it is fit for its intended use, protect the information it handles, meet applicable obligations, and maintain and recover it over time. Our recommendation is to approve a specific application and use on that evidence, with an accountable owner and qualified, funded support, whether internal or contracted. AI authorship alone is neither approval nor a reason to reject it.

Where internal security expertise is limited, engage a qualified outside provider, including an existing technology or security vendor whose expertise and contract cover the work. Section 8 explains how to scope vulnerability assessment, security scans and penetration testing.

Start with three questions:

Was the AI use permitted? Determine whether the employee used an approved AI tool and followed the institution's rules for sharing information and granting access. Then assess whether the resulting application is suitable for use; approval of the AI tool does not approve the application.
What already depends on the software? Recheck outputs used in decisions or records while assessing the application.
Can we stand behind it? Authorize a defined use only when ownership, funded support, independent business and security testing, and demonstrated recovery are in place.

The guide turns those questions into decisions using the institution's existing controls.

Scope: Our operating recommendations serve both banks and credit unions; the source notes distinguish the authorities that apply to each.

Find the decision you need

An application is already in use: Sections 1–2, then records A and B.
You want to allow building: Sections 3–7 cover lifecycle, value, responsibilities and hosting.
You need to authorize or maintain a release: Section 8 and records F and G, with support and funding recorded in C and D.
You need the leadership discussion: Section 9. Intake alone is not authorization to operate.

1. The calculator is already in use

Imagine a lender showing you a calculator they built over the weekend. They described the problem to an AI assistant, tried its output and asked for changes until the screen did what they wanted. It replaces a calculation they were doing repeatedly. A colleague liked it enough to share the link. One of its results has already made its way into a credit memo.

The employee has solved something worth understanding. You also have software in use whose assumptions, access and ownership may not have been reviewed.

Start by finding out what the institution is relying on, then decide what it can safely keep.

The guide also applies to AI-assisted development that includes competent technical review. Whether someone can inspect and maintain the implementation matters more than the label.

AI-written software is not necessarily an AI application. A calculator can execute fixed arithmetic without calling an AI model at all. It still needs correct arithmetic, suitable permissions and someone responsible for its maintenance.

An app can work correctly and still be unsafe to run. It could expose customer records through an unprotected database, include a malicious software package, or let an ordinary user perform administrative actions. A polished screen and a successful demonstration establish none of the security protections the institution needs. These risks do not depend on the application using AI when it runs.

Our recommendation is to give employees an approved route from a useful idea to supported use. Match the route to the application's consequences and the institution's capabilities. Where nobody can reliably inspect, repair or recover an application, enthusiasm for the demonstration isn't enough to put it into service.

Establish what exists before deciding its future

Start with the builder and the people using the tool. Ask them to show you the work, including what happens before information enters the application and after a result leaves it.

Purpose and reliance: What problem does it solve? Who uses the result, and for what decision? What did they use before?
Data and connections: What information enters it? What is stored or transmitted? Can it change another system, send a message or start a transaction?
Location and control: Who controls the code or configuration, hosting account, credentials, billing and copies?
Support: Who can explain the logic, investigate a wrong result and stop the affected function?
Prior outputs: Has a result already entered a credit memo, customer communication, accounting entry, compliance report or other record? Who will independently check that work?

Record uncertainty. “We haven't checked whether this sends data anywhere” is different from “it processes everything locally.” Don't let an attractive interface answer a question about the underlying system.

If there is suspected disclosure, corruption or unauthorized action, use the institution's incident process. Preserve evidence, contain the affected activity and promptly assess notification duties and deadlines; repairing the software doesn't set that timetable. Have the responsible technical team revoke or rotate secrets exposed through an unapproved tool, embedded in shared code or left on an unapproved host, while managing affected connections.

Whether or not an incident is established, identify outputs already used in decisions, records or communications. Assign a business owner to arrange independent review and any necessary correction. For an unreviewed application, document the exposure, interim restrictions and the person responsible for resolving each unknown.

Avoid removing a tool without understanding the work that now depends on it. The Federal Financial Institutions Examination Council (FFIEC), the interagency body that develops IT examination guidance, recognizes this tension. Its Architecture, Infrastructure, and Operations booklet calls for timely action on shadow IT, technology operating without IT management's knowledge, approval or control. It also warns that unplanned removal can disrupt processes. Possible dispositions include removal or transition to institution-managed infrastructure and asset management.¹

Merely adding a name to an inventory doesn't resolve the exposure.

2. Separate the AI activity from the application

The first policy question is about how the software was produced. The second is about whether the institution can use it. A third arises if the finished application itself uses AI.

Was the building activity permitted?

Assess the assistant, account, information and actions used during development against the institution's policies. Was this tool approved for this use? Were customer records, internal documents, schemas, screenshots or credentials supplied to it? Could the agent run commands, install components or deploy to an outside service?

Identify the account, tenant and plan, including the applicable retention and model-training terms. Check the actual agreement and settings rather than assuming a product's consumer and enterprise offerings handle information identically.

An approved chatbot account doesn't necessarily authorize every development feature, connector or hosting service offered alongside it. A policy should make those boundaries understandable before employees start building.

This assessment belongs with AI acceptable-use rules, data handling, tool approval and development permissions. If a policy also covers AI-generated artifacts, follow that scope, but don't confuse approval of the activity with approval of the output.

Can we accept the resulting software?

The artifact may be source code, a packaged application, a spreadsheet or configuration inside a platform. Assess what it does, where it came from, whether the institution has the necessary rights, and how it will be tested and maintained.

A legitimate build process can produce an unsuitable application. An unauthorized build process can produce software that is technically remediable, while still requiring a separate response to the conduct or disclosure. Keep those decisions visible rather than allowing one to settle the other.

Does AI operate inside it?

Check whether a model processes information when the application runs. That can happen through a visible assistant, a classification step, an external service or a platform feature added to a workflow.

Runtime AI brings additional questions about information sent to the model, variable outputs, malicious instructions in content, service changes and effective human review. Ordinary software controls still apply.

Changing a coding assistant doesn't alter a release the institution has retained under change control. Behavior can still change when dependencies, hosting, connected services or a runtime model change. A supplier-controlled application may also receive updates without an institutional deployment. Record development-time AI and runtime AI separately, and identify which components the institution controls and which a supplier can change.

“I built it at home. Can I bring it in?”

Personal time and a personal device don't answer the question. Read the actual policy and establish what happened.

Suppose an employee built a generic calculator using public formulas and fictional inputs. There may be no prohibited disclosure, but the institution still needs to assess policy scope, rights, correctness, dependencies and support before accepting it.

Now change one fact: the employee uploaded real customer files to get the tool working. Moving the finished code onto an approved server doesn't undo that disclosure. Assess it through the appropriate policy and incident channels while separately determining what to do with the software.

Apply software intake checks whether the code came from an employee's AI session, a contractor or a public repository. Establish provenance and licensing; verify that dependencies are the intended packages from legitimate sources and check for known vulnerabilities; inspect for embedded secrets; and arrange isolated technical review before running untrusted code or connecting institutional data. An assistant's suggestion is not evidence that a package is legitimate. Downloaded installation scripts can execute too.

The intake record should therefore contain two conclusions: what we determined about the development activity, and what we authorized for the artifact. If the evidence is incomplete, say which decision remains open and who will resolve it.

3. Start with the lifecycle banks already need

Before AI could generate an application from a conversation, custom development still required a business owner, requirements, implementation, testing, release and support. An institution could do the work internally, commission a supplier or configure an existing platform. The responsibilities had to be allocated somewhere.

AI can change who produces the implementation and how quickly a demonstration appears. It doesn't establish what the application should do, whether it does it correctly or who will answer for it later.

SDLC is not another name for waterfall

SDLC commonly means software development life cycle. The FFIEC uses system development life cycle for the broader system and its components, extending from initiation through operation and disposal. Its development handbook describes five general phases:²

Phase: Initiation; The practical question: Why do we need this, who owns the need, and what constraints apply?
Phase: Development or acquisition; The practical question: How will we build, buy or configure it, including its controls?
Phase: Implementation and assessment; The practical question: What evidence supports putting this version into use, and how will we deploy it?
Phase: Operations and maintenance; The practical question: Who monitors it, supports it and controls changes?
Phase: Sunset and disposal; The practical question: How do we replace or remove it without losing required records or interrupting dependent work?

The questions in the table are our plain-language translation. The underlying principles are accountability, stakeholder involvement, security throughout, identifiable changes and evidence that the system meets its intended purpose. The FFIEC notes that organizations may divide the phases differently.²

Waterfall and agile are methodologies for organizing delivery. Waterfall generally sequences work through stages; agile organizes iterative delivery. Either approach needs to address the lifecycle. The FFIEC treats methodologies separately and recognizes that an institution may use different or hybrid approaches according to project needs.³

DevOps connects development and operations practices, often automating testing and deployment. Automation can make a release repeatable, but it doesn't decide whether the institution should release it. A deployment pipeline needs authorized users, meaningful checks and a defined destination.

For a small tool, the evidence may be compact. For a customer-facing application or a system supporting a consequential decision, the work will be more demanding. Proportionate does not mean undocumented; it means that the effort addresses the actual exposure.

Excel, macros and dashboards are useful precedents

A spreadsheet formula shows why correctness and control matter even when the implementation looks small. Someone has to establish what the calculation means, test its boundaries and prevent an unnoticed edit from changing the answer.

A macro adds action. It may move files, send messages or update records. Those permissions change the consequences of a mistake. An Access application adds another familiar concern: a departmental tool can become important while its design and operating knowledge remain with one person.

A dashboard illustrates a different problem. Two screens can show different delinquency totals because they use different dates, filters or definitions. Neither needs write access to influence a bad decision. Source reconciliation and an authoritative definition matter as much as the chart.

These are useful connections to end-user computing (EUC), the management of tools developed by business users. Extend the institution's existing arrangements where they fit. If there is no functioning program, calling the new tool EUC doesn't supply one.

Keep the application in the EUC or technology-asset inventory. Link it to the relevant change, security, supplier, continuity, incident and model-risk reviews. Include outside builders, hosts, runtime AI services and maintainers in the supplier assessment. One application ID should connect those decisions.

An experiment needs a fuller review when colleagues begin relying on it, it informs a customer or reporting decision, or it can change another system. For an internet-reachable staff tool handling nonpublic information, we recommend institution-managed identity, multi-factor authentication and no anonymous access to the data or public previews exposing it. A different architecture needs a security-reviewed access design. These are recommended controls, not a legal requirement to buy one identity product.

The comparison also needs fairness. A tested, version-controlled application might improve on a fragile spreadsheet. Compare their actual controls and failure modes rather than assuming the older tool is safer or the newer one is better.

4. Assess the use, not the size of the codebase

A ten-line calculation can affect a customer. A larger application may do nothing more than rearrange public information. Neither line count nor user count establishes the appropriate level of review.

Use six questions to describe the exposure:

What information is involved? Include prompts, uploaded examples, application data, logs, support tickets and backups.
What depends on the answer? Distinguish convenience from customer decisions, financial reporting and required controls.
What can the application do? Read, recommend, stage an action or execute it?
Who can reach it? Consider shared links, public previews, administrative interfaces and connected services.
How would we detect and recover from failure? Include wrong results, not just downtime.
Who can maintain it? Identify the skills and access needed, not simply a name on a form.

These are our assessment dimensions, not a regulatory scoring system. A significant control gap should not disappear inside a favorable average.

The same calculator, three different uses

Consider a fictional calculator used with invented numbers during training. Its approved purpose might be limited to illustration, with checked formulas and controlled distribution.

Next, someone enters a customer's financial information. The data path now matters: does anything leave the device, and are those destinations permitted?

Then a result becomes an input to a credit memo. The formula's definition, assumptions and independent checks become part of a consequential business process. The absence of runtime AI doesn't make that reliance harmless.

The interface may never change. The use has changed twice.

Reassessment triggers should therefore include new data, users, connections, action permissions, downstream reliance and removal of the old process. If a reviewer cannot establish a material boundary, restrict the affected use while resolving it. Don't expand on the strength of an assumed answer.

5. Decide whether it is worth owning

There is a difference between being able to make an application work and wanting responsibility for it over time.

Start with the process it replaces. What work does it remove? What new review or reconciliation does it create? What happens when a rule changes, a supplier raises prices or the original builder leaves?

Count implementation, testing, support, licensing, monitoring and eventual exit. Time released can be valuable without being a cash saving. A tool that saves an hour but adds an hour of checking has a different business case from the demonstration.

For an institution without developers, first test whether an existing, governed and supported platform can meet the need using native components. Verify the configuration, required licenses, environment capacity and administrative effort before treating it as the lower-cost option. If it doesn't fit, assess whether qualified custom-software support is worth funding.

Before operational approval, obtain the maintainer's written acceptance of this specific application. What work is covered, how much capacity is available, and who responds when it fails? Record exclusions and the exit route, including access to source or configuration, build materials and tests. A general IT support contract counts only if it covers this work. Have the budget owner approve the implementation, recurring and exit costs, including staff capacity.

For example, a hypothetical platform calculator may need no new server but still require additional licensing, separate environments, administrative time, business-rule checks and support coverage. Compare those costs with the existing worksheet process. Record cash spending separately from staff time, and identify where released capacity will actually be used. A lower development bill is not yet a lower lifetime cost.

When not building is the better choice

An institution without review or maintenance capacity may reasonably decline employee-built operational software for now. An approved place to experiment is useful only if someone can enforce its boundaries. If that capacity is absent too, pause new building and address the process need through supported tools. A prohibition still needs discovery and a route for reporting tools already in use; it doesn't make them disappear.

Nor should a platform rebuild win automatically. Suppose the current worksheet is independently checked, access-controlled and easy to recover, while the proposed app adds several connectors and a support bill. Keep the worksheet unless a demonstrated benefit justifies that extra burden. Conversely, a supported custom application may be the better choice when native platform components cannot meet a necessary rule, integration or recovery requirement and a qualified provider can maintain the implementation.

Those findings would change our recommendation. We favor a governed native platform as a starting test, not a predetermined destination. Choose the route that improves the actual process within the institution's capacity, including choosing no new application.

Choose a disposition with conditions

Retain and remediate when qualified people can establish what exists, correct the weaknesses and maintain the result. They may be internal or contracted, provided they have accepted this application and are funded to support it. This is not permission for an unsupported builder to keep prompting until problems seem to disappear.

Rebuild when the useful workflow can be supported more reliably elsewhere, or the existing implementation is too difficult to inspect and maintain. Carry the accepted business rules and test examples into the rebuild; a new platform doesn't prevent translation errors.

Replace when an existing product or process meets the need with a better support arrangement. Check whether an already licensed feature solves the problem before adding another application.

Keep as a prototype when it clarifies requirements but cannot yet support real work. Its screens, rules, permissions and accepted examples can become a specification. Keep its isolation real: a prototype with live customer data and operational write access isn't isolated because its owner calls it a demo.

Retire when the benefit no longer justifies the burden, or an acceptable support route cannot be established. Move dependent work and preserve required records before removal.

In discussing customized development of certain critical systems and components, the FFIEC notes that having source code, build scripts and tests could enable an institution to have a third party maintain the system if necessary.⁴ It isn't a blanket endorsement of outsourcing. Our decision test is: can the institution secure qualified, funded, continuing support for this particular application?

Without that support, keep it isolated or choose another disposition. Reducing the scope helps only if the narrower use can be supported.

6. Give builders permissions they can handle

A business expert may know the exceptions and practical requirements better than a programmer. That knowledge is valuable during specification and acceptance testing. It doesn't automatically establish competence to assess authentication, database permissions or software dependencies.

Separate permission to experiment, connect data, release and change a live application. A person can be trusted with the first without having the other three.

Before granting access, ask the prospective builder to describe the permitted information, the application's intended behavior, examples of wrong results and when they would seek help. Training should include testing and handoff, not just how to produce a working screen.

For operational use, allocate these responsibilities:

Responsibility: Business owner; What the person must be able to answer: Why do we use it, what rules are correct, and what uses are prohibited?
Responsibility: Builder; What the person must be able to answer: What was built, from what inputs and components, and what limitations remain?
Responsibility: Technical maintainer; What the person must be able to answer: How do we diagnose, secure, change and recover it?
Responsibility: Independent reviewer; What the person must be able to answer: What was checked, against what evidence, and what did not pass?
Responsibility: Institutional approver; What the person must be able to answer: What version and use are authorized, with what conditions?

These aren't necessarily five jobs. A small institution might pair a business owner with a contracted technical specialist and an internal approver. Document combined roles and conflicts, but don't let the builder be the sole reviewer or approver for operational use. The business and technical checks need qualified people; another AI model's agreement doesn't supply that accountability.

“Compliance approved it” is incomplete unless everyone understands what compliance assessed. It shouldn't silently mean that someone inspected the code or accepted responsibility for support.

Make the approved route usable. Tell builders where to experiment, how to request review and what evidence to bring. If review capacity is limited, constrain the number of supported applications rather than accumulating releases nobody can maintain.

7. Choose a governed home, and know what it governs

Hosting is a responsibility decision. An institution-controlled cloud account gives the bank control of an account; it doesn't automatically give it a secure, maintained application.

A local utility on a managed device may avoid a public web service, but still needs controlled distribution, data handling and updates. A shared platform application needs configured roles and release controls. A custom cloud application adds ownership of its application stack, dependencies and deployment process unless a qualified provider takes on specified responsibilities. Choose the least complex arrangement that supports the required use, recovery and access, rather than assuming every tool needs a web address.

Trace development and operation separately:

Development: assistant and account → prompts and files → source code or configuration → test environment → release package.

Operation: user → application → data and connected services → logs, support and backups.

Identify suppliers and control owners along both paths. A production database can remain inside an approved environment while a troubleshooting screenshot sends its contents somewhere else.

Low-code changes what you maintain

Low-code and no-code platforms can express an application through forms, tables, formulas, permissions and workflow definitions interpreted by a vendor-maintained runtime. The institution may not have to maintain a separate web server or application framework.

The business logic still executes. A configuration change can select the wrong customers, expose a record or send an incorrect message. Calling it configuration doesn't remove the need to test and control it.

Microsoft, the vendor of Power Platform, calls this application lifecycle management (ALM). Its documentation includes requirements, architecture, testing, maintenance, change management, deployment and governance. It explicitly covers both developers and app makers.⁵

For a platform-native application, a practical lifecycle looks like this:

Define the rules, permitted data and independently expected results.
Configure the application in a dedicated development environment with approved maker roles, data boundaries and connectors. Don't assume a default or broadly shared environment has those controls.
Retain a versioned export or other supported source record.
Promote it to a separate test environment and check logic, roles, connectors and relevant data changes.
Authorize a known release and deploy with the appropriate environment settings and credentials.
Monitor, support and repeat the process for changes.

Power Platform implementation note: Microsoft documents source-controlled development solutions and managed deployment packages.⁶ Its ALM overview specifies Dataverse databases for participating environments.⁵ Check prerequisites, licenses and capacity before choosing that route; packaging alone doesn't establish effective controls.

Divide the responsibilities explicitly

A governed platform can take on infrastructure operations and automate parts of deployment. The institution still decides what the application should do and whether it is fit for use. Confirm what the provider accepts, then assign the rest:

A platform may provide: Managed infrastructure and runtime updates; The institution still needs to establish: Suitability, supplier oversight, continuity and ownership of any custom extensions
A platform may provide: Identity and authorization mechanisms; The institution still needs to establish: Correct roles, sharing, data permissions and access reviews
A platform may provide: Packaging and deployment features; The institution still needs to establish: Environment separation, review, release authority and evidence that controls are enforced
A platform may provide: Formula engines and connectors; The institution still needs to establish: Correct rules, permitted destinations, credentials and exception handling
A platform may provide: Logging, backup and recovery features; The institution still needs to establish: Appropriate coverage, retention, alert response and tested restoration

Verify each capability for the actual configuration. A platform can supply a control that nobody has enabled, or one that doesn't cover a custom connector.

Distinguish native configuration, configuration with custom extensions, and raw code hosted on approved infrastructure. The latter two can retain substantial engineering obligations. A generated web application doesn't become a native low-code solution merely because its hosting account changes.

For the calculator, a supported calculation component with a staff-built interface may be a sensible design. The interface still has to pass the correct units and inputs and display the result accurately. Infrastructure assurance and business correctness meet at that boundary.

Also ask whether a native feature calls AI at runtime. A governed platform can host both conventional applications and AI-enabled ones; its name doesn't answer the third policy question.

8. Test the work, release the version, maintain the result

Testing needs to establish business correctness, security and recoverability. A clean automated scan doesn't prove a formula is right. A domain expert's correct calculation doesn't prove unauthorized users cannot retrieve the underlying records.

Have business and technical reviewers cover the parts they are qualified to assess, with findings tied to the actual release. The FFIEC's development guidance addresses functionality, security, quality management, release controls, documentation and rollback planning together.⁴

Check whether the application is safe to run

Distinguish insecure software from malware. An application may expose information through a coding mistake, an unsafe default or a missing control, without anyone intending harm. Malware is deliberately malicious code. It may enter through a downloaded package, installation script or copied component. These are possible failure paths, not a claim that every AI-generated application contains malware.

Have a qualified technical reviewer examine the actual code or configuration, its components and its deployed settings. Before running untrusted software, use an isolated review environment without production credentials or sensitive records. A test on an employee's normal workstation is not that isolation.

The review should establish:

What data can escape: Check database access, shared links, exports, logs, backups and outbound connections. Use synthetic records to verify that an unauthenticated person or a user in the wrong role cannot retrieve protected information.
What the code can execute: Inspect dependencies, installation scripts and custom components for suspicious behavior, unexpected network destinations and known vulnerabilities. Malware scanning is one check, not proof of safety.
Whether permissions are enforced: Test the application's server or data layer, not just whether a button is hidden. Verify that users cannot bypass their permitted records or actions by changing a request.
Whether secrets and access are controlled: Keep credentials out of browser code and shared files. Verify appropriate authentication, role restrictions, session controls and protection of sensitive data in transit and storage.
Whether the institution can detect and contain misuse: Check security logs, alert ownership, access revocation and the ability to disable an affected connection or function. Identify who will patch the application and its dependencies.

These are practical checks within the security and release controls discussed in the FFIEC development guidance, not an exhaustive security-testing procedure.⁴ Scale the depth to the application's exposure. A secure host does not repair insecure application logic, and a familiar platform does not establish that its controls are configured correctly. Unresolved material security findings should block the affected use, even when business calculations pass.

Use outside security expertise where needed

For an institution without application-security specialists, we recommend commissioning a qualified outside provider to evaluate the application before consequential operational use. An existing IT, managed-security or software vendor may be suitable, but confirm that its people and contract cover application testing, not just network or infrastructure support. If the provider built the application, use a separate qualified reviewer for independent acceptance.

Scope the work to the actual application, its dependencies, hosting configuration, data paths and connections. Security scans help identify known weaknesses; a vulnerability assessment evaluates findings and their significance; penetration testing attempts to exploit weaknesses within an expressly authorized scope. These methods complement each other. A clean automated scan is not a substitute for testing access controls or reviewing business logic. For internet-exposed applications or those handling sensitive information or consequential actions, include a qualified assessment of the need for application-level penetration testing.

Agree the permitted targets, methods, timing and data handling before testing, including any hosting-provider permission. Require a written report tied to the tested version and environment, with coverage, limitations, findings, remediation owners and retest results. Keep untested areas visible. The institution still decides whether the remaining risk is acceptable and funds ongoing support; a vendor's report is evidence for that decision, not a compliance certification or a guarantee of security.

Work from independently expected answers

Take a hypothetical training calculator whose stated rule is simply annual cash available divided by annual debt service. With inputs of $120,000 and $100,000, the expected ratio is 1.20. That arithmetic can be independently checked. It does not establish which income adjustments or debt obligations belong in an institution's actual credit analysis.

Test that definition separately from its implementation. What happens when monthly debt service is supplied to a field expecting an annual amount? How does the tool handle a zero denominator, missing information or a negative value? What precision does it retain before displaying a rounded answer?

For a dashboard, reconcile record counts and totals to the source and inspect exclusions. A refresh failure must not quietly appear as “no exceptions.” For an automated workflow, test an unauthorized user, a repeated submission and an interrupted run. Verify whether retrying creates a duplicate action.

AI can help produce tests, but tests derived from the same mistaken interpretation can repeat the application's error. Establish expected outcomes from an independent business rule, calculation or authoritative source.

Use synthetic data to limit exposure while developing. Make the fixtures realistic enough to include missing values, duplicate records and unexpected formats. If masked real data is needed, assess its disclosure and re-identification risks under the institution's data controls; removing names doesn't necessarily make it safe.

Retain what actually ran

Keep the released source or supported configuration export, dependency information, deployment settings, test evidence and approval record. Prompt history can explain intent, but repeating a prompt isn't a reliable way to recover the exact application previously used.

Suppose the builder asks the assistant to simplify a screen. The resulting change also modifies rounding or permissions. The small size of the request doesn't establish the small size of the change. Review the differences and repeat affected tests before release.

Where the application calls a model, add checks for unsuitable outputs, hostile instructions in supplied content, model/service changes and escalation. Human review should be workable: the reviewer needs source information, time and authority to reject the result.

Practice the Monday-morning problem

The builder is unavailable, the application fails and a deadline is approaching. Who receives the alert? Who can disable the affected route? Can another qualified person locate the release, restore service or carry out the fallback?

Before operational release, have someone other than the builder demonstrate recovery or an agreed fallback against the permitted interruption and data-loss limits for that use. Record the tester, release, date, result and unresolved problems. A runbook nobody else has used is a hypothesis about recovery.

Monitor silent business failures as well as uptime: stale data, unmatched records, unexpected volumes and results that require repeated correction. Budget for patching, changes in business rules, supplier updates and credential replacement. A one-time review is not a maintenance arrangement.

Set review timing according to consequence and change, with reassessment after material events. An owner leaving, a new connection or a runtime AI feature being enabled can matter more than the anniversary of approval.

Restoring yesterday's code doesn't undo yesterday's incorrect outputs. The business owner should document which decisions, records or communications were affected, arrange correction and retain evidence of completion. Assess incident notification duties through existing procedures without waiting for the software fix.

Retirement needs similar care. Move dependent work, preserve required records and evidence, revoke credentials, disconnect integrations and stop unnecessary charges. Check for unofficial copies that could continue operating after the registered version is gone.

9. Put the approach into practice

Begin with the applications people already depend on. We recommend that the CEO designate an accountable executive for this work, specify delegated approval authority and define which exposures reach senior management and the board or its relevant committee. A coordinator can then manage discovery and triage, with a clear route for employees to bring tools forward. The FFIEC's shadow IT guidance supports both technical discovery and training that encourages personnel to notify management.¹

Select one bounded use and work it through from discovery to release. Record the AI-use decision separately from software acceptance, adding runtime AI review where needed. Use the decision sequence below to establish what can proceed and what remains on hold.

Make the approved route visible to staff, including what help is available and what falls outside it. Expand only as review and support capacity permit.

Five questions for leadership

Can we identify the employee-built applications used in real work, and explain the limits of our discovery?
Does each operational application have an accountable business owner and qualified, funded support that has accepted it?
Do we know who controls its accounts, data paths, release permissions and recovery materials?
Can we show why its answers and access controls are acceptable for its authorized use?
Has someone other than the builder demonstrated recovery or fallback, and is someone assigned to correct work affected by wrong outputs?

A “no” identifies work to assign. An “unknown” needs an owner and a resolution date. These answers aren't a compliance score or a substitute for application-specific review.

A decision sequence for an application in front of you

Suspected disclosure, corruption or unauthorized action: contain the affected route, preserve evidence, revoke or rotate exposed secrets, identify outputs already relied on, and invoke incident handling with prompt notification assessment.
Material facts unknown: restrict the uncertain exposure, assign a resolution owner and due date, and investigate before expanding use.
A simpler supported alternative meets the need better: replace or retire the application with a transition plan.
No qualified, funded support for the intended use: don't authorize operational reliance. Keep it isolated, retire it, or secure support. Narrowing use still requires support and controls for that use.
Required controls or acceptance tests fail: remediate or rebuild before approving that use.
Ready for operational use: confirm passed reviews, accepted and funded support, and recovery or fallback demonstrated by a non-builder. The authorized approver records the exact release, permitted use, accountable owners, conditions and review triggers in the institution's release record.

No-go should describe what isn't authorized and what would change that answer. It needn't discard a valuable idea. Equally, accepting residual risk cannot authorize unlawful conduct or override a contractual restriction.

Measure the result by supported work: useful outcomes, errors caught and escaped, review delays, ownerless dependencies and recovery readiness. A rising application count isn't necessarily progress.

The opportunity is to make employee knowledge easier to turn into useful tools. The institution's job is to make those tools dependable enough for the work they are asked to do.

Appendix: decision records

Use these records in the systems your team already maintains. If a ticket or inventory entry already answers a question, link to it rather than fill it out again. Keep the application ID, version and evidence location with each record so it can travel on its own. A and C support triage; they don't authorize use. F records the release decision and links to support, funding and the recovery evidence in G.

Examples continue the hypothetical calculator case. The blank records are reusable; examples describe decisions and evidence to obtain, not approval of a real application. Use “not applicable” only with a reason and an accountable reviewer.