AI governance at Bank of America
Building a better workflow for AI model reviews
What scoping, building, validating, and handing off scorecard automation taught me about technical implementation.
Preparing an AI model review scorecard meant repeatedly finding information and copying it into a PowerPoint template. During my AI governance internship at Bank of America, I built a workflow that populated 44 of its 80 fields from a single model ID.
The project connected SQL, Excel, VBA, and PowerPoint. Its harder questions were about the information moving between them: which fields had a clear source, which required interpretation, and how I could check that the output matched a manually prepared scorecard.
Working through those questions taught me how much of implementation depends on understanding the user’s task, setting a realistic scope, and carrying the solution through to a handoff.
Build around the reviewer’s task
The user was the Quality Assurance team within AI governance. Reviewers gathered model information and supporting evidence, assessed it, and prepared scorecards for the next stage of review. Repeated lookups and manual copying sat between the available data and the format they needed to use.
I focused on connecting those steps. SQL retrieved information for a model ID, Excel mapped the returned values to the relevant fields, and VBA scripts transferred them into PowerPoint. Token mapping linked a value to the place it belonged in the scorecard template.
The output stayed in the scorecard format the team already used. That gave the project a concrete destination: take the reviewer from a model ID to a populated template, with fewer fields to enter manually.
From a model ID to populated scorecard fields
- RetrieveSQL
Use a model ID to retrieve the relevant information.
- MapExcel
Match the returned values to scorecard fields.
- PopulateVBA → PowerPoint
Use token mapping and scripts to fill the template.
- ReviewQA reviewer
Assess the evidence and complete the evaluation.
I also optimized roughly eight SQL scripts used for data retrieval and reporting. Across both efforts, I was working on the path from available information to something a reviewer could use.
Work through ambiguous documentation
I began with fields that translated directly from the database to the scorecard. Similar naming conventions made those mappings relatively straightforward and gave me a starting point for the automation.
Documentation and evidence fields were harder. The same kind of supporting material could be tagged, named, or classified differently. A label alone did not always make it clear which document met a scorecard requirement.
I had to develop a consistent approach to identifying the relevant documentation from the available information. That meant working from what the scorecard required and considering how the documentation had been described, with a cautious approach when the match was unclear.
Three different information problems
| Information source | What it required |
|---|---|
| Direct database fields | Map to the scorecardBegin with values whose corresponding fields are clear. |
| Document names, tags, and classifications | Identify the relevant documentationUse a consistent approach and handle unclear matches cautiously. |
| Values inside documents | Keep outside the delivered automationThese values were unavailable through SQL and needed a separate extraction approach. |
That distinction changed how I understood data mapping. Some fields required a direct transfer. Others required resolving differences in how people described the same kind of information. Treating both as a simple lookup would have hidden the harder part of the work.
Choose a scope I could deliver
The completed workflow automated entry for 44 of 80 fields, or 55% of the scorecard. That measures field coverage; assessment of the information remained with the reviewer.
The remaining fields required information from inside the documents themselves. Those values were unavailable through the SQL database, so extending the workflow meant taking on a different problem: extracting and interpreting document content.
I considered optical character recognition, or OCR, as a possible extension. Access limitations and the time remaining in my internship kept it outside the implemented scope.
Looking back, OCR would have addressed only part of that extension. Extracting text would still leave the work of identifying the relevant passage, mapping it to a scorecard requirement, and checking the result. That broader task would have needed document access and time for its own validation.
The lesson I took forward was to distinguish a useful workflow I could complete and check from an extension that needed more time and access. Defining that boundary was part of delivering the project.
Check the content that reaches the reviewer
I prepared manual scorecard reviews alongside the automated output and compared their contents. That gave me a concrete reference for checking whether the automation was putting the intended information into the scorecard.
While creating the VBA script, I also checked that the token names corresponded to the relevant database fields. These were two connected checks: whether the mapping pointed to the intended source, and whether the populated scorecard matched the manual version.
Check the mapping, then compare the content
Check that the VBA token names correspond to the intended database fields.
Prepare the review manually as a reference for the content.
Compare the populated fields with the manual version.
The comparison focused on the information delivered to the reviewer.
This made validation part of the implementation itself. The user encountered the information in PowerPoint, so I needed to examine the output there as well as the mapping that produced it.
Alongside the automation project, I conducted QA reviews across four AI/ML models and identified gaps requiring model-owner follow-up. That work reinforced the boundary of the tool: assembling information supports the review, while assessing evidence and communicating findings remain distinct responsibilities.
Carry the work through to a handoff
I presented the use case and methodology to the broader AI governance team and handed the workflow to the head of Quality Assurance. Delivery included explaining how the pieces fit together and transferring the work to the team responsible for the review process.
That experience connected the technical and operational sides of the project for me. I had to understand the reviewer’s task, work through inconsistent information, decide what fit within the available time and access, check the output, and explain the approach to other people.
It is the approach I want to carry into product and implementation work: understand the task closely enough to build something useful, make deliberate choices about scope, and give the next person a clear understanding of what the solution does.
These are personal reflections, not statements on behalf of Bank of America. Workflow descriptions are simplified; internal documentation, model details, and specific findings are not reproduced.